=== doko_ is now known as doko | ||
=== cpaelzer_ is now known as cpaelzer | ||
ginggs | where can i see launchpad's i386 whitelist? | 10:08 |
---|---|---|
laney | ginggs: https://people.canonical.com/~ubuntu-archive/packagesets/impish/i386-whitelist | 10:11 |
ginggs | laney: thanks! | 10:12 |
schopin | doko: so, I have this package which FTBFS against gcc11 (libuv1) because the tests fail (libuv1). I finally tracked it down to LTO, as the failing test passes when I remove those flags. | 12:52 |
schopin | 3 questions : 1/ how hard/long would it be to bisect this regression in GCC11? | 12:52 |
schopin | 2/ would removing the LTO flags in the package break stuff? | 12:53 |
schopin | 3/ Should I report this to GCC upstream? | 12:53 |
ginggs | schopin: maybe this is relevant https://github.com/libuv/libuv/issues/1230 | 12:58 |
ubottu | Issue 1230 in libuv/libuv "The way libuv does inheritance violates strict aliasing" [Closed] | 12:58 |
ginggs | there's a recommendation to built libuv 1.x with -fno-strict-aliasing | 12:58 |
ginggs | which it doesn't look like we currently do | 12:59 |
schopin | I'll try | 13:03 |
ginggs | there are a couple of netplan.io and pyside2 autopkgtests currently running that seem to run for hours and then restart. can they be put out of their misery? | 13:04 |
schopin | ginggs: indeed, that takes care of my second question :). But is it considered a regression in GCC or not? | 13:21 |
ginggs | schopin: did it build with lto in gcc10, ands now fails in gcc11? | 13:29 |
schopin | Yes. | 13:33 |
=== genii-away is now known as genii | ||
xnox | schopin: lots of packages disable lto by exporting deb_maint_flags things in debian/rules. | 14:48 |
xnox | export DEB_BUILD_MAINT_OPTIONS = optimize=-lto | 14:49 |
xnox | https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/rules?h=ubuntu#n13 | 14:51 |
xnox | schopin: it is possible that lto is too agresive, and things rely on it not happening. | 14:51 |
schopin | yeah, I think that's what is happening here. But in this case it seems -fno-strict-aliasing should be set regardless of LTO, I think LTO just surfaced a related bug. | 14:52 |
doko | schopin, please file a bug report about it too. is that a new ftbfs? I don't see it in the hirsute test rebuild | 15:53 |
schopin | doko: new ftbfs from your GCC 11 rebuild. | 15:54 |
schopin | So, I'll file a report upstream then? | 15:54 |
doko | schopin, LP first. need to reduce the test case as well ... | 15:56 |
schopin | LP: #1939707 | 15:57 |
ubottu | Launchpad bug 1939707 in libuv1 (Ubuntu) "FTBFS on impish" [Undecided, In Progress] https://launchpad.net/bugs/1939707 | 15:57 |
bdmurray | xypron: I'm confused about bug 1939409 it looks like slyon uploaded some of the patches but your PPA has another patch? | 15:58 |
ubottu | Bug 1939409 in e2fsprogs (Ubuntu Impish) "e2fsprogs 1.46.3-1 on architecture s390x fails in test f_baddotdir" [Medium, In Progress] https://launchpad.net/bugs/1939409 | 15:58 |
xypron | bdmurray: the one I have in my PPA passes the autopkgtest locally. | 16:00 |
xypron | bdmurray: but it is based on what I did prevously. not being aware of slyon | 16:00 |
bdmurray | xypron: he sponsored your work - https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1939409/comments/7 | 16:01 |
ubottu | Launchpad bug 1939409 in e2fsprogs (Ubuntu Impish) "e2fsprogs 1.46.3-1 on architecture s390x fails in test f_baddotdir" [Medium, In Progress] | 16:01 |
doko | schopin, https://src.fedoraproject.org/rpms/libuv/blob/rawhide/f/libuv.spec so Fedora doesn't disable lto. could you check if the new libuv upstream fixes things? seems to be 1.42.0 | 16:07 |
schopin | FTR, the fix isn't to disable LTO but to pass -fno-strict-aliasing | 16:14 |
dbungert | bdmurray: next steps on vip-manager. I have wondered if the test environment doesn't match what the test steps expect. How do I get more details on the test environment? | 16:18 |
bdmurray | dbungert: do you have a log from your successful test? | 16:19 |
schopin | doko: new upstream fixes things, indeed... By adding that exact flag to their build system :D | 16:23 |
dbungert | bdmurray: https://paste.ubuntu.com/p/XrVBWtgCxm/ | 16:25 |
bdmurray | dbungert: I'm trying to have a look myself | 16:47 |
doko | schopin, "It is recommended to turn on the `-fno-strict-aliasing` compiler flag in projects that use libuv." good luck with that ... | 16:48 |
doko | so you don't need to turn off lto then? | 16:48 |
dbungert | bdmurray: the test in question tries to use a pipe sequence to choose a non-lo interface. I suspect it's doing so incorrectly in the test environment. If you can, I'm curious what the 'ip link show' output looks like. | 16:49 |
bdmurray | dbungert: you could upload a new version of vip-manager to your PPA for debugging and then we could run autopkgtests on that | 16:52 |
bdmurray | https://wiki.ubuntu.com/ProposedMigration#Testing_against_a_PPA | 16:53 |
dbungert | bdmurray: great, I will prepare that and report back | 16:56 |
schopin | doko: no, I just need to add the aliasing flag and voilĂ . | 16:56 |
=== lucas__ is now known as lucascastro | ||
sergiodj | anyone else having trouble pull-lp-source'ing a package? | 18:25 |
sergiodj | I'm getting proxy errors | 18:25 |
bdmurray | It was luggish for me for a bit there yes | 18:28 |
sergiodj | huh, it's been like this for at least 30 min for me | 18:28 |
bdmurray | okay, its still bad for me | 18:33 |
ddstreet | it looks like launchpadlibrarian.net is totally down, i get 503's now | 18:47 |
bdmurray | I believe IS is aware and working on it | 18:52 |
jawn-smith | Interesting, Go on ppc64el seems to be experiencing segmentation faults while compiling code | 19:32 |
dbungert | jawn-smith: I saw that as well - LP: #1941791 | 19:39 |
ubottu | Launchpad bug 1941791 in alertmanager-irc-relay (Ubuntu) "FTBFS on ppc64el with go 1.16" [Undecided, New] https://launchpad.net/bugs/1941791 | 19:39 |
jawn-smith | dbungert: thanks! I've noticed on a few packages as well, and was trying to see if 1.17 fixed it | 19:42 |
jawn-smith | However, it seems to not reproduce consistently. I can run go build twice and only one of them will segfault | 19:42 |
jawn-smith | which I see you've noted in this bug | 19:43 |
dbungert | jawn-smith: with that package it was a pretty consistent build crash for me, maybe try that package if you're interested in the general crash on 1.16 | 19:47 |
jawn-smith | building now | 19:55 |
jawn-smith | odd, I can't get that one to crash | 19:57 |
dbungert | cool | 19:58 |
dbungert | I ended up running it locally in qemu - you doing the same? | 19:58 |
jawn-smith | I'm in a canonistack instance | 19:58 |
dbungert | jawn-smith: https://paste.ubuntu.com/p/PK4wv79QWJ/ - fix up imagedir and PUB_KEY and that might help | 20:02 |
jawn-smith | ooh excellent, thanks! | 20:03 |
mwhudson | good mornig | 20:31 |
mwhudson | is everyone ready to have the autopkgtest queues jammed by glibc for a couple of days? | 20:31 |
sarnold | oh boy oh boy oh boy | 20:33 |
bdmurray | mwhudson: doko was suggesting that we not test everything | 20:33 |
mwhudson | bdmurray: i think that probably makes sense, the only changes are in glibc's testsuite and the postinst | 20:34 |
mwhudson | so we should test a range of things to avoid toolchain-related shenannigans but testing everything is probably overkill | 20:35 |
bdmurray | That sounds reasonable to me | 20:35 |
mwhudson | also i don't know _how_ to not test everything | 20:35 |
bdmurray | do it in a PPA and manually run tests with that glibc? | 20:36 |
bdmurray | I've also been led to believe vorlon might now how to modify the test infrastructure so not every test will run | 20:37 |
mwhudson | debdiff if anyone wants a look https://paste.ubuntu.com/p/tHCp5BPrnP/ | 20:51 |
bdmurray | line 34 looks like it has extra whitespace | 20:51 |
mwhudson | between the > and the /dev/null? | 20:52 |
bdmurray | and or the 2> /dev/null | 20:53 |
mwhudson | i don't think that's meaningful but the other uses in the file don't have the space so i'll make it consistent | 20:54 |
bdmurray | This patch is upstream and we'll get it later? | 20:56 |
mwhudson | yeah | 21:03 |
bdmurray | line 57 says patch 1 of 2 | 21:03 |
bdmurray | Is patch 2 not important? | 21:03 |
mwhudson | patch 2 of 2 is also in the patch | 21:03 |
mwhudson | i just stuck the two diffs together | 21:04 |
bdmurray | ah okay! | 21:04 |
mwhudson | not sure what the best way to handle a patch series in debian/patches is, i guess i could have both | 21:04 |
mwhudson | i think what ddstreet does for systemd is to have thm split out in directories like debian/patches/lp$bug/ | 21:05 |
bdmurray | there was also some mention this morning of balint testing glibc in bileto | 21:12 |
mwhudson | i should do that with 2.35 snapshots next cycle | 21:14 |
jawn-smith | mwhudson had you mentioned in the past that we would have golang-defaults point to 1.17 in impish? | 21:18 |
mwhudson | jawn-smith: i don't think i'd made any commitments either way on that one | 21:18 |
mwhudson | i guess it's getting a bit late now :/ | 21:18 |
jawn-smith | okay. We're seeing some segmentation faults while compiling go packages on ppc64el | 21:18 |
mwhudson | otoh i don't think it makes many more packages ftbfs than fail already | 21:19 |
mwhudson | (go 1.16 broke a bunch) | 21:19 |
jawn-smith | They don't seem to be repeatable with 1.17, but it's hard to be sure as the crashes aren't consistent | 21:19 |
mwhudson | jawn-smith: and 1.17 helps with those? | 21:19 |
mwhudson | hmm | 21:19 |
jawn-smith | I'll look into it more with 1.17 so I can be more sure | 21:20 |
dbungert | bdmurray: does this URL look right? https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=armhf&package=vip-manager&ppa=dbungert/vip-manager-armhf&trigger=vip-manager/1.0.1-4ppa2 | 21:20 |
bdmurray | dbungert: good enough that I clicked on it! ;-) "Test request submitted." | 21:21 |
bdmurray | https://autopkgtest.ubuntu.com/running#pkg-vip-manager | 21:22 |
mwhudson | uploading glibc .. | 21:27 |
bdmurray | where to? | 21:29 |
dbungert | bdmurray: looks like results should be at https://autopkgtest.ubuntu.com/results/autopkgtest-impish-dbungert-vip-manager-armhf/?format=plain but I don't seem to have permissions for that, are you able to see that link? | 21:33 |
bdmurray | really you can't see it? | 21:38 |
dbungert | unauthorized error | 21:38 |
bdmurray | https://autopkgtest.ubuntu.com/results/autopkgtest-impish-dbungert-vip-manager-armhf/impish/armhf/v/vip-manager/20210902_213803_6f51c@/log.gz | 21:40 |
bdmurray | autopkgtest [21:37:47]: @@@@@@@@@@@@@@@@@@@@ apt-source vip-manager | 21:43 |
bdmurray | autopkgtest [21:37:52]: ERROR: erroneous package: rules extract failed with exit code 1 | 21:43 |
bdmurray | looking at your PPA its still pending publication so that could be the issue | 21:43 |
bdmurray | anyway good url - will click again ;-) | 21:44 |
dbungert | ok good, I wasn't sure what to do what that error :) | 21:44 |
bdmurray | could you see the log file? | 21:44 |
dbungert | yes, thank you | 21:45 |
dbungert | just locked out of the results page | 21:45 |
bdmurray | weird | 21:45 |
bdmurray | dbungert: https://autopkgtest.ubuntu.com/results/autopkgtest-impish-dbungert-vip-manager-armhf/impish/armhf/v/vip-manager/20210902_215832_46f25@/log.gz | 22:01 |
dbungert | bdmurray: awesome, that was the info I needed, thanks | 22:02 |
mwhudson | bdmurray: archive | 22:47 |
bdmurray | mwhudson: won't that kick off all the tests though? | 22:49 |
mwhudson | bdmurray: yes, i guess so, i thought that the test requests could be removed after the fact though | 22:49 |
bdmurray | yeah IDK how that works | 22:50 |
mwhudson | bdmurray: i guess it would be possible to avoid that by copying from a bileto ppa straight to the release pocket but that doesn't really seem like a good idea | 22:50 |
mwhudson | copying from a bileto ppa to proposed would have the same effect of triggering all the tests i think | 22:50 |
bdmurray | unless you need to do something to skip the tests in advance | 22:51 |
bdmurray | but the order of operations wasn't clear to me | 22:51 |
mwhudson | me neither | 22:51 |
mwhudson | anyway done now | 22:52 |
mwhudson | for better or worse | 22:52 |
mwhudson | steve or julian or iain might be able to do something tomorrow | 22:52 |
=== genii is now known as genii-core |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!