Bug#948834: glib2.0: FTBFS: SIGABRT in gsocketclient-slow test

[Simon McVittie]

Control: retitle -1 glib2.0: FTBFS: gio/tests/gsocketclient-slow.c: Error resolving ?localhost?: Name or service not known

On Sun, 09 Feb 2020 at 16:45:05 +0100, Mattia Rizzolo wrote:
> I see glib2.0 is also failing in the r-b infra:
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/glib2.0.html
> 
> Could you perhaps check that build log?  It's likely equivalent.

# GLib-GIO-DEBUG: IPv6 DNS error: Error resolving ?localhost?: Name or service not known
# GLib-GIO-DEBUG: IPv4 DNS error: Error resolving ?localhost?: Name or service not known
**
GLib-GIO:ERROR:../../../gio/tests/gsocketclient-slow.c:30:on_connected: assertion failed (error == NULL): Error resolving ?localhost?: Name or service not known (g-resolver-error-quark, 0)

I personally think this is a pbuilder bug (see also
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897662>). The fact that
"localhost" resolves to 127.0.0.1 and/or ::1 is part of the "OS API",
and I think packages' tests should be entitled to assume that this will
happen, without needing to take special steps to achieve it.

According to #897662 this used to work - has it regressed?

We can't work around this by substituting 127.0.0.1 (as I did in dbus)
because the "happy eyeballs" algorithm that GLib is testing here includes
name resolution.

We could probably work around this in glib2.0 with a Build-Depends on
libnss-myhostname | netbase, or the other way round.

Related to <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939099>
(which is about whether the name in /etc/hostname resolves to a local
IP address, whereas this one is about whether localhost resolves to a
local IP adddress, but installing libnss-myhostname or netbase will
usually fix both those anomalous situations).

    smcv