=== ogra is now known as Guest89124 [03:18] rbasak: 8.0.14 might be too old to support new openssl, yeah [03:19] IIRC, we were a bit late with the 1.1.1 support [03:19] I'll see if I can find the patch, and we can see if it applies. The PPA build was 8.0.16, though [07:04] tjaalton: Any luck with upgrading Mesa to >v19.1? [08:59] lag: uploaded, but i messed up with the patches, it seems [09:03] tjaalton: What happened? [09:03] tjaalton: It seems like we are on 19.0.8 still [09:28] failed to build [09:43] tjaalton: Ah [09:43] Will you fix it soon? [09:45] yes [09:48] tjaalton: Great, thanks \o/ [10:00] lag: uploaded [10:00] tjaalton: Can I have a link to the build please? [10:00] lag: https://launchpad.net/ubuntu/+source/mesa/19.1.2-1ubuntu2 [10:02] tjaalton: Thanks dude - fill follow along [10:02] s/fill/will/ [10:28] Skuggen: oh, I see. I didn't realise the PPA was a later version. We could just bump the archive up to the PPA then? [10:43] Yeah, I think that's best === alan_g_ is now known as alan_g [15:55] LocutusOfBorg: virtualbox-dkms dropping support for pre-5.2 kernels is rather painful for upgrades. :/ [15:55] Setting up virtualbox-dkms (6.0.10-dfsg-1) ... [15:55] Loading new virtualbox-6.0.10 DKMS files... [15:55] Building for 5.0.0-16-lowlatency 5.2.0-8-lowlatency [15:55] Building initial module for 5.0.0-16-lowlatency [15:55] ERROR (dkms apport): kernel package linux-headers-5.0.0-16-lowlatency is not supported [15:55] LocutusOfBorg: Kills the postinst, and breaks the upgrade. [15:58] Oh, this is the stupid fcf-protection mismatch madness. [15:59] What a colossal pain. [16:08] coreycb: o/ [16:08] coreycb: just realised you weren't subscribed to bug 1829823 [16:08] bug 1829823 in Ubuntu Cloud Archive mitaka "libvirt-bin: during shutdown libvirt-bin is stopped before libvirt-guests causing hang" [High,In progress] https://launchpad.net/bugs/1829823 [16:08] Please could you take a look to see if you're happy with the staging plan and can commit to SRU verification on that basis? [16:12] ahasenack: what's the status of bug 1834072 in Eoan, please? I don't see that information in the bug. [16:12] bug 1834072 in ruby2.3 (Ubuntu) "Puppet agent using 100% CPU, in sched_yield() loop. Looks like an issue with ruby2.3 which has been fixed but not yet made it into Ubuntu." [High,In progress] https://launchpad.net/bugs/1834072 [16:12] sforshee: The fcf-protection versus dkms modules thing might need more thought than it's been given. [16:12] rbasak: thanks for doing that. i just added my +1 to the bug. as for verification I think matthew will be doing it but if not then yes I can. [16:13] coreycb: great, thanks! I'll review the actual upload next. [16:13] sforshee: On upgrade from bionic or disco, if gcc is updated, then a dkms module, dkms will attempt to rebuild for the running kernel, and explode the upgrade. Which seems not entirely ideal. [16:13] sforshee: I have no good ideas right now (unless there's a way to have dkms itself inject some -fno-evil CCFLAGs into every build), just thought I'd toss that out there. [16:14] sforshee: My laptop's recent eoan->eoan upgrade went through that exact problem. GCC upgrade, virtualbox-dkms upgraded, postinst explodes, dpkg terminate, grandma cries. [16:14] infinity is a grandma? [16:15] rbasak: Grandma is my hypothetical NTEU who would have given up at the point where dpkg told her angry things. [16:15] infinity: but given it's _your_ laptop having the problem that led to grandma crying, the only logical conclusion is that you're a grandma :-P [16:16] I might be. [16:16] Would you like some pie, dearie? [16:17] I'm a tauist myself [16:17] But thanks [16:19] infinity: ok, I'll look at what we can do with dkms [16:19] I don't care if you're just visiting! [16:23] In retrospect, someone really should have given GCC a '-kernel' command line option that just automatically disabled anything clearly meant for userspace. [16:23] Then this sort of thing wouldn't keep happening. [16:25] at minimum we can sru the cflags change to bionic and disco [16:25] if we can't figure out something better [16:30] sforshee: Yeah, that'll mitigate the issue so it's only people doing eoan->eoan upgrades or people upgrading bionic and disco from older kernels. [16:30] Assuming GCC will ignore -fno-feature for a feature it doesn't have. [16:32] infinity: it doesn't, but we check whehter or not the compiler supports it [16:34] sforshee: Ahh, kay. [16:34] And indeed it doesn't. [16:34] $ gcc -fno-unknown-feature-foo -o hello hello.c [16:34] gcc: error: unrecognized command line option ‘-fno-unknown-feature-foo’ [16:34] Seems also like poor design, but whatevs. [16:45] rbasak: wrt #1834072, comments #19 and #20? Is it not in the unapproved queue? [16:46] rbasak: Trying to work out if you will have religious objections to http://www.cadaeic.net/cadenza.htm in that case [16:46] (follow link at the top if you're confused) [16:47] rbasak: ah, eoan, sorry [16:48] cjwatson: no religious objections, but it seems rather arbitrary to base a word game on _half_ the circle constant :-P [16:48] heh [16:49] ahasenack: yeah. Sorry, I just realised that there is a Debian BTS link. Perhaps I could have figured it out from that. [16:49] I do prefer not having to detective work when SRU processing though please :) [16:51] hmm [16:51] sure [16:51] and you may be on to something [16:51] * ahasenack recovers memory from cold storage [16:57] no, I just had a small confusion due to the fact ruby2.3 is not available elsewhere [16:58] rbasak: >= bionic has the fix, let me clarify that in the bug [16:58] [Other Info] [16:58] Bionic has ruby 2.5.1 and it has this fix already, as do all later ubuntu releaes. [16:59] rbasak: ^ [16:59] Thanks! [17:09] rbalint, kenvandine: BTW, you both have an ubuntu-meta in the Xenial SRU queue that conflict. Sorry I didn't get time to look at those today, but you may want to resolve that between yourselves. [17:09] (for the next reviewer who does) [17:10] infinity, shouldn't the kernel be fixed to avoid such flag? [17:10] it should already have that fix [17:26] can anybody please explain this? [17:26] trying: cairocffi [17:26] skipped: cairocffi (50, 0, 37) [17:26] got: 44+0: a-8:a-8:a-8:i-7:p-6:s-7 [17:26] * s390x: printrun [17:26] I can't figure it out [17:31] it claims a bunch of packages (8, 7 and 6, depending on arch) will be removed if cairocffi is to be installed, that's as far as I got [17:31] s390x is just the first it lists in more detail [17:31] but amd64 is in there too [17:31] does it only list printrun? [17:31] or did you truncate the output [17:31] before pasting her [17:32] update_output always truncates and only lists the uninstallables for the "first" arch it processes [17:32] and the uninstallable count tells you the total uninstallable account; if the baseline is non-zero, you have to check which of those numbers have increased [17:33] (baseline from top of the run is: a-8:a-8:a-8:i-7:p-6:s-6) [17:34] so it's an s390x-specific uninstallability, possibly a result of cairocffi, being an arch: all package (and therefore excluded itself from the uninstallable calculation) picking up a new dependency on an arch-dep package which is unavailable on s390x [17:38] vorlon, do you have any idea without an s390x machine to find which one? [17:41] damn, is it python3-xcffib ? [17:41] :/ [18:47] LocutusOfBorg: I haven't looked, but it should be straightforward to look at the dependencies of printrun, figure out which ones are Arch: any, [18:47] LocutusOfBorg: eh- look at the dependencies of *cairocffi*, figure out which ones are arch: any, and see which ones are not built on s390x [18:48] and in particular, look at the changes to the deps of the cairocffi packages between eoan and eoan-proposed [20:32] I'm having some trouble generating source package files with a simple 1 line change I'm trying to make to a package. I made a new patch with "quilt new name-of-patch.patch" then staged chances for it with "quilt edit path-to-file", ran "quilt refresh" to make sure the contents of the patch were updated. When I go to run "debuild -S -d", it insists the patch is in reverse format and stops. When I apply the patch manually with "qui [20:32] push" or "patch" there's no issue, just when using "debuild". Here's the error: https://paste.ubuntu.com/p/KdtJ4FyWJw/ and here's the patch: https://paste.ubuntu.com/p/DtDKXGwvH3/ -- have I missed something terribly obvious? [20:37] connor_k: wild guessing, quilt push -a or quilt pop -a before trying the build [20:38] sarnold, same result with both of those, I'm afraid :( [20:45] connor_k: so you are trying to change a file under debian, is that correct? [20:45] santa_, yes that is right [20:46] under the debian/ directory [20:46] yes [20:46] well, that can't be done I'm afraid [20:47] the thing with quilt patches in the debian packaging is meant to alter the upstream source code in non-native packages (i.e. files outside the debian/ dir) [20:48] if you whish to change the debian files I think you have to change them directly [20:49] at least, I see no other way [20:50] aha, thank you santa_! [20:50] aha! thanks santa_ :) [20:50] if what you want to do is a custom package for yourself and keep track of you changes you can always use git ;) [20:50] you're welcome :) [20:50] It would be desperately confusing to patch files in debian/ using debian/patches/*, so indeed you shouldn't do that [20:51] Even if it worked :-) [20:51] LocutusOfBorg: so I have no idea why python-xcffib is not built on s390x but python3-xcffib is, but anyway I guess you fix this by moving printrun to python3 [20:51] most everything i do is desperately confusing, but it gets a little bit better every day :) [20:52] :) [21:57] thanks vorlon I think I already fixed the problem, unfortunately xcffib is used in testsuite so I hope I fixed xcffib too [21:58] anyway, does anybody know why this package fails to build? https://launchpad.net/ubuntu/+source/ncurses/6.1+20190713-1ubuntu2/+build/17300776 [21:58] it doesn't fail to install on local pbuilder or debomatic sbuild machine... [21:58] looks like some ppa related stuff... [22:16] retrying worked... meh