[01:50] <ivan> could whoever pushes please push to ubuntu/ubuntu-xenial.git, it's missing Ubuntu-4.4.0-71
[03:23] <hallyn> stupid question.  If I have livepatch enabled, how do I know whether my kernel (a) is in fact being livepatched and (b) is uptodate with the most recent panicy cve-patching kernel release?
[03:23] <hallyn> does "fully-patched: true" mean that latter?
[03:24] <hallyn> (as a response to 'sudo canonical-livepatch status')
[04:56] <stgraber> hallyn: canonical-livepatch status --verbose
[04:56] <stgraber> hallyn: that should show you the CVE that got patched too
[08:06] <smb> ivan, xenial tree is updated now
[08:06] <smb> though only the master branch right now
[10:43] <ivan> smb: thanks
[10:43] <ivan> is there anything in 4.4.0-64 -> 4.4.0-69 (proposed, yes) that could have regressed network device renaming? I used to see eth0,eth1 -> em1,em0 renaming but now absolutely no renaming
[10:44] <ivan> on just one machine. of course.
[10:44] <ivan> running a tg3 0000:03:00.0 eth0: Tigon3 [partno(N/A) rev 5720000] (PCI Express)
[10:52] <ivan> oh wow a SIOCSIFNAME ioctl does this so I need to look outside the kernel too
[10:55] <smb> ivan, I believe the whole renaming game is in some way tied into systemd nowadays (formerly done by udev rules)
[10:55] <ivan> thanks
[10:56] <ivan> I need a Really Stable Device Names that just brings up all the network devices and sees which gets which IP over DHCP
[10:58] <smb> ivan, Maybe "man systemd.link" is helpful for you. Should be working nowadays by creating a *.link file in /etc/systemd/network with a match section for the mac address and a link section with the desired name.
[10:58] <smb> Then update-initramfs -u (not 100% its needed but should not hurt either)
[11:04] <ivan> ah thank you
[11:54] <ivan> it looks like I had an empty (with comments) /etc/udev/rules.d/80-net-setup-link.rules that was inhibiting network device renames
[11:57] <ivan> but now they're eno1,eno2 instead of em1,em0. whatever, I'll live with it
[11:59] <ivan> _oh_, em0/1 aren't stable names, that was a dumb thing to assume
[12:08] <ivan> oh, em = embedded NICs and they're supposed to be stable, I guess the kernel stopped thinking my NICs were embedded NICs (?), whatever
[13:09] <hallyn> stgraber: hm, it doesn't.  i wonder whether the latest cve was not patchable
[13:51] <ivan> oh, I see, things changed because I purged biosdevname
[15:12] <manjo> I need to add a module for ethernet and PHY for arm64 vendor.. it is applicable only to ARM64 and a given vendor .. should I add that to d-i/modules/arm64/nic-modules ? d-i/modules/arm64/modules simply includes generic nic-modules so asking 
[15:16] <manjo> apw, ^ any thoughts ? 
[15:16] <manjo> apw, this for di install of that system 
[15:25] <rtg> manjo, looks right
[15:26] <manjo> rtg, add it to arm64 specific nic-modules correct ? 
[15:27] <rtg> manjo, yep
[15:27] <manjo> awesome thanks
[16:24] <lostgoat> hey guys, trying to make a ppa with some local kernel changes + 4.11-rc4
[16:25] <lostgoat> I've got my kernel + debian patches, and a source package I created using "debuild -S -I -i" 
[16:26] <lostgoat> that uploaded nicely to launchpad, but resulted in error building after 5 hours
[16:26] <lostgoat> /bin/bash: line 3: /<<BUILDDIR>>/linux-4.11.0-rc4+losgoat/debian/build/udeb-meta-packages: No such file or directory
[16:27] <lostgoat> I can look for the solution to this, but I was mostly curious if anyone knows any other pitfalls I should be trying to avoid
[16:27] <lostgoat> don't want to have to wait another 5 hours for a silly mistake
[16:27] <lostgoat> Or if anyone knows how to perform the same build locally that would be great
[16:28]  * lostgoat is not super experienced using debuild
[17:22] <apw> lostgoat, did you clean the package before you built it ?
[17:24] <apw> lostgoat, the specific error you have implies you have debian installer bits turned on but no d-i config
[17:24] <apw> lostgoat, if you arn't making old style CDs from your kernel you might want to set disable_d_i=true in your buidl
[18:28] <lostgoat> apw: yeah I had a local build at some point, but I ran fakeroot debian/rules clean before starting the debuild command. (and also a git clean -fd before that). I might have messed this up somehow though
[18:28] <lostgoat> I'll look into disable_d_i and turn it off as you suggested. I don't need CDs
[18:28] <lostgoat> apk: thanks for the tips
[18:28] <lostgoat> *apw
[18:52] <lostgoat> apw: I've also read about disabling abi checks. Is that something else I should be doing?
[18:54] <apw> yes most likely
[18:55] <apw> skipabi and skipmodule something like that
[19:05] <lostgoat> thanks, will do