[00:16] <poolie_> hi spiv
[00:28] <spiv> Morning poolie.
[00:28] <poolie_> hi there
[00:29] <poolie_> your lp haproxy change landed
[00:29] <poolie_> i don't know if you need to qa it or something
[05:58] <jam> morning all
[05:59] <vila> morning jam et al.
[07:12] <poolie_> hi jam
[07:34] <jam> vila: can you try to message me again, I might have gotten ping to work
[07:35] <vila> jam: pingeling
[07:37] <vila> jam: so, does it work ?
[07:38] <poolie_> hi jam, vila
[08:02] <AfC> Is there a newer CIA client than http://samba.org/~jelmer/bzr/cia_bzr.py ? I'm quite impressed with the notifications coming into #gnome-shell from a CIA bot.
[08:07] <Riddell> good morning Bazaar
[08:09] <vila> _o/
[08:18] <jam> no, it doesn't work
[08:18] <jam> hi Riddell
[08:18] <jam> vila: it doesn't highlight lines with my name in them, either
[08:18] <jam> it apparently doesn't think my username is actually my username
[08:19] <vila> what a pity
[08:19] <jam-other> jam-other: test
[08:19] <jam-other> vila:  try with a different name
[08:19] <vila> jam-other: like that ?
[08:19] <jam-other> yeah, doesn't work either
[08:19] <jam-other> try "jam1"
[08:19] <jam-other> yep
[08:19] <jam-other> it still thinks that is my name... ugh
[08:19] <vila> jam1: you mean *this* works ?
[08:19] <jam-other> when I logged in a long time ago, it had to fall back to that
[08:19] <jam-other> vila: yep
[08:20] <vila> hmm, nice bug
[08:20] <jam-other> and it doesn't seem to be following "/nick"
[08:20] <jam-other> I'm going to log back in
[08:20] <jam-other> brb
[08:20] <jam> ok, I think it is working now
[08:20] <jam> hopefully I don't lose my name again
[08:20] <vila> jam: pingeling
[08:21] <jam> vila: got it
[08:38] <vila> jam: regarding bug #786980,
[08:38] <jam> yessir
[08:39] <jam> vila: ??
[08:39] <vila> jam: an interesting point is that the code involved is only triggered if bound_location is an url that will lead to the right branch
[08:39] <vila> i.e. only small variations can trigger it (including the missing final slash)
[08:40] <vila> so I've added tests for + and ~ but we already have coverage for urls that differs in a way that get_transport will point to a different branch (or no branch at all)
[08:41] <vila> I'm merging 2.3 to 2.4 to trunk right now and will make my proposal when lp:bzr is up-to-date
[08:41] <jam> vila: so you're saying we have coverage if URL mangling would cause us to not find the path?
[08:42] <vila> yeah, because get_master_branch is called higher in the stack
[08:42] <vila> so bound_location errors are also caught before we reach this code
[08:43] <jam> sure, but %7E stuff will still open the right branch
[08:43] <vila> it also explains why we didn't get more bug reports, the window is pretty small
[08:43] <vila> jam: yup, hence the added tests
[08:43] <vila> jam: but even %7E requires a manual user intervention
[08:43] <jam> vila: we used to put one way into config files
[08:43] <jam> and then changed which one we saved
[08:43] <vila> jam: indeed
[08:44] <jam> That may not be what is happening here
[08:44] <vila> so the fix should cope with that
[08:44] <jam> but *this* case could be that we used to keep the path read from the config file as Transport.base
[08:44] <jam> and we started normalizing the path, etc.
[08:44] <vila> oh, yeah, sorry isunderstanding
[08:44] <vila> jam: yes, that may be the explanation, .base is now normalized so we shouldn't run into it anymore
[08:45] <vila> s/that may be/that *is*/ but I don't feel like validating that by searching the history for the relevant change
[10:11] <vila> maxb: is there some special stuff going on currently on jubany ?
[10:11] <maxb> Not that I'm aware of
[10:12] <vila> mac_threads == 1 seems... wird
[10:12] <vila> weird
[10:12] <vila> ghaa
[10:12] <vila> maxb: any objection about setting it to 8 again ?
[10:12] <maxb> hrm
[10:13] <maxb> I wonder why it's set to 1
[10:13] <vila> hehe, me too, hence my question
[10:13] <maxb> Regardless, we should set it back to 8 since no reason not to has been advertised
[10:13] <vila> http://webnumbr.com/ubuntu-package-importer-conccurrency
[10:14] <vila> done
[10:15] <vila> maxb: once the queue is down again, I'll retry enigmail and similar (NoFinalPath)
[10:15] <maxb> Ah, when did your fix land?
[10:15] <vila> hehe, when 2.4b4 did (or am I confused ?)
[10:15] <maxb> great
[10:17] <maxb> by the way, since we moved to 2.4b4, a number of packages seem to have started failing with BzrCheckError
[10:18] <vila> ha crap, my fix is not included in 2.4b4 :-/
[10:20] <vila> maxb: I didn't follow who/what/when/why the upgrade was done, could we ask for 2.4b5 with good changes of success ?
[10:20] <maxb> The upgrade occurred as a side effect of jubany hardy->lucid
[10:21] <maxb> To get 2.4b5, we should speak to jelmer since he did the lucid-cat upload for 2.4b4
[10:22] <vila> ooooh, I see, so that's probably a side-effect of lp itself upgrading to 2.4b4
[10:22] <vila> jelmer: ^
[10:26] <spiv> What was the bzr version before the lucid upgrade?
[10:27] <spiv> If it's https://bugs.launchpad.net/udd/+bug/806348, it may be that we now have a bzr version that fetches tags by default, which AFAICT is more likely to hit the corner case that triggers that error.
[10:28] <spiv> Anyway, I'm battling a cold today so I should probably log off.
[10:34] <maxb> spiv: Before you go...
[10:34] <maxb> Would you be ok with me doing the appendrevisionsonly udd rollback?
[10:38] <maxb> I think the tag fetching is indeed the issue
[10:42] <jelmer> hi vila, maxb
[10:43] <jelmer> it's a side-effect of the builders almost upgrading to 2.4b4
[10:43] <jelmer> (Launchpad has its own bzr copy, the builders use the bzr from lucid-cat)
[10:43] <vila> ha, thanks for confirming
[10:43] <vila> jelmer: so how about 2.4b5 ? :D
[10:44] <jelmer> vila: Happy to backport 2.4b5 as well, though I'd prefer to get it into oneiric first
[10:44] <vila> jelmer: fair enough
[10:45] <vila> jelmer: just let me know when it's deployed on jubany so I can retry the affected packages
[10:45] <jelmer> vila: ok
[10:52] <maxb> jam: Thanks for proxying that RT for me :-)      By the way, do you need /srv/package-import.canonical.com/new/test-scripts/ any more? (I tried to mv it into probably_obsolete, but it's owned by jameinel not pkg_import, so I couldn't)
[10:52] <jam> don't you have sudo rights?
[10:52] <jam> anyway, not specifically
[10:54] <maxb> I can sudo to pkg_import, but the file ownership is such that only jameinel or root can move it
[10:54] <jam> removed
[10:54] <maxb> Thanks.
[11:14] <spiv> maxb: go ahead
[11:14] <maxb> acknowledged
[11:50]  * jelmer -> doctor, back in ~1.5 hrs
[13:18] <vila> jam: https://code.launchpad.net/~vila/bzr/786980-url-aliases/+merge/68069 is up for review
[13:31] <jam> vila: approved
[13:32] <vila> \o/
[13:32] <vila> jam: thanks ;)
[14:09] <vila> jelmer: what did the doctor say ?
[14:11] <jelmer> vila: Salut!
[14:12] <jelmer> vila: she took most of the stitches out :)
[14:12] <vila> \o/
[14:12] <vila> (added bonus for 'she', they are more careful ;)
[14:17] <fullermd> Careful?  Nah, you just gotta do it quick.  You grab one stick with a pair of pliers, see, and...
[16:41]  * maxb unsubscribed ~bzr-core from lp:bzr/2.4 and subscribed ~bzr-codereview-subscribers instead
[16:58]  * jelmer waves to maxb
[17:14]  * vila fixes the wiki page used by the losas to create the 2.4 branch so in 6 months maxb won't have to tweak the subscriptions again
[17:14] <maxb> It seems immensely silly that we need LOSAs for this
[17:16] <vila> maxb: DRY :D
[17:16] <jelmer> maxb: at least it's every 6 months now rather than every month..
[20:26] <poolie_> lifeless, in theory of course we can detect someone else has started doing the replacemen
[20:26] <poolie_> in practice there are quite a few different possible traces
[20:29] <poolie_> maybe we should have initialize(threaded=True)
[20:43] <lifeless> poolie_: that sounds like a possible compromise
[20:43] <lifeless> poolie_: my concerns about single-threaded overhead are perhaps unwarranted
[20:43] <lifeless> poolie_: changing it and testing should be pretty straight forward
[20:44] <poolie_> by booting loggerhead and running several clients?
[20:47] <lifeless> 'bzr st' or similar
[20:47] <lifeless> I meant assessing the impact of a simple mutex solution
[20:48] <poolie_> right