On Sat, 20 Mar 2021 at 09:16:45 +0100, Salvatore Bonaccorso wrote: > On Sat, Mar 20, 2021 at 12:12:39AM +0000, Simon McVittie wrote: > > Could x86-conova-01.debian.org be an IPv6-only buildd? If so, this > > reminds me of https://bugs.debian.org/948834 and is perhaps even the > > same bug > > JFTR, this might indeed be the case. I gave it back a couple of times > and building on x86-conova-01.debian.org failed. The last one got > picked on buildd-x86-grnet-01 which now seems to have built.
Philipp Kern tried running the test-case from <https://people.debian.org/~smcv/bug985556/getaddrinfo.c> on the affected buildd, and it looks like this is indeed the same issue as <https://bugs.debian.org/948834> and <https://bugs.debian.org/952740>. The test server only listens on IPv4, the test client connects to http://localhost, and resolving localhost with AI_ADDRCONFIG and AF_UNSPEC resolves to only ::1 (and not 127.0.0.1) on this system, so the connection fails. Is this something that should be fixed immediately for buster, or can it be incorporated into the next update to the flatpak package if there is one? We can probably fix these tests most straightforwardly by patching the affected unit test to connect to http://127.0.0.1 instead of http://localhost. GLib >= 2.64 special-cases localhost to always resolve to 127.0.0.1 and/or ::1 (depending on the address family requested) without consulting nsswitch or taking AI_ADDRCONFIG into account, so bullseye should be unaffected by this. If buster's glib2.0 happens to be built on this buildd, it's very likely to fail build-time tests for the same reason. Unlike flatpak, this can't easily be worked around, because some of the glib2.0 tests are specifically trying to exercise resolver APIs or the ability to use a name that exists in both IPv4 and IPv6 space. The change from GLib >= 2.64 is something that could probably be backported, but is the sort of behaviour change that I would not normally be backporting to stable unless there was a CVE ID attached - do we want it anyway? If the buildd operators want to work around this class of bug, they could add an IPv4 address other than 127.0.0.1. 127.0.0.2 might be sufficient, or failing that, an RFC1918 or RFC3927 address (with no particular routing) should certainly do it. smcv
