[00:06] <poolie> what to do today? reviews maybe?
[00:25] <AfC> poolie: go for a walk outside. It's sunny. Go figure.
[00:31] <poolie> it is a lovely day here
[00:31] <lifeless> its pea soup here
[00:32] <lifeless> couldn't see across the valley before
[00:32] <lifeless> couldn't see 20 meters even
[00:36]  * AfC → coffee
[01:45] <poolie> hi spiv?
[01:46] <spiv> poolie: good morning
[01:47] <spiv> james_w: thanks for releasing bzr-builder 0.4 with the nest-part instruction!
[01:47] <james_w> spiv: thanks for writing it!
[01:48] <poolie> spiv, what do you think about merging https://code.edge.launchpad.net/~mbp/bzr/224373-2.2-ftp-response/+merge/32731 into 2.2 vs trunk?
[01:48] <poolie> perhaps just trunk is better
[01:48] <spiv> I wonder how long before Launchpad has the new bzr-builder.
[01:49] <james_w> probably not this week
[01:51] <spiv> poolie: Hmm, the risk seems pretty smal
[01:54] <spiv> poolie: especially given that e.g. http://cr.yp.to/ftp/stor.html says "A typical server accepts MKD with code 250 if the directory was successfully created"
[01:56] <spiv> poolie: so I'd be comfortable with landing that in any/all stable series (after fixing to invoke _setmode for the 250 case, I guess, but even without that it seems to be strictly an improvement)
[01:57] <poolie> ok
[02:40] <fullermd> So, what's up with bzrtools?
[02:41] <poolie> you tell me,

[02:41] <poolie> does trunk pass or fail with 2.2?
[02:41] <fullermd> What 2.2?
[02:41] <poolie> does it just need to be packaged?
[02:41] <fullermd> Latest version is 2.1.0
[02:41] <poolie> and does that work with bzr 2.2?
[02:41] <fullermd> I dunno.  'bout the only thing I use is multi-pull, and it seems fine.
[02:42] <fullermd> (trunk, that is.  2.1 bleats at least, no idea about working)
[02:43] <poolie> complains about being possibly out of date?
[02:44] <fullermd> Yah.  Only when you run a bzrtools command at least, so I haven't bothered trying to patch it away in the port build.
[02:44] <fullermd> It doesn't strike me that the API has moved all that far, so I'd offhand WAG it _works_ OK.  But still.
[02:54] <poolie> it probably will
[02:55] <poolie> mkanat: hi?
[02:55] <mkanat> poolie: Hey hey.
[02:55] <poolie> hey there
[02:55] <poolie> spm had an interesting loggerhead bug for you to work on
[02:55] <poolie> i can't remember if i gave you the number last week
[02:56] <mkanat> poolie: No, I don't think you did.
[02:56]  * poolie looks
[02:59] <poolie> spm: hi?
[02:59] <poolie> mkanat: bug 617249
[03:02] <mkanat> I'm almost sure it's going to boil down to some scalability problem, but can't know until I investigate.
[03:02] <mkanat> One CPU on one machine is never going to scale to Launchpad size.
[03:02] <poolie> could you investigate? :)
[03:03] <mkanat> poolie: I can, and I just asked for the data I need, in the bug.
[03:03] <poolie> ok
[03:03] <poolie> right it seems very likely to me that we want multiple processes, both for stability and robustness
[03:03]  * mkanat nods.
[03:12] <mwhudson> +1
[03:21] <fullermd> Oh, perforce.  Thank you so much for making fundamental design decisions that make it completely impractical to offer anonymous access...
[03:32] <spiv> poolie: could I get a quick review of http://bazaar.launchpad.net/~spiv/bzr/merge-2.1-into-2.2/revision/5078?  It's related to your symlink fixes.  Without that fix a merge of 2.1 into 2.2 fails (because 2.2's wt.iter_changes calls self.conflicts calls self.list_files, which is the method that patch changes)
[03:34] <spiv> I think it would be valid to backport that to 2.1 and 2.0, but I'm not sure that it affects people much.  Maybe a 'bzr ls' would trigger it?
[04:29] <poolie> hi spiv
[04:33] <poolie> spiv, that seems reasonable to me
[04:33] <poolie> biab, rebooting
[08:19] <vila> hi all !
[08:21] <lifeless>   hi vila
[08:24] <poolie> hi vila, welcome back!
[08:26] <vila> poolie, lifeless : Thanks !
[08:27] <vila> hmm, babune almost all red expect for gentoo and lucid, quite expected though :)
[08:33] <poolie> mm
[08:33] <poolie> even maverick and other ubuntu releases?
[08:35] <vila> I haven't setup a maverick slave yet, but other releases are red yes, I'm checking why
[08:35] <poolie> vila, i wouldn't want you to spend a huge amount of time getting it green again
[08:35] <poolie> it's kinda good but i'm not convinced it's been a really good value for us
[08:37] <poolie> i'm not quite sure where the cutoff would be
[08:37] <vila> :)
[08:38] <vila> Looks like transient failures. Let's see how it goes tomorrow before worrying about it
[08:38] <poolie> k
[12:01] <jml> I'd like to make a working tree that has another branch (tree?) merged into it, in order to test a script I'm writing. How would I do that most easily using bzrlib?
[12:02] <maxb> Wouldn't it be trivial to do it via the command line?
[12:03] <jelmer> jml: tree.merge_from_branch(other_tree.branch)
[12:04] <jml> maxb, yes, but I'm not spawning a process for this.
[12:04] <jml> jelmer, thanks.
[12:13] <jml> is there a similarly convenient way to clone a branch?
[12:14] <jml> branch.bzrdir.sprout, it seems
[12:15] <jelmer> yup
[13:38] <weigon> hmm, a bzr pull or a
[13:38] <weigon> hmm, a bzr pull on a stacked-branch doesn't update the workingtree ?
[13:39] <weigon> I really have to run bzr update to update the working dir ?
[13:41] <weigon> I created the branch with:
[13:41] <weigon> src_b.bzrdir.sprout(dst_branch, stacked=True).open_branch()
[13:41] <weigon> where src_b is a branch.Branch.open(src_branch_url)
[13:48] <jelmer> weigon, only if the workingtree is colocated
[13:48] <jelmer> weigon: you're doing a "bzr pull" as command, or using the API?
[14:00] <weigon> jelmer: using the bzrlib
[14:01] <jelmer> weigon: in that case, call pull() on workingtree, not branch
[14:01] <weigon> ah, thx
[14:01] <weigon> jelmer: *doh* makes sense :)
[15:56] <RobOakes> Is anyone aware of a step-by-step tutorial for bzr builddeb?  I've configured things as explained here (http://jameswestby.net/bzr/builddeb/user_manual/), but I'm just getting an error.
[15:56] <RobOakes> Error: Must supply file_id or path.
[15:56] <james_w> RobOakes: from what command?
[15:56] <RobOakes> I have no idea what file_id or path it's referring to, though.  (Running in merge mode).
[15:56] <RobOakes> bzr builddeb
[15:57] <james_w> RobOakes: please run again with -Derror and pastebin the traceback
[15:58] <RobOakes> james_w: Here is the pastebin: http://pastebin.com/uD1xnc6V
[15:59] <james_w> RobOakes: please file a bug at https://bugs.launchpad.net/bzr-builddeb
[15:59] <james_w> RobOakes: what does an ls of your bzr branch look like? Is it "changelog control copyright rules" etc?
[16:01] <RobOakes> It just shows the debian packaging files (control, copyright, ...)  Unfortunately, the project is complicated, so there are a lot files.
[16:02] <james_w> RobOakes: and you have a debian/ directory there too?
[16:02] <RobOakes> No, just a symlink to the debian directory.  The article I was reading suggested this as a workaround for some packaging systems.
[16:03] <RobOakes> Should say symlink to the current directory.
[16:03] <RobOakes> And, removing the symlink fixed the problem.
[16:04] <james_w> RobOakes: "bzr add" of the symlink should work too
[16:05] <RobOakes> Okay, that's good to know.
[16:05] <RobOakes> Thank you very much for the help.
[16:06] <james_w> RobOakes: please file that bug, as it shouldn't crash in that situation
[16:06] <RobOakes> I am doing that right now.
[16:07] <james_w> thanks
[20:07] <dash> i have a bzr branch that originally used loom; it's at lp:~washort/+junk/modules
[20:08] <dash> i can't find a way to unloomify it for consumption by people without the plugin
[20:08] <dash> export-loom doesn't do anything
[20:08] <dash> is there something i'm missing?
[20:16] <jam> dash: did you ever run 'bzr record' ? That might be necessary before 'bzr export-loom' works. (I'm just guessing, though)
[20:16] <dash> jam: well it gets worse, this is branched from somebody else's loom branch
[20:16] <dash> on which 'bzr record' was never run
[20:17] <dash> i guess i could go ahead and do it, that might make a difference
[20:17] <jam> dash: bzr init new-branch; cd new-branch; bzr pull my-loom-branch ?
[20:17] <dash> worth a shot
[20:21] <quotemstr1> How do you set a branch's parent branch?
[20:21] <james_w> quotemstr1: "bzr pull --remember" I think
[20:22] <quotemstr1> Ah, okay. I was trying to find some git-like configuration entry.
[20:22] <quotemstr1> Works; thanks.
[20:23] <GaryvdM> quotemstr1: It's not really recommended, but I often just edit .bzr/branch/branch.conf
[20:23] <quotemstr1> That was my backup plan.
[20:34] <jelmer> GaryvdM: hi
[20:34] <jelmer> GaryvdM: did you see my bug report earlier about test failures in the qbzr testsuite?
[20:34] <GaryvdM> Hi jelmer
[20:36] <GaryvdM> jelmer: Yes. I have landed a fix that fixes the bug on new versions of qt, but breaks old versions of qt (<=4.4)
[20:36] <jelmer> oh
[20:36] <jelmer> well, that should take care of it for me I guess...
[20:37] <GaryvdM> And then I discovered that the test is missing a whole bunch of things that It should be testing....
[20:37] <GaryvdM> So I still need to put some effort in to it.
[20:37] <GaryvdM> Thanks for the report
[20:42] <jelmer> np :-)
[20:42] <jelmer> I'm trying to get 'bzr selftest' to pass on my local machine and that's harder than it should be ...
[23:15] <poolie> jelmer: urk, what kind of thing is failing? plugins or core?
[23:17] <jelmer> poolie: various plugins
[23:17] <jelmer> mainly adapting tests that have never been tried against particular plugin classes
[23:19] <jelmer> poolie: the recent control dir work I did was inspired by this
[23:19] <poolie> maybe we can get vila to run some of these plugins in babune, when they're close to being green, and then keep them cleaner
[23:19] <lifeless> jelmer: thank you for doing this
[23:20] <lifeless> jelmer: Its what I've been dreaming of :)
[23:29] <jelmer> lifeless, glad to hear it :-)