[00:26] I verified the fix for bug 1076186 - maybe it can be fast tracked? [00:26] 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] bdmurray: Looking. [00:47] bdmurray: What breaks without those dh_ fixes (and how did we not notice that in the previous uploads?) [00:48] bdmurray: Oh, I'm guessing all but the _clean one were no-ops, and no one notices when clean fails? :P === doko_ is now known as doko [01:40] apw: So much for resetting the build number on the move to -1? :) [01:50] 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] No, not as yet [01:51] This could prove irksome. [01:51] * infinity wonders why the module list only changed on ppc... [01:54] Well, different source now [01:54] Yes, I mean, I wonder why they gratuitously changed from master. :P [01:55] Yeah, can't help you there [01:59] https://github.com/benmcollins/ubuntu-raring-powerpc/commit/e3447de62300abec9634e145db45b14a2f23268e [01:59] Hrm. [01:59] Was there no pcmcia on powerbooks? [02:00] There totally was. :/ [02:00] at least my 12" doesn't have one [02:01] A quick google for "pcmcia powerbook" shows a slot on several of the G3 and G4 models. [02:01] I had PCMCIA on my PowerBook [02:01] Well, CardBus [02:02] I think it was CardBus. I forget all the terms now ... [02:03] Kinda curious about the removal of serial-modules.udeb too, but I'm not sure what was actually in it. [11:02] can someone please reject that txstatsd and tastypie upload? [11:02] I put the wrong option in -f, sorry [11:02] err rather I didn't put in the ppa [11:04] ev hmmm tasty pie [11:05] it's not delicious, I assure you [11:06] ev noooooooooooo the pie can't lie I already found out the cake was you can't steal the pie too [11:06] after tastypie, you can always $ apt-get install guilt =))) but it's only a suggests relationship. [11:06] :) [11:06] !info guilt [11:06] 'maverick' is not a valid distribution: [11:06] * xnox goes to #ubuntu-irc for a second. [11:07] !info guilt [11:07] 'maverick' is not a valid distribution: [11:07] ev: I see txstatsd, where's tastypie hiding? [11:08] Oh, there. [11:08] 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] thanks infinity [11:09] NP. Always happy to reject your uploads. [11:09] A++, would reject again. [11:09] infinity, ... nexus7 ? [11:09] ogra-cb_: Sure, I can reject that too, if you like. [11:09] :P [11:10] Let me nap first. Ping me with some violence in ~5h. [11:10] ok [11:10] I got sidetracked with glibc most of yesterday, sorry. :/ [11:10] well, no new builder yet, so it is still not auper urgent [11:10] *super [11:11] but be prepared that i start whining once there is a builder (tomorrow according to IS) [11:11] :) [11:11] Heh. I'm prepared for whining. ;) [11:12] Have you already got all the cdimage/live* bits in place and tested locally? [11:12] well, mostly [11:13] i@m at a point where i would like to have real builds to fine tune, generally they should work [11:13] and i havent done any work on the publishing stuff in cdimage yet, but i want to have img files for that [11:13] Ahh, it's leveraging the ac100 tarball bits? Handy. [11:13] right [11:13] Let the hacks live on! [11:14] heh [11:15] 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] Instead of bootimg/img, you mean? [11:15] right [11:15] Is that doable? [11:15] and having usb-creator unpack it [11:16] ogra-cb_: correction at uds we agreed to provide combined tarball (ev, xnox and ogra are all share blame here ;-) ) [11:16] Oh. But that means people without usb-creator will have an extra manual unpack step. [11:16] tar xzvf ubuntu-desktop.tar.gz *.bootimg *.img [11:16] err [11:16] czvf [11:16] I suppose that's not world-ending. === mmrazik is now known as mmrazik|lunch [11:16] infinity, right, but only one download [11:16] Yeah, fair enough. [11:16] and its harder to download two non matching files that way [11:16] Might I suggest zip instead of tar.gz? [11:17] sure [11:17] i would even prefer a format that cdimage doesnt know about yet [11:17] infinity: are zip's rsyncable / zsyncable? [11:17] instead of having to extend an existing one [11:18] * xnox doesn't feel like re downloading full nexus7 images every day....... [11:18] 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] tar.gz is currently handled as "root filesystem archive" [11:18] having to hack that upp to actually know it is not will be a bit painful [11:18] when's status.u.c updated with more blueprints/topics? :) [11:18] infinity: ogra-cb_: what is that fastboots "update tarball thingy"? can it only have the boot & userdata without recovery? [11:19] xnox, i think that refers to an update.zip which we explicitly avoided [11:19] is that zip? cause it would be nice to be able to point Mac/Windows users at the AndroidSDK tools. [11:19] and say, use those. [11:19] xnox: I see some claims that zip is pretty rsync friendly. [11:20] gzip definitely has an option for rsync [11:20] --rsyncable or so [11:20] gzip != zip [11:20] oh, indeed [11:21] 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] Ah-ha. [11:22] xnox, ok. who can do that? [11:22] For maximum rsyncability, just use "zip -0", since the contents are already compressed anyway. [11:22] knome, the approver :) [11:22] Then you're just getting an uncompressed archive, not unlike a tar, but more cross-platform friendly. [11:22] yeah [11:22] ogra-cb_, no. i can only propose for raring, even if i am the approver [11:22] infinity: sounds good. [11:23] ogra-cb_, if that's a bug, pretty please give me more rights to approve for raring :) [11:23] ogra-cb_: i think you need special extra magic powers =)))) [11:23] imo flavor leads should have that [11:23] knome, lol, what makes you think i can ? [11:23] ++ [11:23] fully agreed [11:23] ogra-cb_, no idea. doesn't hurt to knock on all the doors. [11:23] :) [11:23] 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] i guess you might need to ask in #launchpad [11:24] The organisation of the Ubuntu project isn't #launchpad's business [11:24] Ask the tech board list [11:24] infinity, k, i'll use that in the debian-cd post-boot stuff [11:24] cjwatson, cheers. do you have any idea if that's feasible though? [11:26] 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] 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] infinity: \0/ awesome. [11:27] cjwatson, okay === mmrazik|lunch is now known as mmrazik [14:24] am I doing something wrong in removing this package? http://paste.kde.org/607310/ [14:26] You can't remove from the release pocket post-release that way. [14:26] Riddell: There's a set of known timeouts affecting LP at the moment. I suggest deferring removals until a later day. [14:26] Though ScottK is right too. [14:26] 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] Erk, or possibly not; I don't see anything clear in the code to forbid it [14:27] So please don't try [14:27] At any rate the change would never be published [14:27] You need to upload a new version that either fixes the problems or renders the package useless. [14:28] You should think about as hard about the latter as you might expect ... [14:29] ug, that's new(ish) I've removed packages from released versions before [14:30] Riddell: in the devel release. not post-release. [14:30] also why? [14:30] Riddell: No, it's not new at all. [14:31] Riddell: Perhaps you only thought you had removed them, or perhaps you removed from a post-release pocket. [14:31] It has *never* been permitted (except perhaps accidentally, but definitely not by policy) to remove from the release pocket. [14:31] 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] you can remove from -proposed [14:34] xnox: Which is useless. Can I handle this? [14:34] Riddell: The only release pocket whose Release file is dated after release is hardy. [14:35] 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] 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] There are no publishing records dated from 2012-04-25 onwards in hardy, so I think that timestamp is misleading. [14:37] cjwatson: sorry, wasn't clear. and indeed it's not in oneiric-proposed, so moot. [14:38] 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] ug [14:40] After all nothing else would close the security hole for oneiric users anyway [14:42] Anyway, it's been this way since warty === mmrazik is now known as mmrazik|otp [15:37] stgraber, around-ish? [15:37] TheLordOfTime: yep, what's up? [15:38] got time to jump into -bugs for a second? === mmrazik|otp is now known as mmrazik [16:23] why does rmadison still return natty info? [16:25] 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] It's usually somewhat after EOL that things get moved to old-releases. [16:30] Its almost been a month! ;-) [16:32] heh [17:04] bdmurray: because I hadn't deleted it from the config. fixed [17:06] cjwatson: thanks [18:12] can I get the Nexus7 packages NEWed for Raring ? linux-nexus7, linux-meta-nexus7, and linux-firmware-nexus7 [18:36] rtg: Working on it nowish. === yofel_ is now known as yofel [20:19] stgraber: Has queuebot given up on !raring? [20:21] infinity: hmm, shouldn't have, what did it miss? [20:22] stgraber: I know bdmurray accepted some SRUs a while back, since I see them building (eglibc in lucid and oneiric). [20:22] stgraber: And looking through backscroll, all I see is a lot of raring, so I'm making assumptions. :P [20:23] stgraber: In fact, backscroll doesn't show it catching those uploads either. [20:24] Same with gccgo-4.7/precise, and likely a bunch of others. [20:24] hmm, right, last one for !raring was 9 hours ago [20:27] 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] (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] 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] sorry for the spam, everything should be back to normal now... [20:42] can someone please reject friends from the quantal-proposed NEW queue? that was an accidental dput :) [20:42] kenvandine: Done. [20:42] thanks! [20:53] kenvandine: we are always happy to reject friends [20:53] slangasek, lol [21:55] stgraber: ^^ have fun :) [21:56] 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] infinity what was the reason for the boost-mpi reject for quantal? [23:35] 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] infinity, because it always has to match the exact version of boost [23:36] main/universe split [23:36] doko: Yes, IRC isn't a changelog. It should have a task in the bug, and get closed. [23:36] 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] doko: I think ScottK pinged the sponsoree about rejecting it and asking to reupload with a changelog bug #. [23:37] doko: If you want to just fix it up and reupload, I'll review the pair of them. [23:37] pair? wasn't the other one accepted? [23:38] No, it's sitting in the queue. [23:38] 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] doing it now ... [23:38] xnox: Not your fault at all that someone SRUed without a reference. [23:39] 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] infinity, ^^^ [23:52] * xnox lost the game