| === ogra is now known as Guest89124 | ||
| Skuggen | rbasak: 8.0.14 might be too old to support new openssl, yeah | 03:18 |
|---|---|---|
| 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 | 03:19 |
| lag | tjaalton: Any luck with upgrading Mesa to >v19.1? | 07:04 |
| tjaalton | lag: uploaded, but i messed up with the patches, it seems | 08:59 |
| lag | tjaalton: What happened? | 09:03 |
| lag | tjaalton: It seems like we are on 19.0.8 still | 09:03 |
| tjaalton | failed to build | 09:28 |
| lag | tjaalton: Ah | 09:43 |
| lag | Will you fix it soon? | 09:43 |
| tjaalton | yes | 09:45 |
| lag | tjaalton: Great, thanks \o/ | 09:48 |
| 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:00 |
| lag | tjaalton: Thanks dude - fill follow along | 10:02 |
| lag | s/fill/will/ | 10:02 |
| 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:28 |
| Skuggen | Yeah, I think that's best | 10:43 |
| === alan_g_ is now known as alan_g | ||
| 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:55 |
| infinity | Oh, this is the stupid fcf-protection mismatch madness. | 15:58 |
| infinity | What a colossal pain. | 15:59 |
| rbasak | coreycb: o/ | 16:08 |
| rbasak | coreycb: just realised you weren't subscribed to bug 1829823 | 16:08 |
| ubottu | 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 |
| 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:08 |
| rbasak | ahasenack: what's the status of bug 1834072 in Eoan, please? I don't see that information in the bug. | 16:12 |
| ubottu | 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 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| infinity | I might be. | 16:16 |
| infinity | Would you like some pie, dearie? | 16:16 |
| rbasak | I'm a tauist myself | 16:17 |
| rbasak | But thanks | 16:17 |
| 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:19 |
| 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:23 |
| 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:25 |
| 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:30 |
| sforshee | infinity: it doesn't, but we check whehter or not the compiler supports it | 16:32 |
| 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:34 |
| ahasenack | rbasak: wrt #1834072, comments #19 and #20? Is it not in the unapproved queue? | 16:45 |
| 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:46 |
| ahasenack | rbasak: ah, eoan, sorry | 16:47 |
| 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:48 |
| 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:49 |
| 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:51 | |
| ahasenack | no, I just had a small confusion due to the fact ruby2.3 is not available elsewhere | 16:57 |
| 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:58 |
| ahasenack | rbasak: ^ | 16:59 |
| rbasak | Thanks! | 16:59 |
| 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:09 |
| LocutusOfBorg | infinity, shouldn't the kernel be fixed to avoid such flag? | 17:10 |
| LocutusOfBorg | it should already have that fix | 17:10 |
| 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:26 |
| 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:31 |
| 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:32 |
| vorlon | (baseline from top of the run is: a-8:a-8:a-8:i-7:p-6:s-6) | 17:33 |
| 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:34 |
| LocutusOfBorg | vorlon, do you have any idea without an s390x machine to find which one? | 17:38 |
| LocutusOfBorg | damn, is it python3-xcffib ? | 17:41 |
| LocutusOfBorg | :/ | 17:41 |
| 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:47 |
| vorlon | and in particular, look at the changes to the deps of the cairocffi packages between eoan and eoan-proposed | 18:48 |
| 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:32 |
| sarnold | connor_k: wild guessing, quilt push -a or quilt pop -a before trying the build | 20:37 |
| connor_k | sarnold, same result with both of those, I'm afraid :( | 20:38 |
| 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:45 |
| santa_ | under the debian/ directory | 20:46 |
| connor_k | yes | 20:46 |
| santa_ | well, that can't be done I'm afraid | 20:46 |
| 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:47 |
| santa_ | if you whish to change the debian files I think you have to change them directly | 20:48 |
| santa_ | at least, I see no other way | 20:49 |
| 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:50 |
| 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:51 |
| sarnold | :) | 20:52 |
| LocutusOfBorg | thanks vorlon I think I already fixed the problem, unfortunately xcffib is used in testsuite so I hope I fixed xcffib too | 21:57 |
| 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... | 21:58 |
| LocutusOfBorg | retrying worked... meh | 22:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!