=== doko_ is now known as doko
=== cpaelzer_ is now known as cpaelzer
[10:08] <ginggs> where can i see launchpad's i386 whitelist?
[10:11] <laney> ginggs: https://people.canonical.com/~ubuntu-archive/packagesets/impish/i386-whitelist
[10:12] <ginggs> laney: thanks!
[12:52] <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:53] <schopin> 2/ would removing the LTO flags in the package break stuff?
[12:53] <schopin> 3/ Should I report this to GCC upstream?
[12:58] <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:59] <ginggs> which it doesn't look like we currently do
[13:03] <schopin> I'll try
[13:04] <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:21] <schopin> ginggs: indeed, that takes care of my second question :). But is it considered a regression in GCC or not?
[13:29] <ginggs> schopin: did it build with lto in gcc10, ands now fails in gcc11?
[13:33] <schopin> Yes.
=== genii-away is now known as genii
[14:48] <xnox> schopin:  lots of packages disable lto by exporting deb_maint_flags things in debian/rules.
[14:49] <xnox> export DEB_BUILD_MAINT_OPTIONS = optimize=-lto
[14:51] <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:52] <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.
[15:53] <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:54] <schopin> doko: new ftbfs from your GCC 11 rebuild.
[15:54] <schopin> So, I'll file a report upstream then?
[15:56] <doko> schopin, LP first. need to reduce the test case as well ...
[15:57] <schopin> LP: #1939707
[15:57] <ubottu> Launchpad bug 1939707 in libuv1 (Ubuntu) "FTBFS on impish" [Undecided, In Progress] https://launchpad.net/bugs/1939707
[15:58] <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
[16:00] <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:01] <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:07] <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:14] <schopin> FTR, the fix isn't to disable LTO but to pass -fno-strict-aliasing
[16:18] <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:19] <bdmurray> dbungert: do you have a log from your successful test?
[16:23] <schopin> doko: new upstream fixes things, indeed... By adding that exact flag to their build system :D
[16:25] <dbungert> bdmurray: https://paste.ubuntu.com/p/XrVBWtgCxm/
[16:47] <bdmurray> dbungert: I'm trying to have a look myself
[16:48] <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:49] <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:52] <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:53] <bdmurray> https://wiki.ubuntu.com/ProposedMigration#Testing_against_a_PPA
[16:56] <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à.
=== lucas__ is now known as lucascastro
[18:25] <sergiodj> anyone else having trouble pull-lp-source'ing a package?
[18:25] <sergiodj> I'm getting proxy errors
[18:28] <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:33] <bdmurray> okay, its still bad for me
[18:47] <ddstreet> it looks like launchpadlibrarian.net is totally down, i get 503's now
[18:52] <bdmurray> I believe IS is aware and working on it
[19:32] <jawn-smith> Interesting, Go on ppc64el seems to be experiencing segmentation faults while compiling code
[19:39] <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:42] <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:43] <jawn-smith> which I see you've noted in this bug
[19:47] <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:55] <jawn-smith> building now
[19:57] <jawn-smith> odd, I can't get that one to crash
[19:58] <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
[20:02] <dbungert> jawn-smith: https://paste.ubuntu.com/p/PK4wv79QWJ/ - fix up imagedir and PUB_KEY and that might help
[20:03] <jawn-smith> ooh excellent, thanks!
[20:31] <mwhudson> good mornig
[20:31] <mwhudson> is everyone ready to have the autopkgtest queues jammed by glibc for a couple of days?
[20:33] <sarnold> oh boy oh boy oh boy
[20:33] <bdmurray> mwhudson: doko was suggesting that we not test everything
[20:34] <mwhudson> bdmurray: i think that probably makes sense, the only changes are in glibc's testsuite and the postinst
[20:35] <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:36] <bdmurray> do it in a PPA and manually run tests with that glibc?
[20:37] <bdmurray> I've also been led to believe vorlon might now how to modify the test infrastructure so not every test will run
[20:51] <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:52] <mwhudson> between the > and the /dev/null?
[20:53] <bdmurray> and or the 2> /dev/null
[20:54] <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:56] <bdmurray> This patch is upstream and we'll get it later?
[21:03] <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:04] <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:05] <mwhudson> i think what ddstreet does for systemd is to have thm split out in directories like debian/patches/lp$bug/
[21:12] <bdmurray> there was also some mention this morning of balint testing glibc in bileto
[21:14] <mwhudson> i should do that with 2.35 snapshots next cycle
[21:18] <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:19] <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:20] <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:21] <bdmurray> dbungert: good enough that I clicked on it! ;-) "Test request submitted."
[21:22] <bdmurray> https://autopkgtest.ubuntu.com/running#pkg-vip-manager
[21:27] <mwhudson> uploading glibc ..
[21:29] <bdmurray> where to?
[21:33] <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:38] <bdmurray> really you can't see it?
[21:38] <dbungert> unauthorized error
[21:40] <bdmurray> https://autopkgtest.ubuntu.com/results/autopkgtest-impish-dbungert-vip-manager-armhf/impish/armhf/v/vip-manager/20210902_213803_6f51c@/log.gz
[21:43] <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:44] <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:45] <dbungert> yes, thank you
[21:45] <dbungert> just locked out of the results page
[21:45] <bdmurray> weird
[22:01] <bdmurray> dbungert: https://autopkgtest.ubuntu.com/results/autopkgtest-impish-dbungert-vip-manager-armhf/impish/armhf/v/vip-manager/20210902_215832_46f25@/log.gz
[22:02] <dbungert> bdmurray: awesome, that was the info I needed, thanks
[22:47] <mwhudson> bdmurray: archive
[22:49] <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:50] <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:51] <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:52] <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
=== genii is now known as genii-core