[01:49] <infinity> wxl: Probably less interest than I used to have, given than we've dropped support.
[07:52] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (vivid-proposed) [3.19.0-93.101]
[09:00] <acheronuk> morning. some possible weirdness with s390x tests? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#kcoreaddons
[09:00] <acheronuk> whating https://autopkgtest.ubuntu.com/running it seems that those are constantly starting over, and never completing?
[09:00] <acheronuk> *watching
[09:54] <jbicha> please ignore flatpak/ppc64el autopkgtests http://autopkgtest.ubuntu.com/packages/f/flatpak/artful/ppc64el
[10:01] -queuebot:#ubuntu-release- New binary: retro-gtk [amd64] (artful-proposed/universe) [0.12.0-2] (no packageset)
[10:01] -queuebot:#ubuntu-release- New binary: retro-gtk [ppc64el] (artful-proposed/universe) [0.12.0-2] (no packageset)
[10:01] -queuebot:#ubuntu-release- New binary: retro-gtk [i386] (artful-proposed/universe) [0.12.0-2] (no packageset)
[10:02] <jbicha> approved ffe for retro-gtk is LP: #1714807
[10:02] <ubot5> Launchpad bug 1714807 in retro-gtk (Ubuntu) "[FFe] Update gnome-games-app to 3.26 (and retro-gtk to 0.12)" [Undecided,Fix released] https://launchpad.net/bugs/1714807
[10:03] -queuebot:#ubuntu-release- New binary: retro-gtk [armhf] (artful-proposed/universe) [0.12.0-2] (no packageset)
[10:03] -queuebot:#ubuntu-release- New binary: retro-gtk [s390x] (artful-proposed/universe) [0.12.0-2] (no packageset)
[10:13] -queuebot:#ubuntu-release- New binary: retro-gtk [arm64] (artful-proposed/universe) [0.12.0-2] (no packageset)
[11:01] -queuebot:#ubuntu-release- New: accepted retro-gtk [amd64] (artful-proposed) [0.12.0-2]
[11:01] -queuebot:#ubuntu-release- New: accepted retro-gtk [armhf] (artful-proposed) [0.12.0-2]
[11:01] -queuebot:#ubuntu-release- New: accepted retro-gtk [ppc64el] (artful-proposed) [0.12.0-2]
[11:01] -queuebot:#ubuntu-release- New: accepted retro-gtk [arm64] (artful-proposed) [0.12.0-2]
[11:01] -queuebot:#ubuntu-release- New: accepted retro-gtk [s390x] (artful-proposed) [0.12.0-2]
[11:01] -queuebot:#ubuntu-release- New: accepted retro-gtk [i386] (artful-proposed) [0.12.0-2]
[11:38] -queuebot:#ubuntu-release- Unapproved: walinuxagent (trusty-proposed/main) [2.2.16-0ubuntu1~14.04.1 => 2.2.17-0ubuntu1~14.04.1] (ubuntu-cloud, ubuntu-server)
[11:38] -queuebot:#ubuntu-release- Unapproved: walinuxagent (zesty-proposed/main) [2.2.16-0ubuntu1~17.04.1 => 2.2.17-0ubuntu1~17.04.1] (ubuntu-cloud, ubuntu-server)
[11:38] -queuebot:#ubuntu-release- Unapproved: walinuxagent (xenial-proposed/main) [2.2.16-0ubuntu1~16.04.1 => 2.2.17-0ubuntu1~16.04.1] (ubuntu-cloud, ubuntu-server)
=== beisner is now known as Beisner
[13:26] <ginggs> would someone please 'force-skiptest gyoto' or whatever is needed, it takes *hours* and has never passed - see debian #869980
[13:26] <ubot5> Debian bug 869980 in src:gyoto "gyoto: test suite times out" [Normal,Open] http://bugs.debian.org/869980
[14:09] <slangasek> ginggs: if it's never passed, it wouldn't be a blocker now either, though?
[14:10] <slangasek> ginggs: and indeed, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html only has one reference to it, where it shows as 'always-failed'
[14:16] -queuebot:#ubuntu-release- Unapproved: accepted xorg-server [source] (xenial-proposed) [2:1.18.4-0ubuntu0.5]
[14:18] <ginggs> slangasek: yup, it's not a blocker, it's just an incredible waste of resources
[14:18] <ginggs> http://autopkgtest.ubuntu.com/packages/g/gyoto/artful/amd64 6 to 9 hours a pop
[14:20] <slangasek> ginggs: force-skiptest doesn't stop the tests from being tried
[14:20] <slangasek> there is a blacklist in autopkgtest that we could add it to
[14:21] <ginggs> slangasek: oh, ok.  i was confused by the name
[14:22] <ginggs> slangasek: would you consider updating the hints for casync to 2.1ubuntu1 and possibly ignoring i386 as well?
[14:23] <slangasek> ginggs: not without analysis, because the bug I was hinting for in casync 2-1 is what I /fixed/ in 2-1ubuntu1
[14:26] <ginggs> slangasek: ok, thanks
=== santa is now known as Guest98110
[14:51] -queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (zesty-proposed) [2.2.17-0ubuntu1~17.04.1]
[15:02] -queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (xenial-proposed) [2.2.17-0ubuntu1~16.04.1]
[15:03] -queuebot:#ubuntu-release- Unapproved: accepted walinuxagent [source] (trusty-proposed) [2.2.17-0ubuntu1~14.04.1]
[15:25] <bdmurray> apw, infinity: steve tells me you two are working on making sure that there aren't two vmlinuz files for secureboot kernels. Is there a bug for that?
[16:01] -queuebot:#ubuntu-release- Unapproved: accepted crash [sync] (xenial-proposed) [7.1.4-1ubuntu4.2]
[16:29] <wxl> infinity: yay i'll get rid of it :)
[16:29] <slangasek> time to send it freegeek's direction :P
[16:31] <wxl> slangasek: i'm a little farther south so it will go to nextstep, but, yes, same idea :)
[17:21] <jbicha> slangasek: could you ignore autopkgtest failure for flatpak/ppc64el ? http://autopkgtest.ubuntu.com/packages/f/flatpak/artful/ppc64el
[17:22] <jbicha> they accidentally started passing (!) ;)
[17:23] <acheronuk> wish I could get some to do that!
[17:24] <ginggs> would someone please 'force badtest python-scipy/0.18.1-2ubuntu4/i386' - one test is failing due to floating point tolerance
=== Beisner is now known as beisner
[17:37] <LocutusOfBorg> do you think it is possible to force-badtest mariadb-10.1/10.1.26-1: on ppc64el and s390x? it is regressed in release
[17:41] <LocutusOfBorg> also flatpack seems really regressed in release, blocking security fixes for libarchive
[17:42] <jbicha> flatpak didn't regress, the autopkgtests accidentally started working briefly (this happened earlier on other arches)
[18:05] <slangasek> ginggs: I show a passed test for python-numpy w/ latest lapack+atlas?
[18:07] <slangasek> jbicha: why did this flatpak test start succeeding / failing? what server is returning this '503 unavailable'?
[18:08] <slangasek> (anyway, hint added)
[18:26] <ginggs> slangasek: ok, i think i missed something - running another test now
[19:02] <slangasek> hmmmm why did sru-review not set verification-needed tags on LP: #1717306?
[19:02] <ubot5> Launchpad bug 1717306 in walinuxagent (Ubuntu Zesty) "waalinuxagent 2.2.17" [Undecided,Fix committed] https://launchpad.net/bugs/1717306
[19:28] -queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [0.7.9-233-ge586fe35-0ubuntu1~16.04.1 => 0.7.9-233-ge586fe35-0ubuntu1~16.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
[19:34] -queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-233-ge586fe35-0ubuntu1~17.04.1 => 0.7.9-233-ge586fe35-0ubuntu1~17.04.2] (edubuntu, ubuntu-cloud, ubuntu-server)
[19:55] <ginggs> slangasek: i'm not seeing what you are seeing. http://autopkgtest.ubuntu.com/packages/p/python-scipy/artful/i386 0.18.1-2ubuntu4 	lapack/3.7.1-3ubuntu2 atlas/3.10.3-4 openblas/0.2.20+ds-3 python-numpy/1:1.12.1-3.1ubuntu4 python-scipy/0.18.1-2ubuntu4 	2017-09-15 19:43:57 UTC 	1h 16m 10s 	fail
[19:55] <ginggs> slangasek: FAIL: test_orthogonal.test_j_roots / AssertionError:
[19:55] <ginggs> Not equal to tolerance rtol=1e-15, atol=2e-13
[19:56] <ginggs> slangasek: it has been failing that way since 2017-08-05 when atlas got a no-change rebuild when we switched to GCC 7
[20:02] <slangasek> ginggs: oh sorry, you said scipy and I was looking at numpy
[20:03] <slangasek> ginggs: so, I'm not willing to overlook a floating point tolerance regression to let in packages that are entirely numbers
[20:04] <doko> one more point to drop i386 ...
[20:04] <slangasek> sure
[20:04] <slangasek> which would be more appropriate than badtesting it
[20:05] <doko> please reconsider that, that's the last one having the _pyFpe references in the -release pocket
[20:44] <doko> slangasek: glibc is now left with casync, twisted, why3 and click
[20:45] <doko> - twisted: can we ignore that one for glibc without letting twisted migrate?
[20:45] <doko> - click: I think somebody else asked to ignore the failing test on ppc64el
[20:46] <infinity> doko: twisted just looks like the testsuite needs adjusting for the fact that TLSv1 is disabled?
[20:46] <doko> - why3: I think xnox promised to have a look. otoh, I'm happy to look at what requires removal
[20:46] <doko> infinity: yes, free said he was working on it
[20:47] <doko> - casync: you wanted to have a look
[20:53] <xnox> sigh that
[21:18] <infinity> doko: Anyhow, I think it's clear that the twisted (both old and new) and casync failures aren't glibc's fault, so while I'd like to see them fixed, I'll be happy to skip past them after why3 and click are understood/fixed.
[21:19] <infinity> (That's with a release team hat on, not a glibc maintainer who wants his package to migrate :P)
[21:19] <doko> infinity: are you ok, if I investigate how to remove click on ppc64el?  it's obsolete anyway, so this looks more productive
[21:20] <doko> xnox: ^^^
[21:20] <infinity> doko: Yeah, that wouldn't bug me terribly.  I don't think it would ever have had users on ppc64el anyway.
[21:20] <doko> infinity: in that case, please ignore, and we save both valuable time
[21:20] <infinity> doko: But it might be nice to know why/how it broke, to ease our minds that it's not actually a toolchain bug somewhere.
[21:21] <doko> I'm sure we have more imprtant toolchain issues to resolve
[21:21] <infinity> I vew glibc/gcc/binutils autopkgtest results more as a wide net to try to catch issues that might crop up elsewhere, rather than just "let's make all the tests pass or go away".
[21:22] <doko> sure, but not for corner cases like ocaml on s390x
[21:23] <infinity> doko: Anyhow, looks like the click rdep chain is pretty shallow, so removals aren't the worst answer.  If it's also made to not build on ppc64el anymore.
[21:24] <infinity> In fact, it looks like it's just libusermetrics?
[21:24] <infinity> Ahh, and a few more in build-deps.
[21:25] <infinity> click-systemd, click-apparmor, unity-scopes-api...
[21:25] <infinity> But entirely manageable, and I don't think any ppc64el click packages ever existed, so the packaging toolchain is clearly not in use.
[21:26] <infinity> (Same argument could be made for dropping it from s390x too, IMO, and just letting it live on x86/arm* until it dies entirely)
[21:27] <xnox> infinity, i filed removal bugs for src:click in artful.
[21:27] <doko> just make sure that calc-stats relies on it ...
[21:27] <infinity> xnox: Well, that would be even better.
[21:27] <xnox> infinity, https://bugs.launchpad.net/ubuntu/+bugs?field.tag=u8rm
[21:27] <xnox> infinity, with "importance" used to sort how to remove things. There are mutually reversencing things.
[21:27] <infinity> xnox: I'd certainly prefer total removal, if that's agreed on by whomever needs to do the agreeing.
[21:28] <xnox> infinity, yes yes yes. jdstrand was begging to have click removed.
[21:28] <infinity> Heh.
[21:28] <infinity> doko: ^-- Well, there you go.  Self-solving problem.
[21:28] <xnox> if you or slangasek could process https://bugs.launchpad.net/ubuntu/+bugs?field.tag=u8rm then click and gcc-4.7 can be removed
[21:28] <infinity> xnox: I don't suppose hybris is on your hit list?
[21:28] <doko> infinity: so you can override it and then we remove it for a?
[21:29] <doko> hybris is obsolete with ubuntu-touch
[21:29] <infinity> doko: I'll do the removals, if britney isn't smart enough to notice, then I'll hint it too.
[21:29] <infinity> hybris has rdeps that aren't being removed, so while I agree it should be obsolete, it needs code changes to tear it out, I believe.
[21:29] <xnox> infinity, libhybris too but that needs fixing first....
[21:30] <infinity> xnox: Well, the time is now.
[21:30] <infinity> xnox: Cause hybris has a strict versioned glibc dep, so it either needs to be ported or torn out, and I'd really prefer the latter.
[21:30] <xnox> infinity, sure please process these https://bugs.launchpad.net/ubuntu/+bugs?field.tag=u8rm and then i will continue my crusade.
[21:30] <slangasek> yes, libhybris is uninstallable with new glibc and unbuildable with new everything
[21:30] <xnox> sigh, ok
[21:31] <infinity> xnox: Yeahp, I have that open in a browser, will process the current set tonight, with a bit of wine and some glee.
[21:31] <infinity> The emotion, not the television show.
[21:35] <doko> ahh, I got the perl bug fix message, but not yet the migration message
[21:35] <slangasek> so someone has analyzed the remaining casync failures and confirmed they're not glibc-induced?
[21:35] <slangasek> is that someone also adding a badtest hint?
[21:36] <doko> slangasek: sorry, I had the impression you would do that
[21:36] <slangasek> doko: well, I said I was going to look, and I have time to do so right now, but infinity also asserted that it's not glibc's fault
[21:37] <slangasek> and... those are some interesting combinations of autopkgtest triggers on the retry?
[21:37] <doko> anyway, it's time to leave for me for the day
[21:39] <infinity> slangasek: I've asserted that it was failing before glibc was uploaded.
[21:42] <infinity> slangasek: Your build failure fix appears to have been necessary, but then the failure that -1ubuntu1 see is the same that -1 saw before glibc was updated.
[21:42] <infinity> (Which leads to the annoying reality that we probably want to let -1ubuntu1 in, despite it not passing its tests)
[21:42] <slangasek> right, and that failure seems to be "have a thing that's not a thing"
[21:43] <infinity> So, I think we badtest -1ubuntu1 and let it slide in.
[21:43] <slangasek> yeah, working on that now
[21:43] <infinity> With a bit of nose-pinching.
[21:44] <slangasek> done
[21:46] <slangasek> nice coincidence that the testsuite is reliable on the container archs
[21:46] <infinity> Reliable, or not run?
[21:47] <infinity> Huh, reliable.
[21:47] <infinity> Well, that's backwards.
[21:50] <cjwatson> click/ppc64el is almost certainly something wrong with its horrible LD_PRELOAD wrapper, in case you're wondering; it's the sort of thing that might break even with legit toolchain changes.
[21:51] <cjwatson> I wouldn't lose too much sleep over it.
[21:51] <slangasek> infinity: ah it actually self-disables the nbd test if it can't modprobe nbd. which it can't. because container.
[21:52] <slangasek> cjwatson: yeah, but I dug in and couldn't figure out why it was failing; it could actually be a glibc regression
[21:52] <slangasek> cjwatson: e.g. when I added a debugging printf() into the module init function, the segfault went away
[21:53] <cjwatson> I'm pretty sure I've had that before with real clickpreload bugs
[21:53] <slangasek> k
[21:53] <cjwatson> It's painful to debug
[21:53] <cjwatson> gdb is probably a better place to start if you want to dig
[21:53] <slangasek> that is where I started ;)
[21:53] <cjwatson> did you get a backtrace?
[21:53] <slangasek> not a meaningful one
[21:54] <infinity> Given the complete lack of regressions elsewhere, I'm kinda okay with the "ignore it cause we're removing it" path.
[21:54] <cjwatson> I think I've also had luck divining things from valgrind before
[21:54] <cjwatson> Dunno how well that works on ppc64el
[21:54] <slangasek> there was a bit of gdb, a bit of LD_DEBUG=, and a bit of valgrind, and I didn't manage to find anything that gave me a clue