<div dir="ltr">

On Mon, 8 Jun 2020 10:18:09 +0300 Niko Tyni <<a href="mailto:ntyni@debian.org">ntyni@debian.org</a>> wrote: > On Sat, Jun 06, 2020 at 10:22:58AM +0300, Adrian Bunk wrote: > > Source: libmojolicious-perl > > Version: 8.52+dfsg-1 > > Severity: serious > > Tags: ftbfs > > > > <a href="https://buildd.debian.org/status/logs.php?pkg=libmojolicious-perl&ver=8.52+dfsg-1">https://buildd.debian.org/status/logs.php?pkg=libmojolicious-perl&ver=8.52+dfsg-1</a> > > > > ... > > Can't create listen socket: Address family for hostname not supported at /<<PKGBUILDDIR>>/blib/lib/Mojo/IOLoop.pm line 123. > > # Tests were run but no plan was declared and done_testing() was not seen. > > ... > > Failed 39/103 test programs. 0/6415 subtests failed. > > make[2]: *** [Makefile:1393: test_dynamic] Error 22 > > > > > > See #962019 as example of a similar problem in another package. > > This seems to be a wider issue. Copying the debian-perl list for > discussion. > > The root cause is that IO::Socket::IP defaults to passing AI_ADDRCONFIG > to getaddrinfo(3) if no flags are explicitly specified. From the > getaddrinfo(3) man page: > >        If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4 >        addresses are returned in the list pointed to by res only if >        the local system has at least one IPv4 address configured, and >        IPv6 addresses are returned only if the local system has at >        least one IPv6 address configured.  The loopback address is  not >        considered  for  this  case  as  valid  as  a configured address. >        This flag is useful on, for example, IPv4-only systems, to ensure >        that getaddrinfo() does not return IPv6 socket addresses that >        would always fail in connect(2) or bind(2). > > While this may be useful on IPv4-only systems, it breaks on systems with > an IPv6-only network connection that still provide IPv4 on localhost. This > appears to match the recent new official buildds where these failures > happen. > ../.. > BTW, I noticed nodejs also fails (with test code listening on 127.0.0.1 > but client connecting to ::1) so at least we're not quite alone in this...

<div><br></div><div>Indeed nodejs has the same issue.</div><div>Is there a simple way to setup the network locally so i can reproduce it ?</div><div>Naive attempts (like disabling IPv4 on the wan network) failed.</div><div><br></div><div>Jérémy</div></div>