Hi Vincent, On Sun, Dec 01, 2024 at 07:12:26PM +0100, Vincent Bernat wrote: > On 2024-09-22 20:18, Helmut Grohne wrote: > > > > The following packages have unmet dependencies: > > > builddeps:/build/haproxy_3.0.5-2.dsc:arm64 : Depends: > > > python3-sphinx:amd64 > > > Depends: python3:arm64 but > > > it > > > is not going to be installed > > > Depends: python3-mako:arm64 > > > but it is not installable > > > > I think this is what the first paragraph of my initial submission says. > > I think pbuilder installs Build-Depends-Indep even when only building arch > any. I have added :native for Build-Depends-Indep too and it works fine with > pbuilder.
I am unable to reproduce this. The apt resolver clearly has support for skipping Build-Depends-Indep (https://sources.debian.org/src/pbuilder/0.231.1/pbuilder-satisfydepends-apt/#L82). Are you using the gdebi resolver? This really should work in pbuilder. Please avoid :native as much as possible. Whever any of those dependencies gains M-A:foreign, your haproxy package will become bd-uninstallable natively (i.e. rc-buggy) until you drop :native. As more :native annotations are added, adding M-A:foreign becomes disruptive elsewhere. We should rather ensure that ignoring B-D-I works reliably in common build environments. > gbp buildpackage -nc -sa --git-dist=bookworm-backports > --git-pbuilder-options="--host-arch arm64 --binary-arch" I note that I (as in me personally) am not supporting cross building in suites other than unstable, because the task is already too big there. There may be more issues in bookworm that have been fixed in unstable since its release. > 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? Helmut
