[00:07] * slangasek afks for a bit [00:14] * skaet takes dog for walk, back in about 30 min.... [01:03] ubuntu desktop, alternate 20111007 posted [01:03] kubuntu alternate 20111007 posted [01:04] ScottK, ^ (desktop should be available soon) [01:04] OK. [01:04] xubuntu alternate 20111007 posted [01:04] wubi posted [01:13] skaet: eglibc on ARM is publishing right now, should be able to spin preinstalled images in 30-45mins. [01:14] infinity, good to hear. :) looks like we should have most of them available for europe then, when they wake up. :) [01:14] Here's hoping. [01:14] * skaet crosses fingers [01:23] * infinity is tempted to make another livecd-rootfs change before building ARM images.. [01:27] skaet: Would you be grumpy if I delayed ARM by another publisher cycle? :P [01:29] skaet: Just need one livecd-rootfs upload to get some unwanted cruft off our packages. [01:30] infinity, I'll defer to you for the ARM ones. You'll be the one staying up late for them ;) [01:31] I'm okay with that. :P [01:33] Upload in the queue in ~2 minutes, then. [01:33] If someone can get it reviewed/accepted before :40 or :45, should be good to go. :) [01:33] (3 line diff) [01:34] infinity: mind the contents generation [01:34] (next hour is Dead Time for the publisher, unless you stab cron) [01:34] slangasek: Hrm? [01:34] Oh, feh. Is it that time of day? [01:34] and the hour after that, since contents generation traditionally takes 2h :P [01:34] Actually. I'm going to reject. [01:35] On the basis of wanting to fix a typo in the changelog to look less stupid. [01:35] wait, no, apparently I'm timeshifted [01:35] or can't read big-endian cron syntax [01:35] so you actually have 2 hours :) [01:36] \o/ [01:36] Perfect. [01:36] slangasek: Review for me at :40 when it lands (again) [01:37] (please) [01:42] * infinity wonders how this diff generation business can take this long. [01:42] * skaet notes its like a watching a pot of water boil, always takes longer when you're watching ;) [01:43] skaet: That depends on how warm your face is. [01:43] lol [01:48] I think the queue diffy thingee has given up the will to live. [01:49] http://paste.ubuntu.com/703708/ <-- The diff. [01:49] Hahaha. [01:49] And it lands in the queue right after I paste it. [01:49] Whatever. [01:49] slangasek: Review teh queue for me, silver plates. [01:56] ScottK, kubuntu desktop 20111007 landed [01:57] skaet, ScottK: Or you? :) [01:58] * ScottK looks again. [01:59] infinity: Accepted. [01:59] Danke. [01:59] * infinity puts the publisher on manual, since he's going to miss it by 2 or 3 minutes. [02:01] lubuntu 20111007 posted [02:01] ubuntu-studio 20111007 posted [02:01] Or maybe I won't. [02:08] infinity: sorry, was @dinner [02:09] slangasek: S'all good. [02:11] mythbuntu 20111007 [02:11] posted. ;) [02:12] xubuntu desktop 20111007 posted [02:37] skaet: Alright. preinstalled should be good to go. You want to add it to your queue, or have me do them? [02:37] infinity, please add it to your queue, I'll be calling it a night in about an hour. [02:38] Mmkay. [02:38] I will be too. :P [02:38] I'll just leave the builds running in a screen session, though. [02:38] post the order on the pad, and ask jibel or pitti to post when they get up. [02:39] I'll just use pitti's loop of doom. [02:39] Or, will, if the pad responds. [02:39] kubuntu mobile won't be needed, double check for that. [02:40] http://pad.ubuntu.com/ubuntu-release [02:41] ubuntu-uk pad goes wonky for me about this time of night, so I moved it. [02:41] Yeah, I saw the forward. [02:42] And loop started. [02:42] its in the release channel title now too. But I was using old links myself earlier. [02:42] With no kubuntu-mobile. [02:42] :) [02:44] I could go for a case of Penfold's Grange right now. [02:44] Maybe we should dig up a bottle or three for next Thursday. [02:46] +1 [02:46] mmmm.... Grange. [03:07] infinity, looks like ubuntu-server nova 2011.3-0ubuntu6 produced an uninstallable binary for i386, amd64. worth posting? [03:07] or not. [03:07] Hrm? [03:07] report.html for it. [03:07] nova-compute-xen [03:07] yup [03:07] Well done, server team. [03:08] That's not on the CD though. [03:08] Or is it? [03:08] Ugh, it is now. [03:08] Yeah, they've screwed up and need promotions. [03:09] is the image worth testing for other issues, or does that need to get sorted first/ [03:09] ? [03:10] Nah, it's still worth publishing to test. [03:10] Just means that one metapackage is worthless. [03:10] E: Package 'xen-linux-system' has no installation candidate [03:10] Go team! [03:10] Daviey: nova-compute-xen : Depends: xen-linux-system but it is not installable [03:11] Daviey: You might want to look into that. :P [03:11] thanks. just about to do the same. ;) [03:11] skaet: what's the timeline from here to images that are candidates for release? [03:12] slangasek: We'll find no bugs and the only difference between these and release will be base-file, apport, and kerneloops. [03:12] base-files* [03:12] skaet: wondering about landing a udev workaround for bug #818177 to make the server team happy, and maybe a libpciaccess fix for bug #864123 to make the desktop team happy [03:12] Launchpad bug 818177 in udev (Ubuntu Precise) (and 6 other projects) "boot failures because 'udevadm exit' does not kill udevd worker threads (affects: 9) (heat: 68)" [High,Triaged] https://launchpad.net/bugs/818177 [03:12] Launchpad bug 864123 in libpciaccess (Ubuntu) "libpciaccess0:386 is uninstallable on amd64 (affects: 4) (heat: 20)" [Undecided,Confirmed] https://launchpad.net/bugs/864123 [03:12] slangasek, testing tomorrow, pitti kicks off the candidates on sunday night. we should have the candidate images on monday. [03:13] (this is the udev bug that was discussed with Daviey earlier today; I'm ok with being told no) [03:14] slangasek: What are the odds of the workaround causing more problems than it fixes? [03:14] slangasek, pondering.... [03:14] slangasek: Cause, post-Monday, we pretty much have to live with anything that isn't a showstopper... [03:14] Sigh. I missed a small problem with the postfix package I accepted two days ago. [03:15] Missing debian/copyright. [03:15] infinity: the workaround is "kill it harder in the initramfs" [03:15] I think we'll need to fix that. [03:15] ScottK: ... [03:15] ScottK: Yes. [03:15] infinity: so, ah, approximately no risk of making it worse [03:15] ScottK, ack. [03:15] slangasek: And it was already being killed? Just a larger knife and a gun now? [03:15] slangasek: That seems reasonable to me. [03:15] yes [03:15] udevadm control --exit ; pkill udevd [03:15] so using both the new and the old methods to make sure it dies [03:15] both are racy [03:16] But differently racy! [03:16] yes [03:16] Which is what you're counting on? :) [03:16] so by combining the two, we've turned the race into a gauntlet [03:16] yes, exactly [03:16] Seems fair to me. [03:16] And very low risk. [03:16] We have to rebuild once or twice anyway, and this doesn't change the viability of current images. [03:16] (ie: we don't need to respin RIGHT NOW if you upload it) [03:17] So, +1 from me. [03:17] slangasek, what are the chances of side effects? [03:17] skaet: The only real side effect of this is it working slightly better. Or just as badly as always. [03:18] infinity for the udev one I assume you're talking about. or both? [03:18] skaet: The udev one. [03:18] slangasek: libpciaccess is multiarching it? :/ [03:18] slangasek: (Though for a good cause, it would seem) [03:19] infinity: correct; it's multiarched in Debian already and I'm prodding people about testing the revdeps if they want to have a shot at it [03:19] Yeah. That one's a bit shakier (though I like the proposed outcome) [03:19] But I'm all for the udev thing. [03:20] skaet: Your call, there's my two bits. [03:20] skaet: side effects from the udev change in question are really zero... the only possibility of adding the 'pkill' call are that the processes don't die in time, in which case we still see the bug, or they do, in which case the bug is gone [03:20] infinity, slangasek, ok, +1 on the udev one. [03:20] ok [03:23] slangasek, on the libpciaccess one, if they satisfy you on the revdeps am thinking it would be good to have. What's the impact of 0 day SRU vs. including it? [03:23] good question [03:24] I was mostly thinking that if we're going to make the change at all it should be pre-release because it doesn't fit the SRU criteria [03:24] Inclusion should only matter if anything on the CD tries to install libgl1-mesa-dri:i386... [03:24] but by that logic it doesn't fit the final freeze criteria either [03:24] right, and that won't happen [03:24] so the net effect for users is the same whether we do SRU or late freeze exception [03:24] (Arguably a bug that flash won't attempt to) [03:25] infinity: flash is also happily not on the CD :) [03:25] and yes, it is a bug that flash doesn't pull it in [03:25] slangasek: There's a checkbox to install it... Which of course then comes from the archive... Which means a 0day SRU is fine. [03:25] yep [03:25] Thinking these things through in print is embarassing. [03:25] (hmm, a checkbox to install it? Really?) [03:25] * infinity shrugs. [03:26] Isn't the extras thing a question? I dunno. haven't installed an x86 desktop in a long time. [03:26] It can't possibly be silently done. [03:26] Net access + some other condision = restricted-extras [03:26] condition. [03:26] ah, ok [03:26] I should quit with the fingers. [03:27] It is a check that's not checked by default. [03:27] ^ [03:27] right [03:27] one I've never personally clicked ;) [03:27] Heh. [03:28] (The not checked by default thing went to the TB) [03:28] Anyhow. I'm with you on the spirit of the thing that somehow breaking freeze is less distasteful than pretending a feature change is a sane SRU. [03:28] If we can get it well-testing before Sunday. [03:28] ScottK: And was unanimously voted on, I hear. [03:28] Yes. [03:28] ScottK: So maybe we're not hopeless. [03:28] Almost no discussion needed. [03:28] Nope. [03:32] slangasek, if they can satisfy you its sane and low risk, and everything is ready to go in tomorrow, I'll go along. I don't want it bumping up against Sunday though. [03:34] skaet, infinity: build tests for libpciaccess will certainly be done tonight (see #ubuntu-devel); risk of runtime regression is negligible since everything that uses it does so via ELF dependencies and the ld.so multiarch support is by this point well tested; and I can get the code review done tonight or tomorrow morning. No risk of running into Sunday. [03:35] slangasek, ok then. [03:35] slangasek: Sounds reasonable. Definitely nothing that tries to cleverly dlopen it or such madness? [03:35] infinity: not unless it also fails to declare its dependency on it at the same time [03:35] slangasek: Check. [03:35] it's linked by things that are themselves dlopened, but that's not a problem either [03:36] That's a bug I'm willing to expose. :) [03:36] (the dependency one, should it exist somewhere) [03:36] anyway, libpciaccess is rather specialized :) [03:36] Description: Generic PCI access library *for X* [03:37] Like that would stop anyone from being evil. [03:37] But yeah, it sounds low-risk if some rudimentary testing can be done. [03:37] Make sure file lists are sane, blah blah. [03:39] ubuntu server 20111007 posted ( with known 'xen-linux-system' has no installation candidate) [03:48] ubuntu dvd, kubuntu dvd, lubuntu desktop 20111007 posted [03:52] skaet: Server will need the fixed postfix too. [03:53] ScottK, noted in the pad for rebuilds. [03:56] Need to release quickly before Canonical gets a cease and desist on distributing tzdata ... [04:04] * skaet afraid to ask... [04:06] ScottK: Seriously. [04:07] http://yro.slashdot.org/story/11/10/06/1743226/civil-suit-filed-involving-the-time-zone-database [04:07] skaet: http://blog.joda.org/2011/10/today-time-zone-database-was-closed.html [04:07] D'oh. [04:07] I paste too slowly. [04:07] But I don't paste slashdot, so point to me. [04:15] postfix taken care of. [04:16] edubuntu dvd 20111007 posted [04:16] stgraber ^ [04:21] ScottK, infinity, urk. Thanks for the links though. [04:26] chinese ubuntu finished too. ok, that's it for me, pumpkin time. [04:30] pad is updated, good night all. [04:45] the suit in question is total crap under US case law; I don't know why the plaintiffs haven't already been thrown out on their ears [04:45] So was SCO. That only took 8 years. [04:46] pitti: postfix SRU uploaded for you to have a look at. [04:47] ScottK: the SCO case a) had deep pockets, b) had much less clear facts to work with [04:48] True. [04:48] a lot harder to navigate the question of "did you mean to transfer the IP rights" than "are there any protected IP rights here" :) [04:49] slangasek: That's comforting :) [04:49] It is worrying to see tzdata disappear :( [04:50] it's inconvenient; I don't find it worrying [04:55] Good morning [04:56] Morning Martin. [04:56] pitti: I have preinstalled images spinning according to the order in the pad, if you want to post them as they pop. [04:56] pitti: core and server should be done/finishing, ubuntu's building. [04:56] infinity: sure; will do [04:57] infinity, skaet: libpciaccess passes muster; synced (which I believe will bypass the queue) [04:57] infinity: do we already want to build/post desktop/alternates, or wait with that until Monday? [04:57] slangasek: If you synced it the ftpmaster way, it will, yes. [04:57] pitti: skaet's been building and posting. [04:57] infinity: as for the x86 linuxy stuff, ogasawara said she uploaded a new linux-meta [04:58] pitti: This should get us a nice round of testing over the weekend, then we can spin RCish images Sunday/Monday. [04:58] but seems the new meta didn't help much [04:58] pitti: Well, the meta matches up with everything. [04:58] pitti: It's just a question of components right now. What belongs where? [04:58] pitti: If everything up for demotion is demoted, it should all Just Work. [04:58] pitti: I believe. [04:58] infinity: anything else than "all binaries of linux are in main" are a real PITA [04:59] pitti: (Or, some stuff needs seeding and promoted) [04:59] as we get ten kernels a week in SRUs, and they bypass NEW [04:59] so I think I'll just seed the extra -meta binaries instead [04:59] pitti: Yeah, I dunno. I still think that any time a binary is promoted to main, the source and all other binaries should be too, but I lost that argument long ago. [05:00] I think it's bizarre to claim we support the source but not the binaries. [05:00] infinity: well, sometimes a binary pulls in something into main which we don't want; these cases are justified IMHO [05:00] pitti: That's rare, though. [05:00] not rare enough [05:00] pitti: But I concede that point, I suppose. [05:01] Well, it has to be doing it via a dependency that isn't also a build-dependency. [05:01] Which is vaguely rare. [05:01] But yes, perhaps not rare enough. [05:03] pitti: All the armel uninstallables from britney are arch:all packages that depend on !arm packages. Not much we can do about that, so I declare britney for arm good. [05:03] (Well, we could fix it by making those arch:all packages be arch-specific, but a bit late) [05:04] pitti: The only other suspect thing is openoffice.org-gcj depending on non-existant libreoffice-gcj on all arches, might actually be worth an openoffice.org upload just to remove that metapackage and have apt be slightly less confused. [05:05] infinity: You know how long that takes to build on arm, right? [05:05] ScottK: About 20 seconds? [05:05] ScottK: It's an empty package. [05:06] ScottK: openoffice.org is just a bunch of metapackages depending on libreoffice stuff. [05:06] Oh. [05:06] Right. [05:06] Nevermind me. [05:10] infinity: yeah, agreed [05:14] bug 869459 looks reasonable to me, I'd go ahead with this; infinity, ScottK, any opinion on this (not sure if it was discussed already), or should I just go ahead and take the blame? [05:14] Launchpad bug 869459 in clutter-gst (Ubuntu) "FFe: Sync clutter-gst 1.4.2-1 (main) from Debian unstable (main) (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/869459 [05:15] I'll share the blame if you'll also accept my postfix sru ... [05:16] (I'd say go ahead.) [05:16] at least it promises to finally work on arm [05:17] Promises aren't everything. [05:27] ^^ ignore, taken care of [05:33] * pitti starts building new langpacks, export finished [05:35] I'm glad I didn't wait much longer on the backports I just accepted. [05:40] ScottK: oh, full backports for postfix, not just upstream updates? [05:42] I think it's actually lower risk and easier maintenance. [05:43] The only significant change is the multi-instance support and since upstream has supported that since 2.6 it's really a long standing packaging bug we didn't support it. [05:44] Most of the packaging diff is the addition of a copyright file for the source (all the binaries already had it). [05:48] I commented on bug 869411 [05:48] Launchpad bug 869411 in postfix (Ubuntu Natty) (and 1 other project) "SRU tracking bug for postfix 2.8.2 -> 2.8.5 for natty (affects: 1) (heat: 8)" [Wishlist,In progress] https://launchpad.net/bugs/869411 [05:48] ScottK: sorry, it seems we had a misunderstanding in the meeting then [05:48] I just assumed this is a mere upstream microrelease update, not a full backport including the packaging [05:49] as the former is the usual (and only) case for approved MREs [05:49] OK. Then I've been doing the clamav updates wrong for a long time ... [05:49] I can reduce this to just the upstream changes. [05:50] ok, thanks; I'll reject the current upload then [05:51] ScottK: especially bumping debhelper compat etc. will become more and more difficult the further back you go [05:51] if we would update hardy now, it wouldn't even work [05:51] Right, but this will only go to natty as an SRU. [05:52] It would work in backports. [05:53] I don't anticipate asking for a major version exception like I did for clamav, so postfix 2.8 will never have to go back further than natty in -proposed/updates. [05:53] I've already been backporting it to lucid. [06:04] pitti: Reuploaded. [06:04] BTW, for clamav there are cases where you have no choice to change the packaging or it won't work, so it is a bit different. [06:05] ScottK: right, understood [06:05] thanks, will review when the diff arrives [06:05] I think I'm going to sleep then. [06:05] Good night. [06:08] sleep well! [06:09] gnargh, LP timing out for LP builds === jibel_ is now known as jibel [07:04] pitti: just upoaded the one line for 3 bugs crash fix. I ran it out for an hour [07:04] didrocks: awesome, thanks [07:05] didrocks: so the others have more intrusive fixes where we can't be 100% sure? [07:05] pitti: yeah, that's why I didn't include them, the gain/risk doesn't worth it [07:05] can be a SRU, they aren't crashes (or crash with only one people experience, and the service then restarted) [07:06] of course, it will work once I target oneiric and not precise… [07:07] lol [07:07] it's a bit of a nuisance, isn't it? [07:07] breaks people's habits [07:07] indeed :-) [07:07] It broke me so badly that I started typing my passphrase in the suite field because I got a bit muddled. [07:07] (I only slept 3 hours last night, shut up) [07:08] infinity: you never know, that can maybe works one day [07:08] with verylongandnotstandinguprelease :-) [07:08] pitti: the relevant commit is there: http://bazaar.launchpad.net/~ubuntu-desktop/unity/ubuntu/revision/591 [07:09] Speaking of uploads. [07:09] didrocks: ah, thanks; easier than trying to relate two debian-changes* monsters :) [07:09] yeah, with the previous cherry-pick in particular… :) [07:09] pitti: I'm heading to bed, new openoffice.org in the queue in 50 seconds. [07:09] infinity: yay, will review [07:09] infinity: I bent LP timeouts to my will, new langpacks are being built [07:09] will upload once that's done and I gave them some good beating [07:09] infinity: sleep well [07:10] pitti: Not much to review. But if you notice a GPG passphrase anywhere in the diff, let me know. :P [07:11] *chuckle* [07:11] pitti: Once this builds, you should be able to remove oo.org-gcj. [07:12] pitti: And then the rest of the uninstallables are linux component issues, armel things we can't fix and one "hahaha, server team, lol wut?!" that I pinged Daviey about. [08:26] I just upload a new update-manger, the diff looks big, but its mostly just automatic importint of the oneiric base-installer to ensure that the kernel is correctly picked, that auto updating was disabled recently by accident [08:33] for what it's worth, I can confirm the new wubi is in fact signed [08:39] so what is the game plan for the RC images? Are those intended to land today or over the weekend? [08:40] ev: right now the plan is to trigger them on Sunday, so that on Monday morning we all have fresh images to test which are real RC [08:40] pitti: cool, thanks [08:40] preparing/uploading langpacks right now, will accept apport/kerneloops on Sunday [08:40] (But don't let that stop you from vigorously testing the current builds over the weekend) [08:40] We expect RC to be very nearly identical. [08:40] yes, absolutely [08:41] hm, I think I missed wiring up the wubi images to the simple tree on cdimage [08:41] indeed [08:41] http://iso.qa.ubuntu.com/qatracker/ is there for everyone's testing pleasure [09:02] ok, langpacks are as good as they are going to be [09:02] cjwatson: can we temporarily disable the queuebot, to avoid getting 812 "new package" and 812 "removed" lines? [09:06] infinity: you don't happen to know where the queuebot runs at? [09:06] can't see it on people.c.c [09:06] */2 * * * *publish-queue -s oneiric -Q unapproved [09:06] oh, that might be it? [09:07] I guess it is; disabling for nor [09:07] now [09:43] slangasek: nothing on 745960 yet, probably going to have another crack at it today [09:44] infinity: syslinux-themes-*> maybe? if you want to change it, be my guest :) [09:50] pitti: the queuebot runs on chiark, you don't have access ;-) [09:50] pitti: I can stop the actual bot if you'd prefer [09:50] cjwatson: I just temporarily disabled publish-queue [09:50] it's back on now, all langpacks are in [09:50] ok [09:51] and seb just discovered that lightdm unfixed bug 849027 [09:51] Launchpad bug 849027 in lightdm (Ubuntu Oneiric) (and 2 other projects) "lightdm does not provide an equivalent to the gdm guest session AppArmor profile (affects: 3) (dups: 1) (heat: 274)" [Critical,Fix committed] https://launchpad.net/bugs/849027 [09:51] the merge to 1.0 upstream branch forgot half of the patch [09:51] I uploaded a new package which adds it back [09:52] tested it, works again [09:52] (it's in the queue now) [09:52] it restores the code to what we had last Friday, I didn't actually have to change the commit [09:52] (except for slightly unfuzzing a later patch) [09:55] pitti: bah, sorry I missed the TB meeting, I remembered about it earlier in the day and then completely forgot about it ... it would be nice to reevaluate the meeting time with the current board, it really doesn't work well for me [09:55] cjwatson: yeah, neither for me really, it's very late [09:55] cjwatson: added to the agenda for next time [10:00] thanks [10:23] cjwatson: do you have a minute to review lightdm? (unfortunately still no diff yet, LP is slow on Fridays apparently) [10:23] I'm available for interrogation on the patch [10:33] pitti: yep, moment [10:36] pitti: that's fine (compared with previous patch), accepted [10:36] cjwatson: thanks [10:36] meh, that was quite an unsuspected surprise [10:37] just after you think you've got everything in [11:18] skaet/robbiew: do we have enough information to populate https://wiki.ubuntu.com/PreciseReleaseSchedule yet? [12:04] sladen: there is https://wiki.ubuntu.com/PScheduleInterlock already [12:07] pitti, ^ [12:07] yep, waiting for the diff to appear, to double check [12:08] speaking about next, cycle: https://live.gnome.org/ThreePointThree#Schedule [12:08] GNOME 3.4.1 tarballs should be on april 16 [12:08] it would be nice if we have a schedule that allow to get .1 in Oneiric [12:08] seb128: last week I added the main 3.4 dates to the interlock page [12:08] seb128: ITYM precise? [12:09] yes [12:09] sorry my finger are not used to the next cycle yet :p [12:16] * cjwatson is currently trying to get a last-minute LP fix in for bug 572128 [12:16] Launchpad bug 572128 in debmirror (Ubuntu) (and 1 other project) "Ubuntu Archive translations are missing Index metadata file (affects: 3) (heat: 18)" [Undecided,Confirmed] https://launchpad.net/bugs/572128 [12:16] (FYI) [13:06] pitti: bug 869270, I've got a fix for it. I can upload, but would like approval from the release team first. [13:06] Launchpad bug 869270 in linux (Ubuntu Oneiric) (and 1 other project) "linux-image-extra's install claims unmet dependencies (affects: 1) (heat: 6)" [Medium,Fix committed] https://launchpad.net/bugs/869270 [13:07] pitti: the -extra's package is an elective install though, similar to lbm, so it is not release critical [13:07] ogasawara: that's the wrong (== 3.0.0) dependency? [13:07] pitti: correct, the dependency line was wrong [13:08] ogasawara: hm, but that's the "linux" source, I suppose [13:08] that would take quite a while to build [13:09] pitti: yep, arm takes the longest to build, around 12hrs [13:10] did someone talk to IS about the kernel and the panda builders ? [13:10] we have faster buildds that can be used with some manual fiddling [13:10] (by IS) [13:11] ogra_: so, it would barely fit, but leave us no margin at all for error (weekend and all that) [13:11] erm, ogasawara ^ [13:11] ogasawara: can we upload it to -proposed perhaps, and copy to final when it all built? [13:12] cjwatson: ^ how would that work for you? [13:12] pitti: I can do that if that's the consensus here [13:13] lamont, are you around ? could we fast-path that kernel upload manually into a panda so it builds a bit faster ? [13:13] with the detour via -proposed, 12 hours should even be enough [13:13] ogra_: you'll notice that all of the non-pandas are on manual [13:14] well, the panda should cut the time in half [13:14] lamont, oh, ok [13:15] would you like a little extra boost for the langpack builds, at the cost of idle amd64 builders? [13:15] lamont: it says ETA 33 minutes, so no extra hurry from my side [13:16] wfm [13:18] lamont: but nice to know that this is possible [13:18] lamont: OOI, how much effort it is to change their badge to be "I shall build i386 packages"? [13:20] 1) set to manual and get the buildd idle, because I don't trust the transition edge (wgrant would probably tell me he thoroughly tested this and it's fine, but I don't remember, so I play safe) [13:20] 2) builders/allspice/+edit <-- change architecture, uncheck manual, commit [13:21] N.B.: architectures with no builders do not get build records. that's why there's an lpia builder still... so don't ever take all of them [13:21]