Hi, Quoting Graham Inggs (2024-12-04 10:42:17) > Control: affects -1 + src:glibc > > This regression [1] currently blocks migration of glibc/2.40-4. > > [1] https://ci.debian.net/packages/s/sbuild/testing/amd64/
I have now finally gotten to the bottom of this. Steps to reproduce: mmdebstrap --variant=apt --architecture=amd64,arm64 --setup-hook='printf "Package: *\nPin: release unstable\nPin-Priority: 100\n\nPackage: src:glibc\nPin: release unstable\nPin-Priority: 995\n" > "$1"/etc/apt/preferences.d/autopkgtest-unstable.pref' testing /dev/null "deb http://deb.debian.org/debian testing main" "deb http://deb.debian.org/debian unstable main" --customize-hook='chroot "$1" apt-get satisfy "build-essential:amd64, fakeroot:amd64, crossbuild-essential-arm64:amd64, libc-dev:arm64, libstdc++-dev:arm64"' will result in the same error as in the autopkgtest log: The following packages have unmet dependencies: satisfy:command-line : Depends: libc-dev:arm64 Depends: libstdc++-dev:arm64 Figuring out what this means is a bit tricky. The sbuild autopkgtest log has dose3 results in it, but those are quite useless because dose3 ignores the apt pinning values and will happily mix glibc packages from unstable and testing. The sbuild autopkgtest should be using --bd-uninstallable-explainer=apt instead like so: https://salsa.debian.org/debian/sbuild/-/merge_requests/108 But a bit more work is needed to also pass the apt debug options to the internal resolver: -oDebug::pkgProblemResolver=true -oDebug::pkgDepCache::Marker=1 -oDebug::pkgDepCache::AutoInstall=1 With those I went to the apt developers who thought that this was actually due to a bug in apt and could be fixed by https://paste.debian.net/hidden/21b0b1e6/ This theory was further supported by dose3 finding a solution even after forcing it to respect the desired apt pinning: https://paste.debian.net/hidden/db3713ac/ Why did the last bit work? Because it turns out apt pinning works different from what I thought it does. In the autopkgtest log, one can see that the following apt preferences file is written out: Package: src:glibc Pin: release unstable Pin-Priority: 995 But that will only pin binary packages built from src:glibc for the *native* architecture. To let this pin binary packages built from src:glibc for all architectures, one has to write this: Package: src:glibc:any Pin: release unstable Pin-Priority: 995 This is made even more comical since I should've known that this is how it works because I contributed the documentation to apt describing this feature two years ago: https://salsa.debian.org/apt-team/apt/-/commit/8d15f117b87a3907e31d3c7e380b67fd85c013df So we now know why apt is unable to find a solution. We have a few options now: 1. disable the cross-build test in sbuild 2. change the pinned package from src:glibc to src:glibc:any 2.1. let the sbuild autopkgtest do this adjustment 2.2. let autopkgtest do this adjustment 2.2. let britney2 (or the test requester) do this adjustment 2.3. ??? 3. wait for Helmut's solution to #815172 and then remove libc-dev:arm64 and libstdc++-dev:arm64 from the sbuild-dummy-depends In #debci, elbrus pointed me to this MR which is a bit adjacent to this issue https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/216 In contrast to what this MR tries to do, this is for a native autopkgtest for which we also want foreign architecture packages. That MR only adds :any for the foreign case but the sbuild autopkgtest would need something like this unconditionally: pkglist = ",".join([p + ":any" for p in pkglist.split(",")]) Though that line is probably also not 100% correct because it would add :any even to entries which already are architecture qualified. This cross-build autopkgtest was announced to the release team here: https://lists.debian.org/msgid-search/173156754864.3649146.10791472176546387428@localhost I'm putting them in the loop to get some feedback of how they prefer to resolve this situation. I verified that the :any pinning solution works with the mmdebstrap command at the top of my mail. I think it's now a matter of deciding who should be responsible for adding it. In my mind, there should (famous last words) not be a downside to unconditionally adding it because the existing autopkgtests are all native-architecture only (as evidenced by this issue not having come up before). What do you think? Thanks! cheers, josch
signature.asc
Description: signature
