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