/srv/irclogs.ubuntu.com/2017/05/11/#ubuntu-kernel.txt

ricotzsforshee, 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=d557d1b58b3546bab2c5bc2d624c5709840e6b1007:45
ricotztseliot, hi, ^07:45
tseliotricotz: hi, I'm not on the kernel team. Maybe apw could have a look at it ^07:55
ricotztseliot, more a fyi, since its suppose to fix the nvidia module build07:56
apwthat _GPL stuff is just such utter make-work to not solve the underlying issue07:57
tseliotricotz: err... is nvidia broken in artful?07:57
apwricotz, and it seems reasonable to have, and i'll let sforshee pick it up07:57
ricotztseliot, if 4.11.0-2.7 lands then yes07:58
tseliotricotz: not looking forward to that, then...07:58
ricotzapw, I am hoping so, since it will be in 4.12 anyway07:58
ricotztseliot, 375.66 and 381.22 building fine except for this (fatal) GPL issue07:59
tseliotricotz: yes, that's really annoying08:43
=== JanC is now known as Guest55043
=== JanC_ is now known as JanC
sforsheericotz: applied12:02
ricotzsforshee, thanks12:04
=== leitao_ is now known as leitao
gpiccolixnox, ping16:19
xnoxgpiccoli, hi16:20
gpiccoliHi xnox, how are you doing?16:26
gpiccoliI'm sorry to bother you16:26
gpiccoli(and sorry for my delay in replying)16:26
gpiccoliI have a question about netcfg package16:26
gpiccoliI 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 need16:27
gpiccoli"Also use short stable systemd-udev names to discover descriptions for the network interfaces"  <- I wanna know what is this modification ?16:27
gpiccoliWe 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
gpiccoliWe might have narrowed this to netcfg fix (generically, debian-installer fix)16:28
xnoxgpiccoli, 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:36
xnoxgpiccoli, 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:37
xnoxnetcfg 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
xnoxgpiccoli, https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c#L2116:38
xnoxnote 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
xnoxalso 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:39
xnoxcheck udevadm info -p /sys/class/name/<interface> to figure out _why_ udev named something the way it did.16:40
xnoxgpiccoli, i need to run, if you have further questions do open a bug report or email myircnick@ubuntu.com16:40
gpiccolithanks very much xnox !16:43
gpiccoliReally clear explanation. I'll use the udevadm trick if I ever see this behavior again16:43
sforsheedmj_s76: have you had a chance to test that linux-firmware package yet?21:01
naccsforshee: does LP: #1637059 imply that another package needs backporting to 16.04 for the hwe stack?21:19
ubot5Launchpad 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/163705921:19
sforsheenacc: 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
naccsforshee: there's a user in #ubuntu using 16.04.2 with the same failure :)21:26
naccsforshee: same underlying bug, i guess21:26
sforsheenacc: I'd guess so21:26
naccsforshee: i've fixed a few others like this, but shouldn't they be getting automatically caught?21:27
sforsheenacc: 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:30
naccsforshee: 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 there21:31
sforsheenacc: if you're fixing it you probably also ought to check against linux-hwe-edge21:32
naccsforshee: sure, i just think there's something missing in the process :)21:33
sforsheenacc: so we on the kernel team have filed bugs about the test failure, e.g. bug #167967021:38
ubot5bug 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/167967021:38
naccyeah i saw that21:38
naccbut that log was weird21:38
naccit wasn't a build failure21:39
naccit was a "i can't remove dkms" failure?21:39
sforsheeit is a build failure, it's just a bit hidden21:39
sforsheehttps://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/r/rtl8812au/20170328_225559_0fd39@/artifacts.tar.gz21:39
sforsheenacc: if you download ^ the dkms logs will be in there21:40
sforsheeif you had questions you should have asked ;-)21:40
naccsforshee: honestly, i was just trying to help a user, who is now leaving ubuntu because of this issue :)21:40
naccsforshee: as arch does it right21:40
naccsforshee: tbh, this is also in universe and i'd only be fixing it out of my own generosity :)21:41
sforsheenacc: I see21:41
naccsforshee: 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 kernels21:43
naccsforshee: otherwise, every kernel update for users results in a failed dkms build21:43
naccwhich seems .. bad for users21:43
sforsheenacc: 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:46
naccsforshee: why not? it's about 30-40 packages that r-b-d on dkms right now21:47
naccsforshee: it seems like every hwe bump should be gated that none of those all of a sudden start to fail21:47
naccsforshee: not that i'm signing up to help gate them and change the package :)21:48
sforsheenacc: 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:03
naccsforshee: e.g., smb and I did that to some iscsi package that got mainlined between the 16.04.1 and 16.04.2 kernels22:04
sforsheenacc: not saying it hadn't occurred to anyone else on the team, just not to me ;-)22:04
naccsforshee: 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 builds22:05
naccsforshee: to be clear, i wasn't blaming you personally :)22:08
sforsheenacc: 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
sforshees/discussion/suggestion/22:10
naccsforshee: and i'm happy to help, to be clear, just let me know22:11
sforsheenacc: cool, thanks!22:12

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!