[00:15] <poolie> hi all
[02:09] <poolie> mgz: are you here?
[02:10] <poolie> i get an error on unix from your 220464 changes
[04:28] <spiv> stewart: to be clear, that bug affects all pack-based repository formats, including 2a
[04:29] <spiv> stewart: so upgrading to 2a probably won't workaround it (it *might* by accident, by affecting the timing of the race)
[04:29] <spiv> stewart: not doing concurrent identical fetches into the same shared repository will avoid it (e.g. give each build slave its own repo)
[06:14] <stewart> spiv, ahh... for one project I noticed it went away with 2a upgrade (although as part of building that project it bzr branch another one... so still hits it that way)
[06:14] <stewart> spiv, although I certainly don't have a large enough sample size to say it wasn't just due to timing changes.
[07:43] <maxb> bah, sysvinit udd import failed with a transient connection error
[07:43] <maxb> Could someone requeue? (*NOT* with --full)
[08:57] <mgz> poolie: I am now, what's the error?
[08:58] <mgz> ah, win32utils importing on non-win32 platforms
[08:59] <mgz> that change looks fine... but pqm still didn't land?
[10:00] <kazade> does bzr have support for nested branches?
[10:05] <maxb> It's partially developed, but not ready for production use
[10:14] <maxb> I am beginning to hate TreeTransform's cryptic error messages telling you nothing but a transient transaction id
[10:23] <vila> maxb: yeah, welcome to the club :-/ sysvinit requeued by the way
[10:23] <maxb> :-)
[10:23] <maxb> thanks
[10:25] <maxb> Depending on how busy you are, you might apply "bzr break-lock" to these - http://package-import.ubuntu.com/status/67061a280d79e806c089681dd8b4a524.html
[10:26] <maxb> They all relate to requeued imports from a long time ago
[10:26] <vila> not overly busy but not there for long either (SO waiting :-})
[10:26] <vila> where are the branches ?
[10:28] <maxb> where? in /srv/package-import.canonical.com/new/updates/(packagename)/*
[10:28] <vila> yeah, found them, not all are locked, will be tedious, on it
[10:30] <maxb> tedious? Could you not just do "for i in *; do bzr break-lock $i; done" in each package directory?
[10:30] <vila> Isn't this tedious ? :)
[10:30] <vila> Bad ENglish again ?
[10:31] <vila> oh, you mean breaking the lock without checking first ?
[10:31] <maxb> well, the locks should all be really old ones
[10:31] <vila> ha, silly, the check occurs while trying to break it of course
[10:32] <vila> yeah, hey, be patient I'm just waking up :)
[10:32] <fullermd> Always a bad idea.  I recommend against it.
[10:32] <maxb> Hah
[10:32] <maxb> (And the requeue_package.py --all-of-type ktorrent )
[10:32] <maxb> *then
[10:36] <vila> maxb: done (and gone ;)
[10:36] <vila> maxb: I'll be around for a bit later
[10:38] <vila> maxb: they all seem to fail (I didn't check the previous cause). locks will need to be broken again ?
[10:38] <vila> maxb: this sounds like a good command to add no ?
[10:41] <vila> maxb: ha, I see you're already on this track (catching up with udd mail)
[10:44] <maxb> This is a case of shuffling failures from one failure signature to another to organize the failures page better :-)
[10:46] <vila> lol
[11:10] <maxb> AHA
[11:10] <maxb> bzrtools' tarball import code dislikes it if a symlink to a directory turns in to a real directory in successive versions
[11:14] <maxb> Hmm
[11:15] <maxb> So, if I have this directory structure:
[11:15] <maxb> lenny/
[11:15] <maxb> lenny/foobar
[11:15] <maxb> squeeze -> lenny
[11:16] <maxb> And I call tt.trans_id_tree_path("squeeze/foobar"), and get the same trans_id as for "lenny/foobar" ..... is TreeTransform wrong?
[11:27]  * maxb wonders why trans_id_tree_path ever wants to follow symlinks, actually
[13:19] <hicham> does bzr have a git-format patch equivalent ?
[13:36] <spiv> hicham: yes: a) bzr help merge-directive, or b) install bzr-git plugin, use --format=git IIRC
[13:40] <hicham> thanks spiv