[09:09] <cjwatson> stgraber: I was hoping you could verify that a UEFI (and preferably SB) machine still boots with the grub-efi-amd64-signed in -proposed
[09:09] <cjwatson> stgraber: precise-proposed, that is
[09:26] <jamespage> freaky - I was about to ask for iscsitarget to be accepted :-)
[09:29] <psivaa> cjwatson: I assume that the fix for precise d-i kernel mismatch issue is still pending
[09:39] <cjwatson> psivaa: Yeah, pending my request to stgraber above
[09:39] <cjwatson> (So that I can promote grub2-signed to -updates, so that I can promote debian-installer to -updates)
[09:39] <psivaa> cjwatson: ack, thanks
[14:15] <plars> cjwatson, balloons: are we going to see the iso tracker open soon for 12.04.2?
[14:19] <stgraber> cjwatson: I'll do that today
[14:22] <plars> stgraber: awesome, thanks
[14:23] <cjwatson> I think he was talking about something else :)
[14:23] <cjwatson> plars: no point until stgraber's done with this verification step for me, but after that, yes
[14:23]  * plars sees the scrollback and realizes his confusion :)
[14:24] <plars> but thanks for that too stgraber... I'd like to see about how we might include some uefi in the automated smoke tests that get run too
[14:24] <plars> iirc, someone looked at this at one point and determined that something was blocking it at the time
[14:27] <stgraber> plars: for the tracker, I actually prepared everything yesterday, so it's just a matter of creating the milestone once we think we're ready (and I realise it's kinda blocking on me, so I'll try to do the UEFI test soon ;))
[14:29] <plars> stgraber: is there anything that would cause problems with automation of uefi/secure boot testing still?
[14:29] <plars> stgraber: I'd like to see if we can get a machine in the lab capable of that and just make it one of the normal daily automated tests
[14:32] <stgraber> plars: well, I'm not sure how good our SB PXE boot story is, so chances are you'd need to boot from a media which makes it a bit harder to automate
[14:33] <stgraber> plars: you'd also typically want two machines, one with SB and one without as you can't simply switch between the two modes (requires a change in the firmware UI which only a local user should be able to access)
[14:33] <plars> stgraber: right, iirc it was an issue with pxe booting
[14:34] <stgraber> yeah, we need a signed grub2 with the tftp module (which apparently had some problems of its own), then a signed kernel. With the right DHCP configuration, the firmware should be able to grab grub verify the signature, then let it grab the kernel, verify the signature and finally boot d-i
[14:35] <stgraber> but AFAIK we don't ship a signed grub2 with tftp support at the moment and our netboot images don't include a signed kernel
[14:36] <stgraber> an alternative is to test secureboot in a VM. I believe slangasek is packaging those bits and it's been working relatively well for me here when doing some grub2/shim debugging, though I never tried to actually run a full install on it (I usually just do it on metal as it's faster)
[14:40] <cjwatson> stgraber: the problem with SB in a VM is that AFAIK there's no way to get it to load nvram state
[14:40] <cjwatson> stgraber: we do ship a signed grub2 with tftp support, but it (reportedly) doesn't work
[14:41] <cjwatson> actually, sorry, I'm wrong
[14:41] <cjwatson> I think I didn't bother *because* it was reported not to ork
[14:41] <cjwatson> *work
[14:43] <stgraber> cjwatson: I actually have a trick for the nvram not being persistent. I have a very simple .efi binary which loads all the signature keys into the firmware and enables secureboot. That binary is put into a minimal disk image along with a startup script that calls it and then calls whatever you want.
[14:44] <stgraber> cjwatson: so when the VM starts, the startup script is detect and called, it then loads the keys and turn on secureboot, anything you try to load after that needs to be signed
[14:45] <stgraber> if we really needed that, I guess we could dump all the variables and have the same efi binary restore all the variables at boot time too (not just the PKI bits)
[14:48] <cjwatson> Does that work for efibootmgr variables too?
[14:53] <stgraber> I only have a vague understanding of how the UEFI variables work, but I guess we could save and restore the efibootmgr variables too yeah.
[14:54] <stgraber> cjwatson: though isn't the nvram at least persistent accross reboot? if so, then we don't even have to worry about this for automated install testing (as they don't usually shut down the VM in the middle of the test)
[14:54] <stgraber> but it'd certainly be nice for people who actually want to setup a test environment where they don't need to manually browse and call grub2 every time they want to boot ;)
[14:56] <stgraber> (I only poked at that stuff because I'm writting some UEFI-SB challenges for a security contest I help organise and we needed to automate testing of the binaries we'd receive from the contestants)
[15:02] <cjwatson> stgraber: I don't *think* it's been for me with kvm/ovmf
[15:04] <stgraber> in theory we don't actually need the boot variables for automated testing, as grub always end up at the same place, we could just call its path from the startup script, but that means we can't test the output of efibootmgr -v post-reboot and that this test should be done as a post-install hook then
[15:04] <stgraber> (btw, almost done installing precise on my laptop, so should have test results for grub2 real soon now)
[15:05] <jdstrand> stgraber, plars: fyi, this page has some stuff for testing in a vm for when I was looking at secureboot-db: https://wiki.ubuntu.com/SecurityTeam/SecureBoot
[15:06] <jdstrand> I've run full installs with secure boot enabled in a vm. it doesn't do pxe boot and doesn't automatically preconfigure the databases. warm reboots are fine
[15:06] <stgraber> ok, cool, so yeah, combined with the efi binary I have here to setup the databases at boot time, we should be able to automate secureboot testing
[15:08] <plars> jdstrand: thanks, I certainly prefer testing on real hardware, but this looks like a good option to investigate
[15:08]  * jdstrand nods
[15:09] <jdstrand> plars: I imagine there is quit a bit in there you could consume that isn't VM specific
[15:09] <jdstrand> s/quit/quite/
[15:09] <plars> jdstrand: indeed, thanks for the link
[15:09] <jdstrand> np
[15:21] <stgraber> fully up to date 12.04.2 system works fine on SB, now trying the new grub2
[15:24] <rtg> tyhicks, when does libaudit-dev get promoted to main ?
[15:28] <stgraber> cjwatson: all good, updated grub-efi-amd64-signed, that pulled secureboot-db, rebooted and everything still works
[15:36] <cjwatson> stgraber: yay
[16:27] <mdeslaur> can someone please reject that postgresql ^
[16:27] <mdeslaur> wrong pocket
[16:28] <xnox> there are folks that really really want lvm2 accepted into -proposed (but not for 12.04.2)
[16:29] <mdeslaur> stgraber: could you reject postgresql, please? ^
[16:29] <cjwatson> mdeslaur: done
[16:29] <mdeslaur> cjwatson: thanks!
[16:29] <mdeslaur> stgraber: nm
[16:29] <cjwatson> xnox: hmm, caribou didn't seem that desperate on #ubuntu-devel?
[16:30] <xnox> cjwatson: yeah, he was more desperate in private message =)
[16:30] <xnox> cjwatson: he has folks that can test it / want to test it asap.
[16:32] <stgraber> mdeslaur: I'm not an archive admin or SRU team member so I can only reject stuff from the dev release anyway ;)
[16:33] <mdeslaur> stgraber: oh! for some reason I though your possessed all of those superpowers :P
[16:33] <mdeslaur> s/your/you/
[16:33] <cjwatson> xnox: reviewing
[16:34] <stgraber> mdeslaur: hehe, I think those two are pretty much the only ones I don't have ;)
[16:34] <mdeslaur> hehe
[16:36] <cjwatson> xnox: ok, looks fine for -proposed, preferably not rammed into 12.04.2
[16:36] <xnox> cjwatson: ok. thank you. I will be gatekeeping it away from 12.04.2
[16:39] <cjwatson> xnox: no need, I'm unlikely to accept it ;-)
[16:39] <cjwatson> any further changes to .2 are manual at this point ...
[16:40] <cjwatson> speaking of:
[16:40] <xnox> \o/ good
[16:40]  * cjwatson promotes debian-installer
[16:40] <cjwatson> and I want this unity change so I think I'll need to waive the waiting period
[16:44] <cjwatson> Right, I think that's the door shut for 12.04.2, barring any validation failures
[16:44] <cjwatson> Will be respinning for the new d-i once it publishes
[16:45] <cjwatson> (I promoted unity too, waiving the waiting period, in case that comment got eaten by my ADSL dropping)
[16:48] <seb128> cjwatson, sorry I didn't upload the 12.04(.1) -> 12.04.2 logo updates yet for gnome-control-center/unity-greeter, waiting on design to send the image (rosie is just working on it atm) ... if that missed the image I guess that can still get in an update
[16:48] <seb128> the greeter says "12.04 LTS" atm, not .1, so that's ok
[16:48] <seb128> the system settings -> details is not the most visible panel so it's no big deal
[16:49] <seb128> (that one says 12.04.1)
[16:49] <ogra_> in a graphic ?
[16:49] <cjwatson> Oh, yes
[16:49] <cjwatson> seb128: 12.04 LTS I think is fine as it is, TBH
[16:49] <cjwatson> That's a name for the whole series
[16:49] <seb128> right
[16:49] <seb128> well, system settings has 12.04.1
[16:49] <cjwatson> seb128: But I agree we should fix the system settings - give me a shout once that's uploaded
[16:49] <seb128> I would be fine with either 12.04 or 12.04.2
[16:49] <seb128> thanks
[16:50] <seb128> will do
[16:50] <cjwatson> I'd forgotten about that
[16:51] <ogra_> having the text in the logo seems pretty pointelss at that place, there would be enough space to just have pango text rendered there
[16:51] <stgraber> seb128: any chance this can eventually be changed to just using lsb?
[16:51] <ogra_> (which could be read from lsb)
[16:51] <seb128> patches are welcome
[16:52] <seb128> if the rendering is the same
[16:52] <seb128> I'm also unsure what's the performance cost of running lsb and generate the logo at every boot, but probably low
[16:52] <cjwatson> Not for 12.04 though please?
[16:52] <ogra_> why at every boot ?
[16:53] <stgraber> the unity-greeter text used to be rendered and was moved to an image, so there must have been some reason, is the system settings stuff also using an image? (it looks like simple text without anything fancy around)
[16:53] <ogra_> you would just render it on the fly if the tab is open or when g-c-c is started or so
[16:53] <stgraber> calling lsb_release is indeed pretty slow, parsing /etc/lsb-release is pretty quick though
[16:53] <seb128> stgraber, yes it is
[16:53] <ogra_> stgraber, well, if we wait for the design team to update "the logo" for reading 12.04.2 ...
[16:53] <stgraber> seb128: fun ;)
[16:53] <seb128> cjwatson, no worry, I don't plan to change that in a SRU
[16:54] <ogra_> heh
[16:54] <cjwatson> If it's a significant hassle for design, we should just make it say 12.04 LTS so that they have to update it less often
[16:54] <ogra_> or ask them to use an svg
[16:54] <ogra_> the text could be seeded at build time into it
[16:59] <seb128> cjwatson, I've a call in one min, I uploaded g-c-c with new logo, I will handle the bug to be SRU compliant etc after my call
[16:59] <seb128> the logo says 12.04.2 LTS
[16:59] <seb128> we can change back to 12.04 LTS later
[16:59] <seb128> or I can do that after my call if you prefer
[17:01] <cjwatson> I don't mind.  I'll wait 'til you've fixed up the bug so I don't have to :-)
[17:01] <cjwatson> Thanks
[17:16] <tyhicks> rtg: re libaudit-dev> The audit package will need to go through a main inclusion review
[17:16] <rtg> tyhicks, I thought that was the whole point of that bug ?
[17:17] <tyhicks> rtg: It is. I did the upfront leg work and now the MIR team will need to take over from here.
[17:18] <tyhicks> rtg: I'm not sure how long it will take, but I'll be pushing for it to be done during this cycle. Some of our AppArmor work needs libaudit.
[17:18] <rtg> tyhicks, as does the kernel
[17:19] <tyhicks> rtg: perf, right? (I added that to the bug description yesterday)
[17:19] <rtg> yep
[17:29] <antarus> cjwatson: .... ;)
[17:30] <antarus> cjwatson: now I get to go rip those unity packages out of Goobuntu so we get yours ;p
[17:30] <antarus> cjwatson: no irc alerts for promoting stuff to updates?
[17:31] <cjwatson> Afraid not, they're based on the queues and this isn't a queue operation
[17:32] <cjwatson> (But stgraber runs that bot, not me)
[17:36] <rtg> herton, so, what knobs am I supposed to twist in a release tracking bug ? bug #1118568
[17:36] <ubot2> Launchpad bug 1118568 in linux (Ubuntu Raring) "linux: 3.8.0-5.10 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1118568
[17:36] <rtg> -EWRONGCHAN
[17:37] <stgraber> yeah, detecting promotions isn't that easy as you essentially need to monitor the whole content of -updates which I believe is pretty large for releases like precise ;)
[17:37] <stgraber> easiest way is to subscribe to precise-changes ;)
[17:38] <antarus> stgraber: I am on precise-changes ;p
[17:38] <antarus> stgraber: it mostly goes in a spambox where I just query it later ;p
[17:44] <antarus> cjwatson: thank you for the quick push in any case ;)
[18:27] <seb128> cjwatson, g-c-c in the queue, bug SRU compliant, I opted for "12.04 LTS", that's what we have on the login screen and will avoid having the issue again for .3
[18:29] <seb128> cjwatson, that's 0ubuntu0.9, I'm uploaded a 0ubuntu0.10 with a fix which was waiting in the queue but that one can go after .2
[19:36] <stgraber> Daviey: there you go, lxc for both precise and quantal with the UEFI fix (and a bunch of others)
[19:46] <Daviey> stgraber: thanks
[21:15] <antarus> ahh days when I hate irc ;)
[21:29] <antarus> :(
[21:29] <antarus> I wonder if marga tested that gnome-control-center patch before she sent it in ;p