[09:27] <jibel> 14.04.4 is not frozen, I still see daily images and no milestone on the tracker for 14.04.4?
[10:08] <infinity> jibel: Oh, sorry, I didn't send the email I claimed I would (but thought maybe you'd have spotted in backscroll) that we're going to release it next week instead, due to delayed testing of various bits that have yet to migrate from -proposed.
[10:08] <infinity> jibel: I'll send that email now.
[10:31] <jibel> infinity, no problem, I didn't scroll back enough. thanks
[10:32] <infinity> jibel: Mail's out to -release and -quality now to clear up the confusion.
=== ant_ is now known as Guest40019
[13:32] <Mirv> thanks infinity
[15:03] <flocculant> infinity: trying to get a head start on xenial beta 1 now that the trusty milestone has dropped back a week - when would I expect images for those wanting to join in to be around? 22nd/23rd ?
[15:03] <flocculant> basically - going to send a mail this week - so I can forget about it next week ;)
[15:13] <jderose> flocculant: infinity: so it's official that 14.04.04 is delayed? is the new target thursday feburary 25th?
[15:17] <flocculant> jderose: no - that date is when xenial beta 1 should finish
[15:17] <flocculant> mail to the -release today for 14.04.4 is for release next week
[15:18] <jderose> flocculant: awesome, thanks!
[17:00] <jderose> rharper: turns out qemu wants to open /usr/share/OVMF/OVMF_CODE.fd read-write also, so it seems you need per-instances copies of both OVMF_CODE.fd and OVMF_VARS.fd
[17:00] <rharper> jderose: hrm
[17:00] <jderose> oops, that should have been in #ubuntu-development i guess :P
[17:00] <rharper> yeah, let's move there
[17:00] <jderose> k
[17:18] <smoser> hi.
[17:19] <smoser> i have some requests for move of binary package to main .
[17:19] <smoser> http://paste.ubuntu.com/15009716/
[17:19] <smoser> asking for move to main of
[17:19] <smoser>  source curtin: binary curtin, python3-curtin
[17:20] <smoser>  source simplestreams: binary python3-simplestreams simplestreams
[17:20] <smoser> i dont think i need an MIR for that, but just and archive admin, right ?
[17:20] <smoser> these are really just a result of python2 -> 3 transition of those packages.
[17:25] <cjwatson> those look fine except curtin (as opposed to python3-curtin) isn't currently listed for movement to main - what requires that?
[17:25] <cjwatson> in fact, nor is simplestreams
[17:26] <smoser> cjwatson, its ok to leave both of those off if you'd like. both are simplly very small main's that call into library.
[17:26] <cjwatson> but I've moved python3-{curtin,simplestreams} to main and python-{curtin,simplestreams} to universe
[17:26] <smoser> but you're right, they're strictly different than the others.
[17:27] <cjwatson> smoser: I don't mind either way but if they are to be in main then there must be something to hold them there, either a dependency or a seed
[17:27] <smoser> what is the process for asking for those binaries to be mmoved ?
[17:27] <smoser> cjwatson, ah. yeah. ok.
[17:27] <smoser> for now then, will leave them off.
[17:27] <smoser> thank you.
[17:27] <cjwatson> np
[18:09] <davmor2> hey guys in 16.04 there is a new feature that disables secureboot at the platform level is there a way to reenable it?  From Uefi everything appears to be enabled but obviously it isn't because it says booting in insecure mode when you boot
[18:11] <xnox> davmor2, at install time, you can disable secureboot, which really communicates such desire to the firmware which will present such query on boot, and one needs to validate that request (by providing a matching password).
[18:12] <xnox> davmor2, there should be no way to disable secure boot from a booted system. Thus, most likely, you or an evil maid have disabled secure boot for you.
[18:12] <xnox> go into your bios (at boot, grub has an option to enter firmware setup) and re-eneable secure boot.
[18:13] <davmor2> xnox: secureboot is enabled that's my point.
[18:15] <davmor2> xnox: what happens now in the install if you select install 3rd party drivers it says type in a password to disable secure boot on restart, so you do that and then a little window popsup, you type in the password and disable secureboot, and you get a message on each startup that says booting in insecure mode, I would like to reenable it to test secureboot installs again
[18:16] <xnox> davmor2, which you can from your firmware bios.
[18:16] <davmor2> xnox: my firmware say secureboot is enabled
[18:17] <slangasek> xnox: no
[18:17] <slangasek> davmor2: you can use 'mokutil' from the commandline to re-enable it
[18:18] <davmor2> slangasek: awesome thanks
[18:18] <slangasek> specifically, mokutil --enable-validation
[18:18] <slangasek> you should be able to do it with like a dpkg-reconfigure dkms or such, but I'm not sure about that; cyphermox would know for sure
[18:18] <davmor2> slangasek: is that documented anywhere I could only find the security team uefi secureboot page in the wiki
[18:19] <xnox> davmor2, can you do $ od -An -t u1 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
[18:19] <xnox> first ?
[18:19] <xnox> to check if secureboot is really enabled?
[18:20] <slangasek> davmor2: blueprint for it is at https://wiki.ubuntu.com/Spec/InstallingUnsignedSecureBoot - not sure if that's where the documentation for it should live, we should definitely have something in release notes
[18:20] <xnox> slangasek, would that re-enroll non-free microsoft key too?
[18:21] <xnox> davmor2, cause e.g. my firmware is funny. secureboot can be "enabled" yet have no keys, thus in effect it's disabled, and is not even in an enroll mode to inject fresh keys.
[18:21] <slangasek> xnox: mokutil doesn't change any of the actual SecureBoot variables in firmware, it only lets you configure a shadow policy to override them.  Per spec, nothing except the firmware itself is allowed to have write access to the actual SecureBoot variables
[18:21] <slangasek> xnox: from context, davmor2 is clearly talking about the changes resulting from the development work cyphermox has done this cycle, not about SecureBoot itself :)
[18:22] <xnox> hmmm. okay
[18:22] <davmor2> xnox: 23 0 0 0 1
[18:23] <cyphermox> davmor2: what you want is mokutil --enable-validation, as slangasek pointed out
[18:23] <davmor2> cyphermox: that's what I'm doing thanks
[18:24] <slangasek> xnox: if you run 'mokutil --disable-validation' and do the password dance, you have *effectively* disabled SecureBoot (which is why everything says that you have done so, from our installer text to the shim "Insecure Mode" printout), because we are allowing the boot of arbitrary unsigned code before ExitBootServices() and SB no longer protects you
[18:24] <slangasek> shim upstream objected to providing a more nuanced policy for "yes I want unsigned code but only after EBS()"
[18:24] <davmor2> slangasek, cyphermox: does that need running as root or user?
[18:24] <slangasek> s/objected to/rejected
[18:25] <cyphermox> davmor2: yes
[18:25] <slangasek> davmor2: root, you're poking variables into firmware :)
[18:25] <xnox> slangasek, ok. that was the clarification i was after. and sigh.
[18:25] <davmor2> thanks
[18:26] <slangasek> xnox: long term plan, which has not yet been scoped, is to replace the installer-assisted SB disabling with installer-assisted local key generation and auto-enrollment
[18:26] <xnox> slangasek, awww and storing those keys in ext4 encrypted folder =)
[18:27]  * xnox ponders when we will replace /home folder encryption with ext4 built-in encryption
[18:27] <xnox> or tpm
[18:27] <xnox> slangasek, to be honest i was surprised that my 2016 dell xps did not come with a tpm or any other secure enclave =(
[18:44] <cyphermox> many machines still don't come with tpms
[18:49] <davmor2> cyphermox, slangasek: Thanks managed it, now I have one more question though with secure boot now re-enabled should the boot of failed or did it remove any 3rd party drivers?
[18:49] <slangasek> davmor2: none of the 3rd-party drivers should be required for boot; they will not have been removed but the modules are not guaranteed to load; in practice the modules will still load today
[18:50] <slangasek> the installer question and debconf support have landed *first*, *before* the kernel module enforcement policy has been changed
[18:50] <slangasek> as it should be
[18:50] <davmor2> slangasek: ah okay that makes sense now thanks :)
[18:51] <davmor2> right now to this mini64.iso and figure out if the mouse works on real hardware :)
[19:02] <davmor2> cyphermox: 14.04.4 UEFI mini.iso why do I have install/cli install/expert install/cli expert install when all installs are d-i  I assume the same on 16.04 also but I'm currently testing 14.04.4
[19:03] <infinity> davmor2: They all give you slightly different preseeds (expert makes you answer *all* questions, generally not a sane thing to pick, cli gives you a bare-bones system, non-cli tries to install desktop tasks)
[19:03] <cyphermox> is that really all on the splash menu?
[19:04] <infinity> Pretty sure all those options have always been there, though I'd argue expert shouldn't be (we removed it from ppc64el to prevent people reporting bugs when they selected it and broke everything :P)
[19:05] <cyphermox> +1
[19:05] <infinity> But I'm not changing that for trusty either.
[19:05] <davmor2> infinity: that I get it is the fact that it gives you install and command line install which are both identical as far as I can tell and then you get the same for expert
[19:05] <infinity> davmor2: install and cli install shouldn't be identical, unless you're preseeding your own task selection.
[19:06] <infinity> Though, that might be broken for HWE versions.
[19:06] <infinity> In fact, quite likely is.
[19:06] <infinity> But we don't "officially" support mini.iso either, it's just a convenient side-effect of the d-i built.
[19:06] <infinity> s/built/build/
[19:06] <davmor2> infinity: that's what I'm running http://archive.ubuntu.com/ubuntu/dists/trusty-updates/main/installer-amd64/current/images/wily-netboot/
[19:07] <davmor2> infinity: no but we do support netboot and mini.iso is the way to test that
[19:07] <infinity> davmor2: Things based on tasks have some chicken and egg issues surrounding the fact that we can't change tasks in the release pocket, so it's quite likely that HWE versions don't do the right thing for GUI installs.
[19:08] <infinity> davmor2: mini.iso isn't the way to test netboot, booting the kernel and initrd is.  Anyhow, if you tell me that this is a regression from vivid netboot/mini.iso, file a bug for me and tell me how wily differs.
[19:09] <infinity> davmor2: If lts-utopic/lts-vivid suck the same as lts-wily, I'm less concerned, but maybe we can fix it anyway.
[19:10] <slangasek> to this day, I do not know why joeyh had the bright idea to map 'expert' to priority=low; that should clearly be called 'masochist'
[19:10] <slangasek> or 'gentoo'
[19:10] <infinity> As a general rule, though, I'm not too concerned (from a point release POV) about "trusty has always sucked" bugs, just "this is a regression from the last point release" bugs.
[19:11] <infinity> slangasek: Yeah, pretty sure everyone agrees.  Removing explicit boot options for expert seems to be enough to keep the damage low, letting people manually preseed it is fine, if they want the scars.
[19:11] <infinity> (As we proved with the ppc64el ISOs)
[19:11] <slangasek> infinity: I always argued it should be priority=medium.  Maybe we should make this change?
[19:12] <davmor2> infinity: no it almost certainly isn't, I was just curious as to why it listed the double entries when they both looked the same, but I can't really tell if it is different because I normally test it in vm and this is the first time I got secureboot to work in vm and noticed it :)  Also I had an issue with the mouse being recognised hence installing on hardware now to confirm :)
[19:12] <slangasek> smaller code delta than removing the boot option everywhere
[19:12] <infinity> slangasek: I'm not sure it's worth changing the semantic of the interface, is it?  I've yet to run into an every-day need for either medium or low.
[19:12] <infinity> slangasek: And extra boot options are both confusing and very tempting (everyone wants to be an "expert")
[19:13] <slangasek> yes, I can see the bug reports now
[19:13] <slangasek> "I chose 'expert' and I only had to answer 200 questions!"
[19:14] <slangasek> "what happened to the prompt for the alpha channel setting for the purple used on my console color scheme?"
[19:14] <davmor2> slangasek: you skipped a step there are 201 question in total naughty you ;)
[19:14] <slangasek> infinity: to be clear, I don't actually care if we change this :)
[19:16] <infinity> slangasek: Hah.  Well, I think most people would be better served by expert not being an up-front choice at all.  The very few people who might care might be following some upstream d-i docs or something and legitimately confused that an important prio=low question they wanted (eg: MBR format or something) was displayed in Debian but not Ubuntu.
[19:16] <infinity> Either way, not "fixing" for a stable release.
[19:16] <infinity> Might rip stuff out for 16.04 to make things more streamlined.
[19:45] <Kamilion> pardon my ignorance; but don't experts generally tend to pass all kinds of interesting configuration on the kernel commandline? At least, I know that's been my experience.
[19:46] <flocculant> infinity: trying to get a head start on xenial beta 1 now that the trusty milestone has dropped back a week - when would I expect images for those wanting to join in to be around? 22nd/23rd ?
[19:46] <flocculant> basically - going to send a mail this week - so I can forget about it next week ;)
[19:52] <infinity> flocculant: Yeah, Mon/Tues of that week, timezone depending.
[19:53] <flocculant> yep - that was my assumption (tz's )
[19:54] <infinity> Kamilion: Actual experts tend to pre-seed the entire installation so it's non-interactive, when I use "expert" in quotes, I'm referring to the sort of users who see an "Expert Mode" boot option on an ISO and assume that's going to open the magic gates to some sort of power-user utopia, which generally then ends up with said user wallowing in a pit of despair.
[19:54] <flocculant> ok - I'll send that this week so I know who wants to take part in 16.04 B1
[19:59] <xnox> infinity, "i used expert mode, went back to configure a second network card, and my ssh conenction to the installer dropped...." i was like "...... which is why noone really should use an expert mode, even if one is an otherwise computing expert."
[20:01] <xnox> infinity, to be honest it's like a click-bait / booby trap. which straight away signals the level of user support required.
[20:09] <Kamilion> infinity: ohhh, okay, like when I started using linux and had to make menuconfig blindly
[20:09] <Kamilion> "Config_VT? naaah, that should be off! I don't want THAT!" :D
[20:13] <Kamilion> or having to decide what would be modular and what would be compiled in. Ugh. Twenty years later and I still can't get a minimal kernel; I always end up going "ooh, yeah, USB mass storage modules would be useful... and USB audio too... And all these USB serial devices I'll never own, but someone else might"
=== DalekSec_ is now known as DalekSec
=== stgraber_ is now known as stgraber
[22:16] <bdmurray> arges: Could you have a look at my ubuntu-release-upgrader upload in the wily queue?
=== teward- is now known as teward
=== stokachu_ is now known as stokachu