[00:11] <poolie> so in the end you couldn't reproduce the mismatched inventory bug?
[00:21] <spiv> poolie: right
[00:22] <poolie> so what's next?
[00:22] <spiv> (ADSL still bouncy.  Gar.)
[00:22] <poolie> fiddling with that i guess
[00:22] <poolie> that sucks
[00:27] <spiv> Yeah, I'll try more fiddling.
[00:28] <spiv> The large number of odd things in that bug's current status makes it hard to be sure of anything.
[00:28] <spiv> (e.g. the deleted-but-apparently-not lp branch)
[03:15]  * spiv -> lunch
[07:26] <vila> hi all
[07:26] <vila> . o O (Shudder, I kind of know why I need to reboot after a libssl upgrade, but it's still painful)
[07:52] <poolie> hi vila
[07:52] <vila> heya poolie
[08:09] <bialix> hi poolie
[08:11] <poolie> hi bialix
[08:12] <vila> bialix: hey !
[08:12] <bialix> re Bug 710410
[08:12] <bialix> vila: bonjour!
[08:12] <bialix> poolie: we need to fix the bug in configobj
[08:13] <poolie> hi, yes, i saw your comment
[08:14] <bialix> I'd like to scratch this itch
[08:14] <bialix> we can have a test as well
[08:15] <vila> bialix: michael foord is the configobj upstream maintainer ?
[08:15] <bialix> he's the author
[08:15] <poolie> sounds good to me
[08:16] <bialix> according to http://www.voidspace.org.uk/python/configobj.html there are 2 maintainers: Michael Foord  Nicola Larosa
[08:18] <vila> oh good
[12:28] <maxb> INFO Upload was rejected:
[12:28] <maxb> INFO 	bzr-dbus_0.1~bzr47~ppa59~maverick1.dsc: Version older than that in the archive. 0.1~bzr47~ppa59~maverick1 <= 0.1~bzr47~ppa60~maverick1
[12:28] <maxb> ...weird
[12:29] <jelmer> maxb: I think thjat's a known issue
[12:30] <jelmer> maxb: sorry, different issue
[12:30] <maxb> I mean, weird that the debian branch has apparently been uncommitted from
[12:30] <jelmer> maxb: I uncommitted a direct commit to the debian branch
[12:32] <jelmer> I was going to push a merge of a newer upstream, but it seems like the unstable branch is ahead of upstream (r49 vs r47)
[12:33] <maxb> I'm having trouble understanding that last line
[12:35] <maxb> oh, hmm, do I suck at maths?
[12:35] <jelmer> debian/changelog has 0.1~bzr49-1
[12:35] <jelmer> yet lp:bzr-dbus only has r47
[12:36] <maxb> yes, apparently I typoed when setting the revno in the changelog
[12:36] <maxb> oops
[12:37] <jelmer> ah, ok
[12:46] <jelmer> I've pushed the newer snapshot merge
[12:47] <jelmer> it'll still fail until upstream actually makes it up to r49
[12:58] <maxb> um?
[12:58] <maxb> no it won't - my changelog failure doesn't affect recipe build versioning
[12:59] <jelmer> maxb: it does, my change sets the revision number of upstream back to r47
[12:59] <jelmer> maxb: whereas the currently built packages in the daily builds ppa are at r49
[12:59] <jelmer> so there will be more failures to upload
[13:00] <maxb> Yes, but recipe builds ignore what is in the changelog
[13:00] <maxb> or rather, ours do, since they don't use the debupstream substitution
[13:00] <jelmer> ah, right - sorry
[13:00] <maxb> did you mean to delete .bzrignore when merging the upstream?
[13:01] <jelmer> sortof, it's merge-upstream behaviour
[13:01] <maxb> I don't really mind, but I think you asked me not to in other packaging branches.
[13:14] <ccxCZ> any vim guru here? how do I open specific revision of some file?
[15:35] <jelmer> maxb: I'll revert it, but it'd be really nice to get this fixed in bzr-builddeb :-/
[15:58] <maxb> jelmer: I'm not sure it's a bug though - bzr-builddeb's assumption that the packaging branch should primarily derive from the tarball's contents seems like a good one
[15:58] <maxb> Maybe we should just decide we don't really need .bzrignore in packaging branches after all
[16:29] <jelmer> maxb: except in this case the packaging branch isn't derived from a tarball but from upstream
[16:30] <jelmer> at the very least it should be optional for export() to exclude .bzr* files
[17:11] <ScottK> jelmer: I'm interested in seeing an option for somehting like https://launchpad.net/bzr-diff-revid getting included into bzr so I don't have to manually install the plugin.  Any suggestions on who I should discuss that with/how I should go about it?
[17:24] <jelmer> ScottK: hi
[17:25] <jelmer> ScottK: I think it would certainly make sense for something like that to be available as an option
[17:25] <jelmer> ScottK: perhaps even as the default, though we need to watch out for breaking other tools that rely on our current format
[17:28] <jelmer> ScottK: I would suggest filing a bug about this. If you're interested in hacking on it yourself then myself or one of the other bzr developers should be able to help you get started.
[17:28] <ScottK> OK.  Will do.
[17:29] <ScottK> Default isn't that important to me as just having the option as rb-tools can select the option if it's there (I'll need to coordinate with them too).
[17:29] <jelmer> ScottK: It probably makes sense to have this is one of the available formats for bzr diff
[17:32] <ScottK> That's my thought.
[17:33] <jelmer> ScottK: e.g. "bzr diff --format=revid" (or a better name)
[17:33] <ScottK> works for me.
[17:42] <ScottK> jelmer: https://bugs.launchpad.net/bzr/+bug/720219
[18:22] <ScottK> jelmer: Does Canonical require copyright assignment for bzr contributions?
[18:32] <jelmer> ScottK: yep, see www.canonical.com/contributors
[18:33] <ScottK> jelmer: OK.  Then I guess it's up to you guys.  Sorry.
[19:28] <jdobrien> I am having trouble pushing a branch to launchpad after using bzr pipelines. is there a way i can just get rid of the pipeline business in my branch?
[19:31] <lifeless> AIUI pipeline adds a prev and next key to the .bzr/branch/branch.conf
[19:33] <maxb> Also, depending on how you started using it, it turns your branch into a lightweight checkout of a branch stored inside .bzr/pipes/
[19:33] <maxb> jdobrien: What trouble are you having?
[19:34] <jdobrien> maxb, I figured it out...
[19:34] <jdobrien> maxb, I think changing the branch nick along with relying on locations.conf confused it
[21:29] <hallyn> i branched lp:bzr-bisect, and did sudo python setup.py install.  but i can't "bzr bisect"
[22:16] <zedas> hey folks, has anyone else had problems with bzr running out of ram on OSX 64bit machines?
[22:19] <zedas> it seems that the C extensions are needed but the don't build with the right architecture on the mac.
[22:35] <poolie> zedas, i'm not sure, i would have thought they'd be built in 64-bit
[22:35] <poolie> if you have python installed you can probably rebuild bzr from source
[22:37] <zedas> poolie: trying that now, it looks like there's some issue with 64 builds on this box and python 2.6 so probably ahve to build it all from source.
[23:01] <spiv> Good morning.