Wiki - https://fedoraproject.org/wiki/Changes/Drop_i686_support Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-drop-i686-support...
This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary ==
Fedora package repositories for the x86_64 architecture no longer include libraries for compatibility with 32-bit applications ("multilib"), and packages are no longer built for the i686 architecture.
== Owner ==
* Name: [[User:Decathorpe| Fabio Valentini]], [[User:Fale|Fale]], [[User:Kevin|Kevin Fenzi]] * Email: decathorpe (at) gmail (dot) com, mail (at) fale (dot) io, kevin (at) scrye (dot) com
== Detailed Description ==
Fedora stopped providing [https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels kernel packages, installer images] and stopped publishing [https://fedoraproject.org/wiki/Changes/Noi686Repositories i686 package repositories] with Fedora 31. However, packages were by default still built for the i686 architecture, since they were required for running 32-bit applications on x86_64 hosts ("multilib").
Since Fedora 37, leaf packages (i.e. packages that are not depended on by other packages) can simply [https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval stop building for i686] without any reason, which has allowed package maintainers to focus their work on architectures where packages are actually shipped to users.
This Change Proposal implements the next two (and last) steps:
* Packages built for the i686 architecture are no longer included in x86_64 repositories (dropping "multilib" support, i.e. support for running 32-bit userspace on a 64-bit host). * Packages are no longer built for the i686 architecture.
This is intentionally planned as a two-step process - the first step (no longer including 32-bit libraries in the x86_64 repositories) should be relatively easy to revert (if needed). The second step is basically irreversible, since reversing it would require to partially re-bootstrap the architecture.
Some packages will require changes to adapt for the removal of 32-bit libraries from the x86_64 package repositories - notably, `wine` will need to be built in the [https://src.fedoraproject.org/rpms/wine/pull-request/19 "new WoW64" configuration], which allows running 32-bit Windows applications on top of 64-bit-only host systems.
It is planned to implement the first step as early as possible in the development cycle, but before the mass rebuild at the latest. This provides a transition period of at least four weeks to catch potential issues *before* the potentially irreversible second step is implemented (before the beta freeze).
When this Change is successfully implemented, a mechanism will be provided to remove any installed i686 packages on upgrade to avoid leaving behind packages that will no longer be updated, maintained, or which might cause upgrade issues in the future.
== Feedback ==
N/Y
== Benefit to Fedora ==
By dropping completely the i686 architecture, Fedora will decrease the burden on package maintainers, release engineering, infrastructure, and users.
=== Package Maintainers ===
Building and maintaining packages for i686 (and 32-bit architectures in general, but i686 is the last 32-bit architecture - partially - supported by Fedora) has been requiring more and more effort.
Many projects have already been officially dropping support for building and / or running on 32-bit architectures, requiring either adding back support for this architecture downstream in Fedora, or requiring packaging changes in a significant number of packages to adapt to this dropped support.
By dropping support for the i686 architecture entirely, this additional - and growing - maintenance burden is eliminated.
=== Release engineering ===
The process for including 32-bit libraries in the x86_64 repositories is based on brittle heuristics and rules, which can be removed when this change is implemented - simplifying the process for creating x86_64 package repositories.
=== Infrastructure ===
No longer building packages for the i686 architecture frees up resources on x86 build machines that will instead be available to speed up x86_64 package builds.
=== Users ===
By dropping ~10000 32-bit packages from the x86_64 repositories, repository metadata will get smaller, which should speed up both metadata downloads and any dnf operations that involve dependency resolution.
== Scope ==
* Proposal owners: ** Prepare compose configuration changes to drop multilib support from x86_64 repositories. ** Prepare builder configuration changes to drop the i686 architecture from the f44 build target.
* Other developers: ** Adapt packages for the removal of 32-bit libraries from the x86_64 package repositories. ** Potentially simplify `ExcludeArch` / `ExclusiveArch` usage and / or `%__isa_bits` conditionals in spec files.
* Release engineering: [https://pagure.io/releng/issue/12782 releng#12782] ** Review and deploy compose configuration changes. ** Review and deploy builder configuration changes.
* Policies and guidelines: ** Drop mentions of i686 architecture support from documentation (Packaging Guidelines, ...).
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: :shrug:
== Upgrade/compatibility impact ==
Any 32-bit packages installed on x86_64 systems should get removed on upgrade, and will no longer be available from package repositories. Any third-party software that depends on these 32-bit libraries will no longer be installable on Fedora. Wine prefixes created on older versions of Fedora might need to be recreated.
== How To Test ==
Upgrading to the Fedora version that implements this change should remove any 32-bit packages from x86_64 systems, and no packages for the i686 architecture should be available from the x86_64 package repositories.
Installing and using Wine to run Windows applications should continue to work, but Wine prefixes created on older versions of Fedora and / or with older versions of Wine might need to be re-created.
== User Experience ==
* Package repositories no longer include i686 packages for compatibility with 32-bit applications. Third-party RPM packages that do not provide 64-bit versions for x86 will no longer be installable. * Package repositories no longer include i686 packages for compatibility with 32-bit applications. Package management operations (GNOME Software, Discover, DNF, etc.) should be faster, including metadata downloads and dependency resolution.
== Dependencies ==
* wine: build package with "new WoW64" mode enabled * steam: adapt or drop RPM package from default third-party repositories
== Contingency Plan ==
* Contingency mechanism: ** If only step one has been implemented, Release Engineering needs to revert the compose configuration changes to restore "multilib" support (i.e. include 32-bit compatibility libraires in x86_64 repositories again). ** If both step one and two have already been implemented, reverting the changes would require re-bostrapping the architecture, which would be difficult to justify.
* Contingency deadline: Beta Freeze
* Blocks release? Yes (Change is either fully implemented or reverted)
== Documentation ==
TODO
== Release Notes ==
TODO
On Tue, Jun 24, 2025 at 12:07 PM Aoife Moloney via devel-announce devel-announce@lists.fedoraproject.org wrote:
Wiki - https://fedoraproject.org/wiki/Changes/Drop_i686_support Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-drop-i686-support...
Note that this was mis-tagged (both here and on discussion.fp.o) - the Change is planned for F44 (or later), *not* for F43 already.
Fabio
Apologies, for clarification this is an F44 change proposal.
On Tue, Jun 24, 2025 at 11:02:56AM +0100, Aoife Moloney via devel-announce wrote:
== Detailed Description ==
snip
This Change Proposal implements the next two (and last) steps:
- Packages built for the i686 architecture are no longer included in
x86_64 repositories (dropping "multilib" support, i.e. support for running 32-bit userspace on a 64-bit host).
- Packages are no longer built for the i686 architecture.
This is intentionally planned as a two-step process - the first step (no longer including 32-bit libraries in the x86_64 repositories) should be relatively easy to revert (if needed). The second step is basically irreversible, since reversing it would require to partially re-bootstrap the architecture.
Some packages will require changes to adapt for the removal of 32-bit libraries from the x86_64 package repositories - notably, `wine` will need to be built in the [https://src.fedoraproject.org/rpms/wine/pull-request/19 "new WoW64" configuration], which allows running 32-bit Windows applications on top of 64-bit-only host systems.
It is planned to implement the first step as early as possible in the development cycle, but before the mass rebuild at the latest. This provides a transition period of at least four weeks to catch potential issues *before* the potentially irreversible second step is implemented (before the beta freeze).
What kind of "potential issues" are liable to justify reversing the decision to drop i386 ?
Assuming we confirm that the Wine change is just a formality at before approving this change, that would address the big blocker in Fedora.
What else would be high profile enough *in Fedora* to merit a blocker ? IMHO external apps should not influence our decision, and must adapt to what the distro decides to provide.
The QEMU release coming in Dec this year is expected to be dropping all support for building on 32-bit hosts, and the ripple effect on packages across Fedora is non-negligible.
We're looking at a choice of updating Exclusive/ExcludeArch across many packages (which I'm dieing to avoid the busy work for), or not doing any further updates of QEMU in rawhide until i686 is turned off in koji which is also undesirable as it delays feature integration & testnig.
IOW, from a (somewhat selfish) POV as a maintainer of QEMU, I'd prefer us to go straight to turning off i686 in koji when the F44 dev cycle opens.
=== Package Maintainers ===
Building and maintaining packages for i686 (and 32-bit architectures in general, but i686 is the last 32-bit architecture - partially - supported by Fedora) has been requiring more and more effort.
Many projects have already been officially dropping support for building and / or running on 32-bit architectures, requiring either adding back support for this architecture downstream in Fedora, or requiring packaging changes in a significant number of packages to adapt to this dropped support.
Yep, this. Fedora's policy of only turning off i386 in leaf packages has left us in a painful situation as upstream projects in non-leaf context increasingly decide that 32-bit isn't something they're willing to continue to support.
== Dependencies ==
- wine: build package with "new WoW64" mode enabled
- steam: adapt or drop RPM package from default third-party repositories
IMHO whatever happens with steam should not be our concern.
If steam happens to work on Fedora that's nice, but IMHO its needs don't align with the Fedora project "four foundations" or mission. Thus it shouldn't have significant influence the decision to drop i386, nor be the kind of thing that would justify a reverse in the change inbetween disabling the compose for i686 and turning off i686 in koji
With regards, Daniel
On Tue, Jun 24, 2025 at 1:08 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Tue, Jun 24, 2025 at 11:02:56AM +0100, Aoife Moloney via devel-announce wrote:
== Dependencies ==
- steam: adapt or drop RPM package from default third-party repositories
IMHO whatever happens with steam should not be our concern.
If steam happens to work on Fedora that's nice, but IMHO its needs don't align with the Fedora project "four foundations" or mission. Thus it shouldn't have significant influence the decision to drop i386, nor be the kind of thing that would justify a reverse in the change inbetween disabling the compose for i686 and turning off i686 in koji
Fedora values ethical choices over easy ones. But that does not mean we shouldn't care and say "that's not our problem".
It is our problem. If we leave a significant portion of users without an upgrade path for their favourite software without a good justification, we will force them to leave and they will never come back.
And "we don't care" is not a good justification for me. I'd love to see going to the Steam upstream, and discussing what they could do for us to keep our player base alive, as a part of this proposal.
We might not succeed, but "Valve doesn't care" is still way better justification than "We don't care".
--
Michal Schorm Software Engineer Databases Team Red Hat
--
On Tue, Jun 24, 2025 at 1:08 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Tue, Jun 24, 2025 at 11:02:56AM +0100, Aoife Moloney via devel-announce wrote:
== Detailed Description ==
snip
This Change Proposal implements the next two (and last) steps:
- Packages built for the i686 architecture are no longer included in
x86_64 repositories (dropping "multilib" support, i.e. support for running 32-bit userspace on a 64-bit host).
- Packages are no longer built for the i686 architecture.
This is intentionally planned as a two-step process - the first step (no longer including 32-bit libraries in the x86_64 repositories) should be relatively easy to revert (if needed). The second step is basically irreversible, since reversing it would require to partially re-bootstrap the architecture.
Some packages will require changes to adapt for the removal of 32-bit libraries from the x86_64 package repositories - notably, `wine` will need to be built in the [https://src.fedoraproject.org/rpms/wine/pull-request/19 "new WoW64" configuration], which allows running 32-bit Windows applications on top of 64-bit-only host systems.
It is planned to implement the first step as early as possible in the development cycle, but before the mass rebuild at the latest. This provides a transition period of at least four weeks to catch potential issues *before* the potentially irreversible second step is implemented (before the beta freeze).
What kind of "potential issues" are liable to justify reversing the decision to drop i386 ?
Assuming we confirm that the Wine change is just a formality at before approving this change, that would address the big blocker in Fedora.
What else would be high profile enough *in Fedora* to merit a blocker ? IMHO external apps should not influence our decision, and must adapt to what the distro decides to provide.
The QEMU release coming in Dec this year is expected to be dropping all support for building on 32-bit hosts, and the ripple effect on packages across Fedora is non-negligible.
We're looking at a choice of updating Exclusive/ExcludeArch across many packages (which I'm dieing to avoid the busy work for), or not doing any further updates of QEMU in rawhide until i686 is turned off in koji which is also undesirable as it delays feature integration & testnig.
IOW, from a (somewhat selfish) POV as a maintainer of QEMU, I'd prefer us to go straight to turning off i686 in koji when the F44 dev cycle opens.
=== Package Maintainers ===
Building and maintaining packages for i686 (and 32-bit architectures in general, but i686 is the last 32-bit architecture - partially - supported by Fedora) has been requiring more and more effort.
Many projects have already been officially dropping support for building and / or running on 32-bit architectures, requiring either adding back support for this architecture downstream in Fedora, or requiring packaging changes in a significant number of packages to adapt to this dropped support.
Yep, this. Fedora's policy of only turning off i386 in leaf packages has left us in a painful situation as upstream projects in non-leaf context increasingly decide that 32-bit isn't something they're willing to continue to support.
== Dependencies ==
- wine: build package with "new WoW64" mode enabled
- steam: adapt or drop RPM package from default third-party repositories
IMHO whatever happens with steam should not be our concern.
If steam happens to work on Fedora that's nice, but IMHO its needs don't align with the Fedora project "four foundations" or mission. Thus it shouldn't have significant influence the decision to drop i386, nor be the kind of thing that would justify a reverse in the change inbetween disabling the compose for i686 and turning off i686 in koji
With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, 24 Jun 2025 at 07:26, Michal Schorm mschorm@redhat.com wrote:
On Tue, Jun 24, 2025 at 1:08 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Tue, Jun 24, 2025 at 11:02:56AM +0100, Aoife Moloney via
devel-announce wrote:
== Dependencies ==
- steam: adapt or drop RPM package from default third-party
repositories
IMHO whatever happens with steam should not be our concern.
If steam happens to work on Fedora that's nice, but IMHO its needs don't align with the Fedora project "four foundations" or mission. Thus it shouldn't have significant influence the decision to drop i386, nor be the kind of thing that would justify a reverse in the change inbetween disabling the compose for i686 and turning off i686 in koji
Fedora values ethical choices over easy ones. But that does not mean we shouldn't care and say "that's not our problem".
It is our problem. If we leave a significant portion of users without an upgrade path for
The key problem here is "significant portion of users". We have no idea how many Fedora users actually use steam (it could just be the N people on this list, it could be 99% of the Fedora desktop users). Without that we are constantly fighting over 'stop everything unless this gets fixed' when very little of it is outside of our control.
To me the 'best' fix would be a SIG focused on an i686 micro-OS which delivers the packages in a format which can be easily used by Steam. This means the people working on it are using Steam, and know what needs to be tested to make Steam work. Anything else is always going to be a guessing game of 'does this actually block X' and maintainer fatigue of dealing with things they don't know about.
their favourite software without a good justification, we will force them to leave and they will never come back.
From what I can tell, the Valve exit plan for most Linux Steam users is a "Steam Console". That is where they can control both the quality and the delivery of the products. Outside of that, there are always up to M-factorial different factors on individual laptops, desktops and user-installed other applications to deal with.
And "we don't care" is not a good justification for me. I'd love to see going to the Steam upstream, and discussing what they could do for us to keep our player base alive, as a part of this proposal.
We might not succeed, but "Valve doesn't care" is still way better justification than "We don't care".
--
Michal Schorm Software Engineer Databases Team Red Hat
--
On Tue, Jun 24, 2025 at 1:08 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Tue, Jun 24, 2025 at 11:02:56AM +0100, Aoife Moloney via
devel-announce wrote:
== Detailed Description ==
snip
This Change Proposal implements the next two (and last) steps:
- Packages built for the i686 architecture are no longer included in
x86_64 repositories (dropping "multilib" support, i.e. support for running 32-bit userspace on a 64-bit host).
- Packages are no longer built for the i686 architecture.
This is intentionally planned as a two-step process - the first step (no longer including 32-bit libraries in the x86_64 repositories) should be relatively easy to revert (if needed). The second step is basically irreversible, since reversing it would require to partially re-bootstrap the architecture.
Some packages will require changes to adapt for the removal of 32-bit libraries from the x86_64 package repositories - notably, `wine` will need to be built in the [https://src.fedoraproject.org/rpms/wine/pull-request/19 "new WoW64" configuration], which allows running 32-bit Windows applications on top of 64-bit-only host systems.
It is planned to implement the first step as early as possible in the development cycle, but before the mass rebuild at the latest. This provides a transition period of at least four weeks to catch potential issues *before* the potentially irreversible second step is implemented (before the beta freeze).
What kind of "potential issues" are liable to justify reversing the decision to drop i386 ?
Assuming we confirm that the Wine change is just a formality at before approving this change, that would address the big blocker in Fedora.
What else would be high profile enough *in Fedora* to merit a blocker ? IMHO external apps should not influence our decision, and must adapt to what the distro decides to provide.
The QEMU release coming in Dec this year is expected to be dropping all support for building on 32-bit hosts, and the ripple effect on packages across Fedora is non-negligible.
We're looking at a choice of updating Exclusive/ExcludeArch across many packages (which I'm dieing to avoid the busy work for), or not doing any further updates of QEMU in rawhide until i686 is turned off in koji which is also undesirable as it delays feature integration & testnig.
IOW, from a (somewhat selfish) POV as a maintainer of QEMU, I'd prefer us to go straight to turning off i686 in koji when the F44 dev cycle opens.
=== Package Maintainers ===
Building and maintaining packages for i686 (and 32-bit architectures in general, but i686 is the last 32-bit architecture - partially - supported by Fedora) has been requiring more and more effort.
Many projects have already been officially dropping support for building and / or running on 32-bit architectures, requiring either adding back support for this architecture downstream in Fedora, or requiring packaging changes in a significant number of packages to adapt to this dropped support.
Yep, this. Fedora's policy of only turning off i386 in leaf packages has left us in a painful situation as upstream projects in non-leaf context increasingly decide that 32-bit isn't something they're willing to continue to support.
== Dependencies ==
- wine: build package with "new WoW64" mode enabled
- steam: adapt or drop RPM package from default third-party
repositories
IMHO whatever happens with steam should not be our concern.
If steam happens to work on Fedora that's nice, but IMHO its needs don't align with the Fedora project "four foundations" or mission. Thus it shouldn't have significant influence the decision to drop i386, nor be the kind of thing that would justify a reverse in the change inbetween disabling the compose for i686 and turning off i686 in koji
With regards, Daniel -- |: https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-
https://fstop138.berrange.com :|
|: https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
To me the 'best' fix would be a SIG focused on an i686 micro-OS which delivers the packages in a format which can be easily used by Steam. This means the people working on it are using Steam, and know what needs to be tested to make Steam work. Anything else is always going to be a guessing game of 'does this actually block X' and maintainer fatigue of dealing with things they don't know about.
An i686 microOS sig is a good idea. This may also give a good idea how to manage hardware diversity. People with older computers that were running 32 bit Windows 10 may also have another option for a supported operating system.
On Tue, 24 Jun 2025 at 08:16, Benson Muite benson_muite@emailplus.org wrote:
To me the 'best' fix would be a SIG focused on an i686 micro-OS which delivers the packages in a format which can be easily used by Steam. This means the people working on it are using Steam, and know what needs to be tested to make Steam work. Anything else is always going to be a guessing game of 'does this actually block X' and maintainer fatigue of dealing
with
things they don't know about.
An i686 microOS sig is a good idea. This may also give a good idea how to manage hardware diversity. People with older computers that were running 32 bit Windows 10 may also have another option for a supported operating system.
I realized I wasn't clear on what I meant by a microOS. This would be only the libraries and tools needed to run a specific utility on a 64 bit kernel versus a general operating system which runs on 32bit. I helped sponsor the 32 bit kernel SIG a couple of years ago in Fedora. It fell apart as there were too many different things needed and too few people who could spend more than a small amount of time on anything. Any sort of SIG needs to have motivated and knowledgeable people who can focus on a problem for a long time. If SIG members are focusing on something they use regularly (Steam?) and know how to debug what problems are being seen in that tool.. they can maintain it. If they aren't then it will collapse in a release or two.
V Tue, Jun 24, 2025 at 08:25:09AM -0400, Stephen Smoogen napsal(a):
I realized I wasn't clear on what I meant by a microOS. This would be only the libraries and tools needed to run a specific utility on a 64 bit kernel
Which itself is not a small project because the libraries and tools need to be compiled with a compiler and built with a build system.
Would Koji have to nurse i686 architucture and builders for it, or would a crosscompilation on x86_64 producing x86_64 RPM packages installing i686 ELF files acceptable? Because the first, native approach would also involve supporting Koji, Python, DNF, OpenSSH etc. in their native form.
-- Petr
On Tue, 24 Jun 2025 at 09:09, Petr Pisar ppisar@redhat.com wrote:
V Tue, Jun 24, 2025 at 08:25:09AM -0400, Stephen Smoogen napsal(a):
I realized I wasn't clear on what I meant by a microOS. This would be
only
the libraries and tools needed to run a specific utility on a 64 bit
kernel
Which itself is not a small project because the libraries and tools need to be compiled with a compiler and built with a build system.
Would Koji have to nurse i686 architucture and builders for it, or would a crosscompilation on x86_64 producing x86_64 RPM packages installing i686 ELF files acceptable? Because the first, native approach would also involve supporting Koji, Python, DNF, OpenSSH etc. in their native form.
Oh quite agreed on this. There is a LOT of work involved to make it work and quite likely too much work.. but that work is what is being 'hidden' by having it done as 'well its just another architecture and you can support it easily' that we have been giving i686 for a long time.
-- Petr
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, Jun 24, 2025 at 09:25:23AM -0400, Stephen Smoogen wrote:
On Tue, 24 Jun 2025 at 09:09, Petr Pisar ppisar@redhat.com wrote:
V Tue, Jun 24, 2025 at 08:25:09AM -0400, Stephen Smoogen napsal(a):
I realized I wasn't clear on what I meant by a microOS. This would be
only
the libraries and tools needed to run a specific utility on a 64 bit
kernel
Which itself is not a small project because the libraries and tools need to be compiled with a compiler and built with a build system.
Would Koji have to nurse i686 architucture and builders for it, or would a crosscompilation on x86_64 producing x86_64 RPM packages installing i686 ELF files acceptable? Because the first, native approach would also involve supporting Koji, Python, DNF, OpenSSH etc. in their native form.
Oh quite agreed on this. There is a LOT of work involved to make it work and quite likely too much work.. but that work is what is being 'hidden' by having it done as 'well its just another architecture and you can support it easily' that we have been giving i686 for a long time.
If we only want to build a small subset of packages as i686, then rather than doing it as an architecture in koji, IMHO, we could consider doing it as cross-compiled target, creating sub-RPMs from the native x86_64 package, as we do with the mingw packages for example. That could potentially eliminate pretty all of the rel-eng and infrastructure burden, and ensure package maintainer burden is strictly confined to where its needed.
With regards, Daniel
On Tue, 24 Jun 2025 at 09:45, Daniel P. Berrangé berrange@redhat.com wrote:
On Tue, Jun 24, 2025 at 09:25:23AM -0400, Stephen Smoogen wrote:
On Tue, 24 Jun 2025 at 09:09, Petr Pisar ppisar@redhat.com wrote:
V Tue, Jun 24, 2025 at 08:25:09AM -0400, Stephen Smoogen napsal(a):
I realized I wasn't clear on what I meant by a microOS. This would be
only
the libraries and tools needed to run a specific utility on a 64 bit
kernel
Which itself is not a small project because the libraries and tools
need
to be compiled with a compiler and built with a build system.
Would Koji have to nurse i686 architucture and builders for it, or
would
a crosscompilation on x86_64 producing x86_64 RPM packages installing
i686
ELF files acceptable? Because the first, native approach would also involve supporting Koji, Python, DNF, OpenSSH etc. in their native form.
Oh quite agreed on this. There is a LOT of work involved to make it work and quite likely too much work.. but that work is what is being 'hidden'
by
having it done as 'well its just another architecture and you can support it easily' that we have been giving i686 for a long time.
If we only want to build a small subset of packages as i686, then rather than doing it as an architecture in koji, IMHO, we could consider doing it as cross-compiled target, creating sub-RPMs from the native x86_64 package, as we do with the mingw packages for example. That could potentially eliminate pretty all of the rel-eng and infrastructure burden, and ensure package maintainer burden is strictly confined to where its needed.
Yeah I could picture it as something like: sig_x86_32_glibc.src sig_x86_32_gcc.src sig_x86_32_llvm.src sig_x86_32_mesa.src ...
The versioning and updates would be up to the sig to deal with versus the main maintainer
With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 6/24/25 6:45 AM, Daniel P. Berrangé wrote:
On Tue, Jun 24, 2025 at 09:25:23AM -0400, Stephen Smoogen wrote:
On Tue, 24 Jun 2025 at 09:09, Petr Pisar ppisar@redhat.com wrote:
V Tue, Jun 24, 2025 at 08:25:09AM -0400, Stephen Smoogen napsal(a):
I realized I wasn't clear on what I meant by a microOS. This would be
only
the libraries and tools needed to run a specific utility on a 64 bit
kernel
Which itself is not a small project because the libraries and tools need to be compiled with a compiler and built with a build system.
Would Koji have to nurse i686 architucture and builders for it, or would a crosscompilation on x86_64 producing x86_64 RPM packages installing i686 ELF files acceptable? Because the first, native approach would also involve supporting Koji, Python, DNF, OpenSSH etc. in their native form.
Oh quite agreed on this. There is a LOT of work involved to make it work and quite likely too much work.. but that work is what is being 'hidden' by having it done as 'well its just another architecture and you can support it easily' that we have been giving i686 for a long time.
If we only want to build a small subset of packages as i686, then rather than doing it as an architecture in koji, IMHO, we could consider doing it as cross-compiled target, creating sub-RPMs from the native x86_64 package, as we do with the mingw packages for example. That could potentially eliminate pretty all of the rel-eng and infrastructure burden, and ensure package maintainer burden is strictly confined to where its needed.
I think something like this would be an improvement over the current situation. Although in the case of llvm we may want to just have a completely separate package that is 32-bit (something like llvm32) and not have it be a sub-package of the 64-bit package.
-Tom
With regards, Daniel
On Tue, Jun 24, 2025 at 1:45 PM Daniel P. Berrangé berrange@redhat.com wrote:
If we only want to build a small subset of packages as i686, then rather than doing it as an architecture in koji, IMHO, we could consider doing it as cross-compiled target, creating sub-RPMs from the native x86_64 package, as we do with the mingw packages for example. That could potentially eliminate pretty all of the rel-eng and infrastructure burden, and ensure package maintainer burden is strictly confined to where its needed.
It is an attractive idea, but can the packages do that, and still perform appropriate QA and development and debugging (as needed)?
Cross compile can certainly be used for targeted packages, but I am not sure it solves the general problem of how big the core set of libraries are, and their dependencies going all the way down. However, I will be quite happy to know I am overthinking the potential issues.
On Tue, Jun 24, 2025 at 05:23:24PM +0000, Gary Buhrmaster wrote:
On Tue, Jun 24, 2025 at 1:45 PM Daniel P. Berrangé berrange@redhat.com wrote:
If we only want to build a small subset of packages as i686, then rather than doing it as an architecture in koji, IMHO, we could consider doing it as cross-compiled target, creating sub-RPMs from the native x86_64 package, as we do with the mingw packages for example. That could potentially eliminate pretty all of the rel-eng and infrastructure burden, and ensure package maintainer burden is strictly confined to where its needed.
It is an attractive idea, but can the packages do that, and still perform appropriate QA and development and debugging (as needed)?
Cross compile can certainly be used for targeted packages, but I am not sure it solves the general problem of how big the core set of libraries are, and their dependencies going all the way down. However, I will be quite happy to know I am overthinking the potential issues.
Well the set of mingw packages we provide is pretty huge, with many layers of dependencies down to the base C runtime. Conceptually it isn't difficult work, just time consuming to get the minimal viable set of packages working, and a further maint burden. Initally mingw was completely separate from native, but we ultimately concluded that in most cases it is less work to have mingw be a sub-RPM of the native package (at the discretion of the native pkg maintainer to accept or reject).
IMHO, if people care about the 32-bit Steam use case are willing to invest the time in creating the cross-built i686 packages, it is an approach to seriously evaluate.
With regards, Daniel
Once upon a time, Daniel P. Berrangé berrange@redhat.com said:
Well the set of mingw packages we provide is pretty huge, with many layers of dependencies down to the base C runtime. Conceptually it isn't difficult work, just time consuming to get the minimal viable set of packages working, and a further maint burden. Initally mingw was completely separate from native, but we ultimately concluded that in most cases it is less work to have mingw be a sub-RPM of the native package (at the discretion of the native pkg maintainer to accept or reject).
IMHO, if people care about the 32-bit Steam use case are willing to invest the time in creating the cross-built i686 packages, it is an approach to seriously evaluate.
I guess it's a question of which is the bigger burden - taking that same package set and just building it directly for i686 (mostly burden on infrastructure, some on packagers for build failures or such) or cross-compiling it (burden almost all on packagers, infrastructure just has to have resources like any other x86_64-built package).
It is conceptually easier for packager burden to be spread (I think the bar for getting involved in infrastructure is higher)... but that's "conceptually", it might not practically matter if there aren't enough interested packagers willing to do the work. I'm a packager because there was a package that got me interested enough... I'd be happy to help with infrastructure, but there hasn't been something that grabbed me the same way (saying "see something you can help with and dive in" unfortunately doesn't make it happen, thanks ADHD).
On Tue, 2025-06-24 at 12:38 -0500, Chris Adams wrote:
I guess it's a question of which is the bigger burden - taking that same package set and just building it directly for i686 (mostly burden on infrastructure, some on packagers for build failures or such)
I'd like to highlight that this is a substantial burden. The multilib code we're carrying around the whole releng chain from koji on up is ancient, messy and hard to touch. This whole multilib concept is a *substantial* drag on almost anything you do around release or test. One of the hardest things to try and reason about in writing my new rmdepcheck thingy - https://codeberg.org/AdamWill/rmdepcheck - was "what to do about multilib?" If multilib didn't exist it would've been *far* less mentally taxing work. And even though my end decision was "ignore it as far as possible", doing that takes actual work, and caused two rounds of "why is it giving weird results? oh, multilib weirdness, I have to Do Stuff about it".
I'm also pretty sure 'dealing with multilib' is a significant reason why the preliminary phases of compose - pkgset and gather, I forget which deals with multilib, maybe it's both? - take so long (over an hour).
On Tue, Jun 24, 2025 at 1:49 PM Stephen Smoogen ssmoogen@redhat.com wrote:
On Tue, 24 Jun 2025 at 07:26, Michal Schorm mschorm@redhat.com wrote:
If we leave a significant portion of users without an upgrade path for
The key problem here is "significant portion of users". We have no idea how many Fedora users actually use steam (it could just be the N people on this list, it could be 99% of the Fedora desktop users). Without that we are constantly fighting over 'stop everything unless this gets fixed' when very little of it is outside of our control.
Agreed. That's why I used a vague term. But that's also why I suggested an IMO reachable to-do item: To bring it to Valve, discuss, and share results. We may not need to block the change by having the 64-bit build of Steam, but I suggest to require the discussion at least.
--
Michal Schorm Software Engineer Databases Team Red Hat
--
On Tue, Jun 24, 2025 at 1:49 PM Stephen Smoogen ssmoogen@redhat.com wrote:
On Tue, 24 Jun 2025 at 07:26, Michal Schorm mschorm@redhat.com wrote:
On Tue, Jun 24, 2025 at 1:08 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Tue, Jun 24, 2025 at 11:02:56AM +0100, Aoife Moloney via devel-announce wrote:
== Dependencies ==
- steam: adapt or drop RPM package from default third-party repositories
IMHO whatever happens with steam should not be our concern.
If steam happens to work on Fedora that's nice, but IMHO its needs don't align with the Fedora project "four foundations" or mission. Thus it shouldn't have significant influence the decision to drop i386, nor be the kind of thing that would justify a reverse in the change inbetween disabling the compose for i686 and turning off i686 in koji
Fedora values ethical choices over easy ones. But that does not mean we shouldn't care and say "that's not our problem".
It is our problem. If we leave a significant portion of users without an upgrade path for
The key problem here is "significant portion of users". We have no idea how many Fedora users actually use steam (it could just be the N people on this list, it could be 99% of the Fedora desktop users). Without that we are constantly fighting over 'stop everything unless this gets fixed' when very little of it is outside of our control.
To me the 'best' fix would be a SIG focused on an i686 micro-OS which delivers the packages in a format which can be easily used by Steam. This means the people working on it are using Steam, and know what needs to be tested to make Steam work. Anything else is always going to be a guessing game of 'does this actually block X' and maintainer fatigue of dealing with things they don't know about.
their favourite software without a good justification, we will force them to leave and they will never come back.
From what I can tell, the Valve exit plan for most Linux Steam users is a "Steam Console". That is where they can control both the quality and the delivery of the products. Outside of that, there are always up to M-factorial different factors on individual laptops, desktops and user-installed other applications to deal with.
And "we don't care" is not a good justification for me. I'd love to see going to the Steam upstream, and discussing what they could do for us to keep our player base alive, as a part of this proposal.
We might not succeed, but "Valve doesn't care" is still way better justification than "We don't care".
--
Michal Schorm Software Engineer Databases Team Red Hat
--
On Tue, Jun 24, 2025 at 1:08 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Tue, Jun 24, 2025 at 11:02:56AM +0100, Aoife Moloney via devel-announce wrote:
== Detailed Description ==
snip
This Change Proposal implements the next two (and last) steps:
- Packages built for the i686 architecture are no longer included in
x86_64 repositories (dropping "multilib" support, i.e. support for running 32-bit userspace on a 64-bit host).
- Packages are no longer built for the i686 architecture.
This is intentionally planned as a two-step process - the first step (no longer including 32-bit libraries in the x86_64 repositories) should be relatively easy to revert (if needed). The second step is basically irreversible, since reversing it would require to partially re-bootstrap the architecture.
Some packages will require changes to adapt for the removal of 32-bit libraries from the x86_64 package repositories - notably, `wine` will need to be built in the [https://src.fedoraproject.org/rpms/wine/pull-request/19 "new WoW64" configuration], which allows running 32-bit Windows applications on top of 64-bit-only host systems.
It is planned to implement the first step as early as possible in the development cycle, but before the mass rebuild at the latest. This provides a transition period of at least four weeks to catch potential issues *before* the potentially irreversible second step is implemented (before the beta freeze).
What kind of "potential issues" are liable to justify reversing the decision to drop i386 ?
Assuming we confirm that the Wine change is just a formality at before approving this change, that would address the big blocker in Fedora.
What else would be high profile enough *in Fedora* to merit a blocker ? IMHO external apps should not influence our decision, and must adapt to what the distro decides to provide.
The QEMU release coming in Dec this year is expected to be dropping all support for building on 32-bit hosts, and the ripple effect on packages across Fedora is non-negligible.
We're looking at a choice of updating Exclusive/ExcludeArch across many packages (which I'm dieing to avoid the busy work for), or not doing any further updates of QEMU in rawhide until i686 is turned off in koji which is also undesirable as it delays feature integration & testnig.
IOW, from a (somewhat selfish) POV as a maintainer of QEMU, I'd prefer us to go straight to turning off i686 in koji when the F44 dev cycle opens.
=== Package Maintainers ===
Building and maintaining packages for i686 (and 32-bit architectures in general, but i686 is the last 32-bit architecture - partially - supported by Fedora) has been requiring more and more effort.
Many projects have already been officially dropping support for building and / or running on 32-bit architectures, requiring either adding back support for this architecture downstream in Fedora, or requiring packaging changes in a significant number of packages to adapt to this dropped support.
Yep, this. Fedora's policy of only turning off i386 in leaf packages has left us in a painful situation as upstream projects in non-leaf context increasingly decide that 32-bit isn't something they're willing to continue to support.
== Dependencies ==
- wine: build package with "new WoW64" mode enabled
- steam: adapt or drop RPM package from default third-party repositories
IMHO whatever happens with steam should not be our concern.
If steam happens to work on Fedora that's nice, but IMHO its needs don't align with the Fedora project "four foundations" or mission. Thus it shouldn't have significant influence the decision to drop i386, nor be the kind of thing that would justify a reverse in the change inbetween disabling the compose for i686 and turning off i686 in koji
With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
V Tue, Jun 24, 2025 at 02:29:37PM +0200, Michal Schorm napsal(a):
On Tue, Jun 24, 2025 at 1:49 PM Stephen Smoogen ssmoogen@redhat.com wrote:
On Tue, 24 Jun 2025 at 07:26, Michal Schorm mschorm@redhat.com wrote:
If we leave a significant portion of users without an upgrade path for
The key problem here is "significant portion of users". We have no idea how many Fedora users actually use steam (it could just be the N people on this list, it could be 99% of the Fedora desktop users). Without that we are constantly fighting over 'stop everything unless this gets fixed' when very little of it is outside of our control.
Agreed. That's why I used a vague term. But that's also why I suggested an IMO reachable to-do item: To bring it to Valve, discuss, and share results. We may not need to block the change by having the 64-bit build of Steam, but I suggest to require the discussion at least.
Is Fedora relevant for Steam? The download page https://store.steampowered.com/about/ only offers a Debian package and the only more verbose message I found https://help.steampowered.com/en/faqs/view/1114-3F74-0B8A-B784 talks about Ubuntu LTS.
-- Petr
Yes I think it's still very relevant to Fedora. You don't find Arch listed either, but tons of people run Steam on Arch.
On Tue, Jun 24, 2025 at 8:01 AM Petr Pisar ppisar@redhat.com wrote:
V Tue, Jun 24, 2025 at 02:29:37PM +0200, Michal Schorm napsal(a):
On Tue, Jun 24, 2025 at 1:49 PM Stephen Smoogen ssmoogen@redhat.com
wrote:
On Tue, 24 Jun 2025 at 07:26, Michal Schorm mschorm@redhat.com
wrote:
If we leave a significant portion of users without an upgrade path for
The key problem here is "significant portion of users". We have no
idea how many Fedora users actually use steam (it could just be the N people on this list, it could be 99% of the Fedora desktop users). Without that we are constantly fighting over 'stop everything unless this gets fixed' when very little of it is outside of our control.
Agreed. That's why I used a vague term. But that's also why I suggested an IMO reachable to-do item: To bring it to Valve, discuss, and share results. We may not need to block the change by having the 64-bit build of Steam, but I suggest to require the discussion at least.
Is Fedora relevant for Steam? The download page https://store.steampowered.com/about/ only offers a Debian package and the only more verbose message I found https://help.steampowered.com/en/faqs/view/1114-3F74-0B8A-B784 talks about Ubuntu LTS.
-- Petr
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, Jun 24, 2025 at 4:44 PM Martin Jackson mhjacks@swbell.net wrote:
We also have Nobara downstream and one of its chief selling points is gaming.
Or e.g. Bazzite. https://bazzite.gg/
--
Michal Schorm Software Engineer Databases Team Red Hat
--
On Tue, Jun 24, 2025 at 4:44 PM Martin Jackson mhjacks@swbell.net wrote:
I for one use steam on Fedora. And the i686 packages are critical path for building the flatpak, right? (Though I admit I am not entirely sure inside steam where the line is between what is native and what is encapsulated inside the steam runtimes.)
We also have Nobara downstream and one of its chief selling points is gaming.
I really do not want to lose steam on Fedora.
On Jun 24, 2025, at 8:03 AM, Jonathan Wright via devel devel@lists.fedoraproject.org wrote:
Yes I think it's still very relevant to Fedora. You don't find Arch listed either, but tons of people run Steam on Arch.
On Tue, Jun 24, 2025 at 8:01 AM Petr Pisar ppisar@redhat.com wrote:
V Tue, Jun 24, 2025 at 02:29:37PM +0200, Michal Schorm napsal(a):
On Tue, Jun 24, 2025 at 1:49 PM Stephen Smoogen ssmoogen@redhat.com wrote:
On Tue, 24 Jun 2025 at 07:26, Michal Schorm mschorm@redhat.com wrote:
If we leave a significant portion of users without an upgrade path for
The key problem here is "significant portion of users". We have no idea how many Fedora users actually use steam (it could just be the N people on this list, it could be 99% of the Fedora desktop users). Without that we are constantly fighting over 'stop everything unless this gets fixed' when very little of it is outside of our control.
Agreed. That's why I used a vague term. But that's also why I suggested an IMO reachable to-do item: To bring it to Valve, discuss, and share results. We may not need to block the change by having the 64-bit build of Steam, but I suggest to require the discussion at least.
Is Fedora relevant for Steam? The download page https://store.steampowered.com/about/ only offers a Debian package and the only more verbose message I found https://help.steampowered.com/en/faqs/view/1114-3F74-0B8A-B784 talks about Ubuntu LTS.
-- Petr
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- Jonathan Wright AlmaLinux OS Foundation Mattermost: chat -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, Jun 24, 2025 at 09:43:37AM -0500, Martin Jackson wrote:
I for one use steam on Fedora. And the i686 packages are critical path for building the flatpak, right? (Though I admit I am not entirely sure inside steam where the line is between what is native and what is encapsulated inside the steam runtimes.)
We also have Nobara downstream and one of its chief selling points is gaming.
I really do not want to lose steam on Fedora.
To make the discussion concrete, could you grab a list of the actual libraries that we're talking about here? I'm interested in how hard it would be to adapt them to cross compilation as Dan mentioned upthread.
Rich.
Once upon a time, Richard W.M. Jones rjones@redhat.com said:
To make the discussion concrete, could you grab a list of the actual libraries that we're talking about here? I'm interested in how hard it would be to adapt them to cross compilation as Dan mentioned upthread.
Just looking at a running copy of the Steam client, I see libs loaded from a whole lot of packages. I expect that some are loaded by others, like I don't expect steam is actually using lm_sensors-libs itself.
NetworkManager-libnm atk bzip2-libs cairo dbus-libs elfutils-libelf expat flac-libs fontconfig freetype fribidi gdk-pixbuf2 glib2 glibc gmp gnutls graphite2 gsm gtk2 harfbuzz lame-libs libICE libX11 libX11-xcb libXScrnSaver libXau libXcomposite libXcursor libXdamage libXext libXfixes libXi libXinerama libXrandr libXrender libXtst libXxf86vm libasyncns libblkid libbrotli libcap libdatrie libdrm libedit libffi libgcc libglvnd libglvnd-glx libidn2 libjpeg-turbo libmount libpciaccess libpng libselinux libsndfile libstdc++ libtasn1 libthai libunistring libuuid libva libvdpau libxcb libxml2 libxshmfence libzstd llvm-libs lm_sensors-libs mesa-libGL mpg123-libs ncurses-libs nettle opus p11-kit pango pcre2 pipewire-libs pixman pulseaudio-libs spirv-tools-libs systemd-libs xz-libs zlib-ng-compat
On Tue, Jun 24, 2025 at 12:19:47PM -0500, Chris Adams wrote:
Once upon a time, Richard W.M. Jones rjones@redhat.com said:
To make the discussion concrete, could you grab a list of the actual libraries that we're talking about here? I'm interested in how hard it would be to adapt them to cross compilation as Dan mentioned upthread.
Just looking at a running copy of the Steam client, I see libs loaded from a whole lot of packages. I expect that some are loaded by others, like I don't expect steam is actually using lm_sensors-libs itself.
NetworkManager-libnm atk bzip2-libs
Thanks! It's a lot of libraries. I picked bzip2 at random as it's relatively simple and modified it so it cross-compiled to a 32 bit library. The diff to the spec is attached.
Obviously this could either be done as a new, separate package, or as a subpackage of the existing bzip2 package. (For mingw we're mixing both approaches.)
RPM complains about:
Macro expanded in comment on line 10: %{version}/%{name}-%{version}.tar.gz
Binaries arch (1) not matching the package arch (2). Binaries arch (1) not matching the package arch (2).
I couldn't use 'BuildArch: i686' as I expected. Apparently only 'BuildArch: noarch' works. But surely this could be fixed somehow.
Cross-compiling _all_ of the packages in this way is going to be a fair bit of work.
Rich.
On Fri, Jun 27, 2025 at 01:37:13PM +0100, Richard W.M. Jones wrote:
On Tue, Jun 24, 2025 at 12:19:47PM -0500, Chris Adams wrote:
Once upon a time, Richard W.M. Jones rjones@redhat.com said:
To make the discussion concrete, could you grab a list of the actual libraries that we're talking about here? I'm interested in how hard it would be to adapt them to cross compilation as Dan mentioned upthread.
Just looking at a running copy of the Steam client, I see libs loaded from a whole lot of packages. I expect that some are loaded by others, like I don't expect steam is actually using lm_sensors-libs itself.
NetworkManager-libnm atk bzip2-libs
Thanks! It's a lot of libraries. I picked bzip2 at random as it's relatively simple and modified it so it cross-compiled to a 32 bit library. The diff to the spec is attached.
And I should say this probably only works because I have glibc.i686 installed. The packages would need to be modified & rebuilt in dependency order starting with glibc.
Rich.
Obviously this could either be done as a new, separate package, or as a subpackage of the existing bzip2 package. (For mingw we're mixing both approaches.)
RPM complains about:
Macro expanded in comment on line 10: %{version}/%{name}-%{version}.tar.gz Binaries arch (1) not matching the package arch (2). Binaries arch (1) not matching the package arch (2).I couldn't use 'BuildArch: i686' as I expected. Apparently only 'BuildArch: noarch' works. But surely this could be fixed somehow.
Cross-compiling _all_ of the packages in this way is going to be a fair bit of work.
Rich.
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
diff --git a/bzip2.spec b/bzip2.spec index ca1b861..7a0baab 100644 --- a/bzip2.spec +++ b/bzip2.spec @@ -1,4 +1,5 @@ %global library_version 1.0.8 +%global _libdir32 %{_prefix}/lib
Summary: File compression utility Name: bzip2 @@ -64,28 +65,28 @@ Static libraries for applications using the bzip2 compression format. %patch -P3 -p2
cp -a %{SOURCE1} . -sed -i "s|^libdir=|libdir=%{_libdir}|" bzip2.pc +sed -i "s|^libdir=|libdir=%{_libdir32}|" bzip2.pc
%build
%make_build -f Makefile-libbz2_so CC="%{__cc}" AR="%{__ar}" RANLIB="ranlib" \
- CFLAGS="$RPM_OPT_FLAGS -D_FILE_OFFSET_BITS=64 -fpic -fPIC" \
- CFLAGS="$RPM_OPT_FLAGS -D_FILE_OFFSET_BITS=64 -fpic -fPIC -m32" \ LDFLAGS="%{__global_ldflags}" \ all
rm -f *.o %make_build CC="%{__cc}" AR="%{__ar}" RANLIB="ranlib" \
- CFLAGS="$RPM_OPT_FLAGS -D_FILE_OFFSET_BITS=64" \
- CFLAGS="$RPM_OPT_FLAGS -D_FILE_OFFSET_BITS=64 -m32" \ LDFLAGS="%{__global_ldflags}" \ all
%install chmod 644 bzlib.h -mkdir -p $RPM_BUILD_ROOT{%{_bindir},%{_mandir}/man1,%{_libdir}/pkgconfig,%{_includedir}} +mkdir -p $RPM_BUILD_ROOT{%{_bindir},%{_mandir}/man1,%{_libdir32}/pkgconfig,%{_includedir}} cp -p bzlib.h $RPM_BUILD_ROOT%{_includedir} -install -m 755 libbz2.so.%{library_version} $RPM_BUILD_ROOT%{_libdir} -install -m 644 libbz2.a $RPM_BUILD_ROOT%{_libdir} -install -m 644 bzip2.pc $RPM_BUILD_ROOT%{_libdir}/pkgconfig/bzip2.pc +install -m 755 libbz2.so.%{library_version} $RPM_BUILD_ROOT%{_libdir32} +install -m 644 libbz2.a $RPM_BUILD_ROOT%{_libdir32} +install -m 644 bzip2.pc $RPM_BUILD_ROOT%{_libdir32}/pkgconfig/bzip2.pc install -m 755 bzip2-shared $RPM_BUILD_ROOT%{_bindir}/bzip2 install -m 755 bzip2recover bzgrep bzdiff bzmore $RPM_BUILD_ROOT%{_bindir}/ cp -p bzip2.1 bzdiff.1 bzgrep.1 bzmore.1 $RPM_BUILD_ROOT%{_mandir}/man1/ @@ -95,8 +96,8 @@ ln -s bzdiff $RPM_BUILD_ROOT%{_bindir}/bzcmp ln -s bzmore $RPM_BUILD_ROOT%{_bindir}/bzless ln -s bzgrep $RPM_BUILD_ROOT%{_bindir}/bzegrep ln -s bzgrep $RPM_BUILD_ROOT%{_bindir}/bzfgrep -ln -s libbz2.so.%{library_version} $RPM_BUILD_ROOT%{_libdir}/libbz2.so.1 -ln -s libbz2.so.1 $RPM_BUILD_ROOT%{_libdir}/libbz2.so +ln -s libbz2.so.%{library_version} $RPM_BUILD_ROOT%{_libdir32}/libbz2.so.1 +ln -s libbz2.so.1 $RPM_BUILD_ROOT%{_libdir32}/libbz2.so ln -s bzip2.1 $RPM_BUILD_ROOT%{_mandir}/man1/bzip2recover.1 ln -s bzip2.1 $RPM_BUILD_ROOT%{_mandir}/man1/bunzip2.1 ln -s bzip2.1 $RPM_BUILD_ROOT%{_mandir}/man1/bzcat.1 @@ -115,17 +116,17 @@ ln -s bzgrep.1 $RPM_BUILD_ROOT%{_mandir}/man1/bzfgrep.1
%files libs %license LICENSE -%{_libdir}/libbz2.so.1* +%{_libdir32}/libbz2.so.1*
%files static %license LICENSE -%{_libdir}/libbz2.a +%{_libdir32}/libbz2.a
%files devel %doc manual.html manual.pdf %{_includedir}/* -%{_libdir}/*.so -%{_libdir}/pkgconfig/bzip2.pc +%{_libdir32}/*.so +%{_libdir32}/pkgconfig/bzip2.pc
%changelog
- Thu Jan 16 2025 Fedora Release Engineering releng@fedoraproject.org - 1.0.8-20
-- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Le ven. 27 juin 2025 à 14:40, Richard W.M. Jones rjones@redhat.com a écrit :
On Fri, Jun 27, 2025 at 01:37:13PM +0100, Richard W.M. Jones wrote:
On Tue, Jun 24, 2025 at 12:19:47PM -0500, Chris Adams wrote:
Once upon a time, Richard W.M. Jones rjones@redhat.com said:
To make the discussion concrete, could you grab a list of the actual libraries that we're talking about here? I'm interested in how hard it would be to adapt them to cross compilation as Dan mentioned upthread.
Just looking at a running copy of the Steam client, I see libs loaded from a whole lot of packages. I expect that some are loaded by others, like I don't expect steam is actually using lm_sensors-libs itself.
NetworkManager-libnm atk bzip2-libs
Thanks! It's a lot of libraries. I picked bzip2 at random as it's relatively simple and modified it so it cross-compiled to a 32 bit library. The diff to the spec is attached.
You don't need any change in the spec file, this just works: fedpkg local --arch i686
Now the issue with cross-compiling is more about higher level tools, especially if one wants to reuse the x86_64 repository as is.
* Petr Pisar:
Is Fedora relevant for Steam? The download page https://store.steampowered.com/about/ only offers a Debian package and the only more verbose message I found https://help.steampowered.com/en/faqs/view/1114-3F74-0B8A-B784 talks about Ubuntu LTS.
These days, the default Fedora installation comes with the Steam client ready for installation. Fedora users probably don't install it from a web page, but from Fedora's software management tool.
Debian doesn't enable non-free or third-party software repositories by default.
I don't know what the Debian experience is, but the Fedora experience is *extremely* polished (or at least it was a couple of years ago). You can just install Fedora on a machine with a decent AMD GPU, install Steam, and you have access to lots and lots of mainstream games that just work. There seem to be a fair share of non-technical users playing games on Fedora. It explains why there is such a fierce feedback when we break stuff. We set the bar really high.
Thanks, Florian
On Tue, Jun 24, 2025 at 05:52:02PM +0200, Florian Weimer wrote:
- Petr Pisar:
Is Fedora relevant for Steam? The download page https://store.steampowered.com/about/ only offers a Debian package and the only more verbose message I found https://help.steampowered.com/en/faqs/view/1114-3F74-0B8A-B784 talks about Ubuntu LTS.
These days, the default Fedora installation comes with the Steam client ready for installation. Fedora users probably don't install it from a web page, but from Fedora's software management tool.
That would be the flathub hosted flatpak install of Steam though, right ?
If so that shouldn't be directly affected by the host OS dropping 32-bit libraries.
With regards, Daniel
* Daniel P. Berrangé:
On Tue, Jun 24, 2025 at 05:52:02PM +0200, Florian Weimer wrote:
- Petr Pisar:
Is Fedora relevant for Steam? The download page https://store.steampowered.com/about/ only offers a Debian package and the only more verbose message I found https://help.steampowered.com/en/faqs/view/1114-3F74-0B8A-B784 talks about Ubuntu LTS.
These days, the default Fedora installation comes with the Steam client ready for installation. Fedora users probably don't install it from a web page, but from Fedora's software management tool.
That would be the flathub hosted flatpak install of Steam though, right ?
This hadn't occured to me. I don't know what takes precedence. The RPM repository is enabled as well.
Thanks, Florian
Once upon a time, Daniel P. Berrangé berrange@redhat.com said:
What else would be high profile enough *in Fedora* to merit a blocker ? IMHO external apps should not influence our decision, and must adapt to what the distro decides to provide.
This is a big decision IMHO: is Fedora going to be a "closed" ecosystem? I'm not talking about source code, I mean Fedora only being intended to run Fedora-provided software.
On Tue, Jun 24, 2025 at 08:04:52AM -0500, Chris Adams wrote:
Once upon a time, Daniel P. Berrangé berrange@redhat.com said:
What else would be high profile enough *in Fedora* to merit a blocker ? IMHO external apps should not influence our decision, and must adapt to what the distro decides to provide.
This is a big decision IMHO: is Fedora going to be a "closed" ecosystem? I'm not talking about source code, I mean Fedora only being intended to run Fedora-provided software.
No, this isn't about being a closed platform. It is about defining what should reasonably be considered blockers for Fedora's decisions and what is reasonable to impose as a burden on Fedora maintainers.
It is possible to run plenty of non-Fedora software on Fedora just fine today and long into the future, both OSS and proprietary. None the less it is unreasonable to demand that volunteer Fedora maintainers take on extra work & responsibility to keeping arbitrary 3rd party software working indefinitely, especially when it is proprietary software.
With regards, Daniel
* Daniel P. Berrangé:
What kind of "potential issues" are liable to justify reversing the decision to drop i386 ?
Assuming we confirm that the Wine change is just a formality at before approving this change, that would address the big blocker in Fedora.
What else would be high profile enough *in Fedora* to merit a blocker ? IMHO external apps should not influence our decision, and must adapt to what the distro decides to provide.
The QEMU release coming in Dec this year is expected to be dropping all support for building on 32-bit hosts, and the ripple effect on packages across Fedora is non-negligible.
NodeJS is in a similar boat, apparently (see the thread “Dropping i686 from NodeJS build architectures”).
Both situations could in theory be solved by having 64-bit binaries in the 32-bit buildroot. The x86_64 build could copy the already-built binaries into a specially-named noarch subpackage, and the i686 build would just build stub packages that depend on the noarch packages. We can do this for glibc as well (like we already do in the opposite direction, via the glibc32 package), so you wouldn't even have to link statically. And if we do it for binutils and gcc, quite a lot of i686 build failures due to its limited address space would just go away.
However, this is not really forward-looking work. While technically interesting to some degree, the effort required would likely be spent in a more impactful way somewhere else. I think it's quite likely that soon (maybe in a way) we encounter more issues that make the i686 port even more challenging.
(Funny thought: In a way, the whole discussion is a testament of the portability of Fedora and our build approach.)
Thanks, Florian
Em ter., 24 de jun. de 2025 às 07:07, Aoife Moloney via devel-announce devel-announce@lists.fedoraproject.org escreveu:
Wiki - https://fedoraproject.org/wiki/Changes/Drop_i686_support Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-drop-i686-support...
This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary ==
Fedora package repositories for the x86_64 architecture no longer include libraries for compatibility with 32-bit applications ("multilib"), and packages are no longer built for the i686 architecture.
== Owner ==
- Name: [[User:Decathorpe| Fabio Valentini]], [[User:Fale|Fale]],
[[User:Kevin|Kevin Fenzi]]
- Email: decathorpe (at) gmail (dot) com, mail (at) fale (dot) io,
kevin (at) scrye (dot) com
== Detailed Description ==
Fedora stopped providing [https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels kernel packages, installer images] and stopped publishing [https://fedoraproject.org/wiki/Changes/Noi686Repositories i686 package repositories] with Fedora 31. However, packages were by default still built for the i686 architecture, since they were required for running 32-bit applications on x86_64 hosts ("multilib").
Since Fedora 37, leaf packages (i.e. packages that are not depended on by other packages) can simply [https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval stop building for i686] without any reason, which has allowed package maintainers to focus their work on architectures where packages are actually shipped to users.
This Change Proposal implements the next two (and last) steps:
- Packages built for the i686 architecture are no longer included in
x86_64 repositories (dropping "multilib" support, i.e. support for running 32-bit userspace on a 64-bit host).
- Packages are no longer built for the i686 architecture.
This is intentionally planned as a two-step process - the first step (no longer including 32-bit libraries in the x86_64 repositories) should be relatively easy to revert (if needed). The second step is basically irreversible, since reversing it would require to partially re-bootstrap the architecture.
Some packages will require changes to adapt for the removal of 32-bit libraries from the x86_64 package repositories - notably, `wine` will need to be built in the [https://src.fedoraproject.org/rpms/wine/pull-request/19 "new WoW64" configuration], which allows running 32-bit Windows applications on top of 64-bit-only host systems.
It is planned to implement the first step as early as possible in the development cycle, but before the mass rebuild at the latest. This provides a transition period of at least four weeks to catch potential issues *before* the potentially irreversible second step is implemented (before the beta freeze).
When this Change is successfully implemented, a mechanism will be provided to remove any installed i686 packages on upgrade to avoid leaving behind packages that will no longer be updated, maintained, or which might cause upgrade issues in the future.
== Feedback ==
N/Y
== Benefit to Fedora ==
By dropping completely the i686 architecture, Fedora will decrease the burden on package maintainers, release engineering, infrastructure, and users.
=== Package Maintainers ===
Building and maintaining packages for i686 (and 32-bit architectures in general, but i686 is the last 32-bit architecture - partially - supported by Fedora) has been requiring more and more effort.
Many projects have already been officially dropping support for building and / or running on 32-bit architectures, requiring either adding back support for this architecture downstream in Fedora, or requiring packaging changes in a significant number of packages to adapt to this dropped support.
By dropping support for the i686 architecture entirely, this additional - and growing - maintenance burden is eliminated.
=== Release engineering ===
The process for including 32-bit libraries in the x86_64 repositories is based on brittle heuristics and rules, which can be removed when this change is implemented - simplifying the process for creating x86_64 package repositories.
=== Infrastructure ===
No longer building packages for the i686 architecture frees up resources on x86 build machines that will instead be available to speed up x86_64 package builds.
=== Users ===
By dropping ~10000 32-bit packages from the x86_64 repositories, repository metadata will get smaller, which should speed up both metadata downloads and any dnf operations that involve dependency resolution.
== Scope ==
- Proposal owners:
** Prepare compose configuration changes to drop multilib support from x86_64 repositories. ** Prepare builder configuration changes to drop the i686 architecture from the f44 build target.
- Other developers:
** Adapt packages for the removal of 32-bit libraries from the x86_64 package repositories. ** Potentially simplify `ExcludeArch` / `ExclusiveArch` usage and / or `%__isa_bits` conditionals in spec files.
- Release engineering: [https://pagure.io/releng/issue/12782 releng#12782]
** Review and deploy compose configuration changes. ** Review and deploy builder configuration changes.
- Policies and guidelines:
** Drop mentions of i686 architecture support from documentation (Packaging Guidelines, ...).
Trademark approval: N/A (not needed for this Change)
Alignment with the Fedora Strategy: :shrug:
== Upgrade/compatibility impact ==
Any 32-bit packages installed on x86_64 systems should get removed on upgrade, and will no longer be available from package repositories. Any third-party software that depends on these 32-bit libraries will no longer be installable on Fedora. Wine prefixes created on older versions of Fedora might need to be recreated.
== How To Test ==
Upgrading to the Fedora version that implements this change should remove any 32-bit packages from x86_64 systems, and no packages for the i686 architecture should be available from the x86_64 package repositories.
Installing and using Wine to run Windows applications should continue to work, but Wine prefixes created on older versions of Fedora and / or with older versions of Wine might need to be re-created.
== User Experience ==
- Package repositories no longer include i686 packages for
compatibility with 32-bit applications. Third-party RPM packages that do not provide 64-bit versions for x86 will no longer be installable.
- Package repositories no longer include i686 packages for
compatibility with 32-bit applications. Package management operations (GNOME Software, Discover, DNF, etc.) should be faster, including metadata downloads and dependency resolution.
== Dependencies ==
- wine: build package with "new WoW64" mode enabled
- steam: adapt or drop RPM package from default third-party repositories
== Contingency Plan ==
- Contingency mechanism:
** If only step one has been implemented, Release Engineering needs to revert the compose configuration changes to restore "multilib" support (i.e. include 32-bit compatibility libraires in x86_64 repositories again). ** If both step one and two have already been implemented, reverting the changes would require re-bostrapping the architecture, which would be difficult to justify.
Contingency deadline: Beta Freeze
Blocks release? Yes (Change is either fully implemented or reverted)
== Documentation ==
TODO
== Release Notes ==
TODO
Dropping i686 support and the Steam problem is interesting for me because I see it like this: Steam games shouldn't be affected but the Steam client will be.
Essentially Steam has 3 current runtimes: Steam Linux Runtime 1.0, 2.0 and 3.0, each one slightly newer than the previous and apparently based on a specific Debian release. You can read more about the runtimes here: https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/co... If I understood correctly the 1.0 runtime is based on 2.0 with a LD_LIBRARY_PATH, while the 3.0 has to be setup by game developer. Also 2.0 and 3.0 are used as a base for Proton compatibility layers.
Why is that relevant? While currently most games probably run using the host libraries (either actual host or the feedesktop runtime in case of Flatpaks), there's nothing preventing every game from being set to a runtime so we don't have to depend on host libs at all.
The problem now is that the Steam client itself apparently relies on the 32-bits for some reason, which I'm not sure why.
If you think about it those are the main components of Steam: * The Steam client which uses CEF for its UI * Steam Overlay * Steam chat (includes voice chat) * Steam Game Recording
IMHO the way Valve can fix this: * For games, Valve should either nudge devs into using the SLR 3.0 if possible, otherwise they should automatically set games without a explicit runtime to SLR 1.0 and only revert if it breaks something * For the client, Valve should get around to finally porting it to 64-bits, I guess they only did it on MacOS when 32-bits support got taken away, so it's the same case
If neither can be done, probably Flatpak is the remaining choice. The only game I ever had an issue under Flatpak that couldn't be fixed due to the sandbox was OneShot (since some game behavior would rely on breaking the sandbox), but the World Machine Edition probably workarounds those issues.
-- Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
-- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapro... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Good luck all, Mateus Rodrigues Costa
Once upon a time, Mateus Rodrigues Costa mateusrodcosta@gmail.com said:
Dropping i686 support and the Steam problem is interesting for me because I see it like this: Steam games shouldn't be affected but the Steam client will be.
Heck, almost all the games I run are Windows+Proton anyway... a couple I have to set that manually because they have Linux-native versions, but they haven't been updated in ages (so don't have current UI and sometimes DLC).
The problem now is that the Steam client itself apparently relies on the 32-bits for some reason, which I'm not sure why.
Yeah, that's the catch. Has anybody tried talking to somebody at Valve (if they can be found)? This isn't a Fedora-exclusive issue; Ubuntu and SuSE (and all the downstreams of each) are probably looking at the same thing at some point.
Like - do many Steam games even run well on a true i686? I get targetting a lowest common base, but I can't imagine anybody is using a 32-bit-only system for playing games in 2025.
If neither can be done, probably Flatpak is the remaining choice.
Flatpak IMHO is just punting, trying to make the issue somebody else's problem. Somebody still has to be building the base that goes into the Flatpak (and I prefer running things on a Fedora base). I like the sandboxing Flatpak offers, when it's used, but would rather stick with how Fedora builds libraries and such.
On Tue, Jun 24, 2025 at 4:02 PM Chris Adams linux@cmadams.net wrote:
Yeah, that's the catch. Has anybody tried talking to somebody at Valve (if they can be found)? This isn't a Fedora-exclusive issue; Ubuntu and SuSE (and all the downstreams of each) are probably looking at the same thing at some point.
There was, at one point, an open issue on Valve's steam-on-linux github repo regarding having a 64-bit client, including at least:
https://github.com/ValveSoftware/steam-for-linux/issues/3518
which was opened over a decade ago. I actually think there are other open issues in that repo (but too many to search through).
I have no doubt Valve is aware of the requirement(s). There have been hints they might be working on such. They have, to this point, not announced an actual timeline for they might offer such a 64-bit program.
Once upon a time, Gary Buhrmaster gary.buhrmaster@gmail.com said:
I have no doubt Valve is aware of the requirement(s). There have been hints they might be working on such. They have, to this point, not announced an actual timeline for they might offer such a 64-bit program.
It probably got called version 3, a number Valve doesn't believe in.
On Tue, Jun 24, 2025 at 6:02 PM Chris Adams linux@cmadams.net wrote:
Like - do many Steam games even run well on a true i686? I get targetting a lowest common base, but I can't imagine anybody is using a 32-bit-only system for playing games in 2025.
It certainly seems that Steam has zero or almost zero 32bit OS userbase: https://store.steampowered.com/hwsurvey/
Click on the "OS version" line and see the details. If there are any 32bit OS users, they are not displayed in the statistics, indicating they are definitely under 0.1% of the whole userbase. Furthermore, at least for Windows, Steam only supports Windows 10 and 11, and Windows 11 doesn't have a 32bit version, which means only Windows 10 32bit users can be using it. Support for older Windows was cut more than a year ago.
Why Valve still only publishes a 32bit version of Steam is baffling to me.
On 6/24/25 5:02 AM, Aoife Moloney via devel-announce wrote:
- Name: [[User:Decathorpe| Fabio Valentini]], [[User:Fale|Fale]],
[[User:Kevin|Kevin Fenzi]]
Thank you, Fabio V., for engaging in the discussion on this topic. I hope to see Fabio L. and Kevin involved, too. This is undoubtedly one of the largest change proposals in Fedora's history.
Re: wine
I have not tested the new WOW64 feature and it has not merged. I'll try to get it merged and in testing as soon as time allows.
Re: steam
Red Hat's enterprise ambitions may not take it near Valve headquarters, but I do not see why gaming has to be the primary selling point. RHEL 10 removed i686 but I would not be surprised to see it return once customers attempt to upgrade. Fabios or Kevin, is there no Red Hat manager backing to at least talk to a Valve representative on this topic? I know Valve wants to roll their own distro and could care less about RH's roadmap, but they might run into a situation where something vital, say, systemd, stops building for i686. What will Valve do?
Thanks, Michael
Hello guys,
As I did it in discussion.fp.o, I need to remind everyone that the latest update of Fedora Strategy [1] that one the objectives is to grow our users base, so potentially killing gaming goes directly against that strategy.
Being that said, I think all points discussed here are really interesting. I would love to be part of any sig trying to keep important things like gaming and recording/streaming (OBS) live in the distro, but instead of just dropping and then wait for people to react on that, the step should be done backwards, having a SIG taking care of things for 2 or 3 releases, and then dropping from the main build system. And also, we should involve the marketing team now, to mitigate the already coming press about it [2].
Let's see how this unfolds.
Best regards,
[1] https://discussion.fedoraproject.org/t/strategy-2028-update/155077 [2] https://officialaptivi.wordpress.com/2025/06/24/fedora-44-proposes-dropping-...
On Tue, Jun 24, 2025 at 7:46 PM Eduard Lucena x3mboy@fedoraproject.org wrote:
Hello guys,
As I did it in discussion.fp.o, I need to remind everyone that the latest update of Fedora Strategy [1] that one the objectives is to grow our users base, so potentially killing gaming goes directly against that strategy.
"potentially killing gaming" is a pretty bold and broad statement that I don't think you can actually back up.
In fact, the Change Proposal lists several alternatives or workarounds to make the "gaming" use case work just fine. There are only very few cases where those workarounds aren't enough (like running Steam through Gamescope, apparently).
I have been "gaming" on Fedora for years, without having *any* i686 packages installed on my x86_64 host system. But maybe I'm not "hardcore" enough :P
Being that said, I think all points discussed here are really interesting. I would love to be part of any sig trying to keep important things like gaming and recording/streaming (OBS) live in the distro, but instead of just dropping and then wait for people to react on that, the step should be done backwards, having a SIG taking care of things for 2 or 3 releases, and then dropping from the main build system. And also, we should involve the marketing team now, to mitigate the already coming press about it [2].
Having a dedicated i686 SIG was already tried back when it was proposed to stop building kernel packages and installer images for i686. That SIG was formed and then basically never did anything. So I don't think it's going to work the second time, either ...
Fabio
On Wed, Jun 25, 2025 at 10:42:22AM +0200, Fabio Valentini wrote:
On Tue, Jun 24, 2025 at 7:46 PM Eduard Lucena x3mboy@fedoraproject.org wrote:
Hello guys,
As I did it in discussion.fp.o, I need to remind everyone that the latest update of Fedora Strategy [1] that one the objectives is to grow our users base, so potentially killing gaming goes directly against that strategy.
"potentially killing gaming" is a pretty bold and broad statement that I don't think you can actually back up.
Also 'grow our userbase' is not an absolute statement that stands alone. It is the strategy for how Fedora delivers on its vision / mission, building on the project's foundations.
Some ways to grow our userbase will be aligned with Fedora's mission and some won't be aligned. We need to figure out where the balance between multiple competing factors lies.
Being that said, I think all points discussed here are really interesting. I would love to be part of any sig trying to keep important things like gaming and recording/streaming (OBS) live in the distro, but instead of just dropping and then wait for people to react on that, the step should be done backwards, having a SIG taking care of things for 2 or 3 releases, and then dropping from the main build system. And also, we should involve the marketing team now, to mitigate the already coming press about it [2].
Having a dedicated i686 SIG was already tried back when it was proposed to stop building kernel packages and installer images for i686. That SIG was formed and then basically never did anything. So I don't think it's going to work the second time, either ...
And this is the crux of the problem.
This is one of the periodic unusual Fedora change proposals where not adopting it, is defacto making a concious decision to force volunteers maintainers to continue to work on something that many consider to be undesirable and a technological dead end.
I very much doubt that pushing this down the road for another 2-4 releases will change the situation wrt steam requirements for i686. We'll just end up rehashing the same points and be no closer to a viable solution. IMHO we need some clear action to move us forward, rather than hoping that Valve suddenly decide to do something different after seemingly ignoring the problem for years. Fedora needs to control its own destiny.
IMHO, ideally there would be a counter proposal put forward for F44 by those who want to invest in i686 and steam, outlining a strategy for how to support i686 without the current cross-distro & build infra maint burden it currently imposes, even on maintainers whose packages are not consumed by Steam. We don't neccessarily need to deliver a full solution for F44 but, IMHO, we need to at least make some step forward towards a solution that is more sustainable than the status-quo.
With regards, Daniel
On Wed, Jun 25, 2025 at 11:19 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Wed, Jun 25, 2025 at 10:42:22AM +0200, Fabio Valentini wrote:
On Tue, Jun 24, 2025 at 7:46 PM Eduard Lucena x3mboy@fedoraproject.org wrote:
Hello guys,
As I did it in discussion.fp.o, I need to remind everyone that the latest update of Fedora Strategy [1] that one the objectives is to grow our users base, so potentially killing gaming goes directly against that strategy.
"potentially killing gaming" is a pretty bold and broad statement that I don't think you can actually back up.
Also 'grow our userbase' is not an absolute statement that stands alone. It is the strategy for how Fedora delivers on its vision / mission, building on the project's foundations.
Some ways to grow our userbase will be aligned with Fedora's mission and some won't be aligned. We need to figure out where the balance between multiple competing factors lies.
Being that said, I think all points discussed here are really interesting. I would love to be part of any sig trying to keep important things like gaming and recording/streaming (OBS) live in the distro, but instead of just dropping and then wait for people to react on that, the step should be done backwards, having a SIG taking care of things for 2 or 3 releases, and then dropping from the main build system. And also, we should involve the marketing team now, to mitigate the already coming press about it [2].
Having a dedicated i686 SIG was already tried back when it was proposed to stop building kernel packages and installer images for i686. That SIG was formed and then basically never did anything. So I don't think it's going to work the second time, either ...
And this is the crux of the problem.
This is one of the periodic unusual Fedora change proposals where not adopting it, is defacto making a concious decision to force volunteers maintainers to continue to work on something that many consider to be undesirable and a technological dead end.
I very much doubt that pushing this down the road for another 2-4 releases will change the situation wrt steam requirements for i686. We'll just end up rehashing the same points and be no closer to a viable solution. IMHO we need some clear action to move us forward, rather than hoping that Valve suddenly decide to do something different after seemingly ignoring the problem for years. Fedora needs to control its own destiny.
IMHO, ideally there would be a counter proposal put forward for F44 by those who want to invest in i686 and steam, outlining a strategy for how to support i686 without the current cross-distro & build infra maint burden it currently imposes, even on maintainers whose packages are not consumed by Steam. We don't neccessarily need to deliver a full solution for F44 but, IMHO, we need to at least make some step forward towards a solution that is more sustainable than the status-quo.
Well said, thank you.
I wish discussion.fp.o posts were more like this ...
Fabio
On Wed, Jun 25, 2025 at 11:54:29AM +0200, Fabio Valentini wrote:
I wish discussion.fp.o posts were more like this ...
...it's almost like the folks who prefer to use email versus web forums may have different priorities from each other.
But make no mistake, killing off will effectively end Fedora as a viable target for playing games [1], and this will have serious implications for our userbase. Folks want one OS that does *everything*, and "being able to play games" has consistently ranked as one of the largest barriers to "average folks" adopting Linux.
(And while "let's push all of this onto Valve" solves the problem with Steam, that leaves out everything else..)
[1] As others have pointed out, a wide assortment of 32-bit libraries are still necessary for Wine, and that's not likely to meaningfully change in the next 12 months. Putting aside Wine, there's still the matter of 32-bit GPU driver stack as all existing runtimes expect that to be provided by the host OS. And anectdotally, most *native Linux* game binaries I have will forever remain x86-only.
- Solomon
With Wine solved, it sounds like Steam is the only remaining concern.
I think we could actually remove all 32-bit libraries *not* required by Steam for Fedora *43*. That should probably be uncontroversial, right? I know that doesn't do anything to help with our infrastructure concerns, but it will at least spare most maintainers from fixing 32-bit build failures.
On Wed, Jun 25, 2025 at 4:20 PM Michael Catanzaro mcatanzaro@redhat.com wrote:
With Wine solved, it sounds like Steam is the only remaining concern.
Wine is not solved yet, though.
I think we could actually remove all 32-bit libraries *not* required by Steam for Fedora *43*. That should probably be uncontroversial, right? I know that doesn't do anything to help with our infrastructure concerns, but it will at least spare most maintainers from fixing 32-bit build failures.
Reducing the scope of i686 is probably not too controversial, but I don't think we can do it for F43 or F44. There's some trial work that needs to be done first.
On Wed, 25 Jun 2025 at 10:21, Michael Catanzaro mcatanzaro@redhat.com wrote:
With Wine solved, it sounds like Steam is the only remaining concern.
I think we could actually remove all 32-bit libraries *not* required by Steam for Fedora *43*. That should probably be uncontroversial, right? I know that doesn't do anything to help with our infrastructure concerns, but it will at least spare most maintainers from fixing 32-bit build failures.
Going from all the previous infrastructure moves, the Fedora 43 schedule is going to be dominated with the move and rebuilding of the release infrastructure from the ground up. There are always all kinds of little things which pop up and slow down what can be done. The next release is usually then filled with everything that didn't get done because builds and updates were slowed down. Removing several thousand packages in a release would require
1. How are you going to remove it? Everyone add a ExcludeArch: , someone fix koji to only allow a specific list? a shadow koji which only builds for x86_32? etc 2. What else is broken that comes up because of this. Removing arm32 actually caused problems in completely unrelated parts of the build system because of weird things. 3. Who is going to do the work?
I really don't see this being ready by Fedora 44 with the current 'need to get 300+ cat-like developers to agree' that generally needs to happen.
On Wed, 25 Jun 2025 at 15:36, Stephen Smoogen ssmoogen@redhat.com wrote:
On Wed, 25 Jun 2025 at 10:21, Michael Catanzaro mcatanzaro@redhat.com wrote:
With Wine solved, it sounds like Steam is the only remaining concern.
I think we could actually remove all 32-bit libraries *not* required by Steam for Fedora *43*. That should probably be uncontroversial, right? I know that doesn't do anything to help with our infrastructure concerns, but it will at least spare most maintainers from fixing 32-bit build failures.
Going from all the previous infrastructure moves, the Fedora 43 schedule is going to be dominated with the move and rebuilding of the release infrastructure from the ground up. There are always all kinds of little things which pop up and slow down what can be done. The next release is usually then filled with everything that didn't get done because builds and updates were slowed down. Removing several thousand packages in a release would require
- How are you going to remove it? Everyone add a ExcludeArch: , someone fix koji to only allow a specific list? a shadow koji which only builds for x86_32? etc
We used to do a special list with koji for PowerPC for packages optimised for powerv7 as a 'ppc64v7' sub arch in the ppc64 BE days, you should be able to provide a list of "end packages" and have something like the the critical path script update the full list there and populate it for i686. The functionality is in already in koji.
- What else is broken that comes up because of this. Removing arm32 actually caused problems in completely unrelated parts of the build system because of weird things.
- Who is going to do the work?
I really don't see this being ready by Fedora 44 with the current 'need to get 300+ cat-like developers to agree' that generally needs to happen.
-- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Wed, 25 Jun 2025 at 12:52, Peter Robinson pbrobinson@gmail.com wrote:
On Wed, 25 Jun 2025 at 15:36, Stephen Smoogen ssmoogen@redhat.com wrote:
On Wed, 25 Jun 2025 at 10:21, Michael Catanzaro mcatanzaro@redhat.com
wrote:
With Wine solved, it sounds like Steam is the only remaining concern.
I think we could actually remove all 32-bit libraries *not* required by Steam for Fedora *43*. That should probably be uncontroversial, right? I know that doesn't do anything to help with our infrastructure concerns, but it will at least spare most maintainers from fixing 32-bit build failures.
Going from all the previous infrastructure moves, the Fedora 43 schedule
is going to be dominated with the move and rebuilding of the release infrastructure from the ground up. There are always all kinds of little things which pop up and slow down what can be done. The next release is usually then filled with everything that didn't get done because builds and updates were slowed down. Removing several thousand packages in a release would require
- How are you going to remove it? Everyone add a ExcludeArch: , someone
fix koji to only allow a specific list? a shadow koji which only builds for x86_32? etc
We used to do a special list with koji for PowerPC for packages optimised for powerv7 as a 'ppc64v7' sub arch in the ppc64 BE days, you should be able to provide a list of "end packages" and have something like the the critical path script update the full list there and populate it for i686. The functionality is in already in koji.
Understood. What I was trying to say, but failed, is that there are a lot of ways this could be solved, and Fedora needs to have time to generate consensus on which version can be safely done. I think that it would need to be done by the mass rebuild which seems scheduled around 2025-07-23 . I expect various things could be done 'compose' wise after that date but those would need to be 'done' by mid-August.
On Wed, 25 Jun 2025 17:51:15 +0100 Peter Robinson pbrobinson@gmail.com wrote:
On Wed, 25 Jun 2025 at 15:36, Stephen Smoogen ssmoogen@redhat.com wrote:
On Wed, 25 Jun 2025 at 10:21, Michael Catanzaro mcatanzaro@redhat.com wrote:
With Wine solved, it sounds like Steam is the only remaining concern.
I think we could actually remove all 32-bit libraries *not* required by Steam for Fedora *43*. That should probably be uncontroversial, right? I know that doesn't do anything to help with our infrastructure concerns, but it will at least spare most maintainers from fixing 32-bit build failures.
Going from all the previous infrastructure moves, the Fedora 43 schedule is going to be dominated with the move and rebuilding of the release infrastructure from the ground up. There are always all kinds of little things which pop up and slow down what can be done. The next release is usually then filled with everything that didn't get done because builds and updates were slowed down. Removing several thousand packages in a release would require
- How are you going to remove it? Everyone add a ExcludeArch: , someone fix koji to only allow a specific list? a shadow koji which only builds for x86_32? etc
We used to do a special list with koji for PowerPC for packages optimised for powerv7 as a 'ppc64v7' sub arch in the ppc64 BE days, you should be able to provide a list of "end packages" and have something like the the critical path script update the full list there and populate it for i686. The functionality is in already in koji.
right, that could perhaps do it for i686 too. IIRC it was ppc64p7 "subarch", likely in the RHEL-6 days and there was some handling in rpm (the tool) so ppc64 and ppc64p7 were considered compatible, but with ppc64p7 preferred on Power7 hw. And even more IIRC similar mechanism might had been used ages ago for building i586 kernels when i386 was the default, but that might predate koji :-) Although there might be an issue how the buildroot would be constructed, the ppc64p7 builds were separate buildArch tasks. Not sure if the buildroots were clean ppc64 and they just produced ppc64p7 rpms or if they mixed ppc64 and ppc64p7 ...
Dan
On Wed, 25 Jun 2025 at 18:21, Dan Horák dan@danny.cz wrote:
On Wed, 25 Jun 2025 17:51:15 +0100 Peter Robinson pbrobinson@gmail.com wrote:
On Wed, 25 Jun 2025 at 15:36, Stephen Smoogen ssmoogen@redhat.com wrote:
On Wed, 25 Jun 2025 at 10:21, Michael Catanzaro mcatanzaro@redhat.com wrote:
With Wine solved, it sounds like Steam is the only remaining concern.
I think we could actually remove all 32-bit libraries *not* required by Steam for Fedora *43*. That should probably be uncontroversial, right? I know that doesn't do anything to help with our infrastructure concerns, but it will at least spare most maintainers from fixing 32-bit build failures.
Going from all the previous infrastructure moves, the Fedora 43 schedule is going to be dominated with the move and rebuilding of the release infrastructure from the ground up. There are always all kinds of little things which pop up and slow down what can be done. The next release is usually then filled with everything that didn't get done because builds and updates were slowed down. Removing several thousand packages in a release would require
- How are you going to remove it? Everyone add a ExcludeArch: , someone fix koji to only allow a specific list? a shadow koji which only builds for x86_32? etc
We used to do a special list with koji for PowerPC for packages optimised for powerv7 as a 'ppc64v7' sub arch in the ppc64 BE days, you should be able to provide a list of "end packages" and have something like the the critical path script update the full list there and populate it for i686. The functionality is in already in koji.
right, that could perhaps do it for i686 too. IIRC it was ppc64p7
You are correct, the details of this are sadly paging back into memory :-D
"subarch", likely in the RHEL-6 days and there was some handling in rpm (the tool) so ppc64 and ppc64p7 were considered compatible, but with ppc64p7 preferred on Power7 hw. And even more IIRC similar
It was a nasty hack in the original yum. Thankfully it all went away before we merged the secondary kojis into main koji around f26 so sadly the actual koji details are lost with the ppc instance.
mechanism might had been used ages ago for building i586 kernels when i386 was the default, but that might predate koji :-) Although there might be an issue how the buildroot would be constructed, the ppc64p7 builds were separate buildArch tasks. Not sure if the buildroots were clean ppc64 and they just produced ppc64p7 rpms or if they mixed ppc64 and ppc64p7 ...
They inherited from ppc64, but none of the the hacks would be needed for i686 as it would be a default arch without any of the sub-arch nonsense. None of the yum hacks would be needed client side because it would just have the rpms that are available for the arch just like any other repo. It would just be updating the build list (what ever the variable is called, I do have it all buried in notes somewhere).
From a koji build PoV it should be straight forward, but of course it means the toolchain team and friends would still need to maintain all the build infra packages like gcc/glibc and friends.
On Wed, 25 Jun 2025 18:30:39 +0100 Peter Robinson pbrobinson@gmail.com wrote:
On Wed, 25 Jun 2025 at 18:21, Dan Horák dan@danny.cz wrote:
On Wed, 25 Jun 2025 17:51:15 +0100 Peter Robinson pbrobinson@gmail.com wrote:
On Wed, 25 Jun 2025 at 15:36, Stephen Smoogen ssmoogen@redhat.com wrote:
On Wed, 25 Jun 2025 at 10:21, Michael Catanzaro mcatanzaro@redhat.com wrote:
With Wine solved, it sounds like Steam is the only remaining concern.
I think we could actually remove all 32-bit libraries *not* required by Steam for Fedora *43*. That should probably be uncontroversial, right? I know that doesn't do anything to help with our infrastructure concerns, but it will at least spare most maintainers from fixing 32-bit build failures.
Going from all the previous infrastructure moves, the Fedora 43 schedule is going to be dominated with the move and rebuilding of the release infrastructure from the ground up. There are always all kinds of little things which pop up and slow down what can be done. The next release is usually then filled with everything that didn't get done because builds and updates were slowed down. Removing several thousand packages in a release would require
- How are you going to remove it? Everyone add a ExcludeArch: , someone fix koji to only allow a specific list? a shadow koji which only builds for x86_32? etc
We used to do a special list with koji for PowerPC for packages optimised for powerv7 as a 'ppc64v7' sub arch in the ppc64 BE days, you should be able to provide a list of "end packages" and have something like the the critical path script update the full list there and populate it for i686. The functionality is in already in koji.
right, that could perhaps do it for i686 too. IIRC it was ppc64p7
You are correct, the details of this are sadly paging back into memory :-D
"subarch", likely in the RHEL-6 days and there was some handling in rpm (the tool) so ppc64 and ppc64p7 were considered compatible, but with ppc64p7 preferred on Power7 hw. And even more IIRC similar
It was a nasty hack in the original yum. Thankfully it all went away before we merged the secondary kojis into main koji around f26 so sadly the actual koji details are lost with the ppc instance.
hmm, there could be some remains left in brew ...
for the record, there was even a "Change" for ppc64p7 :-) https://fedoraproject.org/wiki/Features/Power7Subarch
Dan
mechanism might had been used ages ago for building i586 kernels when i386 was the default, but that might predate koji :-) Although there might be an issue how the buildroot would be constructed, the ppc64p7 builds were separate buildArch tasks. Not sure if the buildroots were clean ppc64 and they just produced ppc64p7 rpms or if they mixed ppc64 and ppc64p7 ...
They inherited from ppc64, but none of the the hacks would be needed for i686 as it would be a default arch without any of the sub-arch nonsense. None of the yum hacks would be needed client side because it would just have the rpms that are available for the arch just like any other repo. It would just be updating the build list (what ever the variable is called, I do have it all buried in notes somewhere).
From a koji build PoV it should be straight forward, but of course it means the toolchain team and friends would still need to maintain all the build infra packages like gcc/glibc and friends. -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
W dniu 25.06.2025 o 16:35, Stephen Smoogen pisze:
- How are you going to remove it? Everyone add a ExcludeArch: , someone
fix koji to only allow a specific list? a shadow koji which only builds for x86_32? etc
From what I read in the past I think that it would be better to rather have something like "IncludeArch: i686" and disable 32-bit x86 globally.
The list of packages to build for i686 is probably shorter than list with rest of packages.
glibc, toolchain, kernel headers, then things needed for infrastructure and needed libraries and their dependences.
On Thu, Jun 26, 2025 at 2:55 AM Marcin Juszkiewicz mjuszkiewicz@redhat.com wrote:
W dniu 25.06.2025 o 16:35, Stephen Smoogen pisze:
- How are you going to remove it? Everyone add a ExcludeArch: , someone
fix koji to only allow a specific list? a shadow koji which only builds for x86_32? etc
From what I read in the past I think that it would be better to rather have something like "IncludeArch: i686" and disable 32-bit x86 globally.
The list of packages to build for i686 is probably shorter than list with rest of packages.
glibc, toolchain, kernel headers, then things needed for infrastructure and needed libraries and their dependences.
I'd prefer if we started with this, and work out the list of packages that need i686 and drop the rest.
I think starting from mesa-* and getting all the dependencies might be a good start, but maybe we should look into cross compiling mesa i686 from x86-64 so we can reduce it further as mesa needs a lot of python to build.
Now in stating that we just literally broke this with llvm in f42, so that cross compiles were a lot more painful, but I think we've stepped that back.
Dave.
On Thu, Jun 26, 2025 at 5:24 AM David Airlie airlied@redhat.com wrote:
On Thu, Jun 26, 2025 at 2:55 AM Marcin Juszkiewicz mjuszkiewicz@redhat.com wrote:
W dniu 25.06.2025 o 16:35, Stephen Smoogen pisze:
- How are you going to remove it? Everyone add a ExcludeArch: , someone
fix koji to only allow a specific list? a shadow koji which only builds for x86_32? etc
From what I read in the past I think that it would be better to rather have something like "IncludeArch: i686" and disable 32-bit x86 globally.
The list of packages to build for i686 is probably shorter than list with rest of packages.
glibc, toolchain, kernel headers, then things needed for infrastructure and needed libraries and their dependences.
I'd prefer if we started with this, and work out the list of packages that need i686 and drop the rest.
I think starting from mesa-* and getting all the dependencies might be a good start, but maybe we should look into cross compiling mesa i686 from x86-64 so we can reduce it further as mesa needs a lot of python to build.
Now in stating that we just literally broke this with llvm in f42, so that cross compiles were a lot more painful, but I think we've stepped that back.
Just to provide some more information, here all mesa's non-default build dependencies that would need i686 treatment.
DEBUG util.py:461: DirectX-Headers-devel i686 1.615.0-1.fc43 build 3.5 MiB DEBUG util.py:461: bindgen-cli i686 0.71.1-1.fc43 build 6.1 MiB DEBUG util.py:461: bison i686 3.8.2-10.fc43 build 3.5 MiB DEBUG util.py:461: cargo-rpm-macros noarch 26.3-4.fc42 build 14.7 KiB DEBUG util.py:461: cbindgen i686 0.28.0-1.fc43 build 4.7 MiB DEBUG util.py:461: clang-devel i686 20.1.6-9.fc43 build 28.5 MiB DEBUG util.py:461: elfutils-libelf-devel i686 0.193-2.fc43 build 49.9 KiB DEBUG util.py:461: expat-devel i686 2.7.1-1.fc43 build 202.9 KiB DEBUG util.py:461: flex i686 2.6.4-19.fc42 build 791.1 KiB DEBUG util.py:461: gcc i686 15.1.1-2.fc43 build 109.7 MiB DEBUG util.py:461: gcc-c++ i686 15.1.1-2.fc43 build 42.5 MiB DEBUG util.py:461: gettext i686 0.25-1.fc43 build 13.0 MiB DEBUG util.py:461: glslang i686 15.3.0-1.fc43 build 3.4 MiB DEBUG util.py:461: kernel-headers i686 6.16.0-0.rc2.24.fc43 build 6.7 MiB DEBUG util.py:461: libX11-devel i686 1.8.11-1.fc42 build 1.0 MiB DEBUG util.py:461: libXdamage-devel i686 1.1.6-5.fc42 build 2.5 KiB DEBUG util.py:461: libXext-devel i686 1.3.6-3.fc42 build 98.8 KiB DEBUG util.py:461: libXfixes-devel i686 6.0.1-5.fc42 build 9.2 KiB DEBUG util.py:461: libXrandr-devel i686 1.5.4-5.fc42 build 21.8 KiB DEBUG util.py:461: libXxf86vm-devel i686 1.1.6-2.fc42 build 12.1 KiB DEBUG util.py:461: libclc-devel i686 20.1.6-1.fc43 build 123.6 KiB DEBUG util.py:461: libdrm-devel i686 2.4.124-2.fc42 build 708.5 KiB DEBUG util.py:461: libglvnd-core-devel i686 1:1.7.0-7.fc42 build 40.3 KiB DEBUG util.py:461: libselinux-devel i686 3.8-3.fc43 build 126.8 KiB DEBUG util.py:461: libunwind-devel i686 1.8.1-2.fc43 build 137.1 KiB DEBUG util.py:461: libva-devel i686 2.22.0-4.fc42 build 696.6 KiB DEBUG util.py:461: libvdpau-devel i686 1.5-9.fc42 build 207.5 KiB DEBUG util.py:461: libxcb-devel i686 1.17.0-5.fc42 build 2.7 MiB DEBUG util.py:461: libxshmfence-devel i686 1.3.2-6.fc42 build 1.9 KiB DEBUG util.py:461: libzstd-devel i686 1.5.7-1.fc43 build 208.0 KiB DEBUG util.py:461: llvm-devel i686 20.1.6-9.fc43 build 28.7 MiB DEBUG util.py:461: lm_sensors-devel i686 3.6.0-22.fc42 build 18.4 KiB DEBUG util.py:461: meson noarch 1.8.1-5.fc43 build 13.2 MiB DEBUG util.py:461: python3-devel i686 3.14.0~b3-1.fc43 build 1.9 MiB DEBUG util.py:461: python3-mako noarch 1.2.3-10.fc43 build 712.1 KiB DEBUG util.py:461: python3-ply noarch 3.11-27.fc43 build 575.3 KiB DEBUG util.py:461: python3-pycparser noarch 2.22-2.fc43 build 1.5 MiB DEBUG util.py:461: python3-pyyaml i686 6.0.2-3.fc43 build 814.4 KiB DEBUG util.py:461: rust-paste-devel noarch 1.0.15-3.fc42 build 64.9 KiB DEBUG util.py:461: rust-proc-macro2-devel noarch 1.0.95-1.fc43 build 210.5 KiB DEBUG util.py:461: rust-quote-devel noarch 1.0.40-1.fc43 build 120.1 KiB DEBUG util.py:461: rust-syn+clone-impls-devel noarch 2.0.101-1.fc43 build 4.9 KiB DEBUG util.py:461: rust-unicode-ident-devel noarch 1.0.18-1.fc43 build 305.7 KiB DEBUG util.py:461: spirv-llvm-translator-devel i686 20.1.0-1.fc43 build 23.6 KiB DEBUG util.py:461: spirv-tools-devel i686 2025.2-1.fc43 build 164.4 KiB DEBUG util.py:461: valgrind-devel i686 1:3.25.1-1.fc43 build 533.7 KiB DEBUG util.py:461: vulkan-headers noarch 1.4.313.0-1.fc43 build 30.9 MiB DEBUG util.py:461: vulkan-loader-devel i686 1.4.313.0-1.fc43 build 8.0 KiB DEBUG util.py:461: wayland-devel i686 1.23.1-1.fc43 build 678.1 KiB DEBUG util.py:461: wayland-protocols-devel noarch 1.45-1.fc43 build 966.4 KiB DEBUG util.py:461: xorg-x11-proto-devel noarch 2024.1-4.fc42 build 1.7 MiB DEBUG util.py:461: zlib-ng-compat-devel i686 2.2.4-2.fc43 build 107.0 KiB DEBUG util.py:461: Installing dependencies: DEBUG util.py:461: annobin-docs noarch 12.96-1.fc43 build 98.9 KiB DEBUG util.py:461: annobin-plugin-gcc i686 12.96-1.fc43 build 996.6 KiB DEBUG util.py:461: cargo i686 1.87.0-2.fc43 build 26.0 MiB DEBUG util.py:461: cargo2rpm noarch 0.1.18-3.fc43 build 1.3 MiB DEBUG util.py:461: clang i686 20.1.6-9.fc43 build 397.3 KiB DEBUG util.py:461: clang-libs i686 20.1.6-9.fc43 build 119.7 MiB DEBUG util.py:461: clang-resource-filesystem i686 20.1.6-9.fc43 build 15.3 KiB DEBUG util.py:461: clang-tools-extra i686 20.1.6-9.fc43 build 70.6 MiB DEBUG util.py:461: cmake-filesystem i686 3.31.6-3.fc43 build 0.0 B DEBUG util.py:461: cpp i686 15.1.1-2.fc43 build 39.0 MiB DEBUG util.py:461: emacs-filesystem noarch 1:30.0-4.fc42 build 0.0 B DEBUG util.py:461: expat i686 2.7.1-1.fc43 build 292.6 KiB DEBUG util.py:461: gcc-plugin-annobin i686 15.1.1-2.fc43 build 59.9 KiB DEBUG util.py:461: gettext-envsubst i686 0.25-1.fc43 build 86.8 KiB DEBUG util.py:461: gettext-libs i686 0.25-1.fc43 build 2.3 MiB DEBUG util.py:461: gettext-runtime i686 0.25-1.fc43 build 451.4 KiB DEBUG util.py:461: glibc-devel i686 2.41.9000-16.fc43 build 2.3 MiB DEBUG util.py:461: hwdata noarch 0.396-1.fc43 build 9.5 MiB DEBUG util.py:461: libX11 i686 1.8.11-1.fc42 build 1.3 MiB DEBUG util.py:461: libX11-common noarch 1.8.11-1.fc42 build 1.2 MiB DEBUG util.py:461: libX11-xcb i686 1.8.11-1.fc42 build 10.2 KiB DEBUG util.py:461: libXau i686 1.0.12-2.fc42 build 72.2 KiB DEBUG util.py:461: libXau-devel i686 1.0.12-2.fc42 build 7.5 KiB DEBUG util.py:461: libXdamage i686 1.1.6-5.fc42 build 42.9 KiB DEBUG util.py:461: libXext i686 1.3.6-3.fc42 build 96.8 KiB DEBUG util.py:461: libXfixes i686 6.0.1-5.fc42 build 33.5 KiB DEBUG util.py:461: libXrandr i686 1.5.4-5.fc42 build 63.0 KiB DEBUG util.py:461: libXrender i686 0.9.12-2.fc42 build 53.2 KiB DEBUG util.py:461: libXrender-devel i686 0.9.12-2.fc42 build 50.1 KiB DEBUG util.py:461: libXxf86vm i686 1.1.6-2.fc42 build 28.4 KiB DEBUG util.py:461: libasan i686 15.1.1-2.fc43 build 1.9 MiB DEBUG util.py:461: libatomic i686 15.1.1-2.fc43 build 23.5 KiB DEBUG util.py:461: libclc i686 20.1.6-1.fc43 build 72.6 MiB DEBUG util.py:461: libclc-spirv i686 20.1.6-1.fc43 build 5.3 MiB DEBUG util.py:461: libdrm i686 2.4.124-2.fc42 build 431.8 KiB DEBUG util.py:461: libedit i686 3.1-55.20250104cvs.fc42 build 243.4 KiB DEBUG util.py:461: libedit-devel i686 3.1-55.20250104cvs.fc42 build 59.4 KiB DEBUG util.py:461: libffi-devel i686 3.5.1-1.fc43 build 33.9 KiB DEBUG util.py:461: libgit2 i686 1.9.0-5.fc43 build 1.4 MiB DEBUG util.py:461: libglvnd i686 1:1.7.0-7.fc42 build 471.7 KiB DEBUG util.py:461: libglvnd-glx i686 1:1.7.0-7.fc42 build 615.5 KiB DEBUG util.py:461: libmpc i686 1.3.1-7.fc42 build 167.9 KiB DEBUG util.py:461: libpciaccess i686 0.16-15.fc42 build 47.8 KiB DEBUG util.py:461: libpciaccess-devel i686 0.16-15.fc42 build 15.3 KiB DEBUG util.py:461: libsepol-devel i686 3.8-1.fc42 build 120.8 KiB DEBUG util.py:461: libssh2 i686 1.11.1-3.fc42 build 337.7 KiB DEBUG util.py:461: libstdc++-devel i686 15.1.1-2.fc43 build 15.5 MiB DEBUG util.py:461: libtextstyle i686 0.25-1.fc43 build 389.3 KiB DEBUG util.py:461: libubsan i686 15.1.1-2.fc43 build 550.9 KiB DEBUG util.py:461: libunwind i686 1.8.1-2.fc43 build 179.5 KiB DEBUG util.py:461: libva i686 2.22.0-4.fc42 build 357.3 KiB DEBUG util.py:461: libvdpau i686 1.5-9.fc42 build 20.0 KiB DEBUG util.py:461: libvdpau-trace i686 1.5-9.fc42 build 76.0 KiB DEBUG util.py:461: libwayland-client i686 1.23.1-1.fc43 build 53.0 KiB DEBUG util.py:461: libwayland-cursor i686 1.23.1-1.fc43 build 32.3 KiB DEBUG util.py:461: libwayland-egl i686 1.23.1-1.fc43 build 11.7 KiB DEBUG util.py:461: libwayland-server i686 1.23.1-1.fc43 build 77.5 KiB DEBUG util.py:461: libxcb i686 1.17.0-5.fc42 build 1.0 MiB DEBUG util.py:461: libxcrypt-devel i686 4.4.38-7.fc43 build 30.8 KiB DEBUG util.py:461: libxshmfence i686 1.3.2-6.fc42 build 11.7 KiB DEBUG util.py:461: libyaml i686 0.2.5-16.fc42 build 129.9 KiB DEBUG util.py:461: llhttp i686 9.3.0-4.fc43 build 91.8 KiB DEBUG util.py:461: llvm i686 20.1.6-9.fc43 build 94.8 MiB DEBUG util.py:461: llvm-filesystem i686 20.1.6-9.fc43 build 0.0 B DEBUG util.py:461: llvm-googletest i686 20.1.6-9.fc43 build 2.1 MiB DEBUG util.py:461: llvm-libs i686 20.1.6-9.fc43 build 142.8 MiB DEBUG util.py:461: llvm-static i686 20.1.6-9.fc43 build 313.6 MiB DEBUG util.py:461: llvm-test i686 20.1.6-9.fc43 build 2.2 MiB DEBUG util.py:461: lm_sensors-libs i686 3.6.0-22.fc42 build 81.0 KiB DEBUG util.py:461: m4 i686 1.4.20-1.fc43 build 847.1 KiB DEBUG util.py:461: make i686 1:4.4.1-10.fc42 build 1.8 MiB DEBUG util.py:461: mesa-dri-drivers i686 25.1.3-2.fc43 build 50.0 MiB DEBUG util.py:461: mesa-filesystem i686 25.1.3-2.fc43 build 3.6 KiB DEBUG util.py:461: mesa-libGL i686 25.1.3-2.fc43 build 337.5 KiB DEBUG util.py:461: mesa-libgbm i686 25.1.3-2.fc43 build 18.9 KiB DEBUG util.py:461: mpdecimal i686 4.0.1-1.fc43 build 216.4 KiB DEBUG util.py:461: ncurses-c++-libs i686 6.5-6.20250614.fc43 build 144.0 KiB DEBUG util.py:461: ncurses-devel i686 6.5-6.20250614.fc43 build 893.4 KiB DEBUG util.py:461: ninja-build i686 1.12.1-5.fc43 build 473.8 KiB DEBUG util.py:461: pcre2-devel i686 10.45-1.fc43 build 2.1 MiB DEBUG util.py:461: pcre2-utf16 i686 10.45-1.fc43 build 621.5 KiB DEBUG util.py:461: pcre2-utf32 i686 10.45-1.fc43 build 593.4 KiB DEBUG util.py:461: pyproject-rpm-macros noarch 1.18.1-1.fc43 build 114.5 KiB DEBUG util.py:461: python-pip-wheel noarch 25.1.1-4.fc43 build 1.2 MiB DEBUG util.py:461: python-rpm-macros noarch 3.14-1.fc43 build 22.1 KiB DEBUG util.py:461: python3 i686 3.14.0~b3-1.fc43 build 28.0 KiB DEBUG util.py:461: python3-libs i686 3.14.0~b3-1.fc43 build 42.5 MiB DEBUG util.py:461: python3-markupsafe i686 3.0.2-3.fc43 build 60.6 KiB DEBUG util.py:461: python3-packaging noarch 25.0-3.fc43 build 607.5 KiB DEBUG util.py:461: python3-rpm-generators noarch 14-12.fc42 build 81.7 KiB DEBUG util.py:461: python3-rpm-macros noarch 3.14-1.fc43 build 6.4 KiB DEBUG util.py:461: python3-setuptools noarch 78.1.1-7.fc43 build 9.0 MiB DEBUG util.py:461: rust i686 1.87.0-2.fc43 build 111.8 MiB DEBUG util.py:461: rust-std-static i686 1.87.0-2.fc43 build 137.8 MiB DEBUG util.py:461: rust-syn-devel noarch 2.0.101-1.fc43 build 2.1 MiB DEBUG util.py:461: rust-unicode-ident+default-devel noarch 1.0.18-1.fc43 build 2.0 KiB DEBUG util.py:461: spirv-llvm-translator i686 20.1.0-1.fc43 build 4.0 MiB DEBUG util.py:461: spirv-tools-libs i686 2025.2-1.fc43 build 6.0 MiB DEBUG util.py:461: tzdata noarch 2025b-1.fc43 build 1.6 MiB DEBUG util.py:461: vim-filesystem noarch 2:9.1.1435-1.fc43 build 40.0 B DEBUG util.py:461: vulkan-loader i686 1.4.313.0-1.fc43 build 575.8 KiB
Dave.
On 6/25/25 9:19 AM, Michael Catanzaro wrote:
With Wine solved, it sounds like Steam is the only remaining concern.
I hate to be pessimistic but I think it is premature to say it is "solved" until users use the new Wow64 mode. I'm trying to get the merge in this week.
What annoys me (in a light-hearted way) is that people assume Wine is just like any other package and attempt to update it in some way (maybe even a simple version bump) and it breaks and they ghost. Wine is more complicated than other Fedora packages. It could really use a dedicated RH employee, which RH has never offered and I think this is a RH deficiency. RH has never marketed the ability to use Windows software in RHEL. Probably some political reasons. Maybe some legal reasons. However there was one point in time I was contacted from some RH folks about using Wine in containers to run Windows stuff in RHEL. I don't think it went anywhere.
I think we could actually remove all 32-bit libraries *not* required by Steam for Fedora *43*. That should probably be uncontroversial, right? I know that doesn't do anything to help with our infrastructure concerns, but it will at least spare most maintainers from fixing 32-bit build failures.
This is an obvious solution that another distro has done. I think it could be improved upon by removing multi-lib and offering an "i686" package instead. This would remove the concerns everyone has around multi-lib and restrict maintenance to a single (maybe a meta) package. Building and running i686 packages are two different things. I think we could remove i686 from multi-lib to remove building. Offer a different package for runtime. Maybe its container based. This email thread is too limiting to solution.
It would be nice if RH would set aside a meeting or two to discuss this via call or video. :)
On 6/25/25 9:36 AM, Michael Cronenworth wrote:
I hate to be pessimistic but I think it is premature to say it is "solved" until users use the new Wow64 mode. I'm trying to get the merge in this week.
Rawhide, 10.4-5, is now built with new wow64 as the default. Please test it. F42 will receive a test build once the Mesa update has gone to stable.
On Thu, Jun 26, 2025 at 5:14 AM Michael Cronenworth mike@cchtml.com wrote:
On 6/25/25 9:36 AM, Michael Cronenworth wrote:
I hate to be pessimistic but I think it is premature to say it is "solved" until users use the new Wow64 mode. I'm trying to get the merge in this week.
Rawhide, 10.4-5, is now built with new wow64 as the default. Please test it. F42 will receive a test build once the Mesa update has gone to stable.
Hi Michael,
Thank you for working on this! I'm curious to see how the new WoW64 mode will be working out. I've read that Arch users have seen some issues when it was enabled there by default a few days ago. But I'm hoping that with more people starting to use it, bugs will be found and fixed :)
Fabio
On Wednesday, 25 June 2025 at 16:19, Michael Catanzaro wrote:
With Wine solved, it sounds like Steam is the only remaining concern.
It is not. There are tons of Linux-native games, e.g. from GOG (gog.com) that people like myself have purchased and want to play. Many of them were built as 32-bit x86 only and use an old build of the Unity Engine. For example, ABC Murders has the following direct i686 requirements:
gdk-pixbuf2.i686 glib2.i686 glibc.i686 gtk2.i686 libgcc.i686 libglvnd-glx.i686 libstdc++.i686 libX11.i686 libXcursor.i686 libXrandr.i686 mesa-dri-drivers.i686 pulseaudio-libs.i686 systemd-libs.i686
I haven't walked the dependency graph to find all dependencies of these.
There's a game Botanicula that is written using Adobe AIR and requires that old AIR runtime to run. This has direct requirement on the following:
atk.i686 cairo.i686 dbus-libs.i686 fontconfig.i686 freetype.i686 gdk-pixbuf2.i686 glib2.i686 glibc.i686 gtk2.i686 gtk2-engines.i686 libcurl.i686 libgcc.i686 libglvnd-glx.i686 libstdc++.i686 libX11.i686 libXcursor.i686 libxml2.i686 libXrender.i686 libxslt.i686 libXt.i686 nspr.i686 nss.i686 pango.i686 zlib-ng-compat.i686
There are probably still 32-bit games using other engines that I don't have access to.
I think we could actually remove all 32-bit libraries *not* required by Steam for Fedora *43*. That should probably be uncontroversial, right?
If that included the above packages and their dependencies then I'd be fine with that.
I know that doesn't do anything to help with our infrastructure concerns, but it will at least spare most maintainers from fixing 32-bit build failures.
+1 to that.
Regards, Dominik
I think we could actually remove all 32-bit libraries *not* required by Steam for Fedora *43*. That should probably be uncontroversial, right?
If that included the above packages and their dependencies then I'd be fine with that.
I don't think this is a solution, cause the list of the dependencies would just grow and it is almost impossible to go over all the libraries needed by all the games. So just adding a couple more libraries to the list changes nothing. Just because the games you like need those libraries specifically does not mean other games do not need other libraries. I don't have an elegant solution to the problem but I don't think this is a good solution either.
Best regards,
Pavol.
On Thu, Jun 26, 2025 at 9:39 AM Dominik 'Rathann' Mierzejewski via devel < devel@lists.fedoraproject.org> wrote:
On Wednesday, 25 June 2025 at 16:19, Michael Catanzaro wrote:
With Wine solved, it sounds like Steam is the only remaining concern.
It is not. There are tons of Linux-native games, e.g. from GOG (gog.com) that people like myself have purchased and want to play. Many of them were built as 32-bit x86 only and use an old build of the Unity Engine. For example, ABC Murders has the following direct i686 requirements:
gdk-pixbuf2.i686 glib2.i686 glibc.i686 gtk2.i686 libgcc.i686 libglvnd-glx.i686 libstdc++.i686 libX11.i686 libXcursor.i686 libXrandr.i686 mesa-dri-drivers.i686 pulseaudio-libs.i686 systemd-libs.i686
I haven't walked the dependency graph to find all dependencies of these.
There's a game Botanicula that is written using Adobe AIR and requires that old AIR runtime to run. This has direct requirement on the following:
atk.i686 cairo.i686 dbus-libs.i686 fontconfig.i686 freetype.i686 gdk-pixbuf2.i686 glib2.i686 glibc.i686 gtk2.i686 gtk2-engines.i686 libcurl.i686 libgcc.i686 libglvnd-glx.i686 libstdc++.i686 libX11.i686 libXcursor.i686 libxml2.i686 libXrender.i686 libxslt.i686 libXt.i686 nspr.i686 nss.i686 pango.i686 zlib-ng-compat.i686
There are probably still 32-bit games using other engines that I don't have access to.
I think we could actually remove all 32-bit libraries *not* required by Steam for Fedora *43*. That should probably be uncontroversial, right?
If that included the above packages and their dependencies then I'd be fine with that.
I know that doesn't do anything to help with our infrastructure concerns, but it will at least spare most maintainers from fixing 32-bit build failures.
+1 to that.
Regards, Dominik -- Fedora https://fedoraproject.org Deep in the human unconscious is a pervasive need for a logical universe that makes sense. But the real universe is always one step beyond logic. -- from "The Sayings of Muad'Dib" by the Princess Irulan -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Thu, Jun 26 2025 at 09:37:37 AM +02:00:00, Dominik 'Rathann' Mierzejewski via devel devel@lists.fedoraproject.org wrote:
It is not. There are tons of Linux-native games, e.g. from GOG (gog.com) that people like myself have purchased and want to play. Many of them were built as 32-bit x86 only and use an old build of the Unity Engine. For example, ABC Murders has the following direct i686 requirements:
Proprietary software with too many host dependencies is a ticking time bomb. It's going to break eventually no matter what we do, and it's probably not worth spending too much time to worry about? Notably, *both* of your examples are already impossible because you can't install glib2.i686 on an x86_64 system anymore due to https://bugzilla.redhat.com/show_bug.cgi?id=2258600. This is theoretically fixable, if somebody wanted to attempt to fix it, but it indicates that nobody is currently using software that depends on glib2.i686.
Adobe AIR has an additional challenge besides the glib2.i686 dependency: you say it has a direct requirement on libxml2. If that's true, then bad news: libxml2 just bumped its ABI version. I guess you could try creating a libxml2 compat package to keep old proprietary software working, so it's not an insurmountable challenge, but beware the CVE burden for libxml2 package is considerable and it will become much harder to maintain over time, so it's not a good idea to do so.
Michael
On Thu, Jun 26 2025 at 10:36:51 AM -05:00:00, Michael Catanzaro mcatanzaro@redhat.com wrote:
Notably, *both* of your examples are already impossible because you can't install glib2.i686 on an x86_64 system anymore due to https://bugzilla.redhat.com/show_bug.cgi?id=2258600. This is theoretically fixable, if somebody wanted to attempt to fix it, but it indicates that nobody is currently using software that depends on glib2.i686.
Ah, hey whoops, Dominik has pointed out this bug is for the -devel subpackages, so in practice it is not going to block use of glib2.i686. I'm just wrong.
Notably, *both* of your examples are already impossible because you can't install glib2.i686 on an x86_64 system anymore due to https://bugzilla.redhat.com/show_bug.cgi?id=2258600.
The bug is about a conflict in -devel packages. Installing base glib2.x86_64 and glib2.i686 packages is totally possible.
Artur FI
On Wed, Jun 25, 2025, at 11:19, Daniel P. Berrangé wrote:
This is one of the periodic unusual Fedora change proposals where not adopting it, is defacto making a concious decision to force volunteers maintainers to continue to work on something that many consider to be undesirable and a technological dead end.
Thanks for articulating it this way. Personally I would have not been able to state it this clearly.
On Tue, Jun 24, 2025 at 12:26:27PM -0500, Michael Cronenworth wrote:
Red Hat's enterprise ambitions may not take it near Valve headquarters, but I do not see why gaming has to be the primary selling point. RHEL 10 removed i686 but I would not be surprised to see it return once customers attempt to upgrade.
If a RHEL user still needs i686 multilib support, the solution is to continue to use RHEL-9 either on the host, or as a VM, or as a container. RHEL-9 lifetime has a long way to run yet, and by the end of RHEL-9, i686 multi-lib will be even more niche than it already is.
Also in terms of precedent, RHEL has been willing to drop support for old HW/SW platforms. Most recently the big example is the requirement for x86_64-v2 ABI in RHEL-9, further bumped to x86_64-v3 ABI in RHEL-10, which likely affected more RHEL users than dropping i686 will.
With regards, Daniel
On Tue, Jun 24, 2025 at 10:07 AM Aoife Moloney via devel-announce devel-announce@lists.fedoraproject.org wrote:
By dropping completely the i686 architecture, Fedora will decrease the burden on package maintainers, release engineering, infrastructure, and users.
A completely out-of-the-box alternative to reducing package maintainer efforts (I don't like this idea, but I think it should be explicitly rejected) is that any package which fails to build or fails functionality in i686 can, at the packagers choice, either be fixed by them, or have an ExcludeArch added such that it will fall off the end of Fedora support (notice to some list for adding an ExcludeArch under the "He's dead, Jim" heading is probably appropriate). Those that need/want/wish for i686 support to continue for that package will be expected to offer a tested in a COPR?) and testable MR to fix the build/functionality This places much of the burden of support onto the people who want such support (and while I do realize that some of the people who want support may not be able to provide the MR, that means they will need to find/fund someone else to do so. TANSTAAFL).
One of the many problems of such an approach is that it will not be possible to predict when something really important will break, resulting in dozens (or all) of other packages/builds breaking.
Now is the time to reject this alternative.
On Tue, 2025-06-24 at 21:58 +0000, Gary Buhrmaster wrote:
This places much of the burden of support onto the people who want such support (and while I do realize that some of the people who want support may not be able to provide the MR, that means they will need to find/fund someone else to do so. TANSTAAFL).
It doesn't, though. It still means we have to maintain all the weird infrastructure for putting i686 packages in x86_64 repos, and any other work we want to do on infrastructure or testing has to account for that weirdness. That, to me, is the primary cost of maintaining i686 support. It's not about build failures.
On Tue, Jun 24, 2025 at 10:47 PM Adam Williamson adamwill@fedoraproject.org wrote:
It doesn't, though. It still means we have to maintain all the weird infrastructure for putting i686 packages in x86_64 repos, and any other work we want to do on infrastructure or testing has to account for that weirdness. That, to me, is the primary cost of maintaining i686 support. It's not about build failures.
I have sometimes wondered if putting i686 packages in x86_64 repos was a bad idea, and instead leaving a i686 repo (with a smaller and smaller package set) as a standalone repo that individuals could add if they needed multilib. I don't recall the entire reasoning the various decisions, and at this point, probably water under the bridge, unless it is time to build a dam and divert the packages to a different repo (call it multilib, if you don't want to imply i686 is supported?).
In any case, allowing packagers to be aggressive in adding ExcludeArch could be a first step even if it does not help infrastructure or QA immediately (fixing everything everywhere all at once is probably not achievable).
On Tue, Jun 24, 2025 at 8:07 PM Aoife Moloney via devel-announce devel-announce@lists.fedoraproject.org wrote:
Wiki - https://fedoraproject.org/wiki/Changes/Drop_i686_support Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-drop-i686-support...
This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary ==
Fedora package repositories for the x86_64 architecture no longer include libraries for compatibility with 32-bit applications ("multilib"), and packages are no longer built for the i686 architecture.
== Owner ==
- Name: [[User:Decathorpe| Fabio Valentini]], [[User:Fale|Fale]],
[[User:Kevin|Kevin Fenzi]]
- Email: decathorpe (at) gmail (dot) com, mail (at) fale (dot) io,
kevin (at) scrye (dot) com
== Detailed Description ==
Fedora stopped providing [https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels kernel packages, installer images] and stopped publishing [https://fedoraproject.org/wiki/Changes/Noi686Repositories i686 package repositories] with Fedora 31. However, packages were by default still built for the i686 architecture, since they were required for running 32-bit applications on x86_64 hosts ("multilib").
Since Fedora 37, leaf packages (i.e. packages that are not depended on by other packages) can simply [https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval stop building for i686] without any reason, which has allowed package maintainers to focus their work on architectures where packages are actually shipped to users.
This Change Proposal implements the next two (and last) steps:
- Packages built for the i686 architecture are no longer included in
x86_64 repositories (dropping "multilib" support, i.e. support for running 32-bit userspace on a 64-bit host).
- Packages are no longer built for the i686 architecture.
This is intentionally planned as a two-step process - the first step (no longer including 32-bit libraries in the x86_64 repositories) should be relatively easy to revert (if needed). The second step is basically irreversible, since reversing it would require to partially re-bootstrap the architecture.
Some packages will require changes to adapt for the removal of 32-bit libraries from the x86_64 package repositories - notably, `wine` will need to be built in the [https://src.fedoraproject.org/rpms/wine/pull-request/19 "new WoW64" configuration], which allows running 32-bit Windows applications on top of 64-bit-only host systems.
It is planned to implement the first step as early as possible in the development cycle, but before the mass rebuild at the latest. This provides a transition period of at least four weeks to catch potential issues *before* the potentially irreversible second step is implemented (before the beta freeze).
When this Change is successfully implemented, a mechanism will be provided to remove any installed i686 packages on upgrade to avoid leaving behind packages that will no longer be updated, maintained, or which might cause upgrade issues in the future.
I think this change should also mention updating GPU drivers for i686 clients.
When new hardware is released or bugfixes are made to 64-bit GL/Vulkan drivers, we also build the 32-bit ones and we keep them in lockstep.
This means we can enable newer hardware on our timeline, and Valve don't ship their own copies of Mesa because they don't want to keep the drivers up to date in their runtimes, and believe the host OS should provide the drivers.
Dave.
On Tue, Jun 24, 2025 at 11:02:56AM +0100, Aoife Moloney via devel-announce wrote:
Wiki - https://fedoraproject.org/wiki/Changes/Drop_i686_support Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-drop-i686-support...
This is very problematic not just for the gaming stuff, but also for compilers. If gcc in the distro is supposed to have x86_64 compiler that has at least some minimal -m32 support (which at least various bootloaders or the kernel need), then it needs various i686 libraries in the buildroot, otherwise it needs to be built with --disable-multilib and in that case it can compile stuff with -m32, but won't really have any 32-bit crt files, libgcc.a and the like. In the way that gcc rpms are currently built in Fedora (both x86_64 and i686 builds with some subpackages typically installed from x86_64 only (compiler proper) and others for one or both multilibs (library subpackages)), the need for 32-bit ELF objects in 64-bit builds is fairly limited - we get away (or did, haven't watched closely what has been done there on the glibc side) mostly with glibc32 package which provided a few 32-bit libraries, so that the multilib support in the compiler isn't disabled and e.g. crt files/libgcc can be built, other libraries are mostly taken from the i686 build, but there we require a lot of stuff, e.g. to get documentation built (TeX, texinfo, doxygen, ...). If i686 rpms are gone altogether and some 32-bit ELF objects/libraries are provided in x86_64.rpm packages, then we'd need significantly more than just glibc and a few other libraries, e.g. gmp, mpfr, libmpc, zlib to name just a few. Some of those can be built in-tree which might be ok for package build.
And there is another aspect, Fedora being used often as a distribution used by developers working on compilers and other parts of toolchain. Not having at least basic 32-bit libraries will be a major blocker. And not just for GCC/LLVM/GDB etc. developers, but also for people working on other compilers like EDG that raised concerns about this proposal and there could be many users migrating away from Fedora which no longer provides what the users need.
Note, I'm fine with adding various ExcludeArch: i686 to non-library packages which aren't needed and/or trying to shrink dependencies of i686 packages still built. E.g. in the gcc case, I think it would be just fine for i686 build to disable documentation and thus no longer require TeX, doxygen etc. But shrinking the set to zero will not serve the distro well.
Jakub
On Wed, 25 Jun 2025 at 16:08, Jakub Jelinek wrote:
And there is another aspect, Fedora being used often as a distribution used by developers working on compilers and other parts of toolchain. Not having at least basic 32-bit libraries will be a major blocker. And not just for GCC/LLVM/GDB etc. developers, but also for people working on other compilers like EDG that raised concerns about this proposal and there could be many users migrating away from Fedora which no longer provides what the users need.
Yes, it would be a pretty big problem if the Fedora packagers of gcc, gdb etc. (who are among the most active contributors to the upstream projects) were unable to use Fedora for that upstream development.
On Wed, Jun 25, 2025 at 08:45:33PM +0100, Jonathan Wakely wrote:
On Wed, 25 Jun 2025 at 16:08, Jakub Jelinek wrote:
And there is another aspect, Fedora being used often as a distribution used by developers working on compilers and other parts of toolchain. Not having at least basic 32-bit libraries will be a major blocker. And not just for GCC/LLVM/GDB etc. developers, but also for people working on other compilers like EDG that raised concerns about this proposal and there could be many users migrating away from Fedora which no longer provides what the users need.
Yes, it would be a pretty big problem if the Fedora packagers of gcc, gdb etc. (who are among the most active contributors to the upstream projects) were unable to use Fedora for that upstream development.
Fedora ships just a handful of host architectures, out of the many that GCC, binutils, etc support, so this surely isn't a new / unique problem to i386 ?
Fedora does ship gcc/bintuils cross-compiler builds for all the other target arches already, so presumably i386 could join that collection ? Would that be sufficient for the kernel / firmware -m32 needs ?
With regards, Daniel
On Wed, Jun 25, 2025 at 08:55:00PM +0100, Daniel P. Berrangé wrote:
On Wed, Jun 25, 2025 at 08:45:33PM +0100, Jonathan Wakely wrote:
On Wed, 25 Jun 2025 at 16:08, Jakub Jelinek wrote:
And there is another aspect, Fedora being used often as a distribution used by developers working on compilers and other parts of toolchain. Not having at least basic 32-bit libraries will be a major blocker. And not just for GCC/LLVM/GDB etc. developers, but also for people working on other compilers like EDG that raised concerns about this proposal and there could be many users migrating away from Fedora which no longer provides what the users need.
Yes, it would be a pretty big problem if the Fedora packagers of gcc, gdb etc. (who are among the most active contributors to the upstream projects) were unable to use Fedora for that upstream development.
Fedora ships just a handful of host architectures, out of the many that GCC, binutils, etc support, so this surely isn't a new / unique problem to i386 ?
Fedora does ship gcc/bintuils cross-compiler builds for all the other target arches already, so presumably i386 could join that collection ? Would that be sufficient for the kernel / firmware -m32 needs ?
Certainly not. i686-linux is one of the few primary architectures for gcc, having just cross-compilers especially without the needed libraries for sysroots gives substantially smaller test coverage, there are hundreds of thousands of runtime tests, without libraries one can only test compile tests, with libraries but way to run programs natively one needs to emulate those (qemu etc.). Several of us run daily bootstraps/regtests not just on x86_64-linux but also on i686-linux (currently Fedora with 64-bit kernel but i686.rpms around) to make sure the code is 32 vs. 64-bit clean, etc.). This just wouldn't be possible anymore or would be much harder otherwise.
Sure, similar problems are with powerpc 32-bit or 64-bit big endian or s390 31-bit getting lost from most distros, the compiler farm still has some CentOS 7 boxes where one can test 32-bit and 64-bit big endian powerpc, but it is a lot of pain and not for daily use (e.g. CentOS 7 comes with GCC 4.8 which doesn't support C++14 and so can't build GCC 15+, one needs to use intermediate GCC version).
As I wrote earlier, we don't really need i686 firefox, gimp (or with some work perhaps) TeX, but at least the basic set of libraries would be really nice.
Jakub
On Wed, 2025-06-25 at 22:09 +0200, Jakub Jelinek wrote:
i686-linux is one of the few primary architectures for gcc
Maybe it shouldn't be any more?
On Wed, Jun 25, 2025 at 10:54:21PM +0100, Adam Williamson wrote:
On Wed, 2025-06-25 at 22:09 +0200, Jakub Jelinek wrote:
i686-linux is one of the few primary architectures for gcc
Maybe it shouldn't be any more?
It is important to have some 32-bit architectures among the primary targets to maintain 32 vs. 64 code cleanliness, make sure the right printf or gcc_diag format specifiers are used in the code etc.
Jakub
On Wed, 2025-06-25 at 23:58 +0200, Jakub Jelinek wrote:
On Wed, Jun 25, 2025 at 10:54:21PM +0100, Adam Williamson wrote:
On Wed, 2025-06-25 at 22:09 +0200, Jakub Jelinek wrote:
i686-linux is one of the few primary architectures for gcc
Maybe it shouldn't be any more?
It is important to have some 32-bit architectures among the primary targets to maintain 32 vs. 64 code cleanliness, make sure the right printf or gcc_diag format specifiers are used in the code etc.
It's only important so long as 32-bit matters. Does 32-bit still really matter? Has GCC thought about this?
I'm asking this to some extent as an intentionally dumb question - I'm kinda expecting to be told "yes, GCC still cares about 32-bit for <insert good reasons here>". I just wanted to have that written down.
On Wed, Jun 25, 2025 at 11:15:21PM +0100, Adam Williamson wrote:
On Wed, 2025-06-25 at 23:58 +0200, Jakub Jelinek wrote:
On Wed, Jun 25, 2025 at 10:54:21PM +0100, Adam Williamson wrote:
On Wed, 2025-06-25 at 22:09 +0200, Jakub Jelinek wrote:
i686-linux is one of the few primary architectures for gcc
Maybe it shouldn't be any more?
It is important to have some 32-bit architectures among the primary targets to maintain 32 vs. 64 code cleanliness, make sure the right printf or gcc_diag format specifiers are used in the code etc.
It's only important so long as 32-bit matters. Does 32-bit still really matter? Has GCC thought about this?
Yes, GCC does care about both 32-bit and 64-bit hosts and 8-bit, 16-bit, 20-bit, 24-bit, 32-bit and 64-bit targets. Sure, 64-bit hosts are these days more important, but still GCC is used in many kinds of different environment. Portability is a very important goal of the project. Speaking as one of the Release Managers responsible for it.
Jakub
On Wed, 25 Jun 2025 at 18:15, Adam Williamson adamwill@fedoraproject.org wrote:
On Wed, 2025-06-25 at 23:58 +0200, Jakub Jelinek wrote:
On Wed, Jun 25, 2025 at 10:54:21PM +0100, Adam Williamson wrote:
On Wed, 2025-06-25 at 22:09 +0200, Jakub Jelinek wrote:
i686-linux is one of the few primary architectures for gcc
Maybe it shouldn't be any more?
It is important to have some 32-bit architectures among the primary
targets
to maintain 32 vs. 64 code cleanliness, make sure the right printf or gcc_diag format specifiers are used in the code etc.
It's only important so long as 32-bit matters. Does 32-bit still really matter? Has GCC thought about this?
I'm asking this to some extent as an intentionally dumb question - I'm kinda expecting to be told "yes, GCC still cares about 32-bit for <insert good reasons here>". I just wanted to have that written down.
One thing that the last 4 years outside of Fedora has reinforced to me is how much of the computer world is NOT 64 bit. Most of the hardware in everything from the 900 mini computers in a standard car to the 10 or so in a washing machine are 16 bit and 32 bit ones. The average home computer is at least 4 32 bit cpus and a couple of 16 bit one's working behind the scenes of the 64 bit processor and GPU you do your work in. Intel is still used a lot in this 32 bit world and the compiler that is used is primarily gcc.
Currently, many of the Red Hat developers who work on gcc and other tools are using Fedora (or older RHEL) to support this ecosystem which means that Fedora gets a lot more focus from build-chain problems than probably other operating systems. When they have to move to another operating system, Fedora becomes more and more the 'oh it's broken.. not on my XYZ OS, I'll have to spin up something in my free time to get to it.'
On Wed, 25 Jun 2025 at 20:55, Daniel P. Berrangé berrange@redhat.com wrote:
On Wed, Jun 25, 2025 at 08:45:33PM +0100, Jonathan Wakely wrote:
On Wed, 25 Jun 2025 at 16:08, Jakub Jelinek wrote:
And there is another aspect, Fedora being used often as a distribution used by developers working on compilers and other parts of toolchain. Not having at least basic 32-bit libraries will be a major blocker. And not just for GCC/LLVM/GDB etc. developers, but also for people working on other compilers like EDG that raised concerns about this proposal and there could be many users migrating away from Fedora which no longer provides what the users need.
Yes, it would be a pretty big problem if the Fedora packagers of gcc, gdb etc. (who are among the most active contributors to the upstream projects) were unable to use Fedora for that upstream development.
Fedora ships just a handful of host architectures, out of the many that GCC, binutils, etc support, so this surely isn't a new / unique problem to i386 ?
Of the "primary platforms" that GCC supports (see https://gcc.gnu.org/gcc-15/criteria.html for the current list) Fedora supports more than half of them. And for freebsd and solaris, that's somebody else's problem :-)
I can use power systems (running Fedora or RHEL) to test on power, and aarch64 systems (running Fedora or RHEL) to test on aarch64, but to test i686 I use x86_64 with -m32, and I don't think I'm alone in that, I know Jakub does too. I don't have access to any *real* x86-32 systems, but that's OK because almost all the time testing on x86-64 with -m32 works exactly the same as an i686 kernel+userspace.
For my work (libstdc++) the differences between power64le-linux and x86_64-linux are minor, it's far more common to have portability problems between 64-bit and 32-bit, and that's why doing regular testing with -m32 is so useful for me. The ability to do that on Fedora is extremely valuable for maintaining the C++ runtime.
Fedora does ship gcc/bintuils cross-compiler builds for all the other target arches already, so presumably i386 could join that collection ? Would that be sufficient for the kernel / firmware -m32 needs ?
For the kernel, maybe, but for the toolchain we also need glibc, and a handful of libs (zlibng, zstd, gmp, mpfr, mpc). It's much, much less than the whole distro though. I think using ExcludeArch i686 for the majority of packages makes a lot of sense.
On Wed, Jun 25, 2025 at 09:14:20PM +0100, Jonathan Wakely wrote:
On Wed, 25 Jun 2025 at 20:55, Daniel P. Berrangé berrange@redhat.com wrote:
On Wed, Jun 25, 2025 at 08:45:33PM +0100, Jonathan Wakely wrote:
On Wed, 25 Jun 2025 at 16:08, Jakub Jelinek wrote:
And there is another aspect, Fedora being used often as a distribution used by developers working on compilers and other parts of toolchain. Not having at least basic 32-bit libraries will be a major blocker. And not just for GCC/LLVM/GDB etc. developers, but also for people working on other compilers like EDG that raised concerns about this proposal and there could be many users migrating away from Fedora which no longer provides what the users need.
Yes, it would be a pretty big problem if the Fedora packagers of gcc, gdb etc. (who are among the most active contributors to the upstream projects) were unable to use Fedora for that upstream development.
Fedora ships just a handful of host architectures, out of the many that GCC, binutils, etc support, so this surely isn't a new / unique problem to i386 ?
Of the "primary platforms" that GCC supports (see https://gcc.gnu.org/gcc-15/criteria.html for the current list) Fedora supports more than half of them. And for freebsd and solaris, that's somebody else's problem :-)
I can use power systems (running Fedora or RHEL) to test on power, and aarch64 systems (running Fedora or RHEL) to test on aarch64, but to test i686 I use x86_64 with -m32, and I don't think I'm alone in that, I know Jakub does too. I don't have access to any *real* x86-32 systems, but that's OK because almost all the time testing on x86-64 with -m32 works exactly the same as an i686 kernel+userspace.
For my work (libstdc++) the differences between power64le-linux and x86_64-linux are minor, it's far more common to have portability problems between 64-bit and 32-bit, and that's why doing regular testing with -m32 is so useful for me. The ability to do that on Fedora is extremely valuable for maintaining the C++ runtime.
Yes, I can understand the benefit of testing 64 vs 32 bit in general, as that's a frequent source of bugs in many apps still, alongside big endian vs little endian, which s390x gives coverage of.
Would containers mitigate this use case well enough ?
For most upstream projects I'm invovled in, we've got Debian containers of every arch except x86_64, with the full suite of cross compilers and all libraries required, so we can do all build testing from a x86_64 Fedora host regardless of arch. Actually running binaries of non x86 arches, needs qemu-user though, and that's not foolproof in its emulation.
Fedora does ship gcc/bintuils cross-compiler builds for all the other target arches already, so presumably i386 could join that collection ? Would that be sufficient for the kernel / firmware -m32 needs ?
For the kernel, maybe, but for the toolchain we also need glibc, and a handful of libs (zlibng, zstd, gmp, mpfr, mpc). It's much, much less than the whole distro though. I think using ExcludeArch i686 for the majority of packages makes a lot of sense.
It is a shame RPM doesn't have "IncludeArch", as that could avoid bulk modifying many 1000's of RPM specs, which isn't entirely trivial when some will already have a mix of ExcludeArch and ExclusiveArch.
With regards, Daniel
On Thu, Jun 26, 2025 at 08:50:48AM +0100, Daniel P. Berrangé wrote:
Yes, I can understand the benefit of testing 64 vs 32 bit in general, as that's a frequent source of bugs in many apps still, alongside big endian vs little endian, which s390x gives coverage of.
Would containers mitigate this use case well enough ?
Question: How are said containers to be constructed (much less maintained) when working within the Fedora/RHEL ecosystem?
Or is that "Somebody else's problem"?
- Solomon
On Thu, Jun 26, 2025 at 09:22:58AM -0400, Solomon Peachy wrote:
On Thu, Jun 26, 2025 at 08:50:48AM +0100, Daniel P. Berrangé wrote:
Yes, I can understand the benefit of testing 64 vs 32 bit in general, as that's a frequent source of bugs in many apps still, alongside big endian vs little endian, which s390x gives coverage of.
Would containers mitigate this use case well enough ?
Question: How are said containers to be constructed (much less maintained) when working within the Fedora/RHEL ecosystem?
Thanks to Debian multi-arch it is possible to build cross envs for many archs, from any Linux system with podman/docker. This gets you a build env, though you do need qemu-user emulation (or native HW) for most combinations if you need to actually execute the binaries you build. Just having the build envs though is a massive win in reducing maint burden across distros & arches.
To limit the dockerfile maint overheads long term, auto-generating dockerfiles is pretty important IME.
This is one such example (auto-generated) dockerfile from libvirt's primary git repo:
https://gitlab.com/libvirt/libvirt/-/blob/master/ci/containers/debian-12-cro...
for cross compilers, we have the basic Debian native toolchain installed the first layer (this content is common to all cross containers), then add the cross-arch toolchain and libraries into a second layer.
Using it goes approximately like this:
$ cd $HOME/src/virt/libvirt $ podman --remote run -v `pwd`:/libvirt --security-opt label=disable -it registry.gitlab.com/libvirt/libvirt/ci-debian-12-cross-i686
root@f8a173b98d5b:/# cd /libvirt
root@f8a173b98d5b:/libvirt# echo $MESON_OPTS --cross-file=i686-linux-gnu
root@f8a173b98d5b:/libvirt# meson build-i686 $MESON_OPTS The Meson build system Version: 1.0.1 Source dir: /libvirt Build dir: /libvirt/build-i686 Build type: cross build Project name: libvirt Project version: 11.5.0 C compiler for the host machine: /usr/bin/i686-linux-gnu-gcc (gcc 12.2.0 "i686-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0") C linker for the host machine: /usr/bin/i686-linux-gnu-gcc ld.bfd 2.40 Compiler for language c for the build machine not found. Build machine cpu family: x86_64 Build machine cpu: x86_64 Host machine cpu family: x86 Host machine cpu: i686 Target machine cpu family: x86 Target machine cpu: i686 ...snip... root@f8a173b98d5b:/libvirt# ninja -C build-i686 ...snip...
We auto-generate all our dockerfiles across 30+ project git repos, for 20 different distro versions, and 11 different linux arches and 2 mingw targets. The number of possible variants is enourmous. In CI we limit what we generate by default to remain within our CI budget, but locally a dev can create any of the combinations they might need.
A repo declares what it needs using a list of generic package names
https://gitlab.com/libvirt/libvirt/-/blob/master/ci/lcitool/projects/libvirt...
we then have a centralized mapping file which translates generic names to distro specific names
https://gitlab.com/libvirt/libvirt-ci/-/blob/master/lcitool/facts/mappings.y...
The 'lcitool' command takes the two and spits our dockerfiles for a project. We can spit out individual dockerfiles on demand, but for CI we have a manifest to declare our overall standard target set for CI purposes
https://gitlab.com/libvirt/libvirt/-/blob/master/ci/manifest.yml
this bulk emits the common dockerfiles we need, along with all the gitlab CI yml rules to use them. NB, the FreeBSD/macOS bits there don't use containers, they use a gross hack where we call out to Cirrus CI from GitLab CI, to use Cirrus' free hardware resources while keeping GitLab as a single dashboard.
That's probably way more info than you wanted :-)
Regards, Daniel
On Thu, Jun 26, 2025 at 03:46:44PM +0100, Daniel P. Berrangé wrote:
Question: How are said containers to be constructed (much less maintained) when working within the Fedora/RHEL ecosystem?
Thanks to Debian multi-arch it is possible to build cross envs for many archs, from any Linux system with podman/docker. This gets
[...]
That's probably way more info than you wanted :-)
While that's a ton of information, it didn't actually answer my question. But after looking at:
https://gitlab.com/libvirt/libvirt/-/tree/master/ci/containers
..it appears that the answer to my question is actually "i686 containers will need to be constructed and maintained from the Debian ecosystem instead of Fedora/RHEL"
Will that still work for foundational hardware-interacting things like Mesa? I mean, you're all but guaranteed to have different major versions on the host system (eg Fedora's v25.x actively driving the desktop) vs what's in the container (eg v24.x in the Debian-derived i686 container that gets invoked to run $game)
- Solomon
On Thu, Jun 26, 2025 at 11:07:11AM -0400, Solomon Peachy wrote:
On Thu, Jun 26, 2025 at 03:46:44PM +0100, Daniel P. Berrangé wrote:
Question: How are said containers to be constructed (much less maintained) when working within the Fedora/RHEL ecosystem?
Thanks to Debian multi-arch it is possible to build cross envs for many archs, from any Linux system with podman/docker. This gets
[...]
That's probably way more info than you wanted :-)
While that's a ton of information, it didn't actually answer my question. But after looking at:
https://gitlab.com/libvirt/libvirt/-/tree/master/ci/containers
..it appears that the answer to my question is actually "i686 containers will need to be constructed and maintained from the Debian ecosystem instead of Fedora/RHEL"
Will that still work for foundational hardware-interacting things like Mesa? I mean, you're all but guaranteed to have different major versions on the host system (eg Fedora's v25.x actively driving the desktop) vs what's in the container (eg v24.x in the Debian-derived i686 container that gets invoked to run $game)
Ah so my comments were directly in context of the concerns upthread about use of Fedora as a platform for GCC maint. I think the containers approach I outline, is a good solution for most day-to-day software dev tasks that need to test cross-arch builds, and to a lesser exttent basic unit testing.
I was NOT suggesting that we should promote Debian ecosystem as a way to host steam / other games requirements, ie end user runtime usage. I don't know much about Mesa myself, but what I've read in this debate, it would be highly preferrable to have matching versions of mesa between i386 and native x86_64 host.
So if we want to retain an i386 capability for runtime usage, my suggestion (mentioned earlier in this thread) is to explore the provision of cross-compiled i386 libraries on Fedora, in the same approach we use for Mingw32/64 in Fedora which has been pretty successful over the years, with its maint burden confined to just the packages that are relevant.
NB, there are two ways we do mingw - the legacy approach was to have separate source RPMs for mingw but the modern preferred approach is sub-RPM builds from the native package. While the latter puts a bit of extra burden on the native package maintainer, in many cases this was the same person who was already doing mingw builds, and it avoids the pain of keeping versions in sync.
With regards, Daniel
Hi. I read this thread yesterday and also read about a post on slashdot: https://linux.slashdot.org/story/25/06/25/2042242/bazzite-would-shut-down-if... :
If Fedora drops 32-bit support, the gaming-focused Bazzite project would be
forced to shut down https://www.gamingonlinux.com/2025/06/bazzite-would-shut-down-if-fedora-goes-ahead-with-removing-32-bit/, according to its founder Kyle Gospodnetich. "As much as I'd like this change to happen, it's too soon," said Gospodneitch in a post https://discussion.fedoraproject.org/t/f44-change-proposal-drop-i686-support-system-wide/156324/78. "This change would kill off projects like Bazzite entirely right as Fedora is starting to make major headway in the gaming space. Neal Gompa already pointed out basic use cases that would be broken even if someone built the packages Steam itself needs to function."
He continued: "It's also causing irreparable damage to Fedora from a PR standpoint. I have been inundated all day with people sharing news articles and being genuinely concerned Steam is gong to stop working on their Fedora/Bazzite machines. I would argue not only should this change be rejected, the proposal should be rescinded to limit further damage to Fedora as a project. Perhaps open a separate one to talk about changing build architecture to build fewer 32-bit packages?"
When pushed further, Gospodnetich said: "I'm speaking as it's founder, if this change is actually made as it is written the best option for us is to just go ahead and disband the project."
Hi,
On Wed, Jun 25, 2025 at 08:45:33PM +0100, Jonathan Wakely wrote:
On Wed, 25 Jun 2025 at 16:08, Jakub Jelinek wrote:
And there is another aspect, Fedora being used often as a distribution used by developers working on compilers and other parts of toolchain. Not having at least basic 32-bit libraries will be a major blocker. And not just for GCC/LLVM/GDB etc. developers, but also for people working on other compilers like EDG that raised concerns about this proposal and there could be many users migrating away from Fedora which no longer provides what the users need.
Yes, it would be a pretty big problem if the Fedora packagers of gcc, gdb etc. (who are among the most active contributors to the upstream projects) were unable to use Fedora for that upstream development.
Same for elfutils. It is not that we love i686 specifically so much, but having an easy accessible 32bit build/runtime environment (on x86_64) is really valuable. We don't need much, just a c and c++ compiler that supports -m32 and some base devel libraries.
Cheers,
Mark
On Tuesday, June 24, 2025, Aoife Moloney via devel-announce < devel-announce@lists.fedoraproject.org> wrote:
Wiki - https://fedoraproject.org/wiki/Changes/Drop_i686_support Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-drop-i686- support-system-wide/156324
This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary ==
Fedora package repositories for the x86_64 architecture no longer include libraries for compatibility with 32-bit applications ("multilib"), and packages are no longer built for the i686 architecture.
== Owner ==
- Name: [[User:Decathorpe| Fabio Valentini]], [[User:Fale|Fale]],
[[User:Kevin|Kevin Fenzi]]
- Email: decathorpe (at) gmail (dot) com, mail (at) fale (dot) io,
kevin (at) scrye (dot) com
== Detailed Description ==
Fedora stopped providing [https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels kernel packages, installer images] and stopped publishing [https://fedoraproject.org/wiki/Changes/Noi686Repositories i686 package repositories] with Fedora 31. However, packages were by default still built for the i686 architecture, since they were required for running 32-bit applications on x86_64 hosts ("multilib").
Since Fedora 37, leaf packages (i.e. packages that are not depended on by other packages) can simply [https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval stop building for i686] without any reason, which has allowed package maintainers to focus their work on architectures where packages are actually shipped to users.
This Change Proposal implements the next two (and last) steps:
- Packages built for the i686 architecture are no longer included in
x86_64 repositories (dropping "multilib" support, i.e. support for running 32-bit userspace on a 64-bit host).
- Packages are no longer built for the i686 architecture.
This is intentionally planned as a two-step process - the first step (no longer including 32-bit libraries in the x86_64 repositories) should be relatively easy to revert (if needed). The second step is basically irreversible, since reversing it would require to partially re-bootstrap the architecture.
Some packages will require changes to adapt for the removal of 32-bit libraries from the x86_64 package repositories - notably, `wine` will need to be built in the [https://src.fedoraproject.org/rpms/wine/pull-request/19 "new WoW64" configuration], which allows running 32-bit Windows applications on top of 64-bit-only host systems.
It is planned to implement the first step as early as possible in the development cycle, but before the mass rebuild at the latest. This provides a transition period of at least four weeks to catch potential issues *before* the potentially irreversible second step is implemented (before the beta freeze).
When this Change is successfully implemented, a mechanism will be provided to remove any installed i686 packages on upgrade to avoid leaving behind packages that will no longer be updated, maintained, or which might cause upgrade issues in the future.
== Feedback ==
N/Y
== Benefit to Fedora ==
By dropping completely the i686 architecture, Fedora will decrease the burden on package maintainers, release engineering, infrastructure, and users.
I don't think so that change really "decrease burdens on user". It's actually the opposite, it simplifies the infrastructure at the expense of users, which then would have to jump through hoops to achieve what they want.
And no repository metadata size is hardly a "burden on users".
Reading through the feedback, wouldn't it be better to take a second look on the previous change:
Dne 24. 06. 25 v 12:02 Aoife Moloney via devel-announce napsal(a):
Since Fedora 37, leaf packages (i.e. packages that are not depended on by other packages) can simply [https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval stop building for i686] without any reason, which has allowed package maintainers to focus their work on architectures where packages are actually shipped to users.
While it encourages removal of i686, I think that nobody was ever really serious about this.
For example, I maintain Ruby and I have not disabled i686 build, because there are other packages depending on Ruby. I don't think that they are used, but I am not going to do the review.
Alternatively, I could have disable the i686 build of Ruby, but I'm not sure who would fix the FTBFS packages.
Granted, there is no tooling which would make this easy. This proposal kind of workarounds this ...
Vít
On Thu, Jun 26, 2025 at 11:24 AM Vít Ondruch vondruch@redhat.com wrote:
Reading through the feedback, wouldn't it be better to take a second look on the previous change:
Dne 24. 06. 25 v 12:02 Aoife Moloney via devel-announce napsal(a):
Since Fedora 37, leaf packages (i.e. packages that are not depended on by other packages) can simply [https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval stop building for i686] without any reason, which has allowed package maintainers to focus their work on architectures where packages are actually shipped to users.
While it encourages removal of i686, I think that nobody was ever really serious about this.
Yes, because it's not trivial ...
I wrote https://pagure.io/leafdrop to help packagers with this, but (see below) its guidance is imperfect.
For example, I maintain Ruby and I have not disabled i686 build, because there are other packages depending on Ruby. I don't think that they are used, but I am not going to do the review.
To a first approximation, I don't think you could disable i686 support in ruby right now: - noarch rubygems shouldn't be a problem, noarch builds haven't been scheduled to run on i686 for a while already - rubygems with binary extensions would be a problem, they would need to add ExclusiveArch: %{ruby_arches} - any non-noarch packages that depend on ruby (either at build-time or at run-time) would need to add ExclusiveArch: %{ruby_arches} too
Alternatively, I could have disable the i686 build of Ruby, but I'm not sure who would fix the FTBFS packages.
Granted, there is no tooling which would make this easy. This proposal kind of workarounds this ...
Yes - because it's not easy to determine which packages we'd need to keep and which could be thrown away - the way koji works throws away some information we would need for that.
Only one SRPM from one random architecture is kept, and there is only one "-source" repository that contains these randomized SRPMs - so there are *zero* ways to get complete dependency information about BuildRequires and Requires for any architecture.
If we *had* this information, we could do some graph algorithm magic and determine the minimal self-hosting set of packages needed for i686, and drop everything else.
But we *don't* have this complete and correct information, so any conclusions drawn from the information we have will be imperfect. It might still be worthwhile to do it - it just won't be 100% accurate.
Fabio
On Thu, Jun 26, 2025 at 11:50:10AM +0200, Fabio Valentini wrote:
On Thu, Jun 26, 2025 at 11:24 AM Vít Ondruch vondruch@redhat.com wrote:
Reading through the feedback, wouldn't it be better to take a second look on the previous change:
Dne 24. 06. 25 v 12:02 Aoife Moloney via devel-announce napsal(a):
Since Fedora 37, leaf packages (i.e. packages that are not depended on by other packages) can simply [https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval stop building for i686] without any reason, which has allowed package maintainers to focus their work on architectures where packages are actually shipped to users.
While it encourages removal of i686, I think that nobody was ever really serious about this.
Yes, because it's not trivial ...
I wrote https://pagure.io/leafdrop to help packagers with this, but (see below) its guidance is imperfect.
Also the definition of "leaf" that is has to use is overly restrictive compared to the real world usage. With multi-lib only a small subset of i686 packages make their way into the compose, but the build system still requires we build everything, no matter the fact most won't ever see the light of day outside the build system :-(
So the idea of only dropping packages which are leaves in koji, is way too narrow of a goal to enable sufficient progress to be made to get down to only the small set of RPMs needed in real world deployment.
With regards, Daniel
On Thu, Jun 26, 2025 at 12:09 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Thu, Jun 26, 2025 at 11:50:10AM +0200, Fabio Valentini wrote:
On Thu, Jun 26, 2025 at 11:24 AM Vít Ondruch vondruch@redhat.com wrote:
Reading through the feedback, wouldn't it be better to take a second look on the previous change:
Dne 24. 06. 25 v 12:02 Aoife Moloney via devel-announce napsal(a):
Since Fedora 37, leaf packages (i.e. packages that are not depended on by other packages) can simply [https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval stop building for i686] without any reason, which has allowed package maintainers to focus their work on architectures where packages are actually shipped to users.
While it encourages removal of i686, I think that nobody was ever really serious about this.
Yes, because it's not trivial ...
I wrote https://pagure.io/leafdrop to help packagers with this, but (see below) its guidance is imperfect.
Also the definition of "leaf" that is has to use is overly restrictive compared to the real world usage. With multi-lib only a small subset of i686 packages make their way into the compose, but the build system still requires we build everything, no matter the fact most won't ever see the light of day outside the build system :-(
So the idea of only dropping packages which are leaves in koji, is way too narrow of a goal to enable sufficient progress to be made to get down to only the small set of RPMs needed in real world deployment.
Yes, by design, it *should* give you no "false positives" (i.e. tell you that you can drop something that you actually can't), but it will give you "false negatives" (i.e. tell you that you can't drop something that you actually could drop) - which, given limitations of the data we have, is the safe way to handle this, in my opinion.
Fabio
On Thu, Jun 26, 2025 at 12:16:21PM +0200, Fabio Valentini wrote:
On Thu, Jun 26, 2025 at 12:09 PM Daniel P. Berrangé berrange@redhat.com wrote:
On Thu, Jun 26, 2025 at 11:50:10AM +0200, Fabio Valentini wrote:
On Thu, Jun 26, 2025 at 11:24 AM Vít Ondruch vondruch@redhat.com wrote:
Reading through the feedback, wouldn't it be better to take a second look on the previous change:
Dne 24. 06. 25 v 12:02 Aoife Moloney via devel-announce napsal(a):
Since Fedora 37, leaf packages (i.e. packages that are not depended on by other packages) can simply [https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval stop building for i686] without any reason, which has allowed package maintainers to focus their work on architectures where packages are actually shipped to users.
While it encourages removal of i686, I think that nobody was ever really serious about this.
Yes, because it's not trivial ...
I wrote https://pagure.io/leafdrop to help packagers with this, but (see below) its guidance is imperfect.
Also the definition of "leaf" that is has to use is overly restrictive compared to the real world usage. With multi-lib only a small subset of i686 packages make their way into the compose, but the build system still requires we build everything, no matter the fact most won't ever see the light of day outside the build system :-(
So the idea of only dropping packages which are leaves in koji, is way too narrow of a goal to enable sufficient progress to be made to get down to only the small set of RPMs needed in real world deployment.
Yes, by design, it *should* give you no "false positives" (i.e. tell you that you can drop something that you actually can't), but it will give you "false negatives" (i.e. tell you that you can't drop something that you actually could drop) - which, given limitations of the data we have, is the safe way to handle this, in my opinion.
Yes, but that is also precisely why the "encourage leaf drop" change makes very little dent in the maint burden we face. In the non-leaf case, for each binary RPM identified, someone has to look at the dep and decide whether the functionality can be selectively disabled on i686 via an RPM spec condition, or the package fully disabled on i686.
There are 32 source packages (40 binary packages) as 1st level needing investigation when QEMU drops i686 support likely later this year, which likely implies following many recursive deps too. Some 1st level deps are pretty core to the distro like koji, openqa, lorax but at the same time few of these seem relevant to multi-lib usage.
With regards, Daniel
On Tue, Jun 24, 2025 at 12:07 PM Aoife Moloney via devel-announce devel-announce@lists.fedoraproject.org wrote:
Wiki - https://fedoraproject.org/wiki/Changes/Drop_i686_support Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-drop-i686-support...
This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
Based on feedback on this list and on the discussion thread, I have decided to withdraw this proposal.
I'm looking forward to discussing counter-proposals when they are ready.
Fabio
On 6/28/25 9:57 AM, Fabio Valentini wrote:
Based on feedback on this list and on the discussion thread, I have decided to withdraw this proposal.
I'm looking forward to discussing counter-proposals when they are ready.
Thanks, Fabio. With the combined knowledge base available I know something will work out. :)
-
Adam Williamson -
Aoife Moloney via devel-announce -
Artur Frenszek-Iwicki -
Benson Muite -
Chris Adams -
Dan Horák -
Daniel P. Berrangé -
David Airlie -
Dominik 'Rathann' Mierzejewski -
drago01 -
Eduard Lucena -
Fabio Alessandro Locati -
Fabio Valentini -
Florian Weimer -
Gary Buhrmaster -
Jakub Jelinek -
Jonathan Wakely -
Jonathan Wright -
Kamil Paral -
Konrad Kleine -
Marcin Juszkiewicz -
Mark Wielaard -
Martin Jackson -
Mateus Rodrigues Costa -
Michael Catanzaro -
Michael Cronenworth -
Michal Schorm -
Neal Gompa -
Nicolas Chauvet -
Pavol Sloboda -
Peter Robinson -
Petr Pisar -
Richard W.M. Jones -
Solomon Peachy -
Stephen Smoogen -
Tom Stellard -
Vít Ondruch