[00:01] cjwatson: this grub2-signed downloads the gcdx64.efi.signed, but doesn't appear to install it (Makefile is unchanged) [00:06] cjwatson: reuploaded with this fix, and accepting [00:08] slangasek: Whoops, thanks [00:08] Quite right [00:27] grub-installer looks good [00:28] adding grub-efi-amd64-signed to the installer seed now [00:28] (supported-installer-common, to be precise) [00:29] quantal, not precise? [00:29] I don't want to be quantal [00:29] I want to be precise [00:29] ;) [00:30] I'm also assuming grub2-signed doesn't require an MIR since there's no new binary package code [00:30] so, promoted'n'such [00:31] supported-installer-common isn't really right [00:31] I think it should go in platform.quantal/d-i-requirements plus ubuntu.quantal/ship-live [00:31] (And probably in general all seeds that currently contain grub-efi) [00:32] afk now [00:32] s/right/sufficient/ [00:33] ok [00:59] * xnox ponders how much stuff I have missed over the weekend... [01:09] Well, some of the changes in tcl8.4 we kind of want, but I think it's too involved for 12.10 and I'm not certain whether it would break any dependent packages [01:09] So I'm justs uploading a no-change rebuild for that [01:09] *just [01:18] vte has a fix to an Ubuntu bug that has been getting "so when are you going to apply my clearly sensible patch?" (and it is clearly sensible) for months, and two security fixes [01:19] So I think I'll merge that [02:00] vte merge uploading, and that's the last of the armel rebuilds, so *zonk* [02:00] ARM builds starting to generally emerge from gecko, though it'll be ten more hours or so until those are entirely finished [02:08] cyphermox: I've accepted usb-modeswitch as the only remaining problem I can see is a very unlikely scenario; but I think you should check getenv's return for non-NULL before passing to strdup, as right now I think this will segfault if you run it with PATH missing from the environment [02:08] (not that it would probably work very well in that case anyway, but) [02:08] thanks [06:06] ok, why was nvidia-graphics-drivers 304.51-0ubuntu1 let in during the freeze? [06:06] bug #1063969 [06:06] Launchpad bug 1063969 in plymouth "No Plymouth Splash on Latitude E6420" [Undecided,New] https://launchpad.net/bugs/1063969 [06:10] I'm getting rather sick of having to chase down last-minute regressions in plymouth support with nvidia drivers due to last minute changes to the packaging [06:13] cjwatson: ^^ from scrollback, it looks like you were probably the one who reviewed/accepted the nvidia packages; just a heads-up that there's a pattern of ill-tested last-minute packaging changes... [06:53] cjwatson: I wasn't able to touch it yesterday at all. It will be done today. === mmrazik is now known as mmrazik|otp [07:16] ^-- Who accepted those ppl binaries? [07:16] You just skewed it on armel and armhf... [07:17] Oh, nevermind, the only arch:all package is a -doc package anyway. [07:18] Although, ppl-dev should have probably been NEWed to main. So, I'm back to "who did that?" === mmrazik|otp is now known as mmrazik === henrix_ is now known as henrix [08:11] ^- should fix wrapitk-python/amd64 build failure [08:14] slangasek: Yeah, that was me, sorry - was it the gfxpayload blacklist change? I assumed that was fixing a disease that was worse than the cure, sorry ... [08:16] cjwatson: the "disease" it was fixing is entirely unsubstantiated in the referenced bug report :/ [08:16] cjwatson: Accepted. [08:16] slangasek: *sigh* [08:16] infinity: thanks [08:16] slangasek: About the only validity the report appears to have is that it came from @nvidia.com, but yeah, it doesn't actually say what the problem *is*, just that there might be one. [08:17] Always irksome, that sort of "bug". [08:17] "This package might misbehave sometimes." [08:17] ah, I didn't catch the submitter's domain [08:17] but even so, bleh [08:17] Yeah, I think I took that as authoritative [08:27] grr, grub2-signed override to main didn't take for the binary; promoting now [08:28] (so today's images missed including it; probably not worth a rebuild for just that, we might as well get the d-i piece done first too) [08:28] slangasek: I already promoted [08:28] Yeah, not worth a rebuild, not like we worked on SB yet anyway ... [08:32] * slangasek nods === henrix is now known as henrix_ === henrix_ is now known as henrix === doko_ is now known as doko === mmrazik is now known as mmrazik|lunch === tkamppeter_ is now known as tkamppeter [09:44] * ogra_ wonders why its always cjwatson's uploads that remind me of the sins of my youth ... and files bug 1064271 [09:44] Launchpad bug 1064271 in redboot-tools "please demote redboot-tools to universe" [Medium,Triaged] https://launchpad.net/bugs/1064271 [10:02] gtk reverts http://git.gnome.org/browse/gtk+/patch/?id=5debed5ae247c1dd440cb71d0a6d328df74b0844 ("Shut down a11y when an app shuts down") to workaround https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1056300 [10:02] Ubuntu bug 1056300 in gtk+3.0 "If a GTK application quits the main loop and restarts it again, accessibility is lost." [High,In progress] [10:03] e.g "ubiquity looses a11y midway" [10:03] it's not a fix but it seems to safest option for release [10:04] seb128: yes, please. I am also confused how they managed to slip such a big feature so late in the 3.6 cycle. [10:04] it's not so much of a "feature" than an optimization... [10:05] but GNOME is not very good nowadays to be conservative about their changes (well, the same way we have issues pushing back on #ps changes to be fair) [10:08] seb128: well the point of that gtk commit, as far as I can see, is a workaround the apps that are not using GApplication(-shutdown) and hence don't clean up a11y resources at the end. [10:09] I am not sure if ubiquity should be using GApplication or not. [10:09] it's a good discussion to have with desrt at UDS ;-) [10:10] I'm not sure but, ubiquity is not really a standard "application", well not in sense of desktop application === mmrazik|lunch is now known as mmrazik [11:15] * cjwatson tries to work out why wrapitk-python was deleted from quantal for other architectures [11:15] rejecting gdm - confused, asking a question [11:17] * Laney gets irritated at Launchpad wiggling in the launcher so often [11:17] "NBS libgdcm2.0, and no rdepends for python-insighttoolkit3" [11:18] * cjwatson suggests that removing non-NBS binaries of a source package still in the archive is not the best idea [11:18] asked the schooltool maintainers about a FFe [11:19] you might want to reject so nobody accidently accepts then [11:19] I'm not -release [11:19] or duplicates time reviewing [11:19] oh woe [11:19] ah, a simple rebuild would have fixed wrapitk-python, rather than removal, it seems [11:19] * cjwatson does that [11:23] Laney: what was the gdm question? [11:23] about the prerm change [11:23] doko: I'm doing so. Please could you let them know what's happened? [11:24] I've uninstalled gdm a few times and it's killed my X session which is not nice, I'm not sure there's any need for uninstallation to kill gdm [11:24] yeah possibly not [11:24] Laney, done [11:25] ta [11:25] Laney, please accept zope.interface, synced by cjwatson yesterday [11:25] looking at the rest now [11:27] the base revision chosen by LP for the e-d-s diff is curious [11:27] Probably the last one in -proposed [11:27] Laney, it's the previous upload to that pocket? like if that goes through proposed [11:28] The ancestry code is basically wrong [11:28] Needs a complete overhaul AFAICT [11:28] does indeed seem to be the previous -proposed upload === mmrazik is now known as mmrazik|afk [11:54] cjwatson: freeipmi uploaded (i missed the convention local function on the last upload, now used.) [11:55] kind to review sir? [11:55] Sure [11:55] When the diff arrives [11:56] http://pb.daviey.com/0Dxi/ [12:00] I needed code context anyway :) [12:01] That looks better now, thanks - accepted [12:03] Daviey: Per jdstrand, the MIR still needs these patches forwarded to Debian, and ubuntu-server added to bug subscribers [12:10] cjwatson: Yep [12:10] cjwatson: no, it won't segfault. I tested this by itself in a quick little program by itself [12:10] strdup(NULL) is not defined [12:11] why am I duplicating words ;) [12:11] cjwatson: oh wait, you mean if PATH is undef [12:11] Unset, not empty [12:11] right [12:11] in the case where usb-modeswitch-dispatcher gets run (by udev), very unlikely to happen [12:12] As I say, corner case and will probably fail somewhere else anyway - I just don't like leaving segfault cases around unhandled [12:12] (Which is why I accepted with a comment rather than rejecting) [12:12] sure. I'll fix it first thing in R; I'll start a list now [12:14] ta [12:14] cjwatson, is it ok to update base-files for the rc? [12:14] doko: We're not doing an RC as such [12:15] Just incrementally better until release :) [12:15] doko: But yeah, probably might as well [12:15] ok === mmrazik|afk is now known as mmrazik [12:59] python3-stdlib-extensions: needed to build the _gdbm and _tk extensions for 3.3. talked with jdstrand that it's ok to have it main for q [13:00] seeding and promoting linux-signed - same rationale as slangasek gave earlier for grub2-signed [13:07] Jesus [13:07] There are 7 days left in the current cycle. That means that in order to complete all the work 90.29 workitems must be completed per day. [13:08] OMG [13:09] hey, is someone able to approve flash, please? :-) [13:10] * GridCube gives smartboyhw a chamomile tea [13:10] GridCube, thx:D [13:20] morning release team! [13:20] currently, many udev related tests in checkbox are broken, as they are not using udisk2 [13:20] would this fix require a FFe? https://bugs.launchpad.net/checkbox/+bug/1016035 [13:20] Ubuntu bug 1016035 in checkbox "Add udisks2 support to scripts/removable_storage_* scripts" [High,In progress] === henrix_ is now known as henrix [13:30] Reviews of base-installer and grub-installer would help unblock me a little - more secure boot madness [13:31] Laney: I think you may consider that upload for quantal finale. I tried to be as descriptive as possible in the changelog, but do not hesitate to ask me anything else :) ^ [13:32] cjwatson: I'll take a look in a minute [13:33] didrocks: oui mon ami [13:33] Laney: merci! :-) [13:34] cjwatson: did you get an answer on linux-signed (sorry for the delay-- holiday) [13:35] jdstrand: on which aspect? [13:35] Anyone object to me doing a server spin? [13:35] cjwatson: you asked me about promoting it with a mir [13:35] without a mir [13:35] Daviey: component-mismatches looks pretty unresolved [13:35] jdstrand: oh, I JFDIed that a little earlier today [13:35] and figured I'd apologise if somebody objected [13:36] cjwatson: ok, based on what you said a few days ago, I would have said as much\ [13:36] ok, good [13:36] cjwatson: I think c-m just needs a refresh [13:37] * cjwatson looks at rmadison output [13:38] mm, out of sync across architectures. I'll fix [13:38] cjwatson: I have just fixed [13:38] server spin is fine then as long as it's just amd64/i386 [13:38] That is all i want for this spin [13:39] Actually, freeipmi-common was in universe [13:39] Oh, but that's NBS [13:39] This is confusing :) [13:39] I guess this will settle down in a bit. At the moment I can't say whether a server spin is likely to work [13:40] * Daviey leaves it another hour, for giggles [13:40] Yeah, if I were you I'd let the automatic reports have a chance to catch up before spending any manual time on it [13:40] yeah, ok. Thanks [13:45] cjwatson: accepted [13:46] stgraber: thanks [13:46] ooh, webkit/armhf succeeded [13:46] nice [13:47] armel is nearly there too [13:47] Yeah [13:47] glorious [13:48] I got some new puncture proof tyres for my bike over lunch too — truly a day for vanquishing broken old crap [13:50] the recent linux-meta upload fixes an issue where installing linux-crashdump on an efi system uninstalls your bootloader [13:50] apw: haha [13:50] We rule [13:50] cjwatson, i thought so :) [13:50] Eh, that's not really right - grub-efi is a transitional package [13:51] Should be grub-efi-ia32 | grub-efi-amd64 [13:51] cjwatson, do you think this would require a FFe? https://bugs.launchpad.net/checkbox/+bug/1016035 [13:51] cjwatson, if you reject it can we re-use the version number ? [13:51] Ubuntu bug 1016035 in checkbox "Every script that uses udisk in currently broken in Quantal" [High,Fix committed] [13:51] apw: yes [13:51] ok do that, lets git it right [13:52] apw: ok, done, please pass on to smb [13:52] ara: sorry, eyebrow-deep in secure boot right now, no spare brain [13:52] if in doubt, upload, it'll be queued and reviewed anyway [13:52] cjwatson, OK, now worries [13:52] cjwatson, OK, thanks [13:53] zul: ping [13:53] stgraber: whats up? [13:54] zul: cinder in the queue does a dh_fixperms -X on nova_tgt.conf but the rest of the diff refers to cinder_tgt.conf [13:54] stgraber: crap can you reject it please ill upload a fix [13:54] zul: ok [14:06] * stgraber assumes we want to keep base-files in the queue until FinalFreeze and leaves it there [14:11] ev, are there any more fixes expected for WUBI? ( its time to ask IS to prepare the signed copy) [14:11] skaet: credit where credit is due, cjwatson has been doing all the fixes. I've just been building the binaries [14:11] I am unaware of any further changes that need to be made [14:12] likewise, for the moment [14:12] fair 'nuf ;) [14:12] so we can most certainly put in an RT for the signed copy [14:12] not much changed this cycle [14:12] shall I sort that out then? [14:12] thanks cjwatson, ev - doing. [14:12] ah [14:12] excellent [14:12] :) [14:12] haven't had my recent fix for Tibetan verified, but well [14:12] best-effort at this point given everything else :-/ [14:14] skaet: the kernel team would like to get a freeze exception for a kernel upload. It would be to resolve the following: bug 1063061, bug 1061599, bug 1021471, bug 1030233, bug 717970 [14:14] Launchpad bug 1063061 in linux "please backport support for EFI vars > 1KB" [Medium,In progress] https://launchpad.net/bugs/1063061 [14:14] Launchpad bug 1061599 in linux "beagle: omap3: usb is dead" [Undecided,Fix committed] https://launchpad.net/bugs/1061599 [14:14] Launchpad bug 1021471 in linux "clone() hang when creating new network namespace (dmesg show unregister_netdevice: waiting for lo to become free. Usage count = 2)" [High,Confirmed] https://launchpad.net/bugs/1021471 [14:14] Launchpad bug 1030233 in linux "not have bluetooth usb 0489:e046 Foxconn / Hon Hai" [Medium,Fix committed] https://launchpad.net/bugs/1030233 [14:14] Launchpad bug 717970 in linux "After sleep, key presses get lost and trackpad is jittery" [High,Fix committed] https://launchpad.net/bugs/717970 [14:16] ogasawara, will we need a d-i as well? [14:16] skaet: I don't believe it is an ABI bump, so no [14:17] ogasawara, ok, have all the fixes been independently verified? ( like we would for SRU?) [14:17] skaet: yep, all thoroughly tested [14:17] ogasawara, coolio. If the kernel is ready to upload, rather get it in sooner than later. [14:18] ogasawara, we don't have a patch set yet for 1063061 [14:18] skaet: ack I still need to get the final patch revisions for 1063061 from apw but am told it will be ready shortly [14:18] rtg: ^^ [14:19] ogasawara, understood. just to confirm - plan is to revert if any issues found with this latest kernel? [14:19] ogasawara, hmm, it had a lot of issues and I'm not sure we'll be able to test it sufficiently. [14:19] skaet: indeed, that would be the plan if any regressions appear [14:19] rtg: hrm, maybe we should make sure we're both on the same page with apw [14:19] yeah [14:20] ironically 1063061 is the only one of those I care about ;-) [14:22] * stgraber cares about bug 1021471 (makes LXC almost unusable on 12.10) [14:22] Launchpad bug 1021471 in linux "clone() hang when creating new network namespace (dmesg show unregister_netdevice: waiting for lo to become free. Usage count = 2)" [High,Confirmed] https://launchpad.net/bugs/1021471 [14:22] yes :-) [14:22] * Laney is trying to do a stgraber on this new install and have no dev packages installed on the bare metal [14:22] using lxc for dev [14:23] skaet: there'll necessarily be at least one more d-i anyway [14:24] so I don't think we should worry about that either way [14:25] cjwatson, ok. [14:26] (general catchup; SB work) [14:28] yay, webkit/armel finished [14:28] cjwatson, stgraber: webkit now built in -proposed for armel and armhf. please promote to quantal so that ephiphany can start building [14:28] heh [14:29] doko: I'm going to wait for a publisher run [14:29] I am taking absolutely no risks here [14:29] At least process-accepted, anyway; actually getting it onto disk doesn't matter [14:49] doko: copied [14:49] ^- that grub2 upload is critical path for secure boot images [14:49] cjwatson: will review [14:50] cjwatson, could you have a look at the python3-stdlib-extensions upload? [14:50] cjwatson: can you review isc-dhcp and ifenslave-2.6 in exchange? :) [14:51] one at a time :) [14:54] cjwatson: accepted [14:54] doko: Have you already convinced somebody else on the MIR team that it's OK to promote python3.3? [14:55] stgraber: shorter form: BOND_SLAVES="${BOND_SLAVES:+$BOND_SLAVES }$name" [14:55] cjwatson, from my point of view not needed, only a new upstream version. got approval from jdstrand from a security point of view, and from barry from a technical point of view [14:55] But accepted the increasingly inaccurately named ifenslave-2.6 [14:56] doko: In that case it's fine - I assume you're ready to promote python3.3 so that this can build? [14:56] right [14:56] OK, accepted [14:58] stgraber: and isc-dhcp is fine too, accepted [14:59] cjwatson: thanks [15:20] cjwatson, stgraber, infinity, Laney, and other members of the release team ;) - pitti is uploading apport shortly for the switch over to only have it reporting to errors.ubuntu.com. Please don't accept it in until we're ready to try for the release candidates. [15:21] do the standard reject/accept trick on it then? [15:21] Laney, yeah, I think that best [15:22] will you do the honors, or do you want me to? [15:22] feel free [15:23] btw, shouldn't we have done the same with base-files? I just noticed it was accepted (removing the "dev release" tag from lsb_release and similar tools) [15:24] stgraber, yes. anything with timing issues around it should go to reject, so accidents don't happen. [15:24] not really the end of the world though [15:25] * skaet nods [15:45] Sigh, could really use ARM catching up a bit - this is hard to manage [15:48] cjwatson: if you have a minute, can you look at ifupdown? [15:48] I've an upload of update-manager to precise-proposed that may help with diagnosing upgrade errors so it would be good to get it in precise. [15:49] stgraber,jodh: oh, nice catch (ifupdown) [15:49] cjwatson: thanks :) [16:05] can you reject the horizon please? [16:06] zul: Done. [16:07] thanks [16:16] slangasek, can you add back the amd64, i386 isos for ubuntu and ubuntu server for beta1? [16:19] slangasek, http://cdimage.ubuntu.com/releases/quantal/beta-1/ s missing these images and they are needed for upgrade testing from beta1 to rc [16:20] You can't expect old images to hang around after the next milestone is released [16:20] If your process assumes that then your process needs to be fixed [16:20] cjwatson, I know.. but I'm looking and seeing that beta2 has been gutted also [16:20] Err, no [16:20] No. You need to look on releases.u.c [16:20] desktop and server images live on releases.u.c [16:21] http://releases.ubuntu.com/quantal/ [16:21] Yes [16:21] this was a request by skaet to test an install of beta1 and upgrade to current [16:22] You'll have to get it from somewhere else [16:23] In any case, you'd only be able to do a beta-1 install now if it were networkless ... [16:23] Otherwise it'd be a hybrid [16:23] Yeah, not massively sure any such test results will be useful [16:24] fair enough. ty cjwatson and Laney [16:24] skaet: what are you trying to learn from this that you wouldn't learn from an upgrade from precise? [16:25] balloons: if he had snapshots archive, it would be interesting to install from beta1 archive snapshot & dist-upgrade to -rc archive snapshot or final. [16:25] balloons: but we don't have archive snapshots. [16:25] If we want to do this kind of thing, we would need to plan ahead - e.g. archive test installs done at beta-1 time [16:26] I plan to clean beta-1 entirely off cdimage fairly soon - it should have been done at beta-2, really [16:34] balloons: hrm, why is upgrade testing from beta1 to rc anything that you are focusing on? [16:35] ah, see that's answered in scrollback [16:35] slangasek, we'll have to await skaet for that answer. I believe she wanted to check unity regressions [16:35] infinity: iirc, you asked over the weekend about firefox 16 going to quantal-- I think it needs to go, but we need to test a bit more [16:35] jdstrand: Check. [16:36] jdstrand: At least it's all built now. ;) [16:36] infinity: indeed-- was that the main bit you cared about? ie, can I just pocket copy to quantal after testing? [16:36] infinity: firefox/quantal-proposed is still needs-build, actually [16:36] cjwatson: 16, not 15. [16:36] If that's what you mean ... [16:37] these are in https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+packages [16:37] Oh [16:37] Does that include the changes in quantal-proposed? [16:37] chrisccoulson: ^ [16:38] jdstrand, cjwatson, yeah, it's got all of the changes from quantal-proposed [16:38] And more, apparently. [16:38] Newer version of globalmenu again. [16:38] Then it would be ideal to copy it sooner rather than later and supersede -proposed [16:38] Since we're short of build time and there's no point in duplicate ten-hour builds [16:39] I'm happy to do that. we need to test i386 a bit more though [16:39] cjwatson, balloons, sorry, was otp. Want to make sure that those end users who have installed beta 1 don't have any big surprises esp. on i386/amd64. We can release note if the only issues are on arm - but it would be good to know what they'll be seeing. [16:39] I can just delete 15 from proposed if we definitely plan to copy 16. [16:39] the security issues warrant it [16:39] Yeah, that's why I was pushing for it. [16:39] skaet: it just seems like an oddly specific thing to focus on - one would expect that for the most part any issues seen upgrading from 12.04 would be a superset [16:39] Doesn't seem to make sense to wait and do a 0-day security release. [16:40] no [16:40] skaet: and I really don't want to go resurrecting beta-1 images when QA apparently doesn't already have copies [16:40] this one is pretty important based on the upstream advisories [16:41] jdstrand: What about thunderbird 16, has it been tested? [16:41] not yet, I'll be testing that next [16:41] jdstrand: (Copying that one would also get us out of doing two long builds) [16:41] that one hasn't been tested at all btw. firefox/amd64 has been [16:42] * jdstrand is working on these as we speak-- tbird will be a little while though [16:42] jdstrand: Alrighty. [16:44] cjwatson, ?? Why were the copies of the beta 1 images removed for desktop and server? They are still there for cloud...http://cloud-images.ubuntu.com/releases/quantal/beta-1/ [16:44] infinity, ^ ? [16:44] skaet: We always remove the previous milestone when publishing the next one. We have done ever since long before you joined [16:45] skaet: Cloud has an entirely separate publishing process that is nothing to do with me [16:45] cjwatson: so we're not expecting gcdx64.efi to work for netboot at this stage, right? Given that /.disk/info will not exist [16:45] There isn't even a defined location where previous versions of the ones that go on releases.ubuntu.com mightgo [16:45] slangasek: No, that would need the Fedora fw_path patch I think [16:45] ok [16:45] balloons, can you please test for beta2 forward then. [16:46] skaet: the policy for the cloud images is to provide all milestones indefinately. There was a revolt a bit back on about removing previous milestones. [16:46] Right, that is definitely not the policy for cdimage and never has been [16:46] skaet, lol. I originally announced it as beta2, re-sent the clarification 30 mins ago that we wanted beta1 [16:47] utlemming: That's a strange policy. [16:48] utlemming: Interesting for QA bisection, somewhat confusing to present users with an option to use images that aren't based on release versions (and probably lack an obvious route to the matching source, too) [16:48] I don't want to reinforce any notion that it's just as OK for people to install beta-1 as beta-2 and that we'll support them both. errors.ubuntu.com indicates that we have a hard enough time getting users to upgrade as it is. [16:49] infinity: the bisection is part of why they are there. But if you look http://cloud-images.ubuntu.com/releases you'll see that we have a whole library of all the images that have been declared "release" or "milestone" [16:49] utlemming, cjwatson - something to discuss at UDS. cjwatson, understand your point, keeping them accessible without heroics, so we can set expectations of the experience a bit better seems prudent if we have the space. [16:49] but they shouldn't be an easy default. [16:49] We don't have the space to do it for any more than a short period of time. [16:50] for the cloud-images, space is easy -- we use the cloud [16:51] cjwatson, maybe doing what utlemming is doing might make some sense? [16:51] utlemming: There's probably some GPL violation going on there. [16:51] skaet: I'd rather not. [16:51] I'm honestly quite happy with the way it is ... [16:52] skaet: People installing from old media has always been a problem, any publishing of old media just encourages it. [16:52] I don't want us to have to maintain a full library of all milestones. We build a much larger family of images than cloud-images does. [16:53] And for bisection, it's usually enough to bisect between packages, and they're in the librarian. [16:53] cjwatson, am not advocating all milestones, only the betas [16:53] I don't think they're particularly special for this. [16:54] It took errors.ubuntu.com much longer to stop showing errors from beta-1 than it should have done [16:54] yeah, I noticed that too. [16:54] A ubiquity crasher fixed in beta-2 was the top crasher there for well after beta-2 was released [16:54] That says to me that *any* increase in visibility of beta-1 would be a mistake [16:55] * ScottK agrees with cjwatson [16:56] Understood. It leaves us without a good way of understanding what will happen to the beta1 users when they try to update to the release candidate, but that is the tradeoff then. [16:56] cjwatson: surely it's only a violation if a user requests the source, and it isn't provided? Isn't this just a case of having binaries hanging around? [16:56] (with the source available) [16:56] Daviey: I didn't mention violations. [16:57] Ah, my eyes are too slow.. it was infinity. [16:57] But we are equally without a good way of understanding what will happen to the beta-1 users who'd last updated a week after beta-1, or two weeks after beta-1, and then upgraded to rc [16:58] We do not in general encourage users to upgrade only at milestones; we strongly encourage them to upgrade continuously over the network [16:58] (e.g. by popping dialogs up in their faces) [16:58] If you run the development release and don't update for weeks at a time, I think you own whatever happens [16:59] closer to rc, less update churn, less concern. Its the earlier ones that were lingering I was concerned about. [16:59] Daviey: As long as launchpad keeps every source package ever (a promise we've not made for !release versions, though it may currently be true), then yes, it's only a violation in spirit to not provide a source CD, not in letter. [17:00] However, its moot for now. A possible UDS discussion. I agree its not worth resurrecting the beta 1 images. [17:02] I, like Colin, see no real reason to discuss this at UDS. [17:04] Dear gtk+3.0/armel: please finish building so that the world's installable again there [17:04] (OK, in -proposed) [17:04] infinity: You don't happen to know how to clear the stuck pyorbit build on chort, do you? See #launchpad-ops backlog [17:06] (FWIW, we keep the *logs* of old image builds available essentially forever, so that developers can do archaeology) [17:06] cjwatson: Oh, weird. [17:27] Laney: I noticed you reviewed bug 1064232, can you also review bug 1051162? [17:27] Launchpad bug 1064232 in ubiquity-slideshow-ubuntu "[FFe] New screenshots for installer slideshow in Ubuntu 12.10" [High,Triaged] https://launchpad.net/bugs/1064232 [17:27] Launchpad bug 1051162 in ubiquity-slideshow-ubuntu "FFe: ubiquity-slideshow-ubuntu-gnome" [Wishlist,Confirmed] https://launchpad.net/bugs/1051162 [17:28] I'd prefer to do a single upload before we freeze for good (with updated translations and all the FF that were approved) [17:28] * ogra_ has an ubuntu-meta upload pending ... anyone else wanting any seed changes before i generate the package ? [17:28] I know I could review bug 1051162 myself, but I really don't have an opinion on it. [17:28] Launchpad bug 1051162 in ubiquity-slideshow-ubuntu "FFe: ubiquity-slideshow-ubuntu-gnome" [Wishlist,Confirmed] https://launchpad.net/bugs/1051162 [17:31] stgraber: Seems reasonable to me. [17:37] cjwatson: armel-rebuild is done, I'm guessing, from your text file? (linux-linaro-* don't need rebuilding, obviously, and I assume there's a reason you skipped zope.interface?) [17:37] stgraber: yeah, sure, if gnome remix guys are happy with it [17:38] infinity: zope.interface is building/recently-built [17:38] Ah-ha. So, done. Yay. [17:38] infinity: So yeah, it's done modulo publisher [17:38] Doesn't seem to have reviews though, so you might want to check [17:38] Let queue reviewers rejoice [17:38] infinity: so, as it turns out, tbird won't be released by upstream until tomorrow [17:39] infinity: when is the latest we could push it into quantal? [17:39] infinity: still building, actually, on heka [17:39] slackers [17:39] cjwatson, looking at http://www.freedesktop.org/software/systemd/man/os-release.html /etc/os-release for precise. VERSION_ID may not contain white space, so either set it to 12.04, or 12.04-LTS? [17:39] jdstrand, so 0 day SRU. [17:39] jdstrand: Tomorrow's fine with me. [17:39] * jdstrand got conflicting responses [17:39] doko: you're the os-release guru :) [17:39] infinity, how will that interact with the translations landing? [17:39] we need to have the release candidates on Thursday. [17:40] tbird has its own locales... [17:40] doko: personally I'd be inclined to suggest just 12.04 there, from the description, but I suppose it could go either way [17:40] eg thunderbird-locale-zh-tw [17:40] cjwatson, well, I would keep it as 12.04 for consistency. the pretty names include the LTS anyway [17:40] ok [17:40] "mostly numeric" [17:40] skaet: What jdstrand said. [17:41] skaet: thunderbird and firefox translations are completely decoupled from langpacks. If they weren't, our policy of new upstream releases in security would be a nightmare. [17:41] infinity, its the build time I'm worrying about. [17:41] skaet: It's already built. [17:41]