[01:16] <lifeless> maxb: thats probably because the maintainer script to clean them up is not present in the new package
[15:56] <jelmer> maxb: hmm, I'm not sure I follow
[15:57] <jelmer> maxb: some sort of shim?
[17:27] <jelmer> hmm, odd
[17:27] <jelmer> Bad Gateway error during recipe build :_/
[17:52] <beuno> hi vila!
[17:52] <beuno> any bzr devs around?
[17:52] <vila> beuno: hey. No, I'm not really there, just relaunched xchat
[17:53] <beuno> :)
[18:07] <jelmer> hey beuno
[18:08] <beuno> hey jelmer!  happen to be bored?  :)
[18:08] <beuno> I'm working on a branch to add downloading tarballs to loggerhead
[18:09] <beuno> lifeless pointed out that saving them to a dir to serve them isn't super optimal, but it seems I don't really have an (easy) choice with the way things are set up in bzr
[18:09] <beuno> wanted some smarter eyes to confirm
[18:10] <beuno> *download tarballs of revisions _from_ loggerhead
[18:10] <beuno> bzrlib.export.export only takes a path
[18:11] <jelmer> yeah, it seems like we should be able to improve on that
[18:11] <jelmer> though we should watch out for keeping lp:linux tarballs in memory, too
[18:12] <beuno> right
[18:13] <beuno> I started digging in bzrlib, and it's not trivial to change this
[18:13] <jelmer> it looks like there already is some support for writing to stdout
[18:13] <beuno> oh?
[18:14] <jelmer> '-' is treated specially
[18:14] <jelmer> in bzrlib.export.tar_exporter
[18:14] <beuno> ah
[18:15] <beuno> interesting, I missed that
[18:16] <jelmer> this might also be a good moment to fix some other related issues
[18:16] <jelmer> bug 513752 and bug 711226
[18:17] <jelmer> (also cases where it would help if the exporters could write to an arbitrary stream rather than a specific file)
[18:17] <beuno> hm, if I specify -, it creates a dir called -   :/
[18:17]  * beuno nods
[18:17] <jelmer> you need to specify the format I think
[18:19] <beuno> right, that seems to work
[18:19] <beuno> well, "work", now I need to capture stdout and stream that
[18:20] <beuno> I suspect this may be harder to actually deploy on launchpad, though
[18:20] <jelmer> beuno: urgh
[18:23] <jelmer> beuno: we should just factor the relevant code out of bzrlib.export.tar_exporter
[18:24]  * beuno nods
[18:24] <beuno> doesn't seem too hard, it's just quickly getting out of hand  :)
[18:24] <lifeless> beuno: a temp *file* would be ok
[18:25] <lifeless> beuno: its a persistent temp dir I was whining about
[18:25] <beuno> lifeless, ah, hi lifeless   :)
[18:25] <beuno> lifeless, well, that makes things much simpler
[18:26] <lifeless> a temp file will clean up when its closed
[18:28] <beuno> lifeless, ok, so I'll fiddle with this stdout approach for a bit so at least I have it handy, and then change it to use a tmp path
[18:29] <lifeless> beuno: tmp *file* specifically - tempfile.TemporaryFile
[18:30] <beuno> lifeless, ack
[18:33] <maxb> jelmer: So, what I was thinking was either a straight backport of dh_python2, or a fake dh_python2 executable or debhelper sequence file that would run pycentral instead
[18:34] <maxb> Either way, a solution which does not require modifications to each package's packaging
[18:49] <jelmer> maxb: sounds reasonable
[18:51] <beuno> lifeless, so, since bzrlib.export only really takes a path, it seems I'd need to poke at bzrlib in order to use a TemporaryFile
[18:52] <beuno> or capture stdout and write to this new tempfile
[18:52] <beuno> or...  maybe this temp file has a path, which I guess it would
[18:53] <beuno> of course it does
[18:56] <lifeless> beuno: you may need to change bzrlib.export
[18:56] <lifeless> beuno: TemporaryFile doesn't have a name
[18:56] <lifeless> NamedTemporaryFile is not crash proof
[18:56] <beuno> lifeless, no, but NamedTemporartFile... ah
[18:56] <lifeless> NTF depends on __del__
[18:57] <lifeless> if we kill the process - not unheard of :P - it will leak and slowly mess up /tmp
[18:57] <jelmer> beuno: fwiw I've got a branch which should let you do what you need
[18:57] <beuno> hmeland_, w00t!  that's great
[18:57] <beuno> er
[18:57] <beuno> jelmer, I meant  :)
[18:58] <beuno> although, it kinda sucks for this feature to depend on a future bzr
[18:58] <jelmer> it factors out the bit of bzrlib.export.tar_exporter that writes to the tarball, so it requires you to pass in a tarfile.tarfile object and a tree
[18:59] <beuno> I guess I could hack in using stdout for older bzr versions, and the cleaner one for newer ones
[19:06] <maxb> jelmer: Hi. Shall I file bugs to have the ftpmasters update the overrides for qbzr and wikkid, both of which got override disparity emails on their most recent uploads, or is that on your todo list?
[19:23] <jelmer> maxb: Oh, I don't think I have seen those.
[19:53] <maxb> jelmer: they went to you@debian.org and pkg-bazaar-maint@lists.alioth
[19:55] <jelmer> maxb: wikkid probably should be web
[19:55] <maxb> I think in both cases the package has it right
[19:56] <jelmer> maxb: yeah
[19:57] <maxb> i.e. wikkid s/vcs/web/ because its defining characteristic is being a wiki
[19:57] <jelmer> maxb: if you can file bugs that'd be great
[19:57] <maxb> will do
[21:19] <jelmer> beuno: https://code.launchpad.net/~jelmer/bzr/export-tgz-711226/+merge/53183
[21:36] <jelmer> hmm, like Launchpad Bazaar has an interesting definition of "easy" when it comes to bugs
[21:54] <beuno> jelmer, \o/   thanks, I'll take a peak in a little while
[21:58] <lifeless> beuno: 'peek'
[23:15] <spiv> Morning folks
[23:28] <arjenAU> mm-mysql: hey mark!
[23:28] <jelmer> spiv: mørning!
[23:30] <spiv> jelmer: hï :P
[23:54] <maxb> jelmer: btw, I've just committed "Take 02_external_configobj out of debian/patches/series because it causes tests to fail." to the daily-ppa branch. Any thoughts on what we do about that for Debian?
[23:54] <jelmer> maxb: submitting the fix to the python-configobj package
[23:56] <jelmer> it's on my todo list but I haven't had time to do it yet