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