[01:36] <infinity> Logan: Bootstrapping.
=== juliank is now known as Guest71144
=== juliank_ is now known as juliank
[04:54] <slangasek> pitti: hi, so we're seeing some test failures on the amd64 and i386 autopkgtest runners for glibc revdeps where gtk is failing consistently; it's not a problem on other archs, I can't reproduce it locally, and the error points to a problem related to selecting a mir backend instead of an X backend.  Have there been any testbed config changes recently that could be to blame?
[05:02] <stgraber> could be a side effect of the pocket pinning logic in adt
[05:03] <stgraber> which would explain why a plain adt-run using the whole proposed pocket would succeed but the autopkgtest.ubuntu.com wouldn't as it's only pulling some packages from proposed
[05:36] <slangasek> stgraber: I didn't do an adt-run using the whole proposed pocket.
=== zequence_ is now known as zequence
[07:33] <infinity> Logan: Well, sbcl bootstrap attempted, anyway.  It failed.
[07:36]  * infinity tries it on a newer kernel.
=== shuduo is now known as shuduo-afk
=== shuduo-afk is now known as shuduo
[18:26] <Unit193> infinity: bitlbee had a new release, not entirely bugfix (https://www.bitlbee.org/main.php/changelog.html) but mainly.  It's had a good amount of testing I'm told, I take it an FFe is still needed?
[18:27] <infinity> Unit193: Assuming the release is somewhat featureful, yeah.
[18:27] <Unit193> Bummer.  Thanks.
[18:31] <infinity> Unit193: Oh, but it's not seeded anywhere, so meh.
[18:31] <infinity> Unit193: JFDI, IMO.
[18:31] <infinity> Unit193: Here's your verbal FFe.
[18:32] <Unit193> Woohoo!  If you feel specifically like uploading: https://launchpad.net/~unit193/+archive/ubuntu/staging/+files/bitlbee_3.4.2-0ubuntu1.dsc, otherwise I'll go find someone.
[18:33] <infinity> Unit193: It is just a straight uupdate with a new orig, basically?
[18:33]  * infinity looks.
[18:34] <Unit193> It needs more updating, but on Debian's side.
[18:35] <infinity> Looks like a uupdate job to me.  No changes in debian/ except for the changelog.
[18:35] <Unit193> Mhmm.
[18:36] <infinity> Kay.  Source tarball looks sane, etc.
[18:36] <infinity> Want a slightly more verbose changelog? :P
[18:37]  * infinity shrugs and uploads.
[18:37] <Unit193> Oh dear, I'm too concise again. :3
[18:37] <infinity> Unit193: Too late, it's uploaded.
[18:38] <Unit193> Yey!  Thank you very much, infinity!
[18:38] <Unit193> I'll pass it along to who poked me.
[18:42] <dx> ♥
[20:20] <slangasek> doko: why did libnih need a rebuild for the new libc?  the versioned dep seems to have been resolved some time ago
[20:31] <cjwatson> pitti: Could we generate a stronger key for ddebs.u.c?
[20:32] <infinity> slangasek: It doesn't, I assume he was just working from an old list.
[20:33] <cjwatson> pitti: Also needs --digest-algo SHA384 or similar, but probably not much point until we have something better than 1024-bit DSA
=== damascene is now known as az
=== az is now known as damascene
[21:42] <slangasek> doko: do you know anything about valgrind compatibility with glibc 2.23? http://autopkgtest.ubuntu.com/packages/c/colord/xenial/amd64/ (or is this a toolchain regression somehow?)
[21:44] <mwhudson> infinity: did i ask you to look at https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1555856 at all yet?
[21:44] <ubottu> Launchpad bug 1555856 in golang (Ubuntu) "move to per-Go-major version coinstallable packages" [Undecided,New]
[21:44] <mwhudson> (i asked stgraber to look at it and he asked if you'd seen it...)
[22:52] <doko> slangasek, just looked at the debian transition issue. the armhf build issue is not caused by the libc update. also seen in the test rebuilds
[23:25] <nacc> slangasek: will update my automated file, as i was using apt-cache redepends, which includes breaks and others, while reverse-depends does not. will provide an updated list first thing tmrw