On 2025-03-15 12:03, Matthias Klose wrote: > On 15.03.25 11:41, Aurelien Jarno wrote: > > On 2025-03-15 11:08, Matthias Klose wrote: > > > On 15.03.25 10:55, Aurelien Jarno wrote: > > > > 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. > > > > > > so instead of fixing the issue, threatening to remove the cross compilers > > > from the distro. Great! Users are our priority! > > > > I am not threatening to remove them. I am telling that we will have to > > find alternative way to build the cross toolchain-base packages. The > > current approach of just cross-building the glibc and later converting > > the resulting packages just imposes a lot of constraints. Even minor > > change to the glibc packaging can lead to breakages (and complaints), so > > I am avoiding too many changes, even if it shows not enough. This in > > turns removed me the courage to look at bigger packaging changes like > > locales-all or gconv libraries splitting. > > neither locales-all or gconv are needed by the c-t-b packages. So yes, > please go ahead with that.
Thanks for the approval, I am sure it'll break c-t-b, but that's not my problem anymore. > What I'm really missing here is any commitment testing such changes as > adding the conflicts. Things can break, and I unfortunately also got a lot > of untested patches even breaking GCC native builds. And for that particular > change, I don't think this is appropriate six weeks before a freeze. Retrospectively it's always easy to say this is not appropriate. But it's always difficult to spot which changesat needs to be tested. And no, testing the cross-toolchain-base + gcc-X-cross for each upload is way too heavy and not something you can ask. > > > This is now the another time that patches from Helmut for > > > out-of-the-archive > > > cross builds are breaking the in-archive cross compilers. > > > > You are completely mixing things. This has nothing to do with > > out-of-the-archive cross build. Those are conflicts that users can > > encounter when installing libc-dev biarch packages on a multiarch > > system. And as you say it well: Users are our priority! > > How many users are affected by this? If users are confused by multilib > packages, then let's remove them in trixie. No need to have them anymore in > forky, I assume. People can use the cross compilers instead. I am all for removing the biarch packages, especially the ones built by c-t-b, I never understood their use case, and that will have prevented this bug to happen. But each time I talked about disabling multilib in gcc, you told me you don't want to diverge from upstream. Has your position changed since then? > I'm not mixing things. Yes you do. You are talking about out-of-the-archive cross builds, while the multiarch file conflicts were found as part of the usrmerge developments. > You have various scenarios how the different > -source packages in the distro are used. So either stop providing these, and > replace these by copies, or find a way to collaborate to keep these -source > packages usable. Stop providing glibc-source is just threatening to remove the cross compilers from the distro, and that's what you complained about just above... > I don't have difficulties to do that for the binutils and > the GCC source packages and incorporating packaging issues to let these > packages getting used, so I'm wondering why that isn't possible for the > glibc source package. Again your are mixing things. All the binutils-* source packages using binutils source (except binutils-mipsen) do not use the debian packaging, just the sources and the patches for some of them, and then call configure + make, etc. This is exactly what I initially proposed for forky in this bug report, and that caused you to accuse me of "threatening to remove the cross compilers". In addition, those are not the best example of collaboration. For instance, the upload of binutils 2.43.50.20241126-1 to unstable caused many of the packages using binutils-* to FTBFS (see for instance #1089190, #1089199, #1090194, #1090195). Nicolas Boulenguez promptly proposed you a patch in #1090761, but it has been ignored in the two subsequent uploads, until I pinged you on IRC on 2025-01-01. In the meantime packages implemented various workaround to prevent autoremoval, some of them had to be reverted... Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
