=== cpaelzer_ is now known as cpaelzer
[08:38] <xnox> apw, right and last week i was like "somebody tell me if this fixes it for them or not"
[08:38] <xnox> =)
[08:50] <apw> xnox, this fixes it for me :)
[08:52] <xnox> =)
[11:38] <ricotz> apw, hi, you might be interested in https://paste.debian.net/plain/740703
[11:38] <ricotz> (full log at https://launchpadlibrarian.net/266795156/buildlog_ubuntu-yakkety-amd64.firefox_48.0~b2+build1-0ubuntu0.16.10.1_BUILDING.txt.gz)
[11:41] <ricotz> rtg, hi, or you ;) ^
[12:08] <apw> ricotz, i think thats something that broke in a stable update, and i believe we are respinning at the moment for this
[12:10] <ricotz> apw, I see, the xenial build seems to work while it uses 4.4.0-24.43 instead of 4.4.0-25.44 
[12:11] <ricotz> apw, I guess this only affects x86(_64)?
[12:11] <apw> ricotz, right ... the fix for a cve introduced the issue, and we have a fix on deck for that i believe
[12:12] <ricotz> apw, is there an eta or a bug report to follow?
[12:14] <apw> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1592930
[12:14] <ubot5> Launchpad bug 1592930 in linux (Ubuntu) "failures building userspace packages that include ethtool.h" [Medium,Triaged]
[12:14] <apw> ricotz, ^ that appears to be the bug we are tracking under
[12:14] <ricotz> apw, alright
[12:14] <apw> ricotz, i believe the only affected version is in xenial-proposed and that one will replaced as soon as the new one builds
[12:15] <apw> ricotz, and indeed it may alreday be built and pending review to copy, i'll check next
[12:15] <ricotz> ok, yakkety too of course
[12:17] <apw> ricotz, yes it gets copied there too
[12:19] <ricotz> thanks
=== ratliff_ is now known as ratliff
[17:26] <kees> when/where are the kernel team meetings these days? it seems https://wiki.ubuntu.com/KernelTeam/Meeting is very out of date :)
[17:28] <apw> kees, we don't have scheduled ones any more, noone came for 2 years, so we switched to a newsletter form
[17:29] <apw> kees, do feel free to make free with this channel to start discussions any time
[17:30] <kees> apw: ah! okay. well, in that case, I'd like to discuss a packaging/building changes for future kernels
[17:30] <kees> or rather, give a heads-up.
[17:30] <kees> I'm in the process of merging support for gcc-plugins into the upstream kernel
[17:30] <kees> this means a few things:
[17:30] <kees> - building the kernel with gcc-plugin-enabled features will require the gcc-N-plugin-dev package added
[17:31] <kees> - the kernel-headers package will either need to depend on a new binary package, or will need to become a binary package
[17:31] <kees> - said binary package will need to include the .so files that are the built gcc plugins from the kernel build
[17:31] <kees> (so that out-of-tree builds can run the plugins)
[17:32] <kees> Does any of this sound terrible, and either way, is there anything I can do to help with it?
[17:32] <apw> the headers are already binary arch/flavour specific, we include some kind of .so in the powerpc ones for the same reason; so that sounds tractible
[17:32] <kees> oh, excellent. well that's one problem down. ;)
[17:32] <apw> the first is just new build-depends if i am reading things right
[17:33] <kees> right, that should be trivial
[17:33] <kees> it was the "carry .so files in the headers package" that seemed to me to be the "worst" :)
[17:33] <apw> so overall that sounds like its mostly about knowing what to include in the headers packages
[17:33] <kees> but you're already doing that, so yay
[17:33] <apw> i beleieve we include the config binary in them for instance so we have to be binary
[17:34] <kees> yeah, I'm going to try to figure out what it looks like for out-of-tree builds. I assume some symlinks or something need to be added/tweaked/etc
[17:34] <apw> when is all this slated to land ?
[17:34] <apw> yeah i assume it all lands linked out of /lib/<version>/build/lib or something
[17:34] <kees> the first plugin should be landing in 4.8. more should follow
[17:34] <apw> lib/modules/<version>
[17:35] <apw> damn so we will likley have to figure this out for yakkety then, could you copy me on the patches as and when
[17:35] <kees> I think it would end up being /lib/modules/VER/build/scripts/gcc-plugins/ right now, but yeah
[17:35] <kees> sure thing
[17:35] <apw> ok so we include scripts already, so it might just happen "naturally" but we clearly need to track
[17:35]  * apw dumps this info in our "things to fear" list
[17:35] <apw> kees, and thanks for the heads up
[17:36] <kees> yeah, and I think we'll want to first plug ("latent_entropy") enabled by default on x86, arm, and arm64 at least.
[17:36] <kees> sure thing!
[17:36] <kees> s/want to/want the/
[17:38]  * apw hopes the patches will make it clear what is going on :)
[17:38] <kees> ... I'm hoping so ... but ... the kbuild parts are dark magick that I am only now starting to understand.
[17:39] <kees> and the plugins themselves are compiler dark magick... but they have a lot of comments.
[17:39] <apw> yeah kbuild is deeply arcane black magic, i am supprised it is legal
[17:39] <kees> hehe
=== JanC is now known as Guest79667
=== JanC_ is now known as JanC
[17:55] <kees> (in related news, can't this spl thing be a pre-built dependency, it takes forever to run its configure script in the kernel build)
[18:34] <cyphermox> apw: hey
[18:35] <cyphermox> did you have a look at the testing matrix for secure boot? or is it all just for rtg? 
[19:48] <apw> cyphermox, i cast an eye over it, i've not got to do anything aboutit yet
[20:09] <cyphermox> apw: fair enough