Bug#844420: FTBFS: tests fail on hosts without network access

[Ximin Luo]

Aurelien Jarno:
> On 2016-11-16 09:48, Ximin Luo wrote:
>> Aurelien Jarno:
>>> On 2016-11-15 16:00, Ximin Luo wrote:
 Package: glibc
 Version: 2.24-5
 Severity: important
 Tags: upstream patch
 Forwarded: https://sourceware.org/bugzilla/show_bug.cgi?id=20826

 Dear Maintainer,

 posix/tst-getaddrinfo.c is causing glibc to FTBFS on 
 tests.reproducible-builds.org:

 https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/glibc_2.24-5.rbuild.log.gz

 The attached patch should fix this; I gave a more detailed description in 
 the upstream bug report.
>>>
>>> Hum, I am not sure it is the correct way to fix that. I think that
>>> libnss_files should be able to resolve entries from /etc/hosts when the
>>> query is relative, but also when it is fully qualified. This is how
>>> libnss_dns behaves.
>>>
>>
>> Looks like I was wrong before about getaddrinfo bypassing /etc/hosts, and it 
>> does indeed look at /etc/hosts.
>>
>> $ sudo -u sbuild getent hosts localhost
>> 127.0.0.1   profitbricks-build17-amd64.debian.net 
>> profitbricks-build17-amd64 localhost
>> $ sudo -u sbuild getent hosts localhost.
>> # no results
>>
>> However if you change "localhost" in /etc/hosts to "localhost." then the 
>> above results would be reversed.
>>
>> What do you think the full behaviour should be?
> 
> I think that it should returns 127.0.0.1 for both 'localhost' and
> 'localhost.'
> 

It is more complex than just making "localhost." work. As mentioned, if one 
explicitly adds "localhost." into /etc/hosts then it already works.

So the question is whether libnss_files should attempt to interpret relative 
names in /etc/hosts as if they were absolute names. That is what you are 
effectively proposing. (I assume that you're not proposing everyone to add 
extra duplicate entries into their /etc/hosts file.)

I don't know which sorts of standards documents describe this file or whatever, 
but I guess it would be quite a major change. Anyway I will go ask upstream.

>>> Also note that technically the glibc doesn't require network access,
>>> just a DNS server able to resolve 'localhost.'
>>>
>>
>> So how do you want to fix this? glibc doesn't currently build-depend on a 
>> name server, and I assume you wouldn't want to do that. Can you give me some 
>> hints on what to patch, to fix libnss_files?
> 
> My point about that, is that a package should build without network
> access. Now I am not sure it actually means without even a nameserver.
> 
> Anyway I don't know that part of the code a lot, but the fix has
> probably to be done in nss/nss_files/files-hosts.c.
> 
> Aurelien
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#844420: FTBFS: tests fail on hosts without network access

[Aurelien Jarno]

On 2016-11-16 09:48, Ximin Luo wrote:
> Aurelien Jarno:
> > On 2016-11-15 16:00, Ximin Luo wrote:
> >> Package: glibc
> >> Version: 2.24-5
> >> Severity: important
> >> Tags: upstream patch
> >> Forwarded: https://sourceware.org/bugzilla/show_bug.cgi?id=20826
> >>
> >> Dear Maintainer,
> >>
> >> posix/tst-getaddrinfo.c is causing glibc to FTBFS on 
> >> tests.reproducible-builds.org:
> >>
> >> https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/glibc_2.24-5.rbuild.log.gz
> >>
> >> The attached patch should fix this; I gave a more detailed description in 
> >> the upstream bug report.
> > 
> > Hum, I am not sure it is the correct way to fix that. I think that
> > libnss_files should be able to resolve entries from /etc/hosts when the
> > query is relative, but also when it is fully qualified. This is how
> > libnss_dns behaves.
> > 
> 
> Looks like I was wrong before about getaddrinfo bypassing /etc/hosts, and it 
> does indeed look at /etc/hosts.
> 
> $ sudo -u sbuild getent hosts localhost
> 127.0.0.1   profitbricks-build17-amd64.debian.net 
> profitbricks-build17-amd64 localhost
> $ sudo -u sbuild getent hosts localhost.
> # no results
> 
> However if you change "localhost" in /etc/hosts to "localhost." then the 
> above results would be reversed.
> 
> What do you think the full behaviour should be?

I think that it should returns 127.0.0.1 for both 'localhost' and
'localhost.'

> > Also note that technically the glibc doesn't require network access,
> > just a DNS server able to resolve 'localhost.'
> > 
> 
> So how do you want to fix this? glibc doesn't currently build-depend on a 
> name server, and I assume you wouldn't want to do that. Can you give me some 
> hints on what to patch, to fix libnss_files?

My point about that, is that a package should build without network
access. Now I am not sure it actually means without even a nameserver.

Anyway I don't know that part of the code a lot, but the fix has
probably to be done in nss/nss_files/files-hosts.c.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#844420: FTBFS: tests fail on hosts without network access

[Ximin Luo]

Aurelien Jarno:
> On 2016-11-15 16:00, Ximin Luo wrote:
>> Package: glibc
>> Version: 2.24-5
>> Severity: important
>> Tags: upstream patch
>> Forwarded: https://sourceware.org/bugzilla/show_bug.cgi?id=20826
>>
>> Dear Maintainer,
>>
>> posix/tst-getaddrinfo.c is causing glibc to FTBFS on 
>> tests.reproducible-builds.org:
>>
>> https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/glibc_2.24-5.rbuild.log.gz
>>
>> The attached patch should fix this; I gave a more detailed description in 
>> the upstream bug report.
> 
> Hum, I am not sure it is the correct way to fix that. I think that
> libnss_files should be able to resolve entries from /etc/hosts when the
> query is relative, but also when it is fully qualified. This is how
> libnss_dns behaves.
> 

Looks like I was wrong before about getaddrinfo bypassing /etc/hosts, and it 
does indeed look at /etc/hosts.

$ sudo -u sbuild getent hosts localhost
127.0.0.1   profitbricks-build17-amd64.debian.net 
profitbricks-build17-amd64 localhost
$ sudo -u sbuild getent hosts localhost.
# no results

However if you change "localhost" in /etc/hosts to "localhost." then the above 
results would be reversed.

What do you think the full behaviour should be?

> Also note that technically the glibc doesn't require network access,
> just a DNS server able to resolve 'localhost.'
> 

So how do you want to fix this? glibc doesn't currently build-depend on a name 
server, and I assume you wouldn't want to do that. Can you give me some hints 
on what to patch, to fix libnss_files?

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#844420: FTBFS: tests fail on hosts without network access

[Aurelien Jarno]

On 2016-11-15 16:00, Ximin Luo wrote:
> Package: glibc
> Version: 2.24-5
> Severity: important
> Tags: upstream patch
> Forwarded: https://sourceware.org/bugzilla/show_bug.cgi?id=20826
> 
> Dear Maintainer,
> 
> posix/tst-getaddrinfo.c is causing glibc to FTBFS on 
> tests.reproducible-builds.org:
> 
> https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/glibc_2.24-5.rbuild.log.gz
> 
> The attached patch should fix this; I gave a more detailed description in the 
> upstream bug report.

Hum, I am not sure it is the correct way to fix that. I think that
libnss_files should be able to resolve entries from /etc/hosts when the
query is relative, but also when it is fully qualified. This is how
libnss_dns behaves.

Also note that technically the glibc doesn't require network access,
just a DNS server able to resolve 'localhost.'

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#844420: FTBFS: tests fail on hosts without network access

[Ximin Luo]

Package: glibc
Version: 2.24-5
Severity: important
Tags: upstream patch
Forwarded: https://sourceware.org/bugzilla/show_bug.cgi?id=20826

Dear Maintainer,

posix/tst-getaddrinfo.c is causing glibc to FTBFS on 
tests.reproducible-builds.org:

https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/glibc_2.24-5.rbuild.log.gz

The attached patch should fix this; I gave a more detailed description in the 
upstream bug report.

It would be good if this were already applied to the Debian glibc so that we 
can begin to see diffoscope output again and work on its reproducibility.

Thanks,
X

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable'), (300, 'unstable'), (200, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Description: Don't condition failure of double-dot-FQDN on single-dot-FQDN
 Otherwise the test fails on systems that disable network access during build
 time, since getaddrinfo() fails in all cases and the test returns 2.
 .
 Normally, such systems can still resolve "localhost." via nsswitch/getent and
 getaddrinfo is not suppose to attempt resolution of "localhost." anyways.
Author: Ximin Luo 
Bug: TBD
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/posix/tst-getaddrinfo5.c
+++ b/posix/tst-getaddrinfo5.c
@@ -36,20 +36,6 @@
   size_t len = strlen (host);
   struct addrinfo *ai;
 
-  /* If the name doesn't resolve with a single dot at the
-	 end, skip it.  */
-  host[len-1] = 0;
-  if (getaddrinfo (host, NULL, NULL, ) != 0)
-	{
-	  printf ("resolving \"%s\" failed, skipping this hostname\n", host);
-	  continue;
-	}
-  printf ("resolving \"%s\" worked, proceeding to test\n", host);
-  freeaddrinfo (ai);
-
-  /* If it resolved with a single dot, check that it doesn't with
-	 a second trailing dot.  */
-  host[len-1] = '.';
   if (getaddrinfo (host, NULL, NULL, ) == 0)
 	{
 	  printf ("resolving \"%s\" worked, test failed\n", host);