[Pkg-utopia-maintainers] Bug#985556: flatpak/1.2.5-0+deb10u4 FTBFS on i386

[Simon McVittie]

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