/srv/irclogs.ubuntu.com/2021/09/02/#ubuntu-devel.txt

=== doko_ is now known as doko
=== cpaelzer_ is now known as cpaelzer
ginggswhere can i see launchpad's i386 whitelist?10:08
laneyginggs: https://people.canonical.com/~ubuntu-archive/packagesets/impish/i386-whitelist10:11
ginggslaney: thanks!10:12
schopindoko: 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
schopin3 questions : 1/ how hard/long would it be to bisect this regression in GCC11?12:52
schopin2/ would removing the LTO flags in the package break stuff?12:53
schopin3/ Should I report this to GCC upstream?12:53
ginggsschopin: maybe this is relevant https://github.com/libuv/libuv/issues/123012:58
ubottuIssue 1230 in libuv/libuv "The way libuv does inheritance violates strict aliasing" [Closed]12:58
ginggsthere's a recommendation to built libuv 1.x with -fno-strict-aliasing12:58
ginggswhich it doesn't look like we currently do12:59
schopinI'll try13:03
ginggsthere 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
schopinginggs: indeed, that takes care of my second question :). But is it considered a regression in GCC or not?13:21
ginggsschopin: did it build with lto in gcc10, ands now fails in gcc11?13:29
schopinYes.13:33
=== genii-away is now known as genii
xnoxschopin:  lots of packages disable lto by exporting deb_maint_flags things in debian/rules.14:48
xnoxexport DEB_BUILD_MAINT_OPTIONS = optimize=-lto14:49
xnoxhttps://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/rules?h=ubuntu#n1314:51
xnoxschopin:  it is possible that lto is too agresive, and things rely on it not happening.14:51
schopinyeah, 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
dokoschopin, please file a bug report about it too. is that a new ftbfs? I don't see it in the hirsute test rebuild15:53
schopindoko: new ftbfs from your GCC 11 rebuild.15:54
schopinSo, I'll file a report upstream then?15:54
dokoschopin, LP first. need to reduce the test case as well ...15:56
schopinLP: #193970715:57
ubottuLaunchpad bug 1939707 in libuv1 (Ubuntu) "FTBFS on impish" [Undecided, In Progress] https://launchpad.net/bugs/193970715:57
bdmurrayxypron: I'm confused about bug 1939409 it looks like slyon uploaded some of the patches but your PPA has another patch?15:58
ubottuBug 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/193940915:58
xypronbdmurray: the one I have in my PPA passes the autopkgtest locally.16:00
xypronbdmurray: but it is based on what I did prevously. not being aware of slyon16:00
bdmurrayxypron: he sponsored your work - https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1939409/comments/716:01
ubottuLaunchpad bug 1939409 in e2fsprogs (Ubuntu Impish) "e2fsprogs 1.46.3-1 on architecture s390x fails in test f_baddotdir" [Medium, In Progress]16:01
dokoschopin, 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.016:07
schopinFTR, the fix isn't to disable LTO but to pass -fno-strict-aliasing16:14
dbungertbdmurray: 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
bdmurraydbungert: do you have a log from your successful test?16:19
schopindoko: new upstream fixes things, indeed... By adding that exact flag to their build system :D16:23
dbungertbdmurray: https://paste.ubuntu.com/p/XrVBWtgCxm/16:25
bdmurraydbungert: I'm trying to have a look myself16:47
dokoschopin, "It is recommended to turn on the `-fno-strict-aliasing` compiler flag in projects that use libuv." good luck with that ...16:48
dokoso you don't need to turn off lto then?16:48
dbungertbdmurray: 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
bdmurraydbungert: you could upload a new version of vip-manager to your PPA for debugging and then we could run autopkgtests on that16:52
bdmurrayhttps://wiki.ubuntu.com/ProposedMigration#Testing_against_a_PPA16:53
dbungertbdmurray: great, I will prepare that and report back16:56
schopindoko: no, I just need to add the aliasing flag and voilĂ .16:56
=== lucas__ is now known as lucascastro
sergiodjanyone else having trouble pull-lp-source'ing a package?18:25
sergiodjI'm getting proxy errors18:25
bdmurrayIt was luggish for me for a bit there yes18:28
sergiodjhuh, it's been like this for at least 30 min for me18:28
bdmurrayokay, its still bad for me18:33
ddstreetit looks like launchpadlibrarian.net is totally down, i get 503's now18:47
bdmurrayI believe IS is aware and working on it18:52
jawn-smithInteresting, Go on ppc64el seems to be experiencing segmentation faults while compiling code19:32
dbungertjawn-smith: I saw that as well - LP: #194179119:39
ubottuLaunchpad bug 1941791 in alertmanager-irc-relay (Ubuntu) "FTBFS on ppc64el with go 1.16" [Undecided, New] https://launchpad.net/bugs/194179119:39
jawn-smithdbungert: thanks! I've noticed on a few packages as well, and was trying to see if 1.17 fixed it19:42
jawn-smithHowever, it seems to not reproduce consistently. I can run go build twice and only one of them will segfault19:42
jawn-smithwhich I see you've noted in this bug19:43
dbungertjawn-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.1619:47
jawn-smithbuilding now19:55
jawn-smithodd, I can't get that one to crash19:57
dbungertcool19:58
dbungertI ended up running it locally in qemu - you doing the same?19:58
jawn-smithI'm in a canonistack instance19:58
dbungertjawn-smith: https://paste.ubuntu.com/p/PK4wv79QWJ/ - fix up imagedir and PUB_KEY and that might help20:02
jawn-smithooh excellent, thanks!20:03
mwhudsongood mornig20:31
mwhudsonis everyone ready to have the autopkgtest queues jammed by glibc for a couple of days?20:31
sarnoldoh boy oh boy oh boy20:33
bdmurraymwhudson: doko was suggesting that we not test everything20:33
mwhudsonbdmurray: i think that probably makes sense, the only changes are in glibc's testsuite and the postinst20:34
mwhudsonso we should test a range of things to avoid toolchain-related shenannigans but testing everything is probably overkill20:35
bdmurrayThat sounds reasonable to me20:35
mwhudsonalso i don't know _how_ to not test everything20:35
bdmurraydo it in a PPA and manually run tests with that glibc?20:36
bdmurrayI've also been led to believe vorlon might now how to modify the test infrastructure so not every test will run20:37
mwhudsondebdiff if anyone wants a look https://paste.ubuntu.com/p/tHCp5BPrnP/20:51
bdmurrayline 34 looks like it has extra whitespace20:51
mwhudsonbetween the > and the /dev/null?20:52
bdmurrayand or the 2> /dev/null20:53
mwhudsoni don't think that's meaningful but the other uses in the file don't have the space so i'll make it consistent20:54
bdmurrayThis patch is upstream and we'll get it later?20:56
mwhudsonyeah21:03
bdmurrayline 57 says patch 1 of 221:03
bdmurrayIs patch 2 not important?21:03
mwhudsonpatch 2 of 2 is also in the patch21:03
mwhudsoni just stuck the two diffs together21:04
bdmurrayah okay!21:04
mwhudsonnot sure what the best way to handle a patch series in debian/patches is, i guess i could have both21:04
mwhudsoni think what ddstreet does for systemd is to have thm split out in directories like debian/patches/lp$bug/21:05
bdmurraythere was also some mention this morning of balint testing glibc in bileto21:12
mwhudsoni should do that with 2.35 snapshots next cycle21:14
jawn-smithmwhudson had you mentioned in the past that we would have golang-defaults point to 1.17 in impish?21:18
mwhudsonjawn-smith: i don't think i'd made any commitments either way on that one21:18
mwhudsoni guess it's getting a bit late now :/21:18
jawn-smithokay. We're seeing some segmentation faults while compiling go packages on ppc64el21:18
mwhudsonotoh i don't think it makes many more packages ftbfs than fail already21:19
mwhudson(go 1.16 broke a bunch)21:19
jawn-smithThey don't seem to be repeatable with 1.17, but it's hard to be sure as the crashes aren't consistent21:19
mwhudsonjawn-smith: and 1.17 helps with those?21:19
mwhudsonhmm21:19
jawn-smithI'll look into it more with 1.17 so I can be more sure21:20
dbungertbdmurray: 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-4ppa221:20
bdmurraydbungert: good enough that I clicked on it! ;-) "Test request submitted."21:21
bdmurrayhttps://autopkgtest.ubuntu.com/running#pkg-vip-manager21:22
mwhudsonuploading glibc ..21:27
bdmurraywhere to?21:29
dbungertbdmurray: 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
bdmurrayreally you can't see it?21:38
dbungertunauthorized error21:38
bdmurrayhttps://autopkgtest.ubuntu.com/results/autopkgtest-impish-dbungert-vip-manager-armhf/impish/armhf/v/vip-manager/20210902_213803_6f51c@/log.gz21:40
bdmurrayautopkgtest [21:37:47]: @@@@@@@@@@@@@@@@@@@@ apt-source vip-manager21:43
bdmurrayautopkgtest [21:37:52]: ERROR: erroneous package: rules extract failed with exit code 121:43
bdmurraylooking at your PPA its still pending publication so that could be the issue21:43
bdmurrayanyway good url - will click again ;-)21:44
dbungertok good, I wasn't sure what to do what that error :)21:44
bdmurraycould you see the log file?21:44
dbungertyes, thank you21:45
dbungertjust locked out of the results page21:45
bdmurrayweird21:45
bdmurraydbungert: https://autopkgtest.ubuntu.com/results/autopkgtest-impish-dbungert-vip-manager-armhf/impish/armhf/v/vip-manager/20210902_215832_46f25@/log.gz22:01
dbungertbdmurray: awesome, that was the info I needed, thanks22:02
mwhudsonbdmurray: archive22:47
bdmurraymwhudson: won't that kick off all the tests though?22:49
mwhudsonbdmurray: yes, i guess so, i thought that the test requests could be removed after the fact though22:49
bdmurrayyeah IDK how that works22:50
mwhudsonbdmurray: 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 idea22:50
mwhudsoncopying from a bileto ppa to proposed would have the same effect of triggering all the tests i think22:50
bdmurrayunless you need to do something to skip the tests in advance22:51
bdmurraybut the order of operations wasn't clear to me22:51
mwhudsonme neither22:51
mwhudsonanyway done now22:52
mwhudsonfor better or worse22:52
mwhudsonsteve or julian or iain might be able to do something tomorrow22:52
=== genii is now known as genii-core

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