[09:17] <mgz> morning!
[09:29] <vila> mgz: my man ! :)
[09:30]  * fullermd used to be your man   :(
[09:30] <vila> I can't find the bug about the recent spurious failures on babune, do you ?
[09:31] <vila> fullermd: hehe, I can multi-man for some contexts ;)
[09:31]  * fullermd c&p's into his quotes file.
[09:31] <vila> hehe, see if I care ;)
[09:33] <vila> fullermd: by the way, did you try to run the full test suite lately ?
[09:33] <vila> fullermd: I remember you had issues and mgz landed a patch on trunk that we hope should address them
[09:33] <fullermd> Nah.  I'm just an optimist and assume it'll work.
[09:35] <vila> mgz: also, I just noticed you use 'test' and 'test-failure' as bug tags where I was assuming 'selftest' myself, we should probably discuss and agree on which one(s) we use
[09:36] <vila> mgz: oh, and 'babune' is also relevant
[09:36] <fullermd> Seems the last time I tried a full run (which was however many $AGES ago) I always had the deadlocks run up.
[09:36] <mgz> you edited oneyou want bug 874153 vila?
[09:37] <mgz> ...
[09:37] <mgz> one you just edited, and I think that's the other current one
[09:37] <vila> YES !
[09:38] <mgz> I try and remember to use selftest for... issues with selftest itself, and generally don't tag test failures in any particular way
[09:40] <vila> ha, right, poolie seems to be using test-failure
[09:41] <vila> yeah, keeping 'selftest' for selftest itself seems like a better fit
[09:42] <vila> I think I'll switch to 'test-failure' for regressions triggered on babune
[09:45] <vila> bbiab
[10:47] <mgz> vila: how far back are we backporting fixes currently?
[10:48] <mgz> this bug report is against 2.1.4, the change is against 2.3 and we're on 2.5
[10:49] <mgz> I'll propose against 2.3 for now I guess
[11:58] <vila> mgz: for bug #874153 ? spurious enough to target trunk only I'd say
[11:59] <vila> mgz: oh no, 2.1.4, dunno which bug you're referring then
[12:01] <hrw> hi
[12:02] <mgz> vila: https://code.launchpad.net/~gz/bzr/2.3_unprintable_retrywithnewpacks/+merge/81827
[12:02] <jelmer> hi hrw
[12:03] <mgz> hey hrw, getting on okay with the buildds now?
[12:04] <hrw> mgz: works great
[12:04] <vila> briandealwis: hi
[12:04] <hrw> mgz: thanks a lot for this change
[12:04] <briandealwis> hi vila
[12:05] <mgz> jelmer and poolie were slaving away on getting it deployed all week we were at UDS :)
[12:05] <mgz> (and jelmer had been trying for... I don't want to know how long before that)
[12:05] <hrw> but the question for today is: how to export set of revisions as separate patches. I need to merge some changes from one branch to other but they have no common ancestor so prefer to have patches (like I would do with git and git format-patch)
[12:06] <mgz> if you have both branches, you can cherry-pick the revisions, rather than going via patchfiles
[12:07] <hrw> I cannot export some of changes as they are one huge commit
[12:08] <mgz> anyway, bzr diff with the revision range? depends how you want to edit the patch.
[12:09] <mgz> if your normal git thing is to get interactively select hunks, I'm not sure what would suit you best.
[12:09] <hrw> moment - phone call
[12:10] <briandealwis> vila, I haven't had time to do any further work on hooks-related part. The exception-shielding code comes from some nearly inexplicable interactions I've witnessed from exceptions in hooks. I've nearly reported 3 bugs on bzr-svn or bzr-git that were due to hooks instead.  But I see your points about hooks being able to influence the execution too. Seems we want a HookPoint.run for both with and without exceptions
[12:11] <briandealwis> (sorry for the wall of text)
[12:11] <vila> briandealwis: great, I was worrying you got confused by the reviews across both proposals
[12:12] <briandealwis> not at all
[12:12] <jelmer> briandealwis: do you recall what those hooks were? bzr-git and bzr-svn only hook into the "info" and "version-info" commands.
[12:13] <vila> briandealwis: as said, if you've got enough use cases to triangulate, run_without_exceptions makes sense for purely innocuous hooks
[12:13] <jelmer> ah, bzr-git hooks into Branch.hooks['post_commit'] too
[12:13] <vila> but as soon as we start playing tricks with return values or stopping hook execution when some condition is reached, run() itself becomes less attracting
[12:13] <briandealwis> jelmer: it was due to one of my own plugins :)  I have a 'verbose_hooks' plugin for debugging that dumps info on the hook args for various hooks.  There was an error in one of the branch hooks with bzr-git as it doesn't support generating a revno
[12:14] <briandealwis> So I'd do a dpush, which would throw an exception
[12:14] <briandealwis> I was uncertain as to the state of the branch or the push
[12:14] <jelmer> ah, ok
[12:15] <briandealwis> So from a user's perspective, providing the exception was far more confusing an experience
[12:15] <briandealwis> Or rather, showing the exception without context, was confusing
[12:15] <vila> briandealwis: that being said, I think my review was more about splitting the proposal to separate the parts we all agree upon from the parts for which more discussion may be needed
[12:16] <briandealwis> I moved out the exception-shielding-run into HookPoint at poolie's request :)
[12:16] <vila> it generally makes it a more satisfying experience for both the submitter (stuff lands) and the reviewer (easier to review)
[12:17] <vila> briandealwis: yup, I realized that *after* my review
[12:17] <vila> briandealwis: cross reviews are ... confusing :)
[12:17] <vila> or rather reviews across resubmitted proposals
[12:18] <vila> briandealwis: you know you can just push on the same branch ?
[12:18] <briandealwis> I wondered about adding BZR_PDB support, so the exceptions could be seen and debugged, but it looked harder than I thought
[12:18] <briandealwis> re: pushing: I did, but on a previous proposal, I thought I was told to resubmit
[12:18] <briandealwis> …but that was a while ago
[12:19] <vila> (the distinction between re-submitting or just pushing is rather arbitrary)
[12:19] <vila> and even reviewers may say resubmit for push adding to the confusion ;)
[12:19] <briandealwis> ah that would make sense
[12:20] <vila> it's a judgment call but generally re-submitting is when you want to really re-start the review from scratch because the first proposal is becoming too... complex/diverging from initial intent/whatever
[12:21] <briandealwis> gotcha
[12:21] <briandealwis> oops, I mean: got it
[12:21]  * vila blinks, the subtle difference between 'gotcha' and 'got it' here escapes me...
[12:22] <briandealwis> gotcha seems to have more of a connotation of a surprise.  I think.  In my head at least.
[12:22] <vila> didn't 'gotcha' mean: 'I got what you said' ?
[12:23] <vila> oh
[12:23] <vila> thks
[12:32] <vila> jelmer, mgz: freezing 2.5b3, please don't land, I'll do as fast as possible and tell you when I'm done
[12:42] <vila> Riddell: ping
[12:47] <diwic> Hi! I'm writing a launchpad recipe and when I'm testing it I have to enter my key passphrase 10 times, although read access to these branches are public...?
[12:48] <vila> diwic: you may be interested in an ssh-agent ?
[12:49] <vila> diwic: as soon as you tell lp about your ssh key, ssh will be preferred to http for performance reasons
[12:50] <diwic> vila, hmm, how do I set up an ssh-agent? I tried just running "ssh-agent bzr dailydeb recipe" but it didn't help
[12:51] <hrw> mgz: for f in `seq 1 12`;do bzr diff -c$f >$f.diff;done
[12:51] <vila> diwic: depends on your os/distro, which are you using ?
[12:51] <diwic> Ubuntu 11.10
[12:51] <hrw> mgz: that what I needed ;)
[12:53]  * vila blinks, wth are the key settings gone, can't find them anymore in system settings
[12:54] <vila> diwic: On ubuntu the ssh-agent should already be running... 'ssh-add -l' should tell you which keys are known
[12:55] <vila> diwic: 'ssh-add <path-to-key>' will add a new one
[12:55] <diwic> vila, aha, thanks, that was helpful!
[12:55] <diwic> My recipe still fails though :-(
[12:56] <diwic> bzr: ERROR: No such tag: upstream-3.0.0
[13:09]  * diwic files bug 888539
[13:10] <jelmer> hi diwic
[13:11] <diwic> jelmer, hi there!
[13:11] <jelmer> diwic: is this on a local build, or using Launchpad?
[13:11] <jelmer> (It shouldn't happen using Launchpad)
[13:11] <diwic> jelmer, this is local, testing it before trying it on Launchpad
[13:12] <diwic> jelmer, with 0.7.1-0ubuntu1 of bzr-builder package
[13:12] <hrw> diwic: --force-native-mode or sth like that is needed then
[13:12] <hrw> diwic: --allow-fallback-to-native
[13:13] <jelmer> diwic: newer versions of bzr-builder should give you a clearer error message
[13:13] <hrw> diwic: it will ignore tags and force native package
[13:14]  * diwic tries "bzr dailydeb --allow-fallback-to-native recipe"
[13:14] <diwic> hrw, thanks for keeping me awake at the airport btw :-)
[13:15] <jelmer> I'll release 0.7.2, there are a couple of other fixes that would be nice to get out too
[13:15] <diwic> hrw & jelmer, it worked, thanks!
[13:15] <hrw> diwic: no problemo
[13:15] <hrw> diwic: I had this problem (bzr) before
[13:16] <hrw> diwic: on return path I missed someone to keep me alive - had to rebook flight from FRA to TXL as I missed it (they moved gate and I did not noticed)
[13:17] <diwic> hrw, oh :-( but it got sorted out I hope
[13:18] <Wellark> jelmer: hi! :)
[13:21] <jelmer> Wellark: hi :)
[13:23] <hrw> diwic: yes
[13:23] <hrw> diwic: and they did not charged me
[13:40] <Riddell> vila: pon
[13:41] <Riddell> g
[13:42] <vila> Riddell: I tried to follow your instructions to update po/bzr.pot
[13:42] <vila> and I encountered weird stuff
[13:42] <Riddell> what did you do?
[13:43] <vila> I finally used 'BZR_PLUGIN_PATH=-site make po/bzr.pot' instead of 'make -f po/bzr.pot'
[13:43] <vila> and froze 2.5b3 with that
[13:43] <vila> I wanted to make sure excluding the plugins was the Right Thing to do
[13:44] <Riddell> yes it is
[13:44] <vila> otherwise the ones included depend on the RM :-/
[13:44] <vila> ha good
[13:44] <vila> I've updated the instructions then and I'll send a mp asap
[13:51] <vila> Riddell: the associated diff is an interesting way to look at what has been added since the previous release...
[13:51] <vila> Riddell: good stuff for RMs ;)
[13:58] <vila> jelmer, mgs: 2.5b3 frozen, 2.5b4 opening on pqm, thanks for your patience ;)
[13:58] <vila> s/mgs/mgz/
[13:58] <jelmer> vila: thanks!
[13:58] <mgz> stick the strings file diff up somewhere vila? :)
[13:59] <vila> mgz: 'bzr pull lp:bzr' , it's part of the release commit
[13:59] <mgz> an extractable part though? :)
[13:59]  * mgz tries
[14:00] <vila> the release commits are quite short most of the time
[14:01] <vila> hehe, I just add a wtf moment: I misread 'test_non_ascii.TestNonAscii.' as '^[ascii]' and thought pqm was back in the good old days where we ran the test suite twice ;)
[14:01] <mgz> bah
[14:01] <mgz> a bunch of line number change junk
[14:02]  * mgz grumbles at gettext and the formats it uses
[14:02] <vila> hmm, that reminds me that ediff (in emacs) allows regexps to *ignore* some changes...
[14:07] <mgz> hm, command help paragraphs don't seem to be shared, eg bzrlib/builtins.py:1007 and bzrlib/builtins.py:1147
[14:18] <rvba> Hi there, do you guys happen to know if it's possible to have a mirrored branch inside /~me/+junk/ on lp?  Or do I have to create a project and create the mirrored branch in there?
[14:18] <rvba> I've been sent here from lp-dev so please don't send me back there ;)
[15:08] <fullermd> We really should switch up metals for some variety.
[15:09] <fullermd> Our next beta should go palladium, say.
[15:11] <jelmer> palladium is one of the launchpad buildds
[15:11] <fullermd> OK, ruthenium then.
[15:22] <mgz> fullermd is bored of gold by now?
[15:22] <mgz> just have too much, don't know what to do with it?
[15:25] <fullermd> Nono, I don't have *enough*!  And all those betas keep going off with what I have!
[15:57] <vila> mgz: yup, I noticed the help paragraphs too... did you dig that ?
[15:58] <mgz> nope, but I did notice one was at the end of the help block and one in the middle
[15:58] <mgz> so could be a quirk of how that's split
[15:59] <mgz> or perhaps help blocks aren't deduped at all.
[16:00] <vila> Maybe a final \n quirk
[16:00] <mgz> really, it's a sign that our help needs shortening I thikn
[16:07] <jelmer> vila: 2.5b3 uploaded to sid/precise
[16:07] <jelmer> sorry, experimental+precise
[16:09] <vila> jelmer: Thanks !
[16:10] <mgz> vila: looks like export_pot doesn't actually do deduping.
[16:10] <vila> mgz: export-port is ours right ?
[16:11] <mgz> yup, bzrlib.export_pot
[16:11] <vila> ok, worth a bug then
[16:12] <vila> 2.5 is the first series for translations, it's expected that we encounter a few
[16:12] <vila> bugs
[16:12] <mgz> I better read up on the po format first... :)
[16:12] <vila> hmm, and PEP8 issues there too ;)
[16:13] <vila> jelmer: I kinda lost track of where you are for multiple tarballs, but
[16:14] <vila> jelmer: IIUC you commented a line related to branch freshness and this is causing other import failures
[16:14] <vila> jelmer: is there two different bugs ?
[16:14] <vila> hgaaa
[16:15] <vila> jelmer: I meant: commenting that line (which one ?) will *address* other import failures that we encounter *now*
[16:15] <mgz> as I recall, he only commented a line on his box, for testing, which was a path the importer doesn't go down
[16:15] <mgz> the freshness issues should be all the same old freshness issues
[16:15] <vila> mgz: yup
[16:16] <vila> http://package-import.ubuntu.com/status/3b90b26b3585bde1d5cb6d903f83dc45.html
[16:16] <vila> looks new to me
[16:16] <vila> imbw but it seems that running bzr-2.5 on jubany has caused these new failures
[16:16] <vila> which is surprising in itself
[16:17] <vila> but checking the freshness on the importer seems useless anyway so we probably want a way to disable it if only for the importer
[16:20] <mgz> vila: I wouldn't be suprised if fixing the multiple tarballs error exposed a few more packaged with freshness issues
[16:21] <jelmer> vila: it works at the moment
[16:21] <jelmer> vila: but I'm fixing a bug in the multi  tarball support to handle revisin parents correctly
[16:22] <vila> mgz: the importer is responsible to make the branches fresh enough is what I'm trying to say ;)
[16:22] <mgz> this is pretty fun too: http://package-import.ubuntu.com/status/73d7709fb86e524d019e4c119d698c58.html
[16:22] <vila> jelmer: ok, so I'm still waiting for your green light
[16:24] <vila> mgz: that's one of the bugs where I suspect the importer misunderstands the packager
[16:24] <jelmer> vila: yep
[16:24] <mgz> yeah.
[16:37] <mgz> vila: do you favour merging up older bzr releases when each change lands?
[16:45] <vila> mgz: yup, that means the guy doing the landing also handle the conflicts when merging up
[16:45] <vila> mgz: and they should be easier to resolve by him than by anybody else
[16:47] <mgz> heh, anyone can read release notes and probably realphabetise better than me :P
[16:48] <vila> oh, release notes, yeah, be careful when crossing... 2.2 -> 2.3 where they were split from NEWS to one file per release
[16:49] <vila> but release notes is not my concern here ;)
[17:42] <vila> wgz: confused by the too many spurious test failures, I ended up filing a bug you already filed, in anger, I marked *yours* as a dupe of mine ;)
[18:23] <smoser> hey all. how can i track a git repository in bzr ?
[18:23] <smoser> i know i can set  up launchpad to do it for me
[18:23] <jelmer> hi smoser
[18:23] <smoser> but how can i do it on my own?
[18:23] <jelmer> smoser: if you have bzr-git installed, just use bzr branch as you would with a bzr branch
[18:24] <smoser> perfect.
[18:25] <smoser> easiest question ever
[18:25] <smoser> thank yoiu
[19:36] <george_e> I can't seem to get Bazaar to pull from an HTTP server.
[19:37] <george_e> Using Chromium, I can verify the remote server is up and running and the .bzr folder is accessible.
[19:37] <george_e> ...but I keep getting errors: "bzr: ERROR: Not a branch: 'http://192.168.1.1:8083/'"
[19:39] <george_e> What am I doing wrong?
[19:40] <jelmer> hi george_e
[19:40] <george_e> Hi.
[19:40] <jelmer> george_e: is .bzr/branch-format accessible?
[19:41]  * george_e slaps forehead
[19:41] <george_e> It's spitting out a 403 :)
[19:41] <george_e> That would explain it alright.
[19:41] <george_e> (That's what I get for using IIS :P)
[19:44] <george_e> jelmer: Thank you thank you thank you - that solved the problem.
[19:45] <jelmer> george_e: np :)
[23:03] <poolie> hi all
[23:09] <GRiD> hi poolie
[23:09] <Noldorin> hi jelmer
[23:09] <Noldorin> poolie,
[23:09] <poolie> hi
[23:18] <jelmer> hi poolie, GRiD, Noldorin
[23:18] <Noldorin> hey
[23:19] <GRiD> hey jelmer
[23:19] <Noldorin> how's it going?
[23:21] <GRiD> no hurry, but if someone can take another look at https://code.launchpad.net/~weyrick/bzr/720853-max-recursion-depth/+merge/81297 ...
[23:21] <poolie> oh thanks for th ereminder
[23:24] <poolie> done
[23:27] <GRiD> thanks :)
[23:29] <Noldorin> jelmer, are we any closer to the new bzr-git release/fix, may i ask? :-)
[23:33] <GRiD> poolie, btw, i suppose i should also add something to release-notes?
[23:33] <poolie> yes
[23:35] <GRiD> k