[00:43] <bluesabre> Unit193: I finally got around to updating xfce4-systemload-plugin, any other package updates you'd like me to pick up?
[05:04] <jphilips> bluesabre: the changelog link doesn't work in the tweet https://twitter.com/PlanetBluesabre/status/1373499616977694720
[06:52] <jphilips> bluesabre: updated patches for chapters 4 and 5 have been sent
[09:32] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: thunar 4.16.6 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-thunar-4-16-6-released-tp59942.html (by Alexander Schwinn-2)
[09:43] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: thunar 4.17.1 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-thunar-4-17-1-released-tp59943.html (by Alexander Schwinn-2)
[13:11] -SwissBot:#xubuntu-devel- ::xubuntu-default-settings:: Apply translations in nl @ https://github.com/Xubuntu/xubuntu-default-settings/commit/d7f4e0e57b1395d9aafca3c1a391a06ee7191266 (by transifex-integration)
[13:11] -SwissBot:#xubuntu-devel- ::xubuntu-default-settings:: Apply translations in nl @ https://github.com/Xubuntu/xubuntu-default-settings/commit/d0bf66dc26569bd9501540dc9537dc3a27617776 (by transifex-integration)
[16:52] <Unit193> bluesabre: Not that I remember.


[10:07] <sakrecoer> OvenWerks, eylul krytarik: 19:00 UTC works for me on tuesday!
[10:07] <cfhowlett> eh, whot?
[10:25] <eylul> ok I should just email the ML at this point
[10:27] <sakrecoer> sorry cfhowlett... we were planning a IRC meeting for tuesday at 20.00UTC
[10:27] <sakrecoer> but yeah, it should go to the mailing list..
[10:27] <cfhowlett> ahhhhh, lemme put that up on the clock
[10:27] <sakrecoer> also, very nice mail you sent out cfhowlett
[10:27] <sakrecoer> !!!
[10:27] <cfhowlett> thanks, sak
[10:28] <sakrecoer> haven't got arround answering it yet.. sorry about that!
[10:28] <sakrecoer> but since you are here, i think ttoines and eylul's feedback should be taken into account. then feel free to proceed!
[10:28] <sakrecoer> cfhowlett: ^
[10:28] <cfhowlett> indeed!
[10:29] <sakrecoer> eylul and cfhowlett if you haven't already, please share this post: https://www.facebook.com/Ubuntustudio/posts/10154499649330622
[10:29] <eylul> sure
[10:30] <eylul> let me email the group first before I forget now that we know the time works at least for you, as lead.
[10:30] <sakrecoer> :)
[10:45] <eylul> sakrecoer: done


[02:34] <bkerensa> https://bugs.launchpad.net/ubuntu/+source/unity-lens-shopping/+bug/1073114
[02:34] <darthrobot`> Title: [Bug #1073114 “Users privacy not respected - Implementation of E...” : Bugs : “unity-lens-shopping” package : Ubuntu]
[02:34] <bkerensa> apparently shopping lens will not be default
[02:34] <bkerensa> :D
[02:34] <bkerensa> fix coming to Quantal and Raring
[02:45] <pleia2> \o/
[03:04] <bkerensa> pleia2: at least I do not think kees would target it like that unless that was the case and sabdfl made certain to point out the bug to me so I'm assuming :)
[03:05] <pleia2> kees' post last week was pretty convincing
[21:42] <kdub> ah, back on the nvidia blob :) computer's running at normal speed again :P


[01:21] <CNLiberal> so I upgraded my Mythbuntu 9.04 x64 client to 9.10 using the Update Manager.  Now my font on the screen is HUGE.  I know the resolution is correct because the cursor is the correct size, but I can't see all the text in a window because the text is so large.  What happened?  nVidia 9500GT that is recognized by nvidia-settings
[01:29] <CNLiberal> it's like the DPI has been jacked way up
[01:29] <CNLiberal> when I run the MythBuntu 9.10 x64 install CD, the setup wizard is the correct font/dpi, but if it loads to the LiveCD Desktop, the font/DPI is large too
[01:31] <CNLiberal> Display is a 52" 1080p LCD connected to the FrontEnd with an HDMI cable
[01:34] <CNLiberal> Must be Sunday Dinner Time...lol
[02:36] <randyinneed> hi all, I get snow on channels above 12. the setting is for us-cable, though the scan seems to stop at channel 69.
[02:37] <randyinneed> what can I do?
[02:53] <foxbuntu> superm1, mrand I hate you guys right now
[03:01] <superm1> henrik__, whats up?
[03:15] <randyinneed> I should note that I am able to access channels above 12 with mplayer
[04:14] <randyinneed> it appears if I enter the frequency of each channel above 12 it will change properly
[04:41] <randyinneed> But where do I put channels.conf so that myth will see it since scan to import will not let me type
[04:41] <randyinneed> ?
[06:16] <tazz> hi has anyone come across a problem with channel scanning in myth1.22
[06:16] <tazz> the channel autoscan button is grey out
[06:23] <bullfrogger> hi has anyone come across a problem with channel scanning in myth1.22
[06:23] <bullfrogger> the channel autoscan button is grey out
[07:31] <map7_> Can anyone help me get a diskless mythbuntu system working, I'm so close.  I keep getting the error 'Cannot login to database' on the client.
[07:32] <map7_> I can however login to the database from the client through the command line
[07:32] <map7_> I also have one frontend working on a ubuntu disk based client
[10:21] <henrik__> superm1, still here?
[18:12] <CNLiberal> In .22 (9.10 x64 mythbuntu) i'm trying to update my coverart for my movies.  I run the metadata grabber, but the image file doesn't update.  The permissions on the folder are of my user who logs into the frontend.  Is that correct or does it need to by MythTV?
[18:12] <CNLiberal> *need to be MythTV
[18:24] <CNLiberal> nevermind...it appears that i'm having issues with the NFS mount being read onlyh
[18:24] <CNLiberal> *only
[19:18] <CNLiberal> has anyone gotten NFS4 working properly?
[19:32] <superm1> CNLiberal, these days you shouldn't likely need to use it for much of anything (thanks to storage groups)
[19:32] <superm1> but MCC should configure all of your shares for you properly with RW
[19:49]  * KjetilK just sent this request for a Mantis package in Debian, and by extension Ubuntu: http://bugs.debian.org/559915
[19:49] <KjetilK> just in case anybody here is able to do it and has time
[19:49] <KjetilK> it would have been awfully nice to have this before 10.04... :-)
[19:57] <CNLiberal> superm1:  I did need NFS because i don't want to use Storage Groups
[19:57] <CNLiberal> I have ISOs that I need to play
[19:57] <CNLiberal> and I'm LOVING this whole coverart/fanart thing
[19:57] <CNLiberal> it's fantastical
[19:57] <superm1> ah
[19:58] <CNLiberal> having said that, I could probably seperate out my Movies folder from my other videos
[19:58] <CNLiberal> and mount just the movies folder and let storage groups handle the rest
[19:58] <CNLiberal> but that's config for another day
[19:58] <CNLiberal> so has JAMU been updated to process folder names yet?
[19:59] <superm1> dont think yet
[19:59] <CNLiberal> oh well
[19:59] <superm1> its probably not too hard a patch though, and RDV_Linux (the author) is overworked, so i'm sure he'd love a patch .... :)
[19:59] <CNLiberal> i'm just figuring out how I need to re-org my series folders
[20:08] <CNLiberal> i do have a bug i'm seeing though
[20:08] <CNLiberal> i have episodes of the new Battlestar Galactica
[20:08] <CNLiberal> and they are four channel AC3 audio
[20:08] <CNLiberal> when I play through mplayer, the channels are all correct
[20:09] <CNLiberal> but when i play through Myth...the center comes out rear left
[20:09] <CNLiberal> and the other channels are jacked up too
[20:25] <rhpot1991> !iso | CNLiberal
[20:25] <Zinn> CNLiberal: Storage Groups are a streaming method of transmitting material to a frontend, meaning they don't provide block-level access to the file in question. An ISO is a disk image, and requires block-level access. Upstream has a plan to simulate a block device across the network using NBD for 0.23. Until then you can use the following workaround: http://www.baablogic.net/drupal/node/7
[20:26] <CNLiberal> yeah i know it's for .23...i can use this method until then
[20:26] <CNLiberal> i only have one frontend so it's not a huge deal
[20:46] <CNLiberal> so in MythVideo...if i want to manually put in a Video#...where do I get that number?
[20:46] <CNLiberal> from TTVDB?
[20:49] <CNLiberal> i've tried the numbers in the URL for a TV Episode that are different for other episodes of the same show...but i just get an error
[21:35] <infradude> hi, is there anybody can help me about "serial remote controller" ?
[23:48] <prozaconstilts> hello, I'm having trouble getting xine to work w/ LIRC after upgrading to 9.10. mythtv itself and mplayer use lirc with no problem, but xine specifically doesn't do anything. I've tried using --verbose in the command line to see if xine gives any output in the way of setting up lirc input, bu I haven't seen anything. I've also dug about on the google for possible bug reports, but I haven't come across anything. Can anyone help me out?


[00:05] <igc> morning
[00:11]  * fullermd waves at igc.
[00:12] <igc> hi fullermd!
[00:14] <fullermd> igc: I was curious, in this post-2.1 (or almost-so) world, whether content filter stuff was perking up toward the top of people's stacks.
[00:16] <igc> fullermd: I certainly hope to get branch-specific rules into 2.2
[00:16] <igc> fullermd: what did you have in mind in particular?
[00:17] <fullermd> Oh, just my standard low-level antsyness for $Keywords$.
[00:18] <fullermd> The branch-specific rules and that collapsing bug are the only things I know offhand keeping it in "PoC curiosity" rather than "Try it on for real use".
[00:19] <fullermd> (of course, once we hit the latter, THEN we ferret out the other 15,278 things it really needs   ;)
[00:24] <fullermd> (if the answer is "nahgonna'appen this cycle", that's reasonable; just trying to keep up-to-date on my mental sense of where it falls on the List)
[00:25] <Pilky> hey got a bit of an odd theoretical question
[00:26] <fullermd> Pilky: You're in luck!  I've got an odd theoretical answer right on tap!
[00:26] <Pilky> if I have a repo with a few branches in, the revisions are stored in the repo
[00:26] <Peng> In theory, yes. :D
[00:26] <Pilky> and if I remove the branch by using standard file operations the revisions aren't lost
[00:27] <Pilky> so theoretically would it be possible to then reconstruct that branch
[00:27] <fullermd> Basically, yes.
[00:27] <Pilky> cool
[00:27] <fullermd> You lose branch-specific config bits, like the parent/push/etc branches, the nick, yada yada.
[00:28] <fullermd> But all the history revisions are available.
[00:28] <Pilky> those are minor details, it's the code that's important
[00:28] <Pilky> but yeah it just made me think after reading this blog post: http://rentzsch.tumblr.com/post/384353696/time-machine-your-version-control-safety-net
[00:28] <Peng> The "bzr heads" command from bzrtools will help you find them. (Check the help for the proper options.)
[00:29] <Peng> Then, init a branch in the repo, and do "bzr pull . -r revid:foo" with the ID you got from "heads".
[00:30] <fullermd> Yeah.  There may be cases where that config is necessarily and irreplacable, but I have a very hard time even fabricating such a situation.
[00:30] <Peng> Tags will be lost, too, but presumably you can pull most of them from one of your other branches.
[00:31] <fullermd> Oh, yeah, I forgot about that.  That's probably the most likely source of a crippling (or at least maiming) loss.
[00:31] <Peng> Who ever deletes a branch with more than 1 or 2 unique tags, though?
[00:32] <Peng> ...Well, it's uncommon, at least.
[00:32] <Pilky> well, even if you work alone, you should be pushing to a remote server frequently
[00:32] <Peng> Also you have backups, eh, ehh? :D
[00:32] <fullermd> Peng: Well, nobody, BEFORE.  Now that you've said it, 6 people will show up in the next few hours asking how to recover from it.
[00:33] <Pilky> Peng: heh I have local backups of everything, but I have my source remotely
[00:33] <fullermd> Sounds like a good time for me to leave, and let YOU field them   :p
[00:34] <Peng> fullermd: Nah, I have stuff to do. (Or at least I'll find something!) Let's foist them on Pilky, he brought it up. :D
[00:34] <Pilky> lol
[00:34] <Pilky> I didn't mention tags!
[00:34] <Pilky> you did!
[00:34] <Peng> Oh damn.
[00:34] <fullermd> You just did!
[00:35] <Peng> Anyway, I really do have a little bit of stuff I need to do. See you soon! Probably!
[00:35] <Pilky> heh as do i, that little bit of stuff being sleep
[00:35] <Pilky> thanks for the answer!
[00:58] <Peng> Sleep? I have a _lot_ of that I need to do, but I'm not going to. :P
[01:01] <fullermd> Sl...  eep?  I believe I've heard of this concept.  I thought it was a myth.
[01:02] <Peng> It's a huge waste of time. I'm working on avoiding it.
[01:02] <Peng> I keep seeing Oprah Winfrey in my wall, and I can't really do math anymore, but overall I think it's going well!
[01:04] <fullermd> Hm.  Do you think those two items are related?
[01:04] <fullermd> ...  actually, I'm not even sure which two items I'm asking about, and every permutation I can think of is more interesting than the last.
[01:05] <fullermd> So maybe we're on the same page!
[01:05] <bignose> I have a pending merge, and also some other changes that I want
[01:05] <Peng> Oprah would like some changes, too.
[01:05] <Peng> She thinks my hair sucks. :(
[01:05] <bignose> is the right way to proceed to ‘bzr shelve --all ; bzr commit --message "Merged" ; bzr unshelve --all’? or is there a better way?
[01:05] <Peng> Wait, what are you trying to do?
[01:06] <Peng> You want to commit a merge without some of the changes that exist in the working tree?
[01:06] <bignose> yes.
[01:07] <bignose> I got the merge because I tried to commit my changes, but it failed because the repository was not up-to-date in this bound branch
[01:07] <Peng> Oooooh, bound branches.
[01:07] <bignose> so, I updated, and ended up with a pending merge
[01:07] <Peng> I was wondering how you got into that situation.
[01:08] <Peng> Sorry, but I don't know the right way to get out of this situation..
[01:08] <fullermd> First, you remove commit --local...
[01:08] <Peng> Then you remove bound branches completely? >.>
[01:09] <bignose> well, it seems that shelve gets me through it. (done now.)
[01:09] <bignose> but I'm wondering if there's a less fiddly way.
[01:09] <fullermd> In a way, you're a bit screwed.  You can do OK with local commits, and you can do OK with uncommitted changes, but both at once is Bad Juju.
[01:09] <bignose> I've done no local commits.
[01:10] <bignose> (on this branch)
[01:10] <fullermd> And that shelve won't really _solve_ it.  It'll make a pretty sizable mess in history, since you're committing a merge in which you undo all the changes, and then another commit where you redo all of them.
[01:10] <fullermd> If you didn't, you wouldn't get a pending merge from an update.
[01:11] <maxb> By the same logic that 'bzr merge' will require --force if there are modifications, presumably the same ought to apply to 'bzr update' in a bound branch scenario
[01:12] <bob2> even if you have no local commits, bzr up can still cause lots of annoying conflicts
[01:12] <bob2> (and trash your local changes)
[01:12] <fullermd> Yes, but only of one set of changes.  With local commits, and uncommitted changes, you're in the same position as local changes + merge --force; you've got two things inextricably intermingled.
[01:12] <bob2> it is true
[01:13] <bob2> real unbound branches ftw
[01:13] <fullermd> Well, I don't much care about bound branches, but you can have my heavy checkouts when you pry them from my cold dead hands   :p
[01:14]  * bignose doesn't understand the difference between “heavy checkout” versus “bound branch”
[01:14] <bignose> also, I don'
[01:14] <bignose> also, I don't see what mess is created in history
[01:14] <bob2> haha
[01:14] <mkanat> bignose: The difference is just a configuration variable.
[01:15] <bignose> hmm. what I see in history is that the merge made a change, and the same change is then part of the local changes I've committed after the merge.
[01:15] <bignose> weird.
[01:15] <fullermd> Well, the difference is conceptual, and doesn't formally exist in bzr-today.
[01:16] <lifeless> fullermd: some people dispute that it exists
[01:17] <fullermd> Yes, but their mothers were hamsters, and their fathers smelt of elderberries.
[01:17] <bignose> fullermd: is there anyone else here I can talk to?
[01:18] <fullermd> No!  Now, go away, or I shall confuse you a second time!
[01:18] <bignose> heh
[01:18] <lifeless> bignose: whats the question ?
[01:21] <bignose> lifeless: about 40-50 lines back in this channel
[01:22] <bignose> lifeless: simply, is there a less-fiddly way to resolve local uncommitted changes combined with a pending merge from the remote repository?
[01:23] <lifeless> bignose: just commit
[01:24] <lifeless> bignose: bzr will know what was from the merge and what was your changes
[01:24] <lifeless> because you've done an 'update' right? - bzr should have done a pivot for you
[01:25] <bignose> what's a pivot?
[01:26] <bignose> the problem I encountered was that I want to do partial commits
[01:26] <bignose> but Bazaar won't allow that while I have a pending merge.
[01:27] <bignose> (to answer the question: yes, I did ‘bzr update’, which is where the pending merge came from.)
[01:28] <lifeless> ok, then you should shelve the stuff you aren't ready to commit, and then commit.
[01:28] <bignose> right. that worked. is there a less-fiddly way? say, to get just the merge committed?
[01:28] <bignose> or, ideally, to get the update done without resulting in a pending merge?
[01:29] <lifeless> so the update only adds a pending merge if you have done disconnected commits
[01:30] <lifeless> so one way is 'do not do disconnected commits'
[01:30] <bignose> never happened on this branch.
[01:30] <bignose> (or did it? can I tell?)
[01:30] <lifeless> someone uncommitted then on trunk
[01:30] <lifeless> either an uncommit, push --overwrite, or you did a 'local' or 'offline' commit
[01:31] <bignose> can that be detected after the repository is synchronised?
[01:33] <lifeless> not really; log -n0 may give a hint
[01:33] <fullermd> Mechanically?  Not really.  But by looking at the revision in the log, you can probably figure it out.
[01:34] <bignose> thanks for the help
[02:49] <lamalex> Hi, can someone help me figure out why one of my co-developers is getting this error when he pushes to what (should be) a shared branch? bzr: ERROR: Cannot lock LockDir(chroot-24202192:///var/trac/c4398s10_2/repo/trunk/.bzr/branch/lock): Permission denied: "/var/trac/c4398s10_2/repo/trunk/.bzr/branch/lock/5ffyoe3oy1.tmp": [Errno 13] Permission denied: '/var/trac/c4398s10_2/repo/trunk/.bzr/branch/lock/5ffyoe3oy1.tmp'
[02:50] <lamalex> what should permissions be to prevent this from happening
[02:52] <fullermd> He needs to be able to write into that dir.
[02:52] <fullermd> (and some others under .bzr; probably simplest to be able to write to _everything_ under .bzr)
[02:55] <spiv> lamalex: as fullermd says; they need filesystem write permissions.  You may want to have a 'bzrrepo' group that owns all files/directories in that repo to help with that.
[02:55] <bignose> lamalex: My understanding is that (like most DVCS) Bazaar works on the assumption that there is a single owner of each repository.
[02:55] <spiv> bignose: not really
[02:56] <bignose> so, for a repository to be shared with multiple users, there should be a single account that owns the repository; and some mediator to allow other users to act as that user.
[02:56] <lamalex> spiv: so if I chgrp -R the repo, we should be ok?
[02:56] <spiv> Bazaar is perfectly happy for multiple users to be able to write to the repo, but you do need to arrange the filesystem permissions to allow that, which probably means a common group and maybe also setting a sticky bit on the group perms so new directories are owned by that shared group.
[02:56] <fullermd> lamalex: On a filesystem with SysV semantics, you'll need g+s on the directories as well.
[02:56] <bignose> e.g. the Bazaar server; or the PQM; or an account used via SSH public key.
[02:57] <lamalex> fullermd: merci
[02:57] <lamalex> bignose: that's definitely not true at all
[02:57] <lamalex> that's not even how launchpad works
[02:57] <fullermd> Launchpad works by using FM technology.
[02:58] <spiv> fullermd: fairy munchkins?
[02:58] <lamalex> :)
[02:58] <fullermd> F.....lippin' Magic.
[02:58] <Buginator> Is there a good bzr GUI client for SnowLeopard ?
[03:00] <fullermd> You can't set a snow leopard loose in a bazaar.  It would be chaos.
[03:01] <fullermd> Buginator: Explorer and/or qbzr are the general answers on most platforms.  AFAIK they work on OS X, though I don't know how hard they are to get installed.
[03:03] <Buginator> ok, thanks
[03:06] <bignose> lamalex: there's quite a lot of infrastructure difference between “multi-user repository” versus “Launchpad”
[03:09] <spiv> Need coffee.
[03:15] <slestak> hey guys.  i was just tinkering with bzr before trying to use it for real, and I would liek to start my repo over from nil
[03:15] <slestak> ive googled and looed at the docs but I do not see how to do this
[03:16] <slestak> for instance, i had my eol settings in a state i do not want them longterm, so I think I have crlf stored in the repo.
[03:18] <fullermd> Well, the general means of starting from scratch involves "rm -rf" and...  well...   starting from scratch.
[03:19] <slestak> i think that will just remove the branch,
[03:20] <slestak> i may have not even doen an init-repo, I may have just init'd a single dir
[03:21] <slestak> how can one tell the difference between a repo that holds branches and a dir in your projects folder that is just a branch of a remote project you were hacking on?
[03:21] <fullermd> info will tell you.
[03:22] <fullermd> But if you have a repo separate from the branch, that just means "rm -rf" * 2   :>
[03:22] <slestak> i use several workstaitons and I have not reconciled where my repos will live
[03:23] <meoblast001> hi
[03:23] <slestak> ok, bzr info list root as being . which is good.  And a push branch as my fileserver at home.
[03:23] <meoblast001> is there any way to read Bazaar commits from PHP?
[03:24] <slestak> let me look at bzr help info, thx for assist
[03:25] <spiv> meoblast001: not that I know of, the format is pretty complex so it would take a fair bit of effort to write the PHP to decode it.
[03:25] <meoblast001> maybe this is more of a PHP question
[03:26] <lifeless> system('bzr info')
[03:26] <meoblast001> ok
[03:26] <lifeless> ?
[03:26] <lifeless> :)
[03:26] <poolie> meoblast001: i'd probably run 'bzr log' in a subprocess with popen
[03:26] <poolie> and parse that
[03:27] <meoblast001> ok
[03:28] <poolie> lifeless: rereview https://code.edge.launchpad.net/~mbp/bzr/368931-rename-case-2.0/+merge/19079/+request-review pls?
[03:29] <slestak> if I have a project that is a proof of concept, but could grow large in the future, is it commonr to refactor branches from one repo to another?
[03:30] <slestak> duh, merge.  sorry for elementary questions
[03:30] <lifeless> slestak: repos don't matter for workflow: all the affect is performance.
[03:31] <slestak> lifeless: ive been really in analysis paralysis about project dir setup.  i have a mix of personal and work machines and projects.  I work on all of them on all the machines
[03:31] <lifeless> slestak: thats fine, just do it
[03:32] <lifeless> once you know how you're using it you can decide how to tune it
[03:32] <meoblast001> spiv: http://m.mysticgalaxies.com:8080/host/meoblast001/software/dontwant/bzr.php
[03:32] <meoblast001> that's the only problem :P
[03:32] <lifeless> poolie: + if tests.CaseInsCasePresFilenameFeature.available():
[03:33] <lifeless> won't work too well
[03:33] <poolie> why?
[03:33] <spiv> meoblast001: well, a <pre> tag and HTML-escaping will help a lot :)
[03:33] <meoblast001> ah, probably
[03:33] <lifeless> poolie: its already in tests :)
[03:33] <lifeless> poolie: # new coding style is for feature instances to be lowercase
[03:33] <lifeless> dunno if I'd bother with the comment
[03:33] <spiv> meoblast001: also, I think there's an xmloutput plugin
[03:34] <poolie> you can import a module from within itself
[03:34] <poolie> but it's a bit messy
[03:34] <spiv> meoblast001: so that you could do "bzr log --xml", which might be more convenient (or maybe not)
[03:34] <lifeless> oh I see you have. I wish colourisation upon these diffs
[03:35] <spiv> meoblast001: https://launchpad.net/bzr-xmloutput
[03:35] <lifeless> poolie: anyhow, I'd use the global name space rather than importing inside the feature. other than that , JFDI
[03:35] <poolie> i did that
[03:36] <poolie> just now.  i previously put it in features but then decided it was better next to its buddies
[03:36] <lifeless> then +1
[03:36] <poolie> tell me, do you think my comment in make_canonical_tree is correct?
[03:37] <poolie> if i change it to use _convert_tree i do get some failures
[03:37] <lifeless> this isn't actually guaranteed to return the class ?
[03:37] <poolie> it seems to be returning a workingtree
[03:37] <poolie> whereas this class also wants to test some revisiontrees
[03:38] <lifeless> so per_tree is a bit stubby
[03:38] <lifeless> but the intent of it is definitely to test more than working tree
[03:39] <lifeless>  Ihaven't seen make_canonical_tree before, I'd guess someone adding a helper that is either meant to be _convert_tree'd, or that wasn't really following the intent.
[03:40] <meoblast001> thanks spiv
[03:57]  * igc lunch
[03:58] <lifeless> where?
[03:58]  * lifeless WANTS
[04:03] <fullermd> Maybe he was suggesting himself AS lunch...
[04:05] <idnar> launch
[04:05] <idnar> lunchpad?
[04:05]  * fullermd . o O ( bzr pull lp:BLTandFries )
[04:35] <dOxxx> greetings
[05:23] <spiv> fullermd: hmm, have you signed the contributors agreement?  I have a feeling that you probably have, but don't see your name in the LP team.
[05:42] <dOxxx> good night all
[05:53] <lifeless> fullermd: thats cruel man... oh I could so eat that
[07:44] <igc> night all
[09:06] <gerard_> aahh
[09:07] <gerard_> admin!
[09:08] <lifeless> jelmer: ping
[09:09] <lifeless> jelmer: I'd like to ask a small favour: update the bzr-search packaging :)
[09:11] <lifeless> someone remind me to unban him tomorrow
[09:14] <gerard_> lifeless: thx
[09:19] <jml> hello
[09:19] <jml> if I want to stop receiving emails about bzr merge proposals, I have to leave ~bzr-core, right?
[10:00] <lifeless> jml: I dunno
[10:00] <lifeless> jml: perhaps you coul subscribe to the relevant branch directly and say 'dont mail me' in that subscription
[10:00] <lifeless> jelmer: ping
[10:02] <jml> lifeless, there's a thought. I'll try that.
[10:09] <lifeless> jml: ping
[10:10] <lifeless> meh
[10:10] <lifeless> jelmer: ping
[10:33] <tonfa> gug
[10:33] <tonfa> can anybody point me to the details of the protocol used by bzr to discover remote changes?
[10:41] <jpds> tonfa: I think it uses Avahi.
[10:42] <ronny> jpds: he means the dag differnce finder, not location discovery
[10:43] <ronny> lifeless: is there any spec on/doc on what exactly smart-server does?
[11:05] <spiv> ronny: not really
[11:05] <spiv> ronny: there's some basic stuff in network-protocol.txt in the developer docs
[11:06] <spiv> ronny: but that's more about the basic RPC serialisation than what the RPCs do and how to use them
[11:06] <tonfa> spiv: ok
[11:07] <spiv> ronny: the individual RPCs are implemented in bzrlib/smart/*.py, and mostly have terse docstrings explaining what they do, e.g. http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.smart.repository.SmartServerRepositoryGetParentMap.html#do_repository_request
[11:07] <spiv> tonfa: oops, I should have been addressing you :)
[11:08] <spiv> tonfa: I'd be quite happy to answer questions here (if I'm around, probably not for much longer tonight) or on the mailing list
[11:08] <tonfa> I see
[11:09] <spiv> tonfa: the RPC API assumes a fair bit of familiarity with bzrlib, really.  e.g. the Repository.get_parent_map RPC essentially works the way bzrlib.Repository.get_parent_map does.
[11:09] <spiv> tonfa: the complete list of methods can be seen in the source in bzrlib/smart/request.py
[11:10] <spiv> tonfa: I'd very much like to improve the protocol docs, but there hasn't been much motivation to so far
[11:10] <LeoNerd> I think I broke my bzr-svn cache :/
[11:10] <LeoNerd> bzr: ERROR: exceptions.KeyError: 'No such TDB entry'
[11:10] <spiv> tonfa: if you'd like to provide that motivation, great :)
[11:10] <spiv> LeoNerd: whee!
[11:11] <LeoNerd> I ctrl-C'ed it once because I ran "bzr st" instead of "svn st" by mistake, and didnt' want it to spend 5 minutes now pulling new revs... ever since then it's been broken
[11:11] <spiv> tonfa: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head%3A/bzrlib/smart/request.py#L489 is where the RPC registrations start
[11:11] <tonfa> spiv: btw we plan on adding early error returns for http in hg
[11:12] <spiv> tonfa: what do you mean by "early returns"?
[11:12] <spiv> You're talking about something to do with the finding the differences in the remote graph?
[11:13] <tonfa> spiv: errors happening while streaming data,
[11:13] <spiv> Oh, right.
[11:13] <tonfa> there's a discussion about that at http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head:/doc/developers/network-protocol.txt
[11:13] <spiv> Yeah.
[11:13] <tonfa> so maybe if it works well for us you can do it too :)
[11:14] <spiv> The current bzr protocol allows that, I can't remember if the HTTP medium handles it appropriately or not.
[11:14] <spiv> Mid-stream failures are actually a fairly rare occurence for us!
[11:15] <tonfa> for us too, it's just that we then don't show a meaningful error to the user
[11:16] <spiv> Yeah.  And they are usually "interesting" errors that you'd rather have some hint about :)
[11:16] <tonfa> yes, instead of asking the user to launch wireshark
[11:16] <tonfa> or looking at the server logs
[11:16] <tonfa> which isn't always possible
[11:17] <tonfa> spiv: how do you clone the bzr repo in one line? (ie what's the url)
[11:17] <tonfa> it will be easier to browse the code if I have it locally
[11:18] <tonfa> bzr clone lp:bzr seems to work
[11:21] <spiv> tonfa: in bzr, you clone branches, not repos (a confusing terminology difference vs. hg)
[11:22] <spiv> tonfa: the canonical form is 'bzr branch URL', but 'get' and 'clone' are aliases of 'branch'.
[11:23] <tonfa> ok, so I still didn't do anything wrong :)
[11:23] <spiv> tonfa: so, that command is fine.  Note that Launchpad doesn't yet provide the smart server over HTTP, so you'll need to run provide an SSH key to Launchpad and use 'bzr lp-login' to make lp:bzr fully efficient :)
[11:23] <tonfa> I see
[11:24] <spiv> tonfa: oh,
[11:25] <spiv> tonfa: if you add -Dhpss to your command line (or debug_flags = hpss to your ~/.bazaar/bazaar.conf), then your ~/.bzr.log will show much of the smart protocol conversation
[11:25] <spiv> "hpss" stands for "high-performance smart server", our original jargon for this feature
[11:26] <spiv> Which will certainly give you a much more helpful picture than wireshark :)
[11:28] <tonfa> indeed
[11:38] <lifeless> we'
[11:39] <lifeless> re nuking clone and get for branches I believe
[11:42] <fullermd> lifeless: Well, so setup a munch proposal on lunchpad   :p
[11:43] <fullermd> spiv: This iteration, I don't think so.  Seems I went through whatever we had before it.
[11:44] <tonfa> spiv: looks like search_missing_revision_ids() was what I wanted
[11:48] <spiv> tonfa: yeah (although different operations use different codepaths sometimes, sometimes for good reasons sometimes not... :/ )
[11:49] <spiv> tonfa: we have some plans to make some relatively cheap improvements to search_missing_revision_ids, but we haven't gotten around to implementing them yet
[11:49] <spiv> tonfa: I'd be happy to compare notes with what you do in hg :)
[11:50] <spiv> But not tonight, it's getting late here.
[11:52] <fullermd> Is the fallout from the last round of contributor agreement stuff expected to arrive soon?
[11:53] <tonfa> spiv: ok, night'
[11:57] <spiv> fullermd: not sure, poolie is the one that would know
[11:58] <fullermd> Mmp.  Well, I'd guess you'd know if it were expected in the next few days...
[12:06] <spiv> fullermd: me?  Not likely, I'm essentially working part-time atm due to a newborn
[12:06] <fullermd> Oh, I thought you were older than that   :)
[12:07] <fullermd> Damn child labor laws...
[12:07] <spiv> fullermd: and I'd be superfluous to that discussion anyway, poolie understands all the requirements
[12:08]  * spiv submits a merge proposal and goes to bed
[12:08] <fullermd> Well, I was just thinking if it were about to show up, I'd hold off for it instead of sending in the current one.
[12:09] <fullermd> Owell.
[12:12] <spiv> fullermd: yeah, I understand.  Unfortunately I really have no insight to offer :)
[12:14] <fullermd> Hm.  irc.ubuntu.com is a CNAME for freenode, but isn't it still a little weird listing it in README?
[12:17] <fullermd> spiv: 'k, sent.
[13:11] <rubbs> morning all!
[14:30] <quicksilver> can two completely unrelated projects live in the same shared repo?
[14:30] <beuno> quicksilver, yes
[14:30] <beuno> they just won't share revisions
[14:31] <quicksilver> good.
[14:31] <quicksilver> Can I somehow make bzr push push stuff up as g+w ?
[14:31] <quicksilver> my umask on that machine is actually 002
[14:32] <quicksilver> but newly pushed branches still go up as g-w
[14:32] <quicksilver> (using bzr+ssh, that is)
[14:36] <quicksilver> I remember some discussion years about about sftp ignoring umask
[14:36] <quicksilver> but that was considered to be a shortcoming of sftp
[14:37] <quicksilver> and I thought one of the good things about bzr+ssh was going to be fixing it.
[14:37] <mzz> hmm! I haven't actually done this recently, but are you sure the shell startup script that sets your umask actually gets run if you use bzr+ssh?
[14:37] <mzz> (I'd try putting a "touch /tmp/this-is-reached" in whatever script this is)
[14:38] <mzz> I don't know if bzr+ssh sets umask itself
[14:38] <mzz> but if whatever's setting your umask to 002 isn't reached that'd obviously cause this :)
[14:45] <quicksilver> that's true enough.
[14:45] <quicksilver> No, I'm not sure.
[14:49] <fullermd> quicksilver: bzr preserves the +/-w based on the permissions of the directory.
[14:49] <fullermd> sftp doesn't ignore umask; the problem there is that it refuses to set the set[ug]id bits.
[14:50] <quicksilver> fullermd: but the enclosing directory is drwxrwsr-x
[14:51] <quicksilver> fullermd: and new branches are getting pushed up as drwxr-sr-x
[14:51] <fullermd> There's some uncertainty as to which directory it bases on.  It might be .bzr itself, or .bzr/repository, rather than the packs/ directory.
[14:51] <quicksilver> setgid is being preserved, but not g+w
[14:51] <fullermd> Oh, new branches.  Yes, bzr doesn't itself muck with perms on those.
[14:51] <quicksilver> right, new branches.
[14:52] <quicksilver> although perhaps your implication is that if we switch this to a shared repo, which we are about to do anyway, this problem will go away?
[14:52] <fullermd> Probably an issue with which [parts of] rc files the shell reads in interactive vs. batch environments.
[14:52] <fullermd> No, the packs for the revs would get the right perms, but the branch files themselves will still wind up umask-based.
[16:35] <LeoNerd> Is there a way to alter the number of lines of context 'bzr shelve' uses? I have two unrelated changes in one file that are just close enough that they come out as one diff chunk... I'd like it to be two
[16:39] <Meths> I imagine the solution would be to shelve one change, then make the second and shelve that but I may be corrected.
[16:41] <fullermd> If you were thinking it before the fact, you wouldn't need shelve at all  ;p
[16:41] <fullermd> AFAIK there's no way to split patch hunks in shelve.  There's some 'edit'-ish functionality, but I don't know how easy it would be to fake up what you want.
[16:42] <LeoNerd> It's not that I want to split it, as such
[16:42] <LeoNerd> If you use  bzr diff --diff-options="-c 1"  then they're split OK
[18:42] <poolie> fullermd: re contributor agreement updates; i do expect it soon but it's unpredictable
[18:43] <mtaylor> NEAT!
[18:43] <mtaylor> bzr: ERROR: syntax error: line 1, column 0
[18:58] <nosklo> can't use a proxy, how do I get meaningful error message?
[19:10] <nosklo> lost connection, somebody answered?
[19:10] <rubbs> no
[19:10] <rubbs> what is your question again? I'm not quite understanding it
[19:14] <nosklo> I'm trying to use a proxy
[19:14] <nosklo> so I can branch some code
[19:14] <nosklo> But when trying to do so, bzr returns a cryptic error which I can't make sense of
[19:15] <rubbs> can you post the error on pastebin?
[19:15] <rubbs> !pastebin
[19:15] <rubbs> I can't stay long (I have a meeting) but someone here can usually help if they can see the full error.
[19:16] <nosklo> rubbs: http://paste.ubuntu.com/374922/
[19:17] <nosklo> I don't know exactly *what* is not known
[19:17] <nosklo> wget downloads fine
[19:17] <nosklo> also using bzr alternatives like git and mercurial works
[19:17] <rubbs> hmmm
[19:17] <nosklo> I've tried to setup some proxy
[19:17] <nosklo> in the bzr config files
[19:18] <nosklo> but the bzr docs are hard to find
[19:18] <nosklo> I can't find any mention of how you configure the proxy
[19:18] <nosklo> so I'm doing guesswork
[19:18] <rubbs> not sure how to help :(
[19:18] <rubbs> any dev's in the house now?
[19:20] <rubbs> oh... before I go, have you checked .bzr.log? it's usually in your home directory, or my documents if on windows.
[19:20] <rubbs> that might give you more info, it can help others on here too.
[19:20] <nosklo> oh
[19:20] <nosklo> COOL
[19:20] <rubbs> but I have to go. I'll be back in an hour or so.
[19:20] <luks> it would be easier to use plain http url
[19:21] <luks> I think the lp: directory service does some non-http API calls
[19:21] <nosklo> luks: I've tried that and got a different error
[19:22] <nosklo> luks: http://paste.ubuntu.com/374927/
[19:22] <luks> http://bazaar.launchpad.net/~washort/ecru/trunk is the right url to use
[19:23] <nosklo> same thing :(
[19:23] <nosklo> http://paste.ubuntu.com/374930/
[19:23] <luks> not code
[19:23] <luks> bazaar
[19:23] <luks> bazaar.launchpad.net
[19:23] <nosklo> oh
[19:23] <nosklo> that works!
[19:24] <nosklo> luks: thanks
[19:24] <luks> code.launchpad.net is the launchpad website
[19:24] <luks> and it seems to force you to use https
[19:24] <luks> which you can't do over a http proxy
[19:24] <nosklo> https should work on my proxy
[19:24]  * nosklo tests
[19:25] <nosklo> yeah, wget can use https just fine
[19:26] <nosklo> wget https://code.launchpad.net/ecru # works
[19:26] <luks> no idea then
[19:27] <luks> I prefer to use direct http/bzr+ssh URLs for launchpad to avoid problems like this
[19:27] <nosklo> the error on .bzr.log is InvalidHttpResponse: Invalid http response for https://code.launchpad.net/%7Ewashort/ecru/trunk/.bzr/branch-format: Unable to handle http code 502: Proxy Error ( The parameter is incorrect.  )
[19:28] <nosklo> however wget https://code.launchpad.net/%7Ewashort/ecru/trunk/.bzr/branch-format works
[19:28] <nosklo> returns a file with "Bazaar-NG meta directory, format 1" in it
[19:28] <luks> I don't know how http/https proxies work
[19:29] <luks> but maybe bzr is doing something stupid like using http to talk to a https server
[19:29] <nosklo> unfortunately I'm forced on this proxy in my company
[19:30] <luks> do you have the https_proxy environment variable set?
[19:30] <nosklo> yes
[19:31] <nosklo> that's how wget works btw
[19:31] <nosklo> if I remove the var, wget stops working
[19:31] <luks> ah
[19:31] <luks> (as I said, I don't know much about proxies, so just guessing)
[19:32] <nosklo> me neither, but I'm trying to debug bzr anyway :) I'm trying to read the source code and reproduce the error on python
[19:32] <nosklo> so I can ask on #python instead :)
[19:32] <luks> jam might help :)
[19:33] <jam> hi luks
[19:33] <luks> hey
[19:33] <poolie> hi jam, luks
[19:33] <nosklo> jam: I'm having some issue when using a https proxy with bzr, can you help me debug?
[19:33] <jam> hey poolie, nice to see you so early again :)
[19:40] <nosklo> Hm I think I figured out
[19:40] <nosklo> reading the logs of the proxy server
[19:40] <nosklo> bzr is sending some unprintable bytes instead of CONNECT
[19:41] <nosklo> I think it is trying to talk SSL to the proxy (it's a http proxy that can handle https)
[19:41] <nosklo> wget sends a CONNECT 443 first
[19:41] <jam> nosklo: we have you provide the format
[19:41] <jam> so https_proxy=http://proxy.com:PORT
[19:41] <jam> etcc
[19:41] <jam> etc
[19:41] <nosklo> I did it
[19:44] <jam> nosklo: you can also try running "bzr -Dhttp COMMAND" which should add some debugging information to ~/.bzr.log
[19:44] <jam> which might help figure out when we are trying to connect, and how
[19:45] <jam> also, what version of bzr?
[19:45] <nosklo> I'm gathering the info...
[19:45] <nosklo> 1.13.1-1
[19:51] <nosklo> http://paste.pocoo.org/show/177244/
[19:54] <jam> well if you can, I would recommend upgrading to at least 2.0
[19:54] <jam> I think we've had some recent work done on the proxy support
[19:54] <jam> you can get it from our ppa
[19:55] <nosklo> I will upgrade.
[19:55] <jam> https://edge.launchpad.net/~bzr/+archive/ppa?field.series_filter=hardy
[19:56] <nosklo> I'm on jaunty :)
[19:56] <nosklo> but okay
[19:56] <jam> I would have thought jaunty had newer than 1.13...
[19:56] <jam> but sure
[19:56] <jam> same archive has hardy => lucid
[20:03] <KhaZ> Hello: I'm having an issue pushing to a remote repository - it says they're not compatible due to rich root support.  How can I fix this?
[20:04] <KhaZ> Ah; nevermind.  bzr upgrade worked, on a hunch.
[22:13] <jelmer> poolie, hi
[22:15] <poolie> hi jelmer
[22:21] <jelmer> poolie: Should I request a sync of 2.1rc2 to lucid yet or would you prefer to wait until 2.1 itself is out?
[22:23] <poolie> i agree with james_w, we should sync now
[22:24] <jelmer> ok
[22:24] <james_w> jelmer: I can pull the trigger if it's just bzr
[22:24] <james_w> or if you tell me what else
[22:24] <poolie> you'll probably need some plugins too
[22:25] <jelmer> james_w: all of the bzr world basically :-)
[22:25] <fullermd> What's happening with 2.1 anyway?  I thought it was to be released yesterday or today...
[22:25] <james_w> just a list of source packages will do then
[22:26] <james_w> saves you filing all the bugs
[22:26] <poolie> it will be soon, i think jam was busy with somethig else
[22:27] <jam> poolie, james_w: Yeah it was supposed to be yesterday or today, but today I got caught up with $OTHER
[22:28] <fullermd> Ah, 'k.
[22:30] <jelmer> james_w: oh, it actually seems like most things are already synced
[22:30] <jelmer> (looking at http://qa.ubuntuwire.com/mdt/bazaar.html)
[22:31] <james_w> ah, I'd forgotten about that page
[22:31] <jelmer> james_w: can you just sync bzr from experimental?
[22:33] <james_w> there's no bzrtools release to go with it>
[22:33] <poolie> i think there is?
[22:33] <fullermd> There's a 2.1.0 out.
[22:34] <poolie> at least upstream, announced 5 feb
[22:36] <james_w> jelmer: do we not want that first?
[22:37] <jelmer> james_w: hmm, that's a good point. I guess I'm not running the packaged version on my debian box, otherwise I would've noticed
[22:37] <jelmer> I'll upload a newer version of bzrtools to experimental as well.
[22:37] <james_w> thanks
[22:37] <james_w> any chance of a bzr-builddeb upload as well?
[22:38] <jelmer> sure
[22:39] <jelmer> I think the changelog entry needs some work though..
[22:40] <james_w> I'm writing it now :-)
[22:47] <lifeless> jelmer: hi
[22:47] <lifeless> jelmer: bzr-search :) please pretty please please.
[22:47] <jelmer> lifeless, hey
[22:47] <jelmer> lifeless, can you explain what you would like me to do to it exactly?
[22:47] <jelmer> :-)
[22:47] <lifeless> package a newer snapshot of trunk
[22:47] <lifeless> the ~70 snapshot that is packaged is broken with CHK repos
[22:48] <lifeless> its fixed in trunk, and we're getting lots of bugs from packaged-bzr-search users.
[22:48] <jelmer> lifeless: revno 77 is the latest version packaged
[22:49] <jelmer> at least according to my debian qa page
[22:49] <lifeless> interesting
[22:49] <lifeless> oh, I see - karmic.
[22:49] <lifeless> So I think what I mean is 'sob, karmic is bust'
[22:50] <lifeless> we could look at an SRU I guess
[22:53] <james_w> jelmer: lp:bzr-builddeb should be ok for an upload now
[22:53] <jelmer> james_w: thanks
[22:53] <jelmer> lifeless: ouch :-/
[22:54] <jelmer> james_w: wow, that's a lot of bugs that are fix released now :-)
[22:55] <lifeless> bzr-search | 1.7.0~bzr70-1 | karmic/universe | source, all
[22:55] <james_w> some have been fixed for ages, it's just not clear exactly what constitutes a release
[22:56] <jelmer> james_w:   * Upload to lucid.
[22:56] <jelmer> that's not quite true :-)
[22:57] <james_w> oh yeah :-)
[22:57] <james_w> + (indirectly)
[23:36] <jelmer> james_w: the removal of the dependency on bzrtools isn't mentioned in changelog, did it make it into 2.3?
[23:43] <jelmer> james_w: Looks like it, I'll update changelog
[23:49] <lifeless> james_w: ping
[23:49] <lifeless> james_w: I don't understand why import-upstream would delete stuff (re your calling it dhmake
[23:50] <lifeless> james_w: in fact, bzrtools already has a tarball import; I guess I'd like to see that tarball import do the pristine tar stuff and then builddeb could lose that code altogether (or move it from both into core)


[23:39] <johnc4510> The new issue of the Ubuntu Weekly Newsletter #159 is now available:
[23:39] <johnc4510> https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue159


[09:16] <shawn|HD5650M> howdy]
[09:22] <shawn|HD5650M> anyone here familiar with BIOS modding?
[10:28] <Milor> Hi, Can you speak in Spanish? Is there another channel?
 Unfortunately we can't. There's an Ubuntu Spanish channel on IRC
 https://wiki.ubuntu.com/IRC/ChannelList
 #ubuntu-es
[10:31] <Milor> Thank, I hope to express myself. When closing the lid of my laptop is blocked. I would like you to do nothing ... (But only lets select block, turn off or suspend)
[10:41] <JohnDoe_71Rus> use http://goodies.xfce.org/projects/applications/xfce4-power-manager