Hi Sam, * Sam Hartman <hartm...@debian.org> [2024-07-05 09:43]:
"Chris" == Chris Hofstaedtler <z...@debian.org> 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.orgBut 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
