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.
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.
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!
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.
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.
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.
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'm not mixing things.
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.
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.
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...
On 2025-03-15 12:03, Matthias Klose wrote:
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?
This is exactly thing I am asking Helmut about. Then ok, I'll handle that more strict. My first priority are the native packages, then the cross packages in the archive. In the past I've seen unfortunately patches which break either of these, and where claims were made, that these were tested, which in the end, were not tested.
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?
yes, once you have a solution to depend on foreign architectures, for both release and ports architectures. Are you willing to work on this? No, I'm
not fine to drop support before there is a replacement.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 483 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 137:32:42 |
| Calls: | 9,586 |
| Files: | 13,673 |
| Messages: | 6,147,491 |