[02:13] <JonelethIrenicus> who should I tell about a file that needs to be modified in order for the nvidia binary drivers to work properly with ubuntu kernels on 16.04
[02:15] <sarnold> ubuntu-bug is probably the best bet
[02:15] <sarnold> keeping in mind that the various kernel fixes broke out-of-tree modules in many cases, and perhaps teh fix is already available in newer packages
[02:16] <JonelethIrenicus> im not sure but every time i get a kernel update i have to modify an include file and rebuild
[02:16] <sarnold> JonelethIrenicus: oh? which file? what modification? that doesn't sound right
[02:17] <sarnold> I had the impression it mostly Just Worked for nvidia users most of the time, I wonder if there's something funny with your config?
[02:24] <JonelethIrenicus> sarnold: https://devtalk.nvidia.com/default/topic/1028016/linux/patch-for-compiling-v384-98-modules-with-linux-v4-14-9-/post/5233427/
[02:24] <JonelethIrenicus> just have to add an addtional include
[02:24] <JonelethIrenicus> basically
[02:30] <TJ-> The nvidia-340 dkms fails to build with 4.4.0-112 as well
[02:30] <sarnold> the recent changelogs https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-384/+changelog have "Drop buildfix_kernel_4.14.patch.
[02:30] <sarnold> I'd expect that if the patch was brought upstream ..
[02:33] <TJ-> I just did a build to check and it failed with "error: implicit declaration of function ‘timer_setup’" - the fix is in the graphics-drivers PPA but not in 'restricted'  https://paste.ubuntu.com/26441566/
[02:35] <JonelethIrenicus> im using the nvidia drivers directly from nvidia's website
[03:06] <FourDollars> Hi, could anyone help me to nominate https://bugs.launchpad.net/oem-priority/+bug/1713002 for xenial series?
[03:07] <tsimonq2> For src:ubiquity, right?
[03:07] <FourDollars> yes
[03:08] <tsimonq2> Needs a Core Developer (and I'm not one :) )
[03:08] <FourDollars> :-(
[03:09] <tsimonq2> They're around somewhere...
[11:17] <juliank> cjwatson: strace is FTBFS only on armhf because it starts seeking on fd 3 in a test. It builds fine in Debian. Do you know if the builder do anything weird that could explain that? The program being executed as part of the test only contains a single llseek call for -1
[11:22] <juliank> If anyone else has an idea, the program is http://paste.ubuntu.com/26443755/ - just a simple syscall
[11:22] <juliank> build log at https://launchpadlibrarian.net/354250672/buildlog_ubuntu-bionic-armhf.strace_4.19-1ubuntu1_BUILDING.txt.gz
[11:22] <juliank> It expects one syscall:  _llseek(-1, -374081421428539665, 0xffba69c8, SEEK_SET) = -1 EBADF (Bad file descriptor)
[11:22] <juliank> but it also gets
[11:22] <juliank> +_llseek(3, 944340, [944340], SEEK_SET)  = 0
[11:22] <juliank> +_llseek(3, 937564, [937564], SEEK_SET)  = 0
[11:24]  * juliank thought maybe something is preloaded, some weird libc module thing,  or something
[11:24] <cjwatson> We certainly have no preloads.
[11:25] <cjwatson> It's possible that fd setup is slightly different or something.  Does the test ensure that fds it thinks should be closed are actually closed before it starts?
[11:25] <juliank> I don't think so.
[11:25] <juliank> But there'd also have to be code doing the seeks on fd 3
[11:26] <cjwatson> That is not us.
[11:27] <juliank> I guess I'll run it in a PPA again but let it log all syscalls
[11:27] <cjwatson> I don't believe Debian is running armhf builds on arm64 kernels (there might be some trace in the log that lets you check this), so maybe libc does something slightly different in that case.
[11:27] <cjwatson> To my mind that would be the most likely cause.
[11:30] <juliank> shit
[11:30] <juliank> I uploaded the PPA test to proposed
[11:30] <juliank> Oh well, it's guaranteed to fail anyway
[11:31] <juliank> (I retyped the dput and forgot to specify the ppa)
[11:38] <juliank> +openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
[11:38] <juliank> +read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\331k\1\0004\0\0\0"..., 512) = 512
[11:38] <juliank> +_llseek(3, 944340, [944340], SEEK_SET)  = 0
[11:38] <juliank> ugh
[11:39] <juliank> it's seeking in the library
[11:40] <juliank> Something to fix and forward upstream, awesome
[11:49] <cpaelzer> lyarwood: I took a look at your bug and triaged it further
[11:50] <cpaelzer> lyarwood: I'm subscribed for any further discussion on it
[11:50] <lyarwood> cpaelzer: ack thanks, FWIW I was wrong, the package isn't from UCA, it appears to be the default Xenial version of libvirt AFAIK. Just writing up a reproducer now.
[11:51] <rbalint> ppisati, ogra_, manjo (or anyone interested in and having armhf/arm64 board): i've prepared a merge of flash-kernel but i can't test it myself lacking the hw
[11:51] <cpaelzer> ok, looking forward to look at it then
[11:51] <cpaelzer> thanks lyarwood
[11:52] <rbalint> could someone please test it on an armhf/arm64 system? LP: #1743771
[11:52] <ogra_> rbalint, and i dont have most of the HW the normal distro supports anymore ...
[11:53] <rbalint> ogra_: ok, worst case i'll just upload it to proposed in a few days
[11:54] <ogra_> i could perhaps test beaglebne black and pi2, but thats it (and i'm sure ppisati will do that anyway)
[11:58] <rbalint> ogra_: that would be nice, i'm not looking for full regression on supported systems, just a single run on one
[12:05] <juliank> cjwatson: got it :)
[12:05] <juliank> ogra_: did your ac100 break too?
[12:05] <juliank> :D
[12:06] <cjwatson> juliank: great
[12:06] <ogra_> haha, no idea, i havent booted it in several years (it is somewhere in a box in the basement)
[12:06] <juliank> oh the times spent on that thing.
[12:10] <juliank> Now I only have to wait for my about 30 uploads to migrate :)
[12:41] <lyarwood> cpaelzer: updated, so as I think you have already pointed out this build is actually from the Ocata UCA, apologies about that, I was just confused by the state of an old test instance I was using :)
[12:55] <cpaelzer> lyarwood: never mind, all that helps to clarify is a step in the right direction
[12:55] <cpaelzer> just need to clear my brains cache before looking on it again
[13:19] <cpaelzer> lyarwood: thanks for the details
[13:19] <lyarwood> cpaelzer: np
[13:19] <cpaelzer> lyarwood: interesting that it really is gone in 3.6 (artful / pike)
[13:20] <cpaelzer> lyarwood: I remember we had odd issues with gnutls in zesty, but eventually resolved before release
[13:20] <cpaelzer> I wonder if this might be a strange leftover of this
[13:20] <cpaelzer> coreycb: ^^ as you are on the bug
[13:21] <coreycb> cpaelzer: lyarwood: also worth noting that libvirt in the ocata uca is using gnutls from xenial
[13:23] <coreycb> cpaelzer: lyarwood: well, libvirt in pike uca is also using gnutls from xenial
[13:23] <cpaelzer> yep
[13:24] <cpaelzer> coreycb: there are good repro steps added
[13:24] <cpaelzer> coreycb: if you have ddebs for UCA you mgiht consider stepping through it
[13:24] <cpaelzer> if it really fails on the suggested code section
[13:25] <cpaelzer> lyarwood: was that code snippet found by review or by debugging with gdb?
[13:25] <lyarwood> cpaelzer: review
[13:25] <cpaelzer> tks
[13:25] <cpaelzer> coreycb: so a real debug session might help to verify the theory
[13:25] <cpaelzer> I don't see a much bette rstep forward
[13:25] <cpaelzer> do I miss one in this case
[13:25] <cpaelzer> ?
[14:02] <coreycb> lyarwood: cpaelzer: i wonder if QEMU_CAPS_OBJECT_SECRET is not available
[14:25] <juliank> Something is wrong with the gsequencer autopkgtest: dpkg-buildpackage fails due to missing fakeroot
[14:25] <juliank> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/g/gsequencer/20180123_132702_56441@/log.gz
[14:25] <juliank> (and this test is being triggered by fakeroot)
[14:27] <Laney> juliank: https://tracker.debian.org/news/893466
[14:27] <juliank> ah, it did run them again 1.1.4-1
[14:28] <juliank> all these uploads will be a mess to sort out :)
[14:28] <coreycb> lyarwood: cpaelzer: ok found a difference between the artful/zesty packages. artful has:  configure:#define HAVE_GNUTLS_CIPHER_ENCRYPT 1
[14:31] <cpaelzer> interesting
[14:31] <cpaelzer> coreycb: is that in the resulting config.h or where is that?
[14:31] <coreycb> cpaelzer: that's just in the package from pull-lp-source
[14:35] <cpaelzer> came in with 3.0.0-rc1
[14:54] <cpaelzer> coreycb: the config structure of the m4 files was changed
[14:54] <cpaelzer> not sure this all applies to 2.5
[14:55] <cpaelzer> ha
[14:55] <coreycb> cpaelzer: ok. i'm cloning from anonscm but it's taking a bit. think it's not  backportable to 2.5?
[14:55] <cpaelzer> I think I found it coreycb
[14:55] <cpaelzer> it is backportable semantically
[14:55] <cpaelzer> let me work something out for your to test
[14:56] <coreycb> cpaelzer: ok, thanks cpaelzer
[15:10] <juliank> Can we turn off the stuck in proposed messages for a fww days?
[15:10] <juliank> I did like 30 uploads and of course they're all stuck in proposed
[15:11] <cpaelzer> coreycb: lyarwood: updated the bug
[15:11] <juliank> Maybe like turn them off until Monday and everything caught up?
[15:11] <cpaelzer> coreycb: added to links that should be your fix
[15:11] <cpaelzer> tried to apply to latest zesty, looks good
[15:13] <lyarwood> cpaelzer: cool thanks! :)
[15:16] <cpaelzer> I hope it works as expected
[15:16] <cpaelzer> and if it does keep the good feeling for the next openstack-rant-explosion on our libvirt/qemu :-)
[16:02] <seb128> leosilva, hey, bug #1744855 claims to be a regression from your security update, could you have a look?
[16:03] <leosilva> seb128: tks, let me check.
[16:03] <seb128> leosilva, thanks
[16:27] <nacc> slangasek: i'm sure it's been discussed by the AAs separately, but I would like to point out that hte archive removal of zesty has really shown how many people running non-LTS should not be (or don't get announce e-mails) and also (I think) shows how the yakkety non-removal gave them all a false sense of security in their OS.
[16:28] <nacc> between 10-15 people a day in #ubuntu (which I'm using a metric) complaining of the 404
[16:29] <rbasak> Precise is presumably not removed either.
[16:30] <nacc> true, but ESM makes that wonky, I assumed :)
[16:30] <nacc> I'm less fussed about LTS, because there's a bit of a good story there
[16:30] <nacc> it seemed like non-LTS were not removed promptly in the past, but now they are, and that led to confused/angry users
[16:31] <nacc> totally their fault, admittedly, but it seems like something we should improve on
[17:13]  * rbasak wonders if there's anything in the motd possible via distro-info-data.
[17:13] <rbasak> Though desktop users may well never see that.
[17:14] <nacc> rbasak: there's a bug open to improve it, iirc
[17:14] <nacc> just trying to push on its priority
[17:14] <nacc> :)
[17:17] <TJ-> I've been looking at it... my idea is to teach update-manager to read an EOLdate: field in the changelogs.u.c/meta-release files and then we can trigger early warnings
[17:20] <sarnold> TJ-: doesn't that already exist?
[17:21] <sarnold> TJ-: .. we just don't use it, because we didn't use it last release, so there's no benefit to using it this release. goto 10.
[17:21] <sarnold> TJ-: oh never mind me. sigh. sorry
[17:22] <TJ-> no, there's no EOLdate in meta-release
[17:46] <slangasek> nacc: what improvement do you have in mind, wrt non-LTS removals?
[17:46] <nacc> slangasek: i'm not 100%; is there a policy doc as to when the archives get moved to old-releases?
[17:46] <nacc> slangasek: that might be sufficient, to have it clearly stated in the release notes
[17:47] <nacc> slangasek: several of the users have been reporting they were not bitten by this on the y -> z transition, but have been by the z -> aa transition
[17:48] <slangasek> nacc: right, I think the lack of removal of yakkety was a complete oversight; maybe if we had just done that timely, users would be less likely to be upset?
[17:48] <nacc> slangasek: yeah that is probably true
[17:48] <nacc> slangasek: i guess I wasn't sure if that was oversight, or if it was somethingn that was likely to happen again (even if accidentally) in the future
[17:49] <nacc> or if it become part of the EOL process, maybe?
[17:50] <slangasek> nacc: policy doc> there's https://wiki.ubuntu.com/EndOfLifeProcess , which has always said that we remove it from archive.u.c at EOL
[17:50] <nacc> slangasek: ah that's what i was looking for!
[17:51] <nacc> slangasek: maybe the release notes page(s) can link to the same, or a cleaned up version of that (more user friedly, i mean)
[17:51] <nacc> https://wiki.ubuntu.com/ZestyZapus/ReleaseNotes  Support lifespan section
[17:55] <slangasek> nacc: I don't feel strongly about trying to guard against this in the release notes, I think users who are upset that the release went away at end-of-life are unlikely to have read the release notes and/or unlikely to care about further information about what happens at EOL
[17:55] <slangasek> nacc: but it's a wiki and I don't mind it being edited to include such a link
[17:55] <nacc> slangasek: 100% agree, just want to point them to something
[18:50] <jbicha> maybe some people assumed they had until the end of January before EOL
[18:51] <sarnold> maybe they usually waited for a week or two after one release EOLs before upgrading to the next, to let other people debug the transition
[18:52] <jbicha> and some people were just really hesitant to upgrade to 17.10, although even before 17.04's release, it was widely reported that 17.10 would switch to GNOME
[18:53] <jbicha> I think part of the EOL problem is that Ubuntu developers don't tend to see the issues since we don't usually run Ubuntu versions that old!
[18:58] <slangasek> aiui the only remaining "issues" are that you'll get an error about not finding the repository, but that you will still be prompted to update to the new release
[18:58] <sarnold> will do-release-update complain if they missed the last N weeks of updates?
[18:58] <slangasek> it shouldn't, considering those updates are no longer available ;)
[18:59] <sarnold> right :)
[18:59] <sarnold> I'm glad it fails on the happier side of that fence
[18:59] <TJ-> The guides tell people to alter sources.list and replace the archive.ubuntu with old-releases.ubuntu
[19:00] <TJ-> then an apt-get update/dist-upgrade followed by do-release-upgrade
[19:01] <slangasek> do-release-upgrade itself was fixed some time ago to not care about the current release being missing
[19:08] <TJ-> hmm, tried in an LXD container and got "Cannot open your terminal '' - please check."
[19:09] <nacc> TJ-: you porbably need to run ashell with a controlling tty
[19:09] <nacc> TJ-: in the lxd
[19:10] <jbicha> slangasek: see LP: #1744722
[19:17] <TJ-> nacc: I wrapped it in 'script' which provides pts
[19:19] <nacc> TJ-: oh ok
[19:32] <nacc> Laney: can we allow request.cgi again, or is there any ETA on that for autopkgtest?