[12:04] <xnox> apw, any plans to do mainline builds for s390x?
[12:04] <xnox> e.g. http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-yakkety/
[12:05] <apw> xnox, hmmm, i wonder how we decide
[12:05] <xnox> we are way ahead of everyone else and quite often bugs like "works everywhere but ubuntu" is actually "broke in mainline since X.Y"
[12:05] <xnox> there is ppc64el builds....
[12:05] <xnox> *are
[12:06] <apw> xnox, seem we have a nice non-maintable list ... yay ... so presumably for X+ right ?
[12:07] <xnox> apw, yes please.
[12:08] <apw> xnox, ok added, deployed, and a v4.6 rebuild requested
[12:08] <apw> xnox, we'll see what happens
[12:08] <xnox> cool
[12:39] <rtg> cyphermox, UEFI test kernels at ppa:canonical-kernel-team/unstable
[12:40] <apw> rtg, there was a lot of failure messages in my inbox, was that intentional "don't waste cycled build" failures ?
[12:41] <rtg> apw, I had trouble getting 3.13 to build. It wasn't parsing the ABI number correctly when I added a '~uefi' into the version. I prolly forgot to cancel one of the failing builds before uploading again.
[12:41] <apw> rtg, ahh ok
[12:42] <rtg> it still doesn't build arm64, but I think we can just turn off UEFI on that arch
[12:42] <apw> rtg, sounds like we are missing some packaging back there
[12:42] <apw> rtg, in older releases likely yes we can, but newer ones it may well exist i think
[12:42] <rtg> apw, yeah, I was too tired to figure it out, so I just dropped the '~uefi'
[12:43] <rtg> vivid and wily built OK
[12:58] <rtg> apw, did you change CONFIG_UNIX=m in the mainline build ?
[13:01] <apw> rtg, no, that comes directly from the unstable configs
[13:01] <apw> rtg, so bugger, that means i will ahve to rebuild that _again_ when you fix it
[13:01] <rtg> apw, one of the bug reporters suggested the correct fix was in udev or initrd, though I suppose I could revert the config change for now
[13:01] <apw> xnox, ok s390x builds are now in there anyhow
[13:02] <apw> rtg, it is a trick chicken and egg issue as module loading is handled on demand by udev
[13:03] <rtg> apw, reverted and pushed
[13:03] <apw> rtg, i'll respin that 4.6 so it gets the update
[13:03] <apw> and whoever was testing and failing, can retest
[14:09] <cyphermox> rtg: great. so does that mean there hasn't really been much testing for all of it?
[14:10] <cyphermox> rtg: apw: how far are we from a kernel SRU cycle so we can SRU $everything $everywhere ? ;)
[14:10] <rtg> cyphermox, I've done my own local testing to make sure it does what I think it should. I'm sure these patches could use a bit more exposure.
[14:10] <apw> cyphermox, we start a new cycle next week, so nominally patches need to be avilable today to hit this cycle
[14:11] <rtg> cyphermox, next SRU cycle starts Monday
[14:11] <cyphermox> right, I'm trying to decide if we want to SRU everything now and test there if we're confident enough that things are good, or wait another three weeks or whatever to give us time to test everything in a PPA, on all releases, upgrades, etc.
[14:12] <apw> cyphermox, if we wait 3 weeks can we still hit the point release ?
[14:12] <rtg> cyphermox, given the difficulties consumers of DKMS may face, I'd advise testing, testing, testing
[14:12] <cyphermox> it definitely wouldn't be better to fail to validate and block other things though
[14:13] <cyphermox> 16.04.1 would be July 21st, we'd start to cut it close
[14:14] <cyphermox> I said three weeks, but I really means next one of your SRU cycles
[14:14] <rtg> cyphermox, are all of the user space bits well on their way to -updates ?
[14:14] <apw> cyphermox, will all the rest of the bits be out before then, and do they have to be, i assume they do
[14:14] <cyphermox> rtg: no, things will land along with the kernel, in proposed at the same time
[14:14] <apw> rtg, in theory all of this new code is rendered sterile of we turn off enforcement by default right ?
[14:15] <apw> rtg, so we could consider applying all but that (assuming there is a kernel command line to turn it on for testers)
[14:15] <rtg> apw, its a CONFIG option only right now
[14:15] <rtg> otherwise it kinda defeats the purpose
[14:16] <cyphermox> yeah, I think we shouldn't mess with that especially since it's pretty much what we want to test
[14:19] <apw> mamarley, the v4.6 mainline kernel has been rebuilt with the AF_UNIX thing reverted (in theory)
[14:19] <mamarley> apw: Cool, thanks!
[17:24] <cyphermox> rtg: what about a precise kernel? that seems to be missing from the PPA (or I'm not looking at the right place)
[17:25] <rtg> cyphermox, the Precise kernel did not support signed modules, so we'll have to make do with the LTS Trusty kernel
[17:26] <cyphermox> that's not in the PPA though?
[17:27] <rtg> cyphermox, nope, but you can install the Trusty kernel by hand into a Precise user space
[17:28] <cyphermox> this is a cutoff point at which we won't be making any more of any kernels that can't do signed modules, otherwise we'd be diminishing the value of having a new key (although we haven't got a new key just yet, that will go later)
[17:29] <rtg> cyphermox, personally I think we should just leave Precise as is.
[17:30] <rtg> that, or you'll have to make the new shim dependent on LTS Trusty kernel.
[17:33] <cyphermox> as long as we're supporting precise, I think we can't discount the fact that there may be kernel or other updates -- there's just one key for signing Secure Boot stuff, so I think we need to care about it
[17:34] <cyphermox> afaict that's 10 more months of support, seems unlikely that there won't be some security issue to fix within that time, but I won't pretend I pay much attention to how often kernel SRUs happen on precise :)
[17:35] <rtg> cyphermox, I really don't know either, but I'm sure there will be at least one.
[17:36] <cyphermox> ok
[17:39] <cyphermox> so we should start validating 16.04 since 16.04.1 what's coming up fastest; then trusty (point release in august), and as time permits wily and precise
[17:39] <rtg> cyphermox, ack
[17:40] <cyphermox> rtg: do you have time to do testing on your own with everything? I mean including the userland bits and enabling dkms packages, upgrading to a new release, etc. ?
[17:40] <rtg> cyphermox, we also support LTS Utopic and Vivid for awhile yet.
[17:40] <cyphermox> I have the userland pieces at ppa:cyphermox/efi
[17:40] <cyphermox> ok
[17:41] <rtg> cyphermox, as long as a QEMU instance is OK for testing
[17:41] <cyphermox> needless to say this all means it can't land in the SRU cycle this coming Monday
[17:41] <cyphermox> rtg: should be
[17:41] <cyphermox> you'll want to insert certificates to enable secureboot with the right signature checking
[17:42] <rtg> cyphermox, that is how I tested these kernels thus far, i.e., enrolled my own keys
[17:42] <cyphermox> https://wiki.ubuntu.com/SecurityTeam/SecureBoot
[17:42] <cyphermox> right
[17:42] <rtg> cyphermox, yep, I used jdstrand's script to enroll keys. worked like a charm
[17:43] <cyphermox> I have an unbroken system that can do hardware SB with the MS keys now, so I'll reinstall 16.04 there now and start it
[17:43] <cyphermox> rtg: cool; I haven't had as much luck, but I was able to enroll keys otherwise
[17:43] <rtg> cyphermox, I don't have a bare metal box that will allow me to enroll keys, so I've had to use QEMU.
[17:44] <cyphermox> well
[17:44] <cyphermox> the only keys you ever need enrolled are the Microsoft ones
[17:44] <cyphermox> we're not changing shim itself, so past this it can be done programmatically in MokManager
[17:44] <cyphermox> I think the wiki is missing the relevant info for this; I'll see about adding it
[17:45] <rtg> ok, good point
[17:45] <cyphermox> MS> at the firmware level
[17:45] <cyphermox> Canonical> at the MokManager level
[17:45] <cyphermox> this means your signing keys for the PPA also need to happen at the MokManager level
[17:46] <rtg> I guess that is a change from what I understood needed to happen.
[17:46] <cyphermox> sudo mokutil --import $cert
[17:47] <cyphermox> what did you understand?
[17:47] <rtg> I thought we had to update shim with a new key.
[17:47] <cyphermox> we will
[17:47] <cyphermox> but we're not there yet
[17:47] <rtg> ok
[17:47] <cyphermox> that will be the very last piece, along with an updated grub that disables loading unsigned
[17:48] <rtg> cyphermox, lemme know when the wiki is updated and I'll get started testing.
[17:49] <cyphermox> rtg: ok, but you got the jist of it -- you want to re-sign stuff with your own key since we don't have the PPAs certificate, and then import that cert with the mokutil command above
[17:49] <rtg> yup
[17:49] <cyphermox> on reboot that will get you a blue screen that will have you confirm adding the key
[17:50] <rtg> makes sense
[17:51] <rtg> cyphermox, that reminds me, you don't expect older kernels to read that key from MOK, right ? Only Xenial+ knows how to do that.
[17:52] <rtg> the only recourse for DKMS users on anything prior to Xenial is to disable secure boot.
[17:55]  * rtg pops out for some lunch
[18:18] <cyphermox> well, we at least expect that sudo mokutil --disable-validation will DTRT, and let people boot and load unsigned kernels.
[18:18] <cyphermox> and load unsigned modules
[18:22] <rtg> cyphermox, yes. I have tested that functionality.
[18:41] <cyphermox> rtg: right
[18:42] <cyphermox> well, I'm writing a trusty image to USB now to give this a shot ; I need to test something else to at the same time anyway
[20:02] <cyphermox> rtg: will you add linux-lts-wily and others to the ppa?
[20:04] <rtg> cyphermox, not unless you really want me to. The non-LTS Wily kernel is functionally identical, just built with a newer toolchain.
[20:07] <cyphermox> rtg: it's kind of easier to just dist-upgrade the system with the PPAs enabled rather than mucking around to install various extra packages
[20:07] <cyphermox> we want to make sure upgrades between distros and package upgrades will work, so it's good to be able to pick things up as if they were from the official archive.
[20:08] <rtg> cyphermox, alright, but it'll likely be Monday before they are ready.
[20:09] <rtg> cyphermox, I assume you want all 4 LTS kernels in Trusty ? e.g., Utopic, Vivid, Wily, Xenial
[20:09] <cyphermox> ideally, yes. we want to test everything very carefully and then do the uploads to proposed
[20:09] <rtg> cyphermox, ok