[09:29] <mgz> morning all
[10:24] <vila> mgz: oh, I missed that, hey !
[10:25] <mgz> hey vila!
[10:26] <mgz> hm, I need to fix my builddeb test a little, looking at it again this morning
[10:27] <vila> jelmer: no need for a DictStore, we already have everything we need ;) Running a full test suite before pushing my changes to lp:~bzr/bzr/commit-uses-config-stacks but there are still issues to be addressed (more in my review comment) :-/
[10:30] <vila> jelmer: done
[10:30] <vila> jelmer: all these minors bugs are the most painful part of the option migration :-/
[10:31] <mgz> the bugs were introduced by children?
[10:31] <vila> jelmer: ha crap, I didn't notice you pushed additional revisions :-/
[10:31] <vila> ?
[10:32]  * mgz is just teasing about a misplaced 's' :)
[10:32] <vila> ha ha
[10:32] <vila> :)
[10:35] <vila> mgz: by the way, is http://paste.ubuntu.com/769900/ clearer ?
[10:35] <vila> mgz: i.e. the added comma
[10:39] <jelmer> :)
[10:46] <mgz> ...I still can't parse that I'm afraid
[10:46] <mgz> you need to just flip the clauses
[10:47] <mgz> "The ``SectionMatcher`` objects are for defining which." for eg.
[10:54] <vila> mgz: thanks, fixed
[11:18] <mgz> okay, nearly caught up with life.
[11:18] <mgz> just need to write news and land things...
[11:28] <vila> mgz: yeah for news ! :) If you had a look at what's new for 2.5 too that would also be truly great :-p
[11:39] <vila> mgz: found that bug back: #659763
[11:39] <vila> bug #659763 you helpful bot
[11:46] <sidnei> hi there! how does one change an existing branch hosted in launchpad to set append_revisions_only?
[11:47] <sidnei> is it enough to change .bzr/branch/branch.conf and push?
[11:47] <mgz> vila: hey, another path for doing a similar thing, what fun
[11:48] <mgz> sidnei: with recent enough bzr versions you can do `bzr config append_revisions_only=True -d lp:...`
[11:49] <sidnei> thanks mgz!
[11:53] <mgz> I wonder whether this diff/merge is bad because the file contains conflict markers for test examples...
[11:56] <jelmer> vila, mgz: Could I persuade either of you to take a look at https://code.launchpad.net/~jelmer/bzr/hpss-no-vfs/+merge/85153 ? It's one of the prerequisites for hpss-get-inventories
[11:57] <vila> on it
[12:10] <vila> jelmer: done
[12:11] <jelmer> vila: merci bien :)
[12:11] <vila> hehe
[12:11] <vila> lunch time for me
[12:21] <mgz> bzr info is too slow.
[12:24] <jelmer> mgz: -v you mean?
[12:25] <mgz> just plain, it takes as long as st on hot cache and shouldn't need to do as much work
[12:25] <mgz> -v is just silly.
[12:25] <mgz> takes 6 seconds herre.
[12:26] <mgz> 400ms was what I was talking about with "too slow"
[12:26] <mgz> it's long enough that there's a noticable pause
[12:28] <jelmer> it looks at the full branch history to see what the revid of the first revision is, so it can figure out its date
[12:29] <mgz> yup, at least the other output comes out before it goes off and does that.
[12:51] <jelmer> hmm, is there a particular reason we always open a branch for a working tree?
[12:51] <jelmer> it seems like some operations should be able to get away with not opening the branch (especially if it is remote)
[12:56] <mgz> probably similar to reasons we reopen repos and branches way too much
[13:00]  * jelmer lunches too
[13:21] <jelmer> vila: have you decided what you want to do with lp:~jelmer/bzr-upload/fix-2.4-compat yet?
[13:22] <jelmer> It's fine with me if you reject it, but it would be nice to see it disappear of my activereviews queue :)
[13:35]  * jelmer stumbles onto mumble
[13:37] <mgz> ha, well spotted on bug 317778 jelmer
[13:39]  * jelmer was browsing switch bugs anyway... :)
[13:40] <jelmer> *crickets*
[13:41] <mgz> I think I borked by audio setup someone
[13:41] <mgz> oh, nope, just being an idiot
[13:52] <vila> jelmer: what I don't get is why you uploaded a new version when none has been released >-/
[13:54] <jelmer> vila: I had to earlier, because bzr-upload was broken with bzr 2.5
[13:55] <vila> that's fine, 2.5 is still beta, but then, why trying to ensure compat with 2.4 ?
[13:56] <jelmer> vila: I'd rather not maintain two copies of bzr-upload in debian
[13:57] <vila> meh, the point of splitting into series is to have *less* maintenance to do indeed, can't they be used in debian ?
[13:58] <jelmer> vila: it means I have to do twice as many uploads to debian
[13:59] <jelmer> vila: anyway, the current situation is fine for me, let's just reject the MP
[14:00] <vila> ok, but be aware that I intend to track 2.5 far more than 2.4 so the series will diverge
[14:00] <jelmer> sure
[14:00] <jelmer> 2.4 will stop being relevant in Debian too at some point
[14:01] <vila> right
[14:03] <vila> jelmer: by the way, did you start to CC me when replying to reviews ? I got duplicate mails in the last days...
[14:04] <jelmer> vila: https://code.launchpad.net/~jelmer/bzr/hpss-_get-checkout-format/+merge/85652
[14:04] <vila> ha no, not this thime
[14:04] <jelmer> s/vila/mgz/
[14:04] <jelmer> vila: sometimes I have to resend email if I forget to use GPG/MIME
[14:05] <vila> jelmer: sry, misread your re-submission, I *got* 3 copies last time you CC'ed me,
[14:05] <jelmer> vila: as launchpad seems to refuse GPG signatures from thunderbird that don't use GPG/MIME
[14:05] <vila> the (small but annoying) issue is that some of them are filtered in the wrong mailbox
[14:10] <mgz> lunch lunch
[14:11] <vila> meh, can't '+reply' on comments from previous versions of a proposal o_O
[14:12] <vila> jelmer: you really think BZR_EMAIL is used for cases where it is *also* defined in bazaar.conf and/or branch.conf ?
[14:12] <jelmer> vila: yes
[14:12]  * vila shudders
[14:13] <jelmer> launchpad uses it in its test suite for example, but I also imagine things like cron scripts rely on it
[14:14] <jelmer> -Oemail=.. seems like a reasonable alternative, but IFF we want to change the behaviour I think we should deprecate BZR_EMAIL first and start warning existing users
[14:15] <vila> yeah, but -Oemail may not work for crontab or scripts since it needs to be passed to bzr itself
[14:17] <jelmer> vila: right
[14:18] <vila> email_from_store may do the trick (ugly but doesn't require another confusing parameter to Option), let's try
[14:30] <jelmer> vila: are you looking into implementing that or should I?
[14:30] <vila> jelmer: ok, that fixes the issue with BZR_EMAIL, now looking into post_commit deprecation warnings
[14:32] <jelmer> vila: I already added one to the definition of post_commit in BranchConfig
[14:32] <vila> yeah, but the test suite is complaining now :)
[14:33] <jelmer> vila: ah, ok
[14:33] <jelmer> vila: if you need me to do a review, you know where to find me >-)(
[14:34] <vila> hehe
[14:34] <vila> BZR_EMAIL=me@example.com ./bzr config -Oemail=you@xxx.com  email
[14:34] <vila> gives the expected result :)
[14:34] <jelmer> \o/
[14:34] <vila> well, for some compat-nutty value of expected
[14:37]  * jelmer is compat-nutty and proud of it :P
[14:41] <vila> jelmer: hehe, about compat, tried the loom test suite recently ?
[14:41]  * vila dodges
[14:49] <vila> jelmer: oh, forgot to reply: yes, post_commit predates our hook system (by far)
[14:50] <vila> jelmer: dunno if it's casher but I approved your part of the common branch ;)
[14:55] <mgz> lambed up.
[14:56] <mgz> vila: on the config branch, BZR_EDITOR has a similar issue
[14:56] <vila> of overriding any option setting ?
[14:57] <mgz> order is currently BZR_EDITOR, get('editor'), EDITOR, VISUAL... other fallbacks
[14:57] <vila> same era probably
[14:59] <jelmer> vila: makes sense to deprecate it then, IMO
[15:00] <vila> jelmer: BZR_EDITOR ? BZR_EMAIL ? both ?
[15:00] <vila> I would rather deprecate all of them in one go if only for users to handle them all at once
[15:01] <vila> no ?
[15:02] <jelmer> vila: post_commit
[15:02] <jelmer> vila: I think we should keep BZR_EMAIL and BZR_EDITOR
[15:03] <vila> jelmer: ha, but, yes, we agree that post_commit should be deprecated, you did it (I just fixed the test fallouts)
[15:03] <vila> ha, sorry, mixed conversations, you were replying to my late reply here,
[15:04] <vila> so, yes, post_commit is old, has been replaced by a better mechanism, never formally deprecated
[15:04] <vila> the later is now done
[15:04] <jelmer> great
[15:05] <vila> officiously deprecated since 0.15 if you look at the comment I left
[15:05] <vila> s/left/updated/
[15:11] <jelmer> vila: thanks!
[15:11] <jelmer> I'll approve your work then, and land :)
[15:11] <vila> hehe
[15:12]  * jelmer adds vila to the NEWS entry as well
[16:20] <vila> jelmer: brain dumped my thoughts on your feature-flags proposal, about to leave for an appointment, should be back later
[16:23] <vila> jelmer: oh, thanks for your review on config-explained, just one question:
[16:24] <vila> I addd 'for modifcation' because I thought the parameters was a bit lost and obscure, would 'Where modifcations go' be clearer ?
[16:24] <vila> or may be you know already too much about stacks to need these comments ;)
[16:26] <vila> hmm, yeah, I added the comment first and the docstring later, now that I re-read the two, the comment is redundant
[16:26] <mgz> vila: before you notice independently, yes, I added release notes in the wrong section ;_;
[16:27] <vila> hehe ! Progress !
[16:45] <jelmer> vila: thanks!
[17:32] <mgz> ...and the reaper kills mumble
[17:33] <jelmer> hmm
[17:33] <jelmer> dark-cloaked bastard.
[17:39] <vila> hmm, what a language, missing context I assume I wasn't the target ;)
[17:40] <jelmer> vila: unless you're the person going around killing random processes on mgz's laptop when it runs OOM, no. :-)
[17:40] <vila> oops, busted :)
[20:37] <lamalex> is it possible to fetch just a directory of a bzr branch?
[20:37] <lamalex> so say I want just the debian dir of lp:~ubuntu-desktop/libindicator/ubuntu
[21:30] <maxb> lamalex: No, the data structures / protocols used just don't work that way
[23:32] <Noldorin> hey poolie
[23:53] <poolie> hi Noldorin, all