[07:45] <ricotz> sforshee, hi, is there a chance to get this cherry-picked to the current 4.11/artful branch ? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d557d1b58b3546bab2c5bc2d624c5709840e6b10
[07:45] <ricotz> tseliot, hi, ^
[07:55] <tseliot> ricotz: hi, I'm not on the kernel team. Maybe apw could have a look at it ^
[07:56] <ricotz> tseliot, more a fyi, since its suppose to fix the nvidia module build
[07:57] <apw> that _GPL stuff is just such utter make-work to not solve the underlying issue
[07:57] <tseliot> ricotz: err... is nvidia broken in artful?
[07:57] <apw> ricotz, and it seems reasonable to have, and i'll let sforshee pick it up
[07:58] <ricotz> tseliot, if 4.11.0-2.7 lands then yes
[07:58] <tseliot> ricotz: not looking forward to that, then...
[07:58] <ricotz> apw, I am hoping so, since it will be in 4.12 anyway
[07:59] <ricotz> tseliot, 375.66 and 381.22 building fine except for this (fatal) GPL issue
[08:43] <tseliot> ricotz: yes, that's really annoying
=== JanC is now known as Guest55043
=== JanC_ is now known as JanC
[12:02] <sforshee> ricotz: applied
[12:04] <ricotz> sforshee, thanks
=== leitao_ is now known as leitao
[16:19] <gpiccoli> xnox, ping
[16:20] <xnox> gpiccoli, hi
[16:26] <gpiccoli> Hi xnox, how are you doing?
[16:26] <gpiccoli> I'm sorry to bother you
[16:26] <gpiccoli> (and sorry for my delay in replying)
[16:26] <gpiccoli> I have a question about netcfg package
[16:27] <gpiccoli> I tried to take a look in debian files and even git of the package, following a guidance from leitao..but I wasn't able to find the info I need
[16:27] <gpiccoli> "Also use short stable systemd-udev names to discover descriptions for the network interfaces"  <- I wanna know what is this modification ?
[16:28] <gpiccoli> We are investigating an "issue" on network interfaces naming on installer...seems on Xenial 16.04.1 it's getting ethX, and on Zesty, predictable namings (as expected)
[16:28] <gpiccoli> We might have narrowed this to netcfg fix (generically, debian-installer fix)
[16:36] <xnox> gpiccoli, in ubuntu interface names are created by udev. if you are getting ethX in one release but not the other, it is most likely that the patch for udev is missing.
[16:37] <xnox> gpiccoli, is this about s390x CCW bus on Qemu (gets ethX names in xenial) or the ppc64el VIO bus (which only recently was upstreamed)?
[16:37] <xnox> (including inside the installer)
[16:38] <xnox> netcfg only does things like: which ip you want, what netmask, which gateway, what's your hostname, etc. but doesn't assign or change the interface names as generated by udevd.
[16:38] <xnox> gpiccoli, https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c#L21
[16:39] <xnox> note that c<bus_id> and v<slot> names are not available in xenial at the moment. but with some care we can backport that.
[16:39] <xnox> also note that on upgrades to zesty, we try to preserve existing names, and one may need to remove the udev rules that use non-persistent names.
[16:40] <xnox> check udevadm info -p /sys/class/name/<interface> to figure out _why_ udev named something the way it did.
[16:40] <xnox> gpiccoli, i need to run, if you have further questions do open a bug report or email myircnick@ubuntu.com
[16:43] <gpiccoli> thanks very much xnox !
[16:43] <gpiccoli> Really clear explanation. I'll use the udevadm trick if I ever see this behavior again
[21:01] <sforshee> dmj_s76: have you had a chance to test that linux-firmware package yet?
[21:19] <nacc> sforshee: does LP: #1637059 imply that another package needs backporting to 16.04 for the hwe stack?
[21:19] <ubot5> Launchpad bug 1637059 in rtl8812au (Ubuntu) "rtl8812au-dkms 4.3.8.12175.20140902+dfsg-0ubuntu2: rtl8812au kernel module failed to build [error: implicit declaration of function ‘is_compat_task’]" [High,Confirmed] https://launchpad.net/bugs/1637059
[21:26] <sforshee> nacc: that user isn't running the hwe stack, they're running one of the mainline builds which is unsupported. However if it fails to build with that kernel it seems likely it will also fail to build with the hwe kernels too.
[21:26] <nacc> sforshee: there's a user in #ubuntu using 16.04.2 with the same failure :)
[21:26] <nacc> sforshee: same underlying bug, i guess
[21:26] <sforshee> nacc: I'd guess so
[21:27] <nacc> sforshee: i've fixed a few others like this, but shouldn't they be getting automatically caught?
[21:30] <sforshee> nacc: in theory yes, in practice it seems that has been marked as "known to fail" for whatever reason. If it's fixed the status in our test matrix should flip back to good, at which point a build failure for rtl8812au should actually get someone's attention.
[21:31] <nacc> sforshee: ok, at a minimum, the package in 16.04 should have gotten a patch to not build on newer releases if we aren't going to support it there
[21:32] <sforshee> nacc: if you're fixing it you probably also ought to check against linux-hwe-edge
[21:33] <nacc> sforshee: sure, i just think there's something missing in the process :)
[21:38] <sforshee> nacc: so we on the kernel team have filed bugs about the test failure, e.g. bug #1679670
[21:38] <ubot5> bug 1679670 in rtl8812au (Ubuntu) "rtl8812au 4.3.8.12175.20140902+dfsg-0ubuntu2 ADT test failure with linux-hwe-edge 4.10.0-14.16~16.04.1" [Undecided,New] https://launchpad.net/bugs/1679670
[21:38] <nacc> yeah i saw that
[21:38] <nacc> but that log was weird
[21:39] <nacc> it wasn't a build failure
[21:39] <nacc> it was a "i can't remove dkms" failure?
[21:39] <sforshee> it is a build failure, it's just a bit hidden
[21:39] <sforshee> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/r/rtl8812au/20170328_225559_0fd39@/artifacts.tar.gz
[21:40] <sforshee> nacc: if you download ^ the dkms logs will be in there
[21:40] <sforshee> if you had questions you should have asked ;-)
[21:40] <nacc> sforshee: honestly, i was just trying to help a user, who is now leaving ubuntu because of this issue :)
[21:40] <nacc> sforshee: as arch does it right
[21:41] <nacc> sforshee: tbh, this is also in universe and i'd only be fixing it out of my own generosity :)
[21:41] <sforshee> nacc: I see
[21:43] <nacc> sforshee: i stand by my earlier point, though, that if a package is known to not build with a newer kernel (via hwe) and we are defaulting the isos to install hwe for desktop, then there should be a patch for the package in the release to not try to build on newer kernels
[21:43] <nacc> sforshee: otherwise, every kernel update for users results in a failed dkms build
[21:43] <nacc> which seems .. bad for users
[21:46] <sforshee> nacc: I agree. I'm not sure what the answer is though ... we try to make sure that some of the dkms packages we know are widely used are working, but we're unable to do that for every single dkms package.
[21:47] <nacc> sforshee: why not? it's about 30-40 packages that r-b-d on dkms right now
[21:47] <nacc> sforshee: it seems like every hwe bump should be gated that none of those all of a sudden start to fail
[21:48] <nacc> sforshee: not that i'm signing up to help gate them and change the package :)
[22:03] <sforshee> nacc: there is a process that can gate them, we just haven't had enough spare cycles to fix everything. Personally I hadn't thought about updating the packages to not attempt building against the newer kernels, so there may be something to doing at least that.
[22:04] <nacc> sforshee: e.g., smb and I did that to some iscsi package that got mainlined between the 16.04.1 and 16.04.2 kernels
[22:04] <sforshee> nacc: not saying it hadn't occurred to anyone else on the team, just not to me ;-)
[22:05] <nacc> sforshee: if we did a good job of marking the reason (via bug) in the changelog, i think users will at least be less perturbed by the failed dkms builds
[22:08] <nacc> sforshee: to be clear, i wasn't blaming you personally :)
[22:10] <sforshee> nacc: yeah, no offense taken. I've taken note of your discussion so we can discuss it as a team. Thanks for the feedback.
[22:10] <sforshee> s/discussion/suggestion/
[22:11] <nacc> sforshee: and i'm happy to help, to be clear, just let me know
[22:12] <sforshee> nacc: cool, thanks!