Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test
Hi Sam, * Sam Hartman [2024-07-05 09:43]: "Chris" == Chris Hofstaedtler writes: 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? 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-t...@lists.debian.org But most of those bugs are still open for bookworm and for bullseye there are around 100 failing packages. 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. 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 signature.asc Description: PGP signature
Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test
Hi, On 2024-07-05 09:43, Sam Hartman wrote: > > "Chris" == Chris Hofstaedtler writes: > 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? 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. > 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. 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 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test
> "Chris" == Chris Hofstaedtler writes: 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. --Sam
Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test
On Mon, Jun 10, 2024 at 11:59:34AM +0200, Chris Hofstaedtler wrote: > Hi, > > On Mon, Feb 12, 2024 at 08:43:07AM -0700, Sam Hartman wrote: > > > "Simon" == Simon McVittie writes: [..] > > 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. > > It really seems like krb5 is not quite as ipv6-*only*-happy as one > would like to think. 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
Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test
Hi, On Mon, Feb 12, 2024 at 08:43:07AM -0700, Sam Hartman wrote: > > "Simon" == Simon McVittie writes: [..] > 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. 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. > 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. It really seems like krb5 is not quite as ipv6-*only*-happy as one would like to think. > 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. 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
Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test
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 OpenPGP_0xB01C53D5DED4A4EE.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test
> "Simon" == Simon McVittie 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.
Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test
Control: retitle -1 krb5: FTBFS on IPv6-only buildds: "Can't resolve hostname" in dh_auto_test Control: tags -1 + ipv6 On Sun, 11 Feb 2024 at 23:40:34 +, Simon McVittie wrote: > 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 gave back the failed builds and they succeeded on a different buildd. 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
Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test
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
Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test
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
Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test
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 '/<>/build/lib/rpc' making check in lib/rpc/unit-test... make[5]: Entering directory '/<>/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: /<>/build/lib/rpc/unit-test/testlog Or re-run this test script with the -v flag: cd /<>/build/lib/rpc/unit-test PYTHONPATH=/<>/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 '/<>/build/lib/rpc/unit-test' make[4]: *** [Makefile:1595: check-recurse] Error 1 make[4]: Leaving directory '/<>/build/lib/rpc' make[3]: *** [Makefile:973: check-recurse] Error 1 make[3]: Leaving directory '/<>/build/lib' make[2]: *** [Makefile:1521: check-recurse] Error 1 make[2]: Leaving directory '/<>/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 '/<>' make: *** [debian/rules:153: build-arch] Error 2 dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2 Thanks! cheers, josch
