=== rsalveti_ is now known as rsalveti [10:50] there's no d-i upload using the backport stack for 12.04.2 yet? [10:54] should be in -proposed ... [10:56] oh [10:57] yeah there it is.. didn't think to check -proposed [10:58] I think there is a newer kernel available now (-35), so maybe a rebuild is in order? [10:58] uh [10:58] -21 [10:59] I'd like to finish landing the SB stack first please [10:59] sure, just thinking out loud :) [10:59] stgraber: Did you ever manage to test precise images on non-SB systems of any kind? [10:59] (Or anyone else?) [11:08] cjwatson: you mean like the -proposed netboot image? I can give it a go [11:12] I meant CD images [11:14] I've installed it on a haswell system, no secure boot [11:14] before the holidays [11:14] BIOS or UEFI? [11:15] good question.. I'll check. could be bios === mmrazik is now known as mmrazik|afk [11:41] cjwatson: bios.. [11:45] OK, thanks [11:45] Anyone done a non-SB UEFI test with current precise imageS? [11:45] *images [11:45] i'll try that next [11:46] Brilliant, thanks [11:46] hmm, maybe I should try some other image than this oem one... [11:47] and not on the beta hw :) [11:47] has issues with booting uefi it seems === doko_ is now known as doko [11:54] cjwatson: is it the precise/dvd/current image on cdimages.u.c? [11:55] it says 12.04.2 [11:56] Yeah [11:56] ok, takes a while to download === yofel_ is now known as yofel === mmrazik|afk is now known as mmrazik [13:13] cjwatson: I get "error: couldn't read file; error: you need to load the kernel first" after the grub menu [13:14] Any difference with the desktop image? [13:14] precise/daily-live/current/ [13:14] and this is amd64 I presume [13:15] downloading, and yes [13:16] the oem image had the same problem [13:16] from mid-december with the new stuff on it [13:18] I'm not going to debug the OEM image since some of this stuff can depend on fine details of image construction [13:20] right, but it could be something related to the haswell firmware too. I'll ask around just to be sure [13:21] It's possible, although an outside chance [13:27] Also possibly worth comparing with 12.04.1 to see whether this is a regression [13:42] hm, the amd64+mac image I had doesn't even seem to load grub [13:42] Why are you using amd64+mac? [13:42] Its purpose is not to have UEFI support. [13:42] it's the only cd-sized image there was [13:43] It's not a valid test for this. [13:43] and I had that already [13:43] this was .1 [13:43] .2 just finished downloading [13:43] http://askubuntu.com/questions/37999/what-is-different-about-the-mac-iso-image [13:44] ^- explains that amd64+mac does not have UEFI support [13:44] Does this brand-spanking-new system really have a CD-only drive? [13:45] no :) [13:45] s/cd-sized/reasonably sized/ [13:46] booting off a usb stick didn't work the last time I tried [13:46] eh, the amd64 image is very similar in size to the amd64+mac image [13:46] to within noise, basically [13:46] http://cdimages.ubuntu.com/releases/12.04.1/release/ [13:47] http://releases.ubuntu.com/12.04/ [13:47] besides, it was just what I had on the system readily available, I'll try .2 now while .1 dvd is downloading [13:47] bah [13:47] confusing :) [13:47] (and see the link at the top of that page ...) [13:47] hah [13:48] bad/old habit of using cdimages.u.c.. [13:48] current precise-desktop-amd64 works fine in kvm/uefi for me [13:49] well, gets to grub and boots the kernel [13:50] I'll do a full test install in kvm [13:51] working in kvm seems to eliminate this being an image construction bug, so I think a firmware problem has become more likely [13:52] yeah [13:52] or firmware setting bug [13:52] admittedly I've not tried the DVD yet; it'll take a couple of hours to download [13:53] the fact that grub got as far as it did for you indicates that efidisk is at least somewhat working, since it read its configuration file [13:54] check that the problem's repeatable, too [13:55] same thing with the desktop image.. trying with the usb stick now [13:55] could be a brazero issue on quantal [13:55] I use growisofs for burning DVD images [14:04] cjwatson: ha, booted fine off the usb stick, installing now [14:07] OK, good; I'd still like to know that it isn't a regression, but that's helpful [14:07] cjwatson: I did one before the holidays by accident (forgot to enable SB) and it worked fine [14:07] I'll try with the growisofs-burned image next [14:08] infinity: Do you remember anything else we wanted to check before dropping in the whole lot? [14:11] I still have two other grub2 patches I want to squeeze in for .2 (one customer-requested), and am running out of time ... === lamont` is now known as lamont [14:47] cjwatson: not a regression, getting the same with .1 [14:47] something wrong with the machine [14:48] but usb worked, installed and boots afterwards [14:48] phew (from my pov) [14:48] :) [14:51] the .2 image doesn't seem to use the xorg backport stack yet? [14:51] no, just the kernel backports [14:51] not worked out what we need to do for xorg yet [14:53] a new meta package for ubuntu-desktop, and the desktop task that installs it? [14:55] mlankhorst should know, I'll ask.. [14:57] task changes are troublesome [14:57] I think we're actually going to have to switch to the metapackage; but if we change the metapackage then that upgrades existing users ... [14:57] the kernel was easier since that's already handled specially [14:58] so there's xserver-xorg-lts-quantal, but the current archive version would remove ubuntu-desktop [14:58] and there's a new version that fixes that, but not accepted yet === Ursinha-afk is now known as Ursinha [15:00] let's see about that [15:00] on the proposed queue I'm told.. [15:00] no bug ref, makes it hard to coordinate validation? [15:01] hmm [15:01] there are occasional very routine things we do without that, but not sure this counts as routine [15:01] hey [15:01] mlankhorst: 17:00 < cjwatson> no bug ref, makes it hard to coordinate validation? [15:01] for the xorg upload [15:02] hm would have to check [15:03] don't know if it had a bug or not [15:03] if not, could you create an artificial one, please? [15:03] I just want some way of ensuring that this all works together nicely [15:04] and somebody is going to have to recommend a set of installer/metapackage/whatever changes, bearing in mind upgrade effects [15:04] so far most communication goes through me [15:04] so felt like having a bug was confusing [15:04] for SRUs it needs to be in bugs [15:04] please [15:05] it will make things better since there'll be clear status right there on the SRU report [15:05] can't do much about the existing xorg updates; right now they're all sitting there with no way to indicate whether they're good for promotion to -updates :-/ [15:06] so, the spec says that upgraders won't be pulled into the new enablement stack [15:06] right [15:07] yeah the xorg package just allows the lts-quantal version to be coinstalled [15:07] this means we somehow need to get the images changed without touching metapackages [15:07] but the .2 image needs to have some way to pull xorg-lts-quantal [15:07] which then provides 'xorg' for ubuntu-desktop [15:07] this is kind of horribly out of spec for the image building tools - but there may be some ways to achieve it [15:08] erm [15:08] xorg can install just fine [15:08] it's just the xserver-xorg that will conflict with xserver-xorg-lts-quantal [15:08] I can't really do anything until the SB stack lands, at risk of entangling the two [15:08] sure, but that doesn't address the image building problem [15:09] it makes it possible to do something without breaking upgraders, yes [15:10] but I think we're going to need to SRU at least livecd-rootfs and possibly pkgsel to manually arrange to install -lts-quantal [15:10] actually I'd rather leave pkgsel alone and only support installing the enablement stack from desktop images ... [15:10] (and DVD) [15:10] and there's the question of things like the Chinese edition [15:12] kind of unfortunate nobody arranged for anyone cdimagey to have a work item for this ... [15:12] :) [15:13] so, if I can have an xorg reupload with a bug ref, I'll accept that, and then we can get going on the image building changes after the SB changes are in -updates [15:14] ok [15:14] could you look at the video blobs in the meantime? [15:15] specific package names? [15:15] nvidia-* and fglrx whatever, that are still in the proposed queue [15:15] mkay [15:18] do you want a bug specific about xorg, or just generic 'xorg quantal in precise' bug [15:19] the latter's fine [15:20] sigh, at least one of these fglrx uploads is busted [15:20] is tseliot on IRC anywhere? [15:20] should be [15:20] but not online atm [15:20] probably on holiday [15:24] in that case perhaps one of you could upload new fglrx-installer-experimental-9 and fglrx-installer-updates packages in line with comments #31 and #32 in bug 1080588 (i.e. drop the xserver-xorg-core deps and upload with appropriate -v)? [15:24] Launchpad bug 1080588 in jockey (Ubuntu Precise) "jockey suggests not installable packages on renamed stack" [High,In progress] https://launchpad.net/bugs/1080588 [15:33] cjwatson: hm should I bump version of xorg as well or can you delete the current one from -proposed? [15:33] mlankhorst: I've rejected it [15:34] ah k [15:36] cjwatson: so can I reuse 2:9.010-0ubuntu0.2 and squash both changes there? [15:37] In this case, since there's an additional change, I'd rather you used a new version number [15:37] (actual source change rather than just changelog) [15:37] so 0.4? [15:37] Yeah [15:38] ok I'll deal with those [15:43] cjwatson: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1095686 good enough? [15:43] Launchpad bug 1095686 in xorg (Ubuntu) "xorg needs to be updated to allow quantal xserver stack to be installed" [Critical,In progress] [15:43] jeez, fglrx is huge.. [15:44] mlankhorst: yes, thanks, now that I've targeted it to precise :) [15:44] ah right [15:44] uploading [15:46] oops [15:46] oops? [15:46] raced with your bug changes :) [15:47] not a problem ... [15:47] but it's there now, I'm uncertain about the fglrx changes, tjaalton are you working on it? [15:48] yeah, I'll review it once the queue gets a debdiff [15:48] mlankhorst: yeah, trying to figure out what to actually change :) [15:49] how are those maintained btw? [15:50] in git somewhere I think, but pulled them from the rejected queue [15:50] https://launchpad.net/ubuntu/precise/+queue?queue_state=4&queue_text= [15:50] yeah I was just curious if we had a central repo or something, similar to other xorg things [15:51] nothing we can touch [15:51] it's on github or such [15:51] ah [16:08] fglrx-installer-experimental uploaded [16:08] -updates after dinner [16:22] cjwatson: the nvidia-96 upload you accepted failed to upload (after build) on amd64, should I just kick a rebuild? [16:24] sure, if it looks transient [16:27] yup, built fine [16:34] ok now xorg should work? :) [16:34] hmm, so fglrx-updates in precise doesn't even support the new backport stack, is there any point in updating that version for that bug? [16:34] nah [16:35] ok, so it may wait for the other sru to pass [16:35] although, it has the same bug as the experimental one [16:42] yay [16:46] anyone know why in 12.04.2 the kernel versions vary between the amd64 and i386 builds? [16:46] http://cdimage.ubuntu.com/precise/daily-live/current/precise-desktop-i386.manifest [16:46] linux-image-generic-pae 3.2.0.35.40 [16:46] http://cdimage.ubuntu.com/precise/daily-live/current/precise-desktop-amd64.manifest [16:46] linux-image-generic-lts-quantal 3.5.0.21.28 [16:47] oh ... are the boot kernels on i386 non-pae i wonder [16:49] hmm no, that is a pae kernel on there, so not that [16:52] brendand: ara already asked about that on #ubuntu-devel [16:52] and yes it probably is something to do with pae [16:52] it's on my list [16:53] cjwatson, ok. a fix isn't an emergency from our perspective. mainly we just needed to know whether it was in fact a bug [16:53] cjwatson, we wanted to make sure that 3.5 was the kernel that was supposed to be included [16:54] it is a bug and is something I need to fix for .2 [16:55] cjwatson: both fglrx packages uploaded, but the other sru's still block them [17:01] cjwatson: I'm sure we have a lot more misfeatures to shake out on images, but I can't think of anything else SB-specific that needed testing. I've been mostly not getting in the way of you, slangasek, and stgraber testing, mind you. :P [17:10] infinity: OK. Do you have any objection if I just promote the lot now, then? [17:14] cjwatson: Nope. [18:43] * cjwatson copies all the things === TheLordOfTime is now known as LordOfTime === LordOfTime is now known as TheLordOfTime [19:44] cjwatson: The patch to debian/* in grub doesn't match the behaviour you patched into grub itself. [19:45] cjwatson: (That is, the debian bits will ignore grub.d if /etc/default/grub doesn't exist, while grub will still use grub.d even if default/grub isn't there) [19:46] cjwatson: Not sure which behaviour is most desirable, but they should probably be consistent. [19:48] fair point; I'll fix that later (and in experimental/raring too) [19:49] feel free to reject/hold/whatever [19:51] cjwatson: I'd probably lean toward the way you did grub, so one could break out default/grub to .d snippets and delete the file entirely, but your call. I'll reject for now. [19:54] cjwatson: Something like http://paste.ubuntu.com/1492918/ perhaps. [19:55] (And a similar munging of postinst) [20:00] cjwatson: Tested the above locally, seems to work as I'd expect. [20:04] Can the release of Precise SRUs proceed as usual? If so until when? [20:06] bdmurray: Yes, until the 17th, ish. [20:07] ah. just a week left. [20:08] infinity: thanks! [20:08] xnox: Your weeks are 14 days long? [20:11] that'd make for less weekends :-( [20:12] cjwatson: Oh, hey, I have commit access to grub in Debian, don't I? Maybe I'll just commit this directly, unless you'd rather I didn't? [20:15] infinity: 1 week to upload & accepted in -proposed + 1 week of baking , to be release on time. [20:16] xnox: Final freeze for 12.04.2 is the 24th, I was giving the 17th as the last possible day to accept things (barring emergencies). [20:16] oh, ok. [20:16] Not that I have problems with people thinking the deadline is a week earlier. Last minute panic sucks. [20:34] I just verified bug 1008225 if somebody wants to release it - its been in -proposed for some time. [20:34] Launchpad bug 1008225 in vm-builder (Ubuntu Precise) "vmbuilder fails using tmpfs due to upstart restarting cron in the tmpfs" [High,Fix committed] https://launchpad.net/bugs/1008225 [20:43] bdmurray: Done. [21:20] I've made an ubuntu-archive-tools merge proposal - https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/comment-date/+merge/141818 - nothing too exciting though [22:06] bdmurray: I object. The diff has more green than red, and I hate green. [23:52] infinity: that's fine to commit directly, but isn't it needed in postinst.in too? [23:53] infinity: (definitely to experimental though, not to the unstable/wheezy branch)