Package: sbuild Version: 0.87.1 Severity: important Quoting Helmut Grohne (2024-12-01 21:03:00) > > However, I am unable to use sbuild: > > > > gbp buildpackage --git-builder=sbuild --arch-any --no-arch-all > > --no-clean-source --dist=bookworm --host=arm64 > > > > Ultimately, this runs: > > > > sbuild --arch-any --no-arch-all --no-clean-source --dist=bookworm > > --host=arm64 > > > > But it fails with: > > > > /usr/lib/apt/solvers/apt: /lib/x86_64-linux-gnu/libstdc++.so.6: version > > `GLIBCXX_3.4.32' not found (required by /usr/lib/apt/solvers/apt) > > Execute external solver... > > Some packages could not be installed. This may mean that you have > > requested an impossible situation or if you are using the unstable > > distribution that some required packages have not yet been created > > or been moved out of Incoming. > > The following information may help to resolve the situation: > > > > The following packages have unmet dependencies: > > sbuild-build-depends-main-dummy:arm64 : Depends: debhelper-compat:arm64 (= > > 12) > > Depends: libpcre2-dev:arm64 but it > > is not going to be installed > > Depends: libssl-dev:arm64 but it is > > not going to be installed > > Depends: liblua5.4-dev:arm64 but it > > is not going to be installed > > Depends: libsystemd-dev:arm64 but > > it is not going to be installed > > Depends: libjemalloc-dev:arm64 but > > it is not going to be installed > > Depends: python3-sphinx:amd64 > > Depends: > > libopentracing-c-wrapper-dev:arm64 but it is not going to be installed > > Depends: pkgconf:arm64 but it is > > not going to be installed > > Depends: systemd-dev:arm64 but it > > is not installable > > Depends: fakeroot:amd64 > > Depends: > > crossbuild-essential-arm64:amd64 > > Depends: libc-dev:arm64 > > Depends: libstdc++-dev:arm64 > > That's a funky issue. Thank's for not giving and reporting it instead. > It can actually be reproduced in a quite simplified setting. What you > need is an unstable installation with sbuild and a bookworm chroot. Then > go (Johannes needs to use amd64 instead): > > sbuild -d bookworm --host=arm64 hostname > > I tend to use hostname as the most minimal dummy package as it builds > really quickly and if building it fails, something tends to be seriously > broken. When running it, you can see the very same symptom: > > /usr/lib/apt/solvers/apt: /lib/x86_64-linux-gnu/libstdc++.so.6: version > `GLIBCXX_3.4.32' not found (required by /usr/lib/apt/solvers/apt) > > If instead, -d sid is used or --host=arm64 is dropped, the build readily > succeeds. > > What is happening here is that we strangely mix the apt installations of > bookworm and unstable. I suspect that we run the outer installation's > solver but somehow pick up bookworm's libstdc++.so.6 thus lacking > required symbols. I do not yet understand why this happens. > > Johannes/Jochen: > * Do you agree that this is a bug in sbuild? > * If yes, do you create a bug report or should I? > * Do you see what is going on here?
it's a bug in apt that I introduced in 2022 and it's strangle that it took this long before it was found: https://salsa.debian.org/debian/sbuild/-/commit/e0cb27671efef0d0c177cbe094dbf6ed1bc8dc68 Copying /usr/lib/apt/solvers/apt from outside the chroot into the chroot is a bad idea. We need to find another solution to make the sbuild-cross-resolver work. Thank you for reporting this problem! Bug is now filed. :) cheers, josch
signature.asc
Description: signature
