=== jbicha is now known as Guest1332
[06:46] <micahg> BTW, the rest of the tntnet binaries will be coming through shortly
[06:49] <micahg> pitti: could I ask you to process the promotion requests in the ubuntu-archive queue as well please?
[06:49] <micahg> multiverse -> universe ones I mean
=== yofel_ is now known as yofel
[06:59] <pitti> micahg: done
[06:59] <micahg> pitti: thanks
[10:08] <RAOF> Another gtk+3.0? :/
[10:09] <seb128> RAOF, there was a regression in the previous one
[10:10] <RAOF> Yay.
[14:02] <cjwatson> precise daily CD builds should be up and running again now, though the first ones haven't run yet
[14:14] <skaet> :)
[14:14]  * ogra_ crosses fingers for arms
=== bjf[swapped] is now known as bjf
[14:44] <bjf> skaet, pitti, can someone copy the Precise kernel package (3.2.0-24.38) from -proposed to -updates?
[14:48] <skaet> bjf, hmm... looks like someones just taken care of it.
[14:48] <pitti> bjf: done
[14:49] <skaet> :)
[14:49] <bjf> pitti, thanks
[14:51] <pitti> (ubuntu-docs shouldn't go to -security, rejecting that)
[17:42] <cjwatson> I have moved the sync-blacklist to lp:~ubuntu-archive/+junk/sync-blacklist; please stop using the old location (which I'm going to render inoperative)
[17:43]  * micahg assumes that includes fixing syncpackage and/or launchpad to check the new location as well?
[17:44] <cjwatson> No, because they already used http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
[17:44] <cjwatson> Launchpad itself hasn't cared for some months
[17:45] <cjwatson> The only clients are syncpackage and auto-sync, both client-side
[17:45] <micahg> sorry, ignore me :)
[21:22] <bdmurray> is this the right channel to talk about the SRU-ability of a bug for Precise?
[21:24] <slangasek> probably
[21:25] <infinity> Almost certainly.
[21:25] <bdmurray> I want to SRU this change to Precise but I'm not excited about writing a test case
[21:25] <bdmurray> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/quantal/apport/ubuntu/revision/1961
[21:25] <bdmurray> honestly, I'm not sure how to get a .deb to generate that message
[21:26] <slangasek> hmm, quite
[21:27] <bdmurray> and this seems like an 'obviously safe patch' to me
[21:29] <slangasek> obviously safe, yes, but we also want to be sure it fixes the bug
[21:29] <bdmurray> ah true
[21:30] <slangasek> bdmurray: how about dpkg-divert --add --local --rename --divert /usr/bin/dpkg.real /usr/bin/dpkg, and then a wrapper script that deliberately clobbers any files in /var/cache/apt/archives with bogus data?
[21:31] <infinity> If you're diverting dpkg, you can just replace it with something that throws the error every time it's run...
[21:31] <infinity> Mangling data seems a bit silly at that point.
[21:32] <bdmurray> The foundations bug bot takes care of these after reporting and I only see 24 tagged not-debian-format so maybe its not worth it
[21:33] <slangasek> maybe something like this: http://paste.ubuntu.com/999824/
[21:33] <slangasek> (untested)
[21:33] <slangasek> infinity: this bug is tied up with whether strings are localized or not
[21:34] <slangasek> infinity: so I think it's easier to do a wrapper script than to correctly emulate dpkg behavior
[21:34] <slangasek> (I'm not even sure which fd the message is output on...)
[21:34] <slangasek> $ sudo dpkg -i /var/cache/apt/archives/postfix_2.9.1-5_amd64.deb
[21:34] <slangasek> dpkg-deb: error: `/var/cache/apt/archives/postfix_2.9.1-5_amd64.deb' is not a debian format archive
[21:34] <slangasek> dpkg: error processing /var/cache/apt/archives/postfix_2.9.1-5_amd64.deb (--install):
[21:34] <slangasek>  subprocess dpkg-deb --control returned error exit status 2
[21:34] <slangasek> Errors were encountered while processing:
[21:34] <slangasek>  /var/cache/apt/archives/postfix_2.9.1-5_amd64.deb
[21:35] <slangasek> bdmurray: ^^ tested
[21:35] <jdstrand> cjwatson: fyi, I started adding comments to the end of the commands I have been running on cocoplum so that 'history' will show why I am doing things
[21:36] <jdstrand> cjwatson: (referencing your eliminating shell access on cocoplum work items here)
[21:38] <bdmurray> slangasek: okay, noted I'll open a bug with the test case and precise task but may wait for more bugs before causing the SRU work
[21:38] <slangasek> bdmurray: sounds good
[21:39] <cjwatson> jdstrand: OK, but maybe best just edit the wiki page directly if you do something not mentioned there; I'm probably not going to trawl the history again :)
[21:40] <jdstrand> well, it was more about "why did he do that?" if someone was looking there. I will update the wiki as needed
[21:50] <cjwatson> Laney: your update-sources problems were a MoM bug - 'def open' at the top level of a module is liable to produce abject confusion ...
[21:51] <Laney> hrm, how did it ever work then?
[21:51] <cjwatson> It used to use file()
[21:52] <cjwatson> I changed it some time ago (since file() no longer works in Python 3), but either an older version of Python resolved local definition vs. builtin differently, or I didn't deploy that change until after MoM stopped working for other reasons
[21:53] <cjwatson> Ooh, this new box has twice the disk too
[21:53] <cjwatson> And a honkload of CPUs
[22:09] <Laney> woot
[22:15] <lamont> slangasek: what have you done!?!?
[22:21] <slangasek> lamont: mm?
[22:26] <jdstrand> fyi, my team has also been seeing oddities with the work items tracker
[22:26] <slangasek> lamont: I have done many things... care to be more specific? :)
[22:26] <lamont> slangasek: the postfix dpkg -i highlighted me, that's all.
[22:26] <slangasek> oh, haha
[22:26] <slangasek> lamont: I replaced dpkg with a very malicious shell script
[22:26] <jdstrand> people haven't been able to delete things from 'security-q-ecryptfs' and things are reordered after save ('security-q-apparmor-dev')
[22:27] <lamont> slangasek: ah, yes, I can see that now.
[22:27] <jdstrand> to delete, when I went to edit, I copied all the work items somewhere (I used gnote), and then deleted everything from the work items, saved it, then added them all back minus the one I deleted
[22:28] <jdstrand> s/I deleted/I wanted deleted/
[22:29] <slangasek> skaet: do you know who it was that worked on the WI implementation in launchpad?
[22:29] <jdstrand> I will probably be copying things somewhere else for a little while