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
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.
...
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
Control: retitle -1 krb5: FTBFS on IPv6-only buildds: "Can't resolve hostname" in dh_auto_test
Control: tags -1 + ipv6
I also notice that the original Architecture: all build of 1.20.1-5 failed
on x86-conova-02, and succeeded when retried on x86-grnet-02. I think
this supports the theory that this is really "FTBFS on IPv6-only buildds".
smcv
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.
Dear maintainer, This bug is (apparently?) currently preventing the amd64 build of 1.20.1-6. I apologize if this is already understood (by the way, is there somewhere on [1] or elsewhere to see if the build is being retried?). I'm also assuming I am not authorized to "give back" and trigger another build attempt. So, I'm asking for someone to please "give back" the build to the buildds, so that we can spin the roulette wheel and hopefully get a buildd with an ipv4 address. Best, Antonio Russo [1] https://tracker.debian.org/pkg/krb5
Hi, [..] I have asked on #debian-buildd, and got the answer that all buildds have their own hostname in /etc/hosts. Thus this is not the source of the problem. It really seems like krb5 is not quite as ipv6-*only*-happy as one would like to think. That might or might not help to swipe the problem under a large enough carpet. I'll note that on buildds using sbuild with unshare backend, the setup will look slightly differently. More testing might be required. Chris
[..] Adam (adsb) points out that the test code in lib/rpc/unit-test/client.c [1] uses code that does not support IPv6(-only). I.e. gethostbyname for a name that has no IPv4 address will fail. Please try fixing this before adding workarounds? Chris [1] https://sources.debian.org/src/krb5/1.20.1-6/src/lib/rpc/unit-test/client.c/#L127
We believe that the bug you reported is fixed in the latest version of krb5, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1063648@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Sam Hartman <hartmans@debian.org> (supplier of updated krb5 package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org) Format: 1.8 Date: Wed, 03 Jul 2024 13:47:10 -0600 Source: krb5 Architecture: source Version: 1.21.3-2 Distribution: unstable Urgency: high Maintainer: Sam Hartman <hartmans@debian.org> Changed-By: Sam Hartman <hartmans@debian.org> Closes: 1063648 Changes: krb5 (1.21.3-2) unstable; urgency=high . * Enable lmdb database, Closes: ##1075723 * use libnss-myhostname to guarantee we have a hostname for builds, Closes: #1063648 Checksums-Sha1: 487e37c670a39ecb6dce069c8cb17015759fc39f 3381 krb5_1.21.3-2.dsc 2c039e5d6aa10bb3ded55628902c07b0f0e091cc 103440 krb5_1.21.3-2.debian.tar.xz e8bc37c336bbd4970434b6375ca6620013403a8d 5002 krb5_1.21.3-2_source.buildinfo Checksums-Sha256: 4a4ae0f6933b417c7ed93361b1544d78ce02a1a806ce1e42b6f8a22165ef4122 3381 krb5_1.21.3-2.dsc 00c30cc079ad592ead2a8c1d7c13a150af346bfb9484c3a271c8ac95f3b59ca9 103440 krb5_1.21.3-2.debian.tar.xz 02e6acd7e1c4c30a47cbf7ef37f11517175958efd05c7f0048afa81a7b0037d8 5002 krb5_1.21.3-2_source.buildinfo Files: 2a90e228cb1290e8fbf76913e542d15f 3381 net optional krb5_1.21.3-2.dsc 6ef7d409d672ea56073a391a3a4eda55 103440 net optional krb5_1.21.3-2.debian.tar.xz 49fe4af7a6267e61c66eacc58573cd14 5002 net optional krb5_1.21.3-2_source.buildinfo -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQSj2jRwbAdKzGY/4uAsbEw8qDeGdAUCZoWvnQAKCRAsbEw8qDeG dLb+AP9mzKMvAe5YaRZXv40U+MkRe7dqRHSx7S6CTAMtT9OOdgD+Kh9T6MnohRpp GBEnOuavk9YWIAjftSGaqkuEDU+/SgI= =qfuK -----END PGP SIGNATURE-----
Chris> Adam (adsb) points out that the test code in
Chris> lib/rpc/unit-test/client.c [1] uses code that does not
Chris> support IPv6(-only). I.e. gethostbyname for a name that has
Chris> no IPv4 address will fail.
So, are the builds going to unshare or not?
given that the code is apparently quite happy to work with a hostname
that points to ipv4 loopback and given that I already spent a good
chunk of time dealing with buildd churn this month, I don't have a lot
of love for dealing with more gratuitous environment changes entirely
outside my control.
I'm kind of tempted to take this to the TC and ask for clarity about
what is reasonable to expecte from buildds.
Hi, Yes, that's the plan, but there is still packages to fix before we can do that, so that will still take a few weeks or months. Your package is not able to cope with host names pointing to an IPv6 due the use of gethostbyname in the testsuite to do the name resolution. Switching to unshare buildds will only hide the problem. It has nothing to do with gratuitous environment change. Regards Aurelien
Hi Sam, * Sam Hartman <hartmans@debian.org> [2024-07-05 09:43]: I am not part of the buildd team but my understanding is that we are switching to unshare or something similar [1]. The problem is that this is not an easy switch. For trixie most packages build fine with unshare now, as tracked here: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=unshare;users=debian-wb-team@lists.debian.org But most of those bugs are still open for bookworm and for bullseye there are around 100 failing packages. I think policy wise the situation is clear that builds are not allowed to use the network, the problem is a) that the buildd with schroot do not restrict network access and leak the outside network configuration into the schroot and b) that packages builds, as krb5, behave differently depending on the network configuration. I see three ways out of this: - Live with the current situation where builds may fail depending on the buildd and use the self service to retrigger failed builds. - Special case these packages in wanne build. - Make the package builds immune to the different buildd configurations. Cheers Jochen [1]: See The discussion on devel@: https://lists.debian.org/debian-devel/2024/06/msg00257.html
Control: severity -1 important [..] [..] Given the package currently seems to build fine on the buildd network, I doubt the severity is still serious. Chris