On Fri, 19 Mar 2021 at 22:48:33 +0100, Salvatore Bonaccorso wrote: > While reviewing the current uploads for the upcoming point release I > noticed that the i386 build of flatpak was apparently not done, and > indeed it failed. > > Attached are two build logs.
The failing test runs a simple Python web server (`python3 ${builddir}/tests/http-utils-test-server.py 0`), reads back the port number that was allocated for it, and uses it to test Flatpak's http client implementation by connecting to http://localhost:$port. Instead, in those logs, it gets "Could not connect: Connection refused". 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 (briefly: with the getaddrinfo flags normally used in GLib, if you have no IPv4 addresses other than 127.0.0.1 - not even RFC1918 LAN addresses - then resolving 'localhost' in the obvious way will not yield 127.0.0.1 as expected). Post-buster versions of GLib avoid this by special-casing localhost to always resolve to 127.0.0.1 and/or ::1, like the major web browsers do. I think this should probably be something that glibc does, or at least something that glibc nsswitch plugins can do, rather than being individual network clients' responsibility, but that's not the way the nsswitch interface works right now. Or, if not that, could it be the case that this buildd is firewalled or otherwise restricted such that connections from the build to a test server listening on an arbitrary high port number on the loopback interface will fail? src:glib2.0 and src:dbus are examples of other packages that need to communicate with a TCP server on the loopback interface during their build-time tests. If the root cause for this is #948834, then this is also going to affect buster's glib2.0 next time we update that. smcv