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

[Simon McVittie]

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