[03:18] <Skuggen> rbasak: 8.0.14 might be too old to support new openssl, yeah
[03:19] <Skuggen> IIRC, we were a bit late with the 1.1.1 support
[03:19] <Skuggen> 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] <lag> tjaalton: Any luck with upgrading Mesa to >v19.1?
[08:59] <tjaalton> lag: uploaded, but i messed up with the patches, it seems
[09:03] <lag> tjaalton: What happened?
[09:03] <lag> tjaalton: It seems like we are on 19.0.8 still
[09:28] <tjaalton> failed to build
[09:43] <lag> tjaalton: Ah
[09:43] <lag> Will you fix it soon?
[09:45] <tjaalton> yes
[09:48] <lag> tjaalton: Great, thanks \o/
[10:00] <tjaalton> lag: uploaded
[10:00] <lag> tjaalton: Can I have a link to the build please?
[10:00] <tjaalton> lag: https://launchpad.net/ubuntu/+source/mesa/19.1.2-1ubuntu2
[10:02] <lag> tjaalton: Thanks dude - fill follow along
[10:02] <lag> s/fill/will/
[10:28] <rbasak> 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] <Skuggen> Yeah, I think that's best
[15:55] <infinity> LocutusOfBorg: virtualbox-dkms dropping support for pre-5.2 kernels is rather painful for upgrades. :/
[15:55] <infinity> Setting up virtualbox-dkms (6.0.10-dfsg-1) ...
[15:55] <infinity> Loading new virtualbox-6.0.10 DKMS files...
[15:55] <infinity> Building for 5.0.0-16-lowlatency 5.2.0-8-lowlatency
[15:55] <infinity> Building initial module for 5.0.0-16-lowlatency
[15:55] <infinity> ERROR (dkms apport): kernel package linux-headers-5.0.0-16-lowlatency is not supported
[15:55] <infinity> LocutusOfBorg: Kills the postinst, and breaks the upgrade.
[15:58] <infinity> Oh, this is the stupid fcf-protection mismatch madness.
[15:59] <infinity> What a colossal pain.
[16:08] <rbasak> coreycb: o/
[16:08] <rbasak> coreycb: just realised you weren't subscribed to bug 1829823
[16:08] <rbasak> 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] <rbasak> ahasenack: what's the status of bug 1834072 in Eoan, please? I don't see that information in the bug.
[16:12] <infinity> sforshee: The fcf-protection versus dkms modules thing might need more thought than it's been given.
[16:12] <coreycb> 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] <rbasak> coreycb: great, thanks! I'll review the actual upload next.
[16:13] <infinity> 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] <infinity> 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] <infinity> 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] <rbasak> infinity is a grandma?
[16:15] <infinity> rbasak: Grandma is my hypothetical NTEU who would have given up at the point where dpkg told her angry things.
[16:15] <rbasak> 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] <infinity> I might be.
[16:16] <infinity> Would you like some pie, dearie?
[16:17] <rbasak> I'm a tauist myself
[16:17] <rbasak> But thanks
[16:19] <sforshee> infinity: ok, I'll look at what we can do with dkms
[16:19] <infinity> I don't care if you're just visiting!
[16:23] <infinity> In retrospect, someone really should have given GCC a '-kernel' command line option that just automatically disabled anything clearly meant for userspace.
[16:23] <infinity> Then this sort of thing wouldn't keep happening.
[16:25] <sforshee> at minimum we can sru the cflags change to bionic and disco
[16:25] <sforshee> if we can't figure out something better
[16:30] <infinity> 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] <infinity> Assuming GCC will ignore -fno-feature for a feature it doesn't have.
[16:32] <sforshee> infinity: it doesn't, but we check whehter or not the compiler supports it
[16:34] <infinity> sforshee: Ahh, kay.
[16:34] <infinity> And indeed it doesn't.
[16:34] <infinity> $ gcc -fno-unknown-feature-foo -o hello hello.c
[16:34] <infinity> gcc: error: unrecognized command line option ‘-fno-unknown-feature-foo’
[16:34] <infinity> Seems also like poor design, but whatevs.
[16:45] <ahasenack> rbasak: wrt #1834072, comments #19 and #20? Is it not in the unapproved queue?
[16:46] <cjwatson> rbasak: Trying to work out if you will have religious objections to http://www.cadaeic.net/cadenza.htm in that case
[16:46] <cjwatson> (follow link at the top if you're confused)
[16:47] <ahasenack> rbasak: ah, eoan, sorry
[16:48] <rbasak> cjwatson: no religious objections, but it seems rather arbitrary to base a word game on _half_ the circle constant :-P
[16:48] <cjwatson> heh
[16:49] <rbasak> ahasenack: yeah. Sorry, I just realised that there is a Debian BTS link. Perhaps I could have figured it out from that.
[16:49] <rbasak> I do prefer not having to detective work when SRU processing though please :)
[16:51] <ahasenack> hmm
[16:51] <ahasenack> sure
[16:51] <ahasenack> and you may be on to something
[16:51]  * ahasenack recovers memory from cold storage
[16:57] <ahasenack> no, I just had a small confusion due to the fact ruby2.3 is not available elsewhere
[16:58] <ahasenack> rbasak: >= bionic has the fix, let me clarify that in the bug
[16:58] <ahasenack> [Other Info]
[16:58] <ahasenack> Bionic has ruby 2.5.1 and it has this fix already, as do all later ubuntu releaes.
[16:59] <ahasenack> rbasak: ^
[16:59] <rbasak> Thanks!
[17:09] <rbasak> 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] <rbasak> (for the next reviewer who does)
[17:10] <LocutusOfBorg> infinity, shouldn't the kernel be fixed to avoid such flag?
[17:10] <LocutusOfBorg> it should already have that fix
[17:26] <LocutusOfBorg> can anybody please explain this?
[17:26] <LocutusOfBorg> trying: cairocffi
[17:26] <LocutusOfBorg> skipped: cairocffi (50, 0, 37)
[17:26] <LocutusOfBorg>     got: 44+0: a-8:a-8:a-8:i-7:p-6:s-7
[17:26] <LocutusOfBorg>     * s390x: printrun
[17:26] <LocutusOfBorg> I can't figure it out
[17:31] <ahasenack> 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] <ahasenack> s390x is just the first it lists in more detail
[17:31] <ahasenack> but amd64 is in there too
[17:31] <ahasenack> does it only list printrun?
[17:31] <ahasenack> or did you truncate the output
[17:31] <ahasenack> before pasting her
[17:32] <vorlon> update_output always truncates and only lists the uninstallables for the "first" arch it processes
[17:32] <vorlon> 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] <vorlon> (baseline from top of the run is: a-8:a-8:a-8:i-7:p-6:s-6)
[17:34] <vorlon> 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] <LocutusOfBorg> vorlon, do you have any idea without an s390x machine to find which one?
[17:41] <LocutusOfBorg> damn, is it python3-xcffib ?
[17:41] <LocutusOfBorg> :/
[18:47] <vorlon> 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] <vorlon> 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] <vorlon> and in particular, look at the changes to the deps of the cairocffi packages between eoan and eoan-proposed
[20:32] <connor_k> 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] <connor_k>  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] <sarnold> connor_k: wild guessing, quilt push -a or quilt pop -a before trying the build
[20:38] <connor_k> sarnold, same result with both of those, I'm afraid :(
[20:45] <santa_> connor_k: so you are trying to change a file under debian, is that correct?
[20:45] <connor_k> santa_, yes that is right
[20:46] <santa_> under the debian/ directory
[20:46] <connor_k> yes
[20:46] <santa_> well, that can't be done I'm afraid
[20:47] <santa_> 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] <santa_> if you whish to change the debian files I think you have to change them directly
[20:49] <santa_> at least, I see no other way
[20:50] <connor_k> aha, thank you santa_!
[20:50] <sarnold> aha! thanks santa_ :)
[20:50] <santa_> 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] <santa_> you're welcome :)
[20:50] <cjwatson> It would be desperately confusing to patch files in debian/ using debian/patches/*, so indeed you shouldn't do that
[20:51] <cjwatson> Even if it worked :-)
[20:51] <vorlon> 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] <connor_k> most everything i do is desperately confusing, but it gets a little bit better every day :)
[20:52] <sarnold> :)
[21:57] <LocutusOfBorg> thanks vorlon I think I already fixed the problem, unfortunately xcffib is used in testsuite so I hope I fixed xcffib too
[21:58] <LocutusOfBorg> anyway, does anybody know why this package fails to build? https://launchpad.net/ubuntu/+source/ncurses/6.1+20190713-1ubuntu2/+build/17300776
[21:58] <LocutusOfBorg> it doesn't fail to install on local pbuilder or debomatic sbuild machine...
[21:58] <LocutusOfBorg> looks like some ppa related stuff...
[22:16] <LocutusOfBorg> retrying worked... meh