On 2025-03-15 07:01, Helmut Grohne wrote: > Control: reassign -1 libc6-dev-i386 > Control: affects -1 = src:gcc-14-cross > Control: tags -1 + ftbfs > > On Sat, Mar 15, 2025 at 05:45:15AM +0100, Matthias Klose wrote: > > sudo apt build-dep gcc-14-cross > > > > 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: > > > > Unsatisfied dependencies: > > builddeps:gcc-14-cross : Depends: libc6-dev-amd64-cross (>= 2.37) but it is > > not installable > > libc6-dev-i386-amd64-cross : Depends: libc6-dev-amd64-cross (= > > 2.40-4cross1) but it is not installable > > libc6-dev-x32-amd64-cross : Depends: libc6-dev-amd64-cross (= 2.40-4cross1) > > but it is not installable > > Error: Unable to correct problems, you have held broken packages. > > Matthias and me discussed the matter on irc. The bug introducing the > problem was #1092278 asking for libc6-dev-* to conflict with one > another. Now the transformed libc6-dev-*-*-cross packages move e.g. > /usr/lib32 to /usr/<triplet>/lib32 thereby resolving the underyling > conflict in the transformed packages. Moreover, since the conflicts lack > architecture qualifiers we get funky ones such as > libc6-dev-amd64-amd64-cross that don't exist anywhere. Qualifying them > is not a solution, because gcc-14-cross really wants both > libc6-dev-x32-i386-cross and libc6-dev-x32-amd64-cross at the same time > and while their package contents are coinstallable, the underlying glibc > packages libc6-dev-x32:i386 and libc6-dev-x32:amd64 really are not > coinstallable. It is the sysroot transformation that renders them > coinstallable. > > Our discussion arrived at three ways to move forward from here and we > did not reach any agreement here. > > 1. glibc should conditionally emit these Conflicts. When a particular > environment variable is set by c-t-b, their emission is suppressed. > > 2. Someone (me?) develops a c-t-b patch that discards the conflicts in > the repacking step as that also is the step that fixes > coinstallability. > > 3. We revert those conflicts in trixie and retry with more time in > forky. > > Matthias prefers 1. I object to 1 on reproducibility grounds and > favour 3 given the state of discussion.
cross-toolchain-base has been an increasing burden in packaging glibc, imposing too many development constraints and limiting changes that can be made. Therefore my plan is to stop shipping the debian/ directory in the glibc-source package starting with forky. cross-toolchain-base we'll have to build the glibc from sources in its own way. The toolchain being already frozen (since today), any change needs a pre-approval, so I would rather go with option 1 to make the approval easier. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
