/srv/irclogs.ubuntu.com/2018/01/23/#ubuntu-devel.txt

=== mnepton is now known as mneptok
JonelethIrenicuswho 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.0402:13
sarnoldubuntu-bug is probably the best bet02:15
sarnoldkeeping in mind that the various kernel fixes broke out-of-tree modules in many cases, and perhaps teh fix is already available in newer packages02:15
JonelethIrenicusim not sure but every time i get a kernel update i have to modify an include file and rebuild02:16
sarnoldJonelethIrenicus: oh? which file? what modification? that doesn't sound right02:16
sarnoldI 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:17
JonelethIrenicussarnold: https://devtalk.nvidia.com/default/topic/1028016/linux/patch-for-compiling-v384-98-modules-with-linux-v4-14-9-/post/5233427/02:24
JonelethIrenicusjust have to add an addtional include02:24
JonelethIrenicusbasically02:24
TJ-The nvidia-340 dkms fails to build with 4.4.0-112 as well02:30
sarnoldthe recent changelogs https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-384/+changelog have "Drop buildfix_kernel_4.14.patch.02:30
sarnoldI'd expect that if the patch was brought upstream ..02:30
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:33
JonelethIrenicusim using the nvidia drivers directly from nvidia's website02:35
FourDollarsHi, could anyone help me to nominate https://bugs.launchpad.net/oem-priority/+bug/1713002 for xenial series?03:06
ubottuLaunchpad bug 1713002 in OEM Priority Project xenial "oem-config-gtk crashed when using some UTF-8 based languages" [Critical,Confirmed]03:06
tsimonq2For src:ubiquity, right?03:07
FourDollarsyes03:07
tsimonq2Needs a Core Developer (and I'm not one :) )03:08
FourDollars:-(03:08
tsimonq2They're around somewhere...03:09
=== wgrant changed the topic of #ubuntu-devel to: Launchpad build farm capacity limited | Artful Released + taken down LP#1734147 | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of trusty-artful | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
juliankcjwatson: 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 -111:17
juliankIf anyone else has an idea, the program is http://paste.ubuntu.com/26443755/ - just a simple syscall11:22
juliankbuild log at https://launchpadlibrarian.net/354250672/buildlog_ubuntu-bionic-armhf.strace_4.19-1ubuntu1_BUILDING.txt.gz11:22
juliankIt expects one syscall:  _llseek(-1, -374081421428539665, 0xffba69c8, SEEK_SET) = -1 EBADF (Bad file descriptor)11:22
juliankbut it also gets11:22
juliank+_llseek(3, 944340, [944340], SEEK_SET)  = 011:22
juliank+_llseek(3, 937564, [937564], SEEK_SET)  = 011:22
* juliank thought maybe something is preloaded, some weird libc module thing, or something11:24
cjwatsonWe certainly have no preloads.11:24
cjwatsonIt'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
juliankI don't think so.11:25
juliankBut there'd also have to be code doing the seeks on fd 311:25
cjwatsonThat is not us.11:26
juliankI guess I'll run it in a PPA again but let it log all syscalls11:27
cjwatsonI 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
cjwatsonTo my mind that would be the most likely cause.11:27
juliankshit11:30
juliankI uploaded the PPA test to proposed11:30
juliankOh well, it's guaranteed to fail anyway11:30
juliank(I retyped the dput and forgot to specify the ppa)11:31
juliank+openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libc.so.6", O_RDONLY|O_CLOEXEC) = 311: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) = 51211:38
juliank+_llseek(3, 944340, [944340], SEEK_SET)  = 011:38
juliankugh11:38
juliankit's seeking in the library11:39
juliankSomething to fix and forward upstream, awesome11:40
cpaelzerlyarwood: I took a look at your bug and triaged it further11:49
cpaelzerlyarwood: I'm subscribed for any further discussion on it11:50
lyarwoodcpaelzer: 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:50
rbalintppisati, 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 hw11:51
cpaelzerok, looking forward to look at it then11:51
cpaelzerthanks lyarwood11:51
rbalintcould someone please test it on an armhf/arm64 system? LP: #174377111:52
ubottuLaunchpad bug 1743771 in flash-kernel (Ubuntu) "Please merge flash-kernel (main) 3.90 from Debian unstable (main)" [Undecided,In progress] https://launchpad.net/bugs/174377111:52
ogra_rbalint, and i dont have most of the HW the normal distro supports anymore ...11:52
rbalintogra_: ok, worst case i'll just upload it to proposed in a few days11:53
ogra_i could perhaps test beaglebne black and pi2, but thats it (and i'm sure ppisati will do that anyway)11:54
rbalintogra_: that would be nice, i'm not looking for full regression on supported systems, just a single run on one11:58
juliankcjwatson: got it :)12:05
juliankogra_: did your ac100 break too?12:05
juliank:D12:05
cjwatsonjuliank: great12:06
ogra_haha, no idea, i havent booted it in several years (it is somewhere in a box in the basement)12:06
juliankoh the times spent on that thing.12:06
juliankNow I only have to wait for my about 30 uploads to migrate :)12:10
lyarwoodcpaelzer: 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:41
=== mhcerri_ is now known as mhcerri
cpaelzerlyarwood: never mind, all that helps to clarify is a step in the right direction12:55
cpaelzerjust need to clear my brains cache before looking on it again12:55
cpaelzerlyarwood: thanks for the details13:19
lyarwoodcpaelzer: np13:19
cpaelzerlyarwood: interesting that it really is gone in 3.6 (artful / pike)13:19
cpaelzerlyarwood: I remember we had odd issues with gnutls in zesty, but eventually resolved before release13:20
cpaelzerI wonder if this might be a strange leftover of this13:20
cpaelzercoreycb: ^^ as you are on the bug13:20
coreycbcpaelzer: lyarwood: also worth noting that libvirt in the ocata uca is using gnutls from xenial13:21
coreycbcpaelzer: lyarwood: well, libvirt in pike uca is also using gnutls from xenial13:23
cpaelzeryep13:23
cpaelzercoreycb: there are good repro steps added13:24
cpaelzercoreycb: if you have ddebs for UCA you mgiht consider stepping through it13:24
cpaelzerif it really fails on the suggested code section13:24
cpaelzerlyarwood: was that code snippet found by review or by debugging with gdb?13:25
lyarwoodcpaelzer: review13:25
cpaelzertks13:25
cpaelzercoreycb: so a real debug session might help to verify the theory13:25
cpaelzerI don't see a much bette rstep forward13:25
cpaelzerdo I miss one in this case13:25
cpaelzer?13:25
=== ogasawara_ is now known as ogasawara
=== ogasawara is now known as Guest58359
coreycblyarwood: cpaelzer: i wonder if QEMU_CAPS_OBJECT_SECRET is not available14:02
juliankSomething is wrong with the gsequencer autopkgtest: dpkg-buildpackage fails due to missing fakeroot14:25
juliankhttps://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/g/gsequencer/20180123_132702_56441@/log.gz14:25
juliank(and this test is being triggered by fakeroot)14:25
Laneyjuliank: https://tracker.debian.org/news/89346614:27
juliankah, it did run them again 1.1.4-114:27
juliankall these uploads will be a mess to sort out :)14:28
coreycblyarwood: cpaelzer: ok found a difference between the artful/zesty packages. artful has:  configure:#define HAVE_GNUTLS_CIPHER_ENCRYPT 114:28
cpaelzerinteresting14:31
cpaelzercoreycb: is that in the resulting config.h or where is that?14:31
coreycbcpaelzer: that's just in the package from pull-lp-source14:31
cpaelzercame in with 3.0.0-rc114:35
cpaelzercoreycb: the config structure of the m4 files was changed14:54
cpaelzernot sure this all applies to 2.514:54
cpaelzerha14:55
coreycbcpaelzer: ok. i'm cloning from anonscm but it's taking a bit. think it's not  backportable to 2.5?14:55
cpaelzerI think I found it coreycb14:55
cpaelzerit is backportable semantically14:55
cpaelzerlet me work something out for your to test14:55
coreycbcpaelzer: ok, thanks cpaelzer14:56
juliankCan we turn off the stuck in proposed messages for a fww days?15:10
juliankI did like 30 uploads and of course they're all stuck in proposed15:10
cpaelzercoreycb: lyarwood: updated the bug15:11
juliankMaybe like turn them off until Monday and everything caught up?15:11
cpaelzercoreycb: added to links that should be your fix15:11
cpaelzertried to apply to latest zesty, looks good15:11
lyarwoodcpaelzer: cool thanks! :)15:13
cpaelzerI hope it works as expected15:16
cpaelzerand if it does keep the good feeling for the next openstack-rant-explosion on our libvirt/qemu :-)15:16
seb128leosilva, hey, bug #1744855 claims to be a regression from your security update, could you have a look?16:02
ubottubug 1744855 in transmission (Ubuntu) "Upgrade to 2.84-3ubuntu3.1 breaks remote access (webui)" [Undecided,New] https://launchpad.net/bugs/174485516:02
leosilvaseb128: tks, let me check.16:03
seb128leosilva, thanks16:03
naccslangasek: 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:27
naccbetween 10-15 people a day in #ubuntu (which I'm using a metric) complaining of the 40416:28
rbasakPrecise is presumably not removed either.16:29
nacctrue, but ESM makes that wonky, I assumed :)16:30
naccI'm less fussed about LTS, because there's a bit of a good story there16:30
naccit seemed like non-LTS were not removed promptly in the past, but now they are, and that led to confused/angry users16:30
nacctotally their fault, admittedly, but it seems like something we should improve on16:31
* rbasak wonders if there's anything in the motd possible via distro-info-data.17:13
rbasakThough desktop users may well never see that.17:13
naccrbasak: there's a bug open to improve it, iirc17:14
naccjust trying to push on its priority17:14
nacc:)17:14
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 warnings17:17
sarnoldTJ-: doesn't that already exist?17:20
sarnoldTJ-: .. 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
sarnoldTJ-: oh never mind me. sigh. sorry17:21
TJ-no, there's no EOLdate in meta-release17:22
slangaseknacc: what improvement do you have in mind, wrt non-LTS removals?17:46
naccslangasek: i'm not 100%; is there a policy doc as to when the archives get moved to old-releases?17:46
naccslangasek: that might be sufficient, to have it clearly stated in the release notes17:46
naccslangasek: 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 transition17:47
slangaseknacc: 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
naccslangasek: yeah that is probably true17:48
naccslangasek: 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 future17:48
naccor if it become part of the EOL process, maybe?17:49
slangaseknacc: policy doc> there's https://wiki.ubuntu.com/EndOfLifeProcess , which has always said that we remove it from archive.u.c at EOL17:50
naccslangasek: ah that's what i was looking for!17:50
naccslangasek: 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
nacchttps://wiki.ubuntu.com/ZestyZapus/ReleaseNotes  Support lifespan section17:51
slangaseknacc: 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 EOL17:55
slangaseknacc: but it's a wiki and I don't mind it being edited to include such a link17:55
naccslangasek: 100% agree, just want to point them to something17:55
jbichamaybe some people assumed they had until the end of January before EOL18:50
sarnoldmaybe they usually waited for a week or two after one release EOLs before upgrading to the next, to let other people debug the transition18:51
jbichaand 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 GNOME18:52
jbichaI 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:53
slangasekaiui 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 release18:58
sarnoldwill do-release-update complain if they missed the last N weeks of updates?18:58
slangasekit shouldn't, considering those updates are no longer available ;)18:58
sarnoldright :)18:59
sarnoldI'm glad it fails on the happier side of that fence18:59
TJ-The guides tell people to alter sources.list and replace the archive.ubuntu with old-releases.ubuntu18:59
TJ-then an apt-get update/dist-upgrade followed by do-release-upgrade19:00
slangasekdo-release-upgrade itself was fixed some time ago to not care about the current release being missing19:01
TJ-hmm, tried in an LXD container and got "Cannot open your terminal '' - please check."19:08
naccTJ-: you porbably need to run ashell with a controlling tty19:09
naccTJ-: in the lxd19:09
jbichaslangasek: see LP: #174472219:10
ubottuLaunchpad bug 1744722 in ubuntu-release-upgrader (Ubuntu) "Unknown bad source brings up during 'zesty' to 'artful' upgrade and It break the process" [High,Triaged] https://launchpad.net/bugs/174472219:10
TJ-nacc: I wrapped it in 'script' which provides pts19:17
naccTJ-: oh ok19:19
naccLaney: can we allow request.cgi again, or is there any ETA on that for autopkgtest?19:32

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