[00:26] <bdmurray> I verified the fix for bug 1076186 - maybe it can be fast tracked?
[00:26] <ubot2> Launchpad bug 1076186 in ubuntu-release-upgrader (Ubuntu Quantal) "not possible to upgrade to raring" [High,Fix committed] https://launchpad.net/bugs/1076186
[00:44] <infinity> bdmurray: Looking.
[00:47] <infinity> bdmurray: What breaks without those dh_ fixes (and how did we not notice that in the previous uploads?)
[00:48] <infinity> bdmurray: Oh, I'm guessing all but the _clean one were no-ops, and no one notices when clean fails? :P
[01:40] <infinity> apw: So much for resetting the build number on the move to -1? :)
[01:50] <infinity> cjwatson: So, uhm.  I'm guessing britney has no magic in place to match the nbs report's clever handling of d-i-images?
[01:51] <cjwatson> No, not as yet
[01:51] <infinity> This could prove irksome.
[01:51]  * infinity wonders why the module list only changed on ppc...
[01:54] <cjwatson> Well, different source now
[01:54] <infinity> Yes, I mean, I wonder why they gratuitously changed from master. :P
[01:55] <cjwatson> Yeah, can't help you there
[01:59] <infinity> https://github.com/benmcollins/ubuntu-raring-powerpc/commit/e3447de62300abec9634e145db45b14a2f23268e
[01:59] <infinity> Hrm.
[01:59] <infinity> Was there no pcmcia on powerbooks?
[02:00] <infinity> There totally was. :/
[02:00] <doko> at least my 12" doesn't have one
[02:01] <infinity> A quick google for "pcmcia powerbook" shows a slot on several of the G3 and G4 models.
[02:01] <cjwatson> I had PCMCIA on my PowerBook
[02:01] <cjwatson> Well, CardBus
[02:02] <cjwatson> I think it was CardBus.  I forget all the terms now ...
[02:03] <infinity> Kinda curious about the removal of serial-modules.udeb too, but I'm not sure what was actually in it.
[11:02] <ev> can someone please reject that txstatsd and tastypie upload?
[11:02] <ev> I put the wrong option in -f, sorry
[11:02] <ev> err rather I didn't put in the ppa
[11:04] <davmor2> ev hmmm tasty pie
[11:05] <ev> it's not delicious, I assure you
[11:06] <davmor2> ev noooooooooooo the pie can't lie I already found out the cake was you can't steal the pie too
[11:06] <xnox> after tastypie, you can always $ apt-get install guilt =))) but it's only a suggests relationship.
[11:06] <ev> :)
[11:06] <xnox> !info guilt
[11:06] <ubot2> 'maverick' is not a valid distribution:
[11:06]  * xnox goes to #ubuntu-irc for a second.
[11:07] <xnox> !info guilt
[11:07] <ubot2> 'maverick' is not a valid distribution:
[11:07] <infinity> ev: I see txstatsd, where's tastypie hiding?
[11:08] <infinity> Oh, there.
[11:08] <xnox> ubottu> guilt (source: guilt): quilt for git; similar to Mercurial queues. In component universe, is optional. Version 0.35-1 (quantal), package size 56 kB, installed size 145 kB
[11:08] <ev> thanks infinity
[11:09] <infinity> NP.  Always happy to reject your uploads.
[11:09] <infinity> A++, would reject again.
[11:09] <ogra-cb_> infinity, ... nexus7 ?
[11:09] <infinity> ogra-cb_: Sure, I can reject that too, if you like.
[11:09] <ogra-cb_> :P
[11:10] <infinity> Let me nap first.  Ping me with some violence in ~5h.
[11:10] <ogra-cb_> ok
[11:10] <infinity> I got sidetracked with glibc most of yesterday, sorry. :/
[11:10] <ogra-cb_> well, no new builder yet, so it is still not auper urgent
[11:10] <ogra-cb_> *super
[11:11] <ogra-cb_> but be prepared that i start whining once there is a builder (tomorrow according to IS)
[11:11] <ogra-cb_> :)
[11:11] <infinity> Heh.  I'm prepared for whining. ;)
[11:12] <infinity> Have you already got all the cdimage/live* bits in place and tested locally?
[11:12] <ogra-cb_> well, mostly
[11:13] <ogra-cb_> i@m at a point where i would like to have real builds to fine tune, generally they should work
[11:13] <ogra-cb_> and i havent done any work on the publishing stuff in cdimage yet, but i want to have img files for that
[11:13] <infinity> Ahh, it's leveraging the ac100 tarball bits?  Handy.
[11:13] <ogra-cb_> right
[11:13] <infinity> Let the hacks live on!
[11:14] <ogra-cb_> heh
[11:15] <ogra-cb_> xnox wants us to distribute a combined tarball image instead of two files, so that will still need some fiddling in debian-cd and cdimage
[11:15] <infinity> Instead of bootimg/img, you mean?
[11:15] <ogra-cb_> right
[11:15] <infinity> Is that doable?
[11:15] <ogra-cb_> and having usb-creator unpack it
[11:16] <xnox> ogra-cb_: correction at uds we agreed to provide combined tarball (ev, xnox and ogra are all share blame here ;-) )
[11:16] <infinity> Oh.  But that means people without usb-creator will have an extra manual unpack step.
[11:16] <ogra-cb_> tar xzvf ubuntu-desktop.tar.gz *.bootimg *.img
[11:16] <ogra-cb_> err
[11:16] <ogra-cb_> czvf
[11:16] <infinity> I suppose that's not world-ending.
[11:16] <ogra-cb_> infinity, right, but only one download
[11:16] <infinity> Yeah, fair enough.
[11:16] <ogra-cb_> and its harder to download two non matching files that way
[11:16] <infinity> Might I suggest zip instead of tar.gz?
[11:17] <ogra-cb_> sure
[11:17] <ogra-cb_> i would even prefer a format that cdimage doesnt know about yet
[11:17] <xnox> infinity: are zip's rsyncable / zsyncable?
[11:17] <ogra-cb_> instead of having to extend an existing one
[11:18]  * xnox doesn't feel like re downloading full nexus7 images every day.......
[11:18] <infinity> xnox: Oh, that I'm not sure of.  But easily researchable/testable.  I was mostly thinking if someone wanted to write up a quick "how to do this from Windows" doc, the first step being "download some weird third-party archive manager" is a bit unfriendly.
[11:18] <ogra-cb_> tar.gz is currently handled as "root filesystem archive"
[11:18] <ogra-cb_> having to hack that upp to actually know it is not will be a bit painful
[11:18] <knome> when's status.u.c updated with more blueprints/topics? :)
[11:18] <xnox> infinity: ogra-cb_: what is that fastboots "update tarball thingy"? can it only have the boot & userdata without recovery?
[11:19] <ogra-cb_> xnox, i think that refers to an update.zip which we explicitly avoided
[11:19] <xnox> is that zip? cause it would be nice to be able to point Mac/Windows users at the AndroidSDK tools.
[11:19] <xnox> and say, use those.
[11:19] <infinity> xnox: I see some claims that zip is pretty rsync friendly.
[11:20] <ogra-cb_> gzip definitely has an option for rsync
[11:20] <ogra-cb_> --rsyncable or so
[11:20] <infinity> gzip != zip
[11:20] <ogra-cb_> oh, indeed
[11:21] <xnox> knome: it autoupdates itself a few times a day. but the blueprints should be accepted for the raring series to show up on the status tracker.
[11:22] <infinity> Ah-ha.
[11:22] <knome> xnox, ok. who can do that?
[11:22] <infinity> For maximum rsyncability, just use "zip -0", since the contents are already compressed anyway.
[11:22] <ogra-cb_> knome, the approver :)
[11:22] <infinity> Then you're just getting an uncompressed archive, not unlike a tar, but more cross-platform friendly.
[11:22] <ogra-cb_> yeah
[11:22] <knome> ogra-cb_, no. i can only propose for raring, even if i am the approver
[11:22] <xnox> infinity: sounds good.
[11:23] <knome> ogra-cb_, if that's a bug, pretty please give me more rights to approve for raring :)
[11:23] <xnox> ogra-cb_: i think you need special extra magic powers =))))
[11:23] <knome> imo flavor leads should have that
[11:23] <ogra-cb_> knome, lol, what makes you think i can ?
[11:23] <ogra-cb_> ++
[11:23] <ogra-cb_> fully agreed
[11:23] <knome> ogra-cb_, no idea. doesn't hurt to knock on all the doors.
[11:23] <knome> :)
[11:23] <infinity> ogra-cb_: Or "zip --compression-method store" if you prefer your command line options to be self-documenting (-0 isn't exactly intuitive).
[11:23] <ogra-cb_> i guess you might need to ask in #launchpad
[11:24] <cjwatson> The organisation of the Ubuntu project isn't #launchpad's business
[11:24] <cjwatson> Ask the tech board list
[11:24] <ogra-cb_> infinity, k, i'll use that in the debian-cd post-boot stuff
[11:24] <knome> cjwatson, cheers. do you have any idea if that's feasible though?
[11:26] <cjwatson> knome: It's technically possible, but since "flavour leads should all be drivers, even those who weren't track leads at UDS" isn't something that's been articulated as a general policy before, we'd want to talk about it
[11:27] <infinity> xnox: Anyhow, should you be curious, it looks like zip's storage structure is very rsyncable, even when using deflate (ie: compression) instead of store (none), so learned something new today.
[11:27] <xnox> infinity: \0/ awesome.
[11:27] <knome> cjwatson, okay
[14:24] <Riddell> am I doing something wrong in removing this package? http://paste.kde.org/607310/
[14:26] <ScottK> You can't remove from the release pocket post-release that way.
[14:26] <cjwatson> Riddell: There's a set of known timeouts affecting LP at the moment.  I suggest deferring removals until a later day.
[14:26] <cjwatson> Though ScottK is right too.
[14:26] <cjwatson> Even if you'd got past the timeout it would (hopefully) have refused on the grounds that that pocket is immutable.
[14:26]  * ScottK doesn't know what the process is for that.
[14:27] <cjwatson> Erk, or possibly not; I don't see anything clear in the code to forbid it
[14:27] <cjwatson> So please don't try
[14:27] <cjwatson> At any rate the change would never be published
[14:27] <cjwatson> You need to upload a new version that either fixes the problems or renders the package useless.
[14:28] <cjwatson> You should think about as hard about the latter as you might expect ...
[14:29] <Riddell> ug, that's new(ish) I've removed packages from released versions before
[14:30] <xnox> Riddell: in the devel release. not post-release.
[14:30] <xnox> also why?
[14:30] <cjwatson> Riddell: No, it's not new at all.
[14:31] <cjwatson> Riddell: Perhaps you only thought you had removed them, or perhaps you removed from a post-release pocket.
[14:31] <cjwatson> It has *never* been permitted (except perhaps accidentally, but definitely not by policy) to remove from the release pocket.
[14:31] <Riddell> there's no security fix for owncloud other than "upgrade to the latest" and a backport isn't possible (I counted about 15 other packages needing a backport before I gave up)
[14:31] <xnox> you can remove from -proposed
[14:34] <cjwatson> xnox: Which is useless.  Can I handle this?
[14:34] <cjwatson> Riddell: The only release pocket whose Release file is dated after release is hardy.
[14:35] <cjwatson> So it's possible that a mistake was made there (I vaguely remember something, although I don't think it was a removal - could be wrong)
[14:36] <cjwatson> xnox: (owncloud isn't *in* oneiric-proposed, so nothing to remove, and removals of things that don't exist in a pocket don't work that way)
[14:37] <cjwatson> There are no publishing records dated from 2012-04-25 onwards in hardy, so I think that timestamp is misleading.
[14:37] <xnox> cjwatson: sorry, wasn't clear. and indeed it's not in oneiric-proposed, so moot.
[14:38] <cjwatson> Riddell: The only thing that can be done in that case is to replace the package in -proposed with one that refuses to do anything.
[14:40] <Riddell> ug
[14:40] <cjwatson> After all nothing else would close the security hole for oneiric users anyway
[14:42] <cjwatson> Anyway, it's been this way since warty
[15:37] <TheLordOfTime> stgraber, around-ish?
[15:37] <stgraber> TheLordOfTime: yep, what's up?
[15:38] <TheLordOfTime> got time to jump into -bugs for a second?
[16:23] <bdmurray> why does rmadison still return natty info?
[16:25] <stgraber> bdmurray: my guess would be that the archive mirror on lillypilly is still mirroring natty (as it still exists on archive.u.c)
[16:30] <ScottK> It's usually somewhat after EOL that things get moved to old-releases.
[16:30] <bdmurray> Its almost been a month! ;-)
[16:32] <TheLordOfTime> heh
[17:04] <cjwatson> bdmurray: because I hadn't deleted it from the config.  fixed
[17:06] <bdmurray> cjwatson: thanks
[18:12] <rtg> can I get the Nexus7 packages NEWed for Raring ? linux-nexus7, linux-meta-nexus7, and linux-firmware-nexus7
[18:36] <infinity> rtg: Working on it nowish.
[20:19] <infinity> stgraber: Has queuebot given up on !raring?
[20:21] <stgraber> infinity: hmm, shouldn't have, what did it miss?
[20:22] <infinity> stgraber: I know bdmurray accepted some SRUs a while back, since I see them building (eglibc in lucid and oneiric).
[20:22] <infinity> stgraber: And looking through backscroll, all I see is a lot of raring, so I'm making assumptions. :P
[20:23] <infinity> stgraber: In fact, backscroll doesn't show it catching those uploads either.
[20:24] <infinity> Same with gccgo-4.7/precise, and likely a bunch of others.
[20:24] <stgraber> hmm, right, last one for !raring was 9 hours ago
[20:27] <stgraber> so apparently it received an unknown or corrupted status for some uploads in LP, sadly the code to catch that and raise an exception was buggy and raising itself an exception... I fixed it now so if it happens again I should be able to figure out what's going on
[20:28] <stgraber> (forgot to rotate the log, was getting pretty big...)
[20:31]  * stgraber needs to get queuebot to reload its config without restarting entirely...
[20:33] <stgraber> oops, wrong debug value, that's the "let's dump all the queues at startup time" option and I don't quite want that...
[20:35] <stgraber> sorry for the spam, everything should be back to normal now...
[20:42] <kenvandine> can someone please reject friends from the quantal-proposed NEW queue?  that was an accidental dput :)
[20:42] <infinity> kenvandine: Done.
[20:42] <kenvandine> thanks!
[20:53] <slangasek> kenvandine: we are always happy to reject friends
[20:53] <kenvandine> slangasek, lol
[21:55] <micahg> stgraber: ^^ have fun :)
[21:56] <stgraber> micahg: yay! I'll check that we don't have any bad bugs with lxc on quantal and if all looks good, will request a backport for it too
[23:30] <doko>  infinity what was the reason for the boost-mpi reject for quantal?
[23:35] <infinity> doko: I didn't reject it, but at a glance, I'd say because it has absolutely no reference in the changelog as to why it was uploaded?
[23:35] <doko> infinity, because it always has to match the exact version of boost
[23:36] <doko> main/universe split
[23:36] <infinity> doko: Yes, IRC isn't a changelog.  It should have a task in the bug, and get closed.
[23:36] <infinity> In fact, it DOES have a task on the SRU bug.  All the more reason the upload was wrong to not reference it.
[23:37] <xnox> doko: I think ScottK pinged the sponsoree about rejecting it and asking to reupload with a changelog bug #.
[23:37] <infinity> doko: If you want to just fix it up and reupload, I'll review the pair of them.
[23:37] <doko> pair? wasn't the other one accepted?
[23:38] <infinity> No, it's sitting in the queue.
[23:38] <xnox> infinity: the person who created the package didn't know about mpi package in the first place, and I opened the bug task with a comment. My fault at not following up and demanding for the second package to close the bug #.
[23:38] <doko> doing it now ...
[23:38] <infinity> xnox: Not your fault at all that someone SRUed without a reference.
[23:39] <infinity> doko: Anyhow, modulo the bug closure, they both look sane to me.  So, if the new one's the same diff, I'll let 'em both in ASAP.
[23:51] <doko> infinity, ^^^
[23:52]  * xnox lost the game