Source: krb5
Version: 1.20.1-5+b1
Severity: serious
Tags: ftbfs

Hi,

there as a binNMU "Rebuild to sync binNMU versions" for krb5 and that
failed for arm64, armel and ppc64el:

https://buildd.debian.org/status/package.php?p=krb5

The error logs look very similar:

making check in lib/rpc...
make[4]: Entering directory '/<<PKGBUILDDIR>>/build/lib/rpc'
making check in lib/rpc/unit-test...
make[5]: Entering directory '/<<PKGBUILDDIR>>/build/lib/rpc/unit-test' PYTHONPATH=../../../../src/util VALGRIND="" python3 ../../../../src/lib/rpc/unit-test/t_rpc.py
*** Failure: ./client failed with code 1.
*** Last command (#10): ./client -t arm-conova-03 58621 host@arm-conova-03 1026 *** Output of last command:
Can't resolve hostname arm-conova-03
For details, see: /<<PKGBUILDDIR>>/build/lib/rpc/unit-test/testlog
Or re-run this test script with the -v flag:
cd /<<PKGBUILDDIR>>/build/lib/rpc/unit-test
PYTHONPATH=/<<PKGBUILDDIR>>/src/util /usr/bin/python3 ../../../../src/lib/rpc/unit-test/t_rpc.py -v

Use --debug=NUM to run a command under a debugger. Use
--stop-after=NUM to stop after a daemon is started in order to
attach to it with a debugger. Use --help to see other
options.
make[5]: *** [Makefile:644: check-pytests] Error 1
make[5]: Leaving directory '/<<PKGBUILDDIR>>/build/lib/rpc/unit-test'
make[4]: *** [Makefile:1595: check-recurse] Error 1
make[4]: Leaving directory '/<<PKGBUILDDIR>>/build/lib/rpc'
make[3]: *** [Makefile:973: check-recurse] Error 1
make[3]: Leaving directory '/<<PKGBUILDDIR>>/build/lib'
make[2]: *** [Makefile:1521: check-recurse] Error 1
make[2]: Leaving directory '/<<PKGBUILDDIR>>/build'
dh_auto_test: error: cd build && make -j1 check "TESTSUITEFLAGS=-j1 --verbose" VERBOSE=1 returned exit code 2
make[1]: *** [debian/rules:150: override_dh_auto_test] Error 25
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
make: *** [debian/rules:153: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2


Thanks!

cheers, josch

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Feb 10, 2024 at 01:33:15PM +0100, Johannes Schauer Marin Rodrigues wrote:

there as a binNMU "Rebuild to sync binNMU versions" for krb5 and that
failed for arm64, armel and ppc64el:

https://buildd.debian.org/status/package.php?p=krb5

The error logs look very similar:
*** Output of last command:
Can't resolve hostname arm-conova-03

This is due more to the build environment than the test suite per se. I am pretty sure that there was a previous discussion of this but I could not construct a search query to find it quickly (maybe Sam can do better than
me?).

In short, the test suite, as for the protocol itself, assumes that it can resolve the server's hostname to an IP address; for the test suite the
server will be the local machine, and so this becomes an assumption that
what the "machine" (or container/etc.) thinks its hostname is will resolve
with the resolver on that machine. In this case it looks like a bare name (without domain) that is not localhost, and presumably a local resolver
with no search path set.

I do not remember whether the previous discussion reached a firm conclusion about what can reasonably be expected from a build/test environment in this regard.

-Ben

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 11 Feb 2024 at 13:53:56 -0800, Benjamin Kaduk wrote:

On Sat, Feb 10, 2024 at 01:33:15PM +0100, Johannes Schauer Marin Rodrigues wrote:

there as a binNMU "Rebuild to sync binNMU versions" for krb5 and that failed for arm64, armel and ppc64el:

https://buildd.debian.org/status/package.php?p=krb5

The error logs look very similar:
*** Output of last command:
Can't resolve hostname arm-conova-03

This is due more to the build environment than the test suite per se.

...

In short, the test suite, as for the protocol itself, assumes that it can resolve the server's hostname to an IP address

It might be relevant that according to #972151, arm-conova-03 (and
perhaps other *-conova-* buildds?) is IPv6-only, with no IPv4 addresses
or routes other than loopback (not even via NAT).

I believe there is consensus that we consider "localhost resolves to
127.0.0.1" to be a reasonable thing to demand from all buildds as part
of the build-essential interface.

I am unsure whether there is consensus that "the result of gethostname() resolves to some address of the local machine" is also a reasonable
thing to demand from all buildds as part of build-essential: /etc/hosts typically makes this true, but is not *guaranteed* to do so. On Linux,
packages can ensure that it happens by build-depending on
libnss-myhostname [linux-any], if necessary.

However, even with both of those, if the krb5 test suite (or protocol)
is resolving the local hostname with AF_INET (IPv4-only), and with either AI_ADDRCONFIG or NULL hints, then that will not yield any results on
an IPv6-only system for the reasons discussed in #952740 and related
bug reports.

A workaround is to resolve with AF_UNSPEC, which currently disregards AI_ADDRCONFIG, but that is, itself, arguably a bug (#854301).

If I'm understanding the krb5 issue correctly, the version of this in krb5
is more troublesome than the related issues seen in the GLib test suite, because the GLib test suite would be happy with localhost always being resolvable to 127.0.0.1 (as requested in #801362), but the krb5 test suite wants to be able to resolve the local host name as well (so
resolving #801362 would not be enough).

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Processing control commands:

retitle -1 krb5: FTBFS on IPv6-only buildds: "Can't resolve hostname" in dh_auto_test

Bug #1063648 [src:krb5] krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test
Changed Bug title to 'krb5: FTBFS on IPv6-only buildds: "Can't resolve hostname" in dh_auto_test' from 'krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test'.

tags -1 + ipv6

Bug #1063648 [src:krb5] krb5: FTBFS on IPv6-only buildds: "Can't resolve hostname" in dh_auto_test
Added tag(s) ipv6.

--
1063648: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1063648
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Simon" == Simon McVittie <smcv@debian.org> writes:

Simon> It might be relevant that according to #972151, arm-conova-03
Simon> (and perhaps other *-conova-* buildds?) is IPv6-only, with no
Simon> IPv4 addresses or routes other than loopback (not even via
Simon> NAT).

Simon> I believe there is consensus that we consider "localhost
Simon> resolves to 127.0.0.1" to be a reasonable thing to demand
Simon> from all buildds as part of the build-essential interface.

Simon> I am unsure whether there is consensus that "the result of
Simon> gethostname() resolves to some address of the local machine"
Simon> is also a reasonable thing to demand from all buildds as part
Simon> of build-essential: /etc/hosts typically makes this true, but
Simon> is not *guaranteed* to do so. On Linux, packages can ensure
Simon> that it happens by build-depending on libnss-myhostname
Simon> [linux-any], if necessary.

Simon> However, even with both of those, if the krb5 test suite (or
Simon> protocol) is resolving the local hostname with AF_INET
Simon> (IPv4-only), and with either AI_ADDRCONFIG or NULL hints,
Simon> then that will not yield any results on an IPv6-only system
Simon> for the reasons discussed in #952740 and related bug reports.

Krb5 is very v6-happy.
So, you're suggesting that I fix this by build-depending on
libnss-myhostname [linux-any] assuming tests are enabled?
If so, that's easy.
(I don't remember the order of build profiles and architecture
specifications in a build depends but can go look that up.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)