[05:33] <jimis> Is there a way to apply to my current branch a specific change commited in another?
[05:33] <jimis> Not a whole commit, just a hunk of it
[05:35] <jimis> I did it manually, but I'm being curious
[05:35] <jimis> I think git has the cherry-pick functionality for this purpose
[08:14] <hno> Is it normal to get lots of "conversion error: The branch format Meta directory format 1 is already at the most recent format." during bzr upgrade?
[09:15] <cheater__> hi!
[09:16] <cheater__> i've found a fairly annoying bug in bzr, it has to do with it losing ownership data of files when i do bzr shelve
[09:16]  * cheater__ wonders if there is a workaround other than resetting that over and over
[09:48] <cheater__> i have isolated the reason for the bug
[09:49] <cheater__> https://bugs.launchpad.net/bzr/+bug/825732
[09:49] <cheater__> ah yes, it's a security bug, it won't be accessible publicly
[09:49] <cheater__> i'm not sure if i should make it public
[09:50] <maxb> My inclination is that this is not a bug
[09:51] <cheater__> how so? it clobbers ownership of the file
[09:51] <cheater__> no other operations do that
[09:51] <maxb> Simply that your expectations disagree with the design goals of most version control tools
[09:52] <cheater__> it's not homogenous in its behavior
[09:52] <cheater__> other operations do not do this
[09:52] <cheater__> just shelve (that i know of)
[09:55] <maxb> No, try bzr revert for example
[09:55] <cheater__> hm
[09:55] <cheater__> what others do that?
[09:55] <cheater__> and which ones don't?
[09:56] <maxb> pretty much anything that changes the file via the generic treetransform code
[09:56] <cheater__> is there a reason to overwrite the file instead of updating it?
[09:57] <cheater__> if not, maybe i can make a patch (if htat part is in python and not, say, C)
[09:57] <maxb> Yes, bzr prepares all of the updates it is going to do within .bzr, and then moves files in and out to commit the result of the operation in a nearly atomic fashion
[09:58] <cheater__> mhm
[09:59] <cheater__> i understand that a rename is atomic while a write doesn't have to be
[10:01] <cheater__> i wonder if there could be a plugin which takes note of the ownership, and chown's the files (and asks you to sudo if necessary)
[10:02] <maxb> Not entirely impossible, I suppose, though it does sound like it would have to hook very deeply into the core. I doubt sufficient hooks are available now
[10:02] <maxb> What is the use case?
[10:03] <maxb> Software development certainly doesn't require anything like this
[10:03] <cheater__> dev server, files are in the project folder of the user working on the code, server needs to access it therefore the files need its group
[10:04] <maxb> Sounds like you should simply make use of the directory setgid bit and an appropriate umask
[10:05] <cheater__> i know that setgid can be used, the problem wasn't with being able to do that, but instead with the fact that it was a surprising change
[10:05] <cheater__> pretty much nothing i've done so far has behaved like this in bzr
[10:05] <cheater__> or it did so in a way that wasn't visible
[10:06] <maxb> Even a text editor which writes out the new version and renames it into place would behave in the same way
[10:07] <cheater__> i've never come across a text editor that is broken in this way
[10:07] <cheater__> hmm.. except one i've written myself
[10:07] <cheater__> now that i think about it
[10:07] <cheater__> but it was just a bash wrapper around cat, that doesn't matter
[10:08] <cheater__> :)
[10:08] <cheater__> s/matter/count
[10:08] <cheater__> :)
[10:09] <cheater__> well, thanks for the response maxb
[10:10] <cheater__> are you on the bzr team by the way?
[10:17] <OutOfControl> I get bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[10:29] <cheater__> good to know.
[10:29] <cheater__> lol
[10:30] <cheater__> :)
[11:04] <cheater__> maxb: in fact, setgid doesn't fix that.. the group is still getting clobbered
[11:14] <maxb> I think the user would need to be a member of the group for that to work
[11:21] <fullermd> The files are getting created (and thus getting their ownership set) in limbo somewhere, not in their final dir locations.
[11:22] <cheater__> fullermd, yes
[11:22] <cheater__> fullermd, maybe they could instead be copied to the limbo and then emptied as opposed to being just created in limbo
[13:01] <maxb> cheater__: I'm confused. Why do you care so much about *retaining* ownership? Surely the ownership of newly created files matters just as much?
[13:30] <cheater__> maxb, when you create new files you know that's a new object and you need to check on permissions
[13:30] <cheater__> when you just modify files, you don't expect their metadata to slip out from under you
[14:35] <tshirtman> hi there, i would like to automate bzr pull on a server with crontab, but i need it to stop asking my password of my ssh-key, is it mandatory to use the key to pull?
[14:36] <AuroraBorealis> uhh
[14:36] <AuroraBorealis> use a ssh key agent
[14:36] <AuroraBorealis> like pageant (on windows) or something else (like gnome password manager)
[14:36] <tshirtman> it's a debian server, i'm not the only one to use it
[14:37] <tshirtman> i want to keep an up to date clone, and build the doc automaticaly here
[14:37] <AuroraBorealis> if its over sftp or whatever then you will need the ssh key :3
[14:37] <tshirtman> it was a bzr branch from launchpad (lp:ultimate-smash-friends)
[14:38] <tshirtman> hm, i should re-branch with different params?
[14:38] <AuroraBorealis> you should be able to do it anonmyously
[14:38] <AuroraBorealis> if its public
[14:38] <AuroraBorealis> and it will yell at you that you haven't identified but it should still do it
[14:38] <tshirtman> so i have to unauthentify?
[14:39] <AuroraBorealis> i dunno
[14:39] <AuroraBorealis> maybe?
[14:39] <tshirtman> i'll try that later
[14:39] <AuroraBorealis> dunno how to get bzr to forget your login name
[14:40] <maxb> Unnecessary, just branch from http://bazaar.launchpad.net/whatever
[14:42] <vila> maxb: You know 2.4.0 has been frozen right ?
[14:43] <vila> maxb: <cough>, I meant hello maxb, by the way you &
[14:43] <maxb> I had not noticed that, thanks :-)
[14:46] <vila> maxb: I was wondering if 2.4.0 should go into the beta ppa before the stable one or not at all...
[14:47] <vila> somehow, I feel the beta ppa users expect 2.4b1... 2.4b5/2.4.0/2.5b1 but I may be wrong
[15:12] <maxb> 2.4.0 into beta first, get it all promoted into proposed and then stable, and only then start to care about the 2.5 series, IMO
[15:27] <vila> maxb: /me nods
[15:28] <vila> maxb: care to reply to the freeze announcement to outline your expected roadmap ? I don't mean ETA, just steps, if only to get more testers at each step
[15:32] <maxb> Hmm, I'm not seeing the annoucement
[15:38] <in3xes> how do I launch bzr-gtk? I installed it from debian repos. bzr-gtk doesn't work
[15:38] <in3xes> 'bzr-gtk' command is not working
[15:38] <vila> on the bzr ml ? :-/
[19:50] <jelmer> vila, hi
[19:51] <vila> jelmer: me ?
[19:51] <vila> :)
[19:51] <jelmer> vila: hey!
[19:51] <jelmer> vila: there doesn't seem to be a tag for 2.4.0
[19:51] <vila> how did you know ? Freeze announce ?
[19:51] <vila> WHAT ?
[19:52] <jelmer> vila: Thanks for releasing 2.4.0 :)
[19:52] <jelmer> vila: Yeah, just saw the release announcement :)
[19:52] <vila> I sent the mail on Thursaday but it seems it get blocked for approval :-(
[19:52] <jelmer> ah :-/
[19:52] <vila> I subscribe from a news email but mailman didn't realize vila@ and vila+bzr@ are the same...
[19:53]  * vila blinks
[19:53] <vila> Where on internet went this flag...
[19:56] <jelmer> vila: ah
[19:58] <vila> ok, so, I tagged the right version locally (the tag is not there either) how to I propagate it now... A dummy commit and a pqm submission should do no ?
[19:59] <vila> I took notes and the notes say I tagged...
[20:01] <vila> jelmer: how urgent is that ?
[20:02] <vila> jelmer: pkg-import will blow up ?
[20:03] <jelmer> vila: it's not urgent, just nice to have this complete (and it means I have to specify the revision manually to 'bzr merge-upstream')
[20:04] <vila> jelmer: ok, I'll submit to pqm anyway, do you need it on lp:bzr/2.4 or lp:bzr ?
[20:04] <jelmer> vila: bzr/2.4
[20:05] <vila> ok, it will propagate to lp:bzr later then
[20:06] <vila> The weird thing is that poolie knew I did release on Thursday, so if he didn't see the mail nor the tag, how did he know ?
[20:07] <fullermd> You talk in your sleep.
[20:07] <vila> hehe
[20:10] <vila> jelmer: submitted, 1e6 thanks for the heads-up
[20:30] <jelmer> vila: thank you for adding the tag :)
[20:30]  * jelmer uploads 2.4.0 to unstable
[20:31] <jelmer> crap, 6 test failures :-/
[20:32] <jelmer> vila, Yeah, definitely looks like it was your fix that broke config_dir() for me (though admittedly it was already inconsistent before that)
[20:33] <vila> 6 test failures where ?
[20:33]  * hno (or actually Fedora upstream monitoring tool) saw the 2.4.0 tarball on launchpad some day(s) ago.Packaged it for Fedora yesterday.
[20:34]  * vila applause hno and thanks him
[20:34] <vila> hno: would you mind replying to the freeze announce on the ml ?
[20:35] <jelmer> vila: 6 test failures in 2.4 on oneiric
[20:35] <vila> meh, context ?
[20:38] <jelmer> vila: some are the testtools compatibility issues
[20:38] <jelmer> and two are related to locks
[20:39] <vila> argh, oneiric needs a new testtools ?
[20:40] <vila> I thought your fix was to workaround that....
[20:40] <jelmer> no, my fix isn't on 2.4 yet - I'm adding it to the package as a patch now
[20:41] <jelmer> maybe we should backport it to 2.4
[20:41] <vila> if you need to add it as a patch, we definitely need to backport it
[20:42] <jelmer> yeah, that'd be nice
[20:43] <hno> vila, I have not seen the announce message yet. But only subscribed to bazaar-announce and bzr-packagers.
[20:44] <vila> hno: bah, I *really* should CC bzr-packagers :-/
[20:45] <hno> that list should have some better visibility in general as well.. not sure how to find it's existence.
[20:47] <hno> but yes, it would be great if freeze announses were cc bzr-packagers as it's a heads up to prepare packaging for the next release.
[20:51] <jelmer> vila: http://pastebin.ubuntu.com/665251/
[20:52] <vila> hno: releasing.txt updated in that regard
[20:54] <vila> jelmer: no idea :-/
[20:54] <vila> and I really need to sleep :-/
[20:57] <jelmer> vila: no hurry :)
[20:58] <jelmer> vila: bonne nuit
[20:58] <jelmer> vous parler de lundi
[20:58] <jelmer> (or something close to that :)
[20:58] <vila> jelmer: the only thing that comes to mind is that it's related to the recent poolie change to break dead locks so *may* also be impacted by an unknown bug in config (including some config_dir, though I can't see where in this case)
[21:01] <jelmer> vila: thanks, I'll have a look
[21:10] <jelmer> vila: nevermind, I found it
[21:10] <jelmer> vila: the problem is that my hostname is 'localhost'
[21:13] <fullermd> Oh cool, I'm not the only one whose hostname breaks tests then  ;p
[21:23] <gour> fullermd: thank you for 2.4 port...however, i've problem...bzr verify-signatures fails with 'bzr: ERROR: python-gpgme is not installed, it is needed to verify signatures' and i cannot build py-pyme :-/
[21:26] <jelmer> fullermd: :)
[21:26] <fullermd> Mmm.  I don't know anything about pyme.  What's wrong with the build?
[21:27] <jelmer> fullermd, gour: note that bzr doesn't use pyme but python-gpgme
[21:27] <gour> jelmer: hmm...why that message then?
[21:29] <fullermd> The message that says 'python-gpgme'?  ;)
[21:29] <gour> jelmer: dec for py-pyme port says: Python interface to GPGME library
[21:29] <gour> *description
[21:29] <fullermd> According to the plist, it's all under pyme, so it seems likely to be something different.
[21:30] <jelmer> gour: there are multiple python bindings for gpg
[21:31] <gour> in any case, bzr-2.4 port does not work :-)
[21:31] <fullermd> Sure it does.  Just verify-signatures doesn't   ;)
[21:32] <fullermd> The port by itself won't run selftest either; you'd have to install testtools for that.
[21:32] <gour> he he
[21:33] <fullermd> I think if there were a py-gpgme port (there doesn't appear to be), I would be inclined to not stick it in the depends list either; pulls in a lot of extra stuff, for a currently-niche feature.
[21:34] <gour> hmmm...one can do similar thing in hg with simple extension...it would be bad to limit bzr
[21:35] <fullermd> Oh, I wouldn't be averse to an OPTIONS entry; that would be sensible.  And if signing ever becomes common in the community, defaulting it on would make more sense.  But grabbing all the stuff that would be in the dep chain is a little hefty to want to make it unconditional.
[21:36] <gour> i'm ok with option
[21:37] <fullermd> But first someone would have to knock up py-gpgme   ;)
[21:37] <gour> this is one of the release sections - Digital Signature Verification
[21:37] <gour> now it's too late here...i was away whole day...se you tomorrow
[22:10] <dvheumen> hi, I'm casually reading through the source code at the moment, trying to get a good grasp of the code and structure. Now I've encountered some abbreviation a few times that I don't know: e.g. in revisionspec.py, they use 'dwim'. What is 'dwim'?
[22:10] <fullermd> Do What I Mean
[22:10] <dvheumen> ah okay, didn't expect that one :) thanks!
[22:11] <fullermd> (The only opcode needed by the perfect computer   ;)
[22:11] <dvheumen> yeah, wish it was available already ;)
[22:20] <dvheumen> I didn't know that diwm was actually used in source code :P so I didn't expect it :P
[22:21] <fullermd> Only cool source code uses it.
[22:22] <dvheumen> hmm... I'm honored, I'm ready a cool source then :)
[22:22] <bignose> lies! I've written very un-cool code referring to DWIM.
[22:23] <dvheumen> bignose: so did maybe your DWIM was malfunctioning?
[22:23] <dvheumen> (* -did)
[22:24] <fullermd> Or maybe it was functioning correctly, and he _meant_ it to be uncool.
[22:25] <fullermd> (and functioned doubly-properly, in preventing the infinite loop of contradictions of being uncool, too!  Why, that's the coolest thing ever!)
[22:25] <dvheumen> well, in that case it worked perfectly :)
[22:59] <dvheumen> hmmm... I'm a bit confused, but I'm not sure where to find this. Bazaar also stores rwx access modifiers right? (or only some of them?)
[23:00] <fullermd> Only x
[23:01] <dvheumen> so, it stores executability for files *and* directories?
[23:01] <fullermd> Not much point in having a -x directory   ;p
[23:02] <dvheumen> okay, so that explains :) ... the code said that everything but 'file' was not executable ... I was wondering about that :)
[23:03] <dvheumen> thanks :)
[23:07] <dvheumen> (b.t.w, it depends on whether you store group information right, we could be storing not executable for group' and it would not be completely meaningless)
[23:08] <dvheumen> :P
[23:46] <RenatoSilva> verterok: hi
[23:56] <pathogenic> hi
[23:56] <pathogenic> how does Bazaar compare to something like Mercurial or git