i686 removal - easy win set

[Michal Schorm]

For those interested in this topic, I compiled a set of packages that exactly:
  builds i686 && all binary RPMs are buildroot-only && leaf && NOT on
FESCo "protected" list

https://mschorm.fedorapeople.org/ARCHIVE/i686-removal/koji-only-leaf-i686_20...

If my method and understanding are both correct, we could add
'ExcludeArch: %{ix86}' to each of these 3,400 packages with zero
impact on the rest of the packages and save some resources.

What do you think?

Michal

--

Michal Schorm
Senior Software Engineer
Databases Team
Red Hat

--

[Mateus R. Costa]

Em sex., 17 de jul. de 2026, 19:32, Michal Schorm 
escreveu:
> For those interested in this topic, I compiled a set of packages that
> exactly:
>   builds i686 && all binary RPMs are buildroot-only && leaf && NOT on
> FESCo "protected" list
>
> https://mschorm.fedorapeople.org/ARCHIVE/i686-removal/koji-only-leaf-i686_20...
>
> If my method and understanding are both correct, we could add
> 'ExcludeArch: %{ix86}' to each of these 3,400 packages with zero
> impact on the rest of the packages and save some resources.
>
> What do you think?

I noticed bign-handheld-thumbnailer made it to this list.

Since that project is just a thumbnailer and preferably the version
equivalent to the host os architecture should be installed (and there's no
x86 32-bits Fedora anymore AFAIK), this makes me curious on something.

It seems to me that you're saying "hey, we could remove 32-bits x86
versions from these!", as if a large portion of the community has to agree
beforehand on whether it's a good choice.

This brings it to my question: since to me I am almost sure nobody will
ever install the x86_32 version, although it's perfectly buildable, what
prevents me from, as a packager, to simply disable it for only that package?

Is there a specific policy I should be aware of?

Thanks for your time,
Mateus Rodrigues Costa
> Michal
>
> --
>
> Michal Schorm
> Senior Software Engineer
> Databases Team
> Red Hat
>
> --
>
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam, report it:
> https://forge.fedoraproject.org/infra/tickets/issues/new

[Michal Schorm]

On Sat, Jul 18, 2026 at 2:32 AM Mateus R. Costa
 wrote:
> This brings it to my question: since to me I am almost sure nobody will ever install the x86_32 version, although it's perfectly buildable, what prevents me from, as a packager, to simply disable it for only that package?
>
> Is there a specific policy I should be aware of?

Hi Mateus,
The current policy actually encourages package maintainers to drop the
leaf i686 packages on their discretion:
  https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval
You can go for it right now.

This thread's goal is to coordinate a larger independent effort - here
I seek validation of my analysis, and assistance with realization.

--

Michal Schorm
Senior Software Engineer
Databases Team
Red Hat

--

On Sat, Jul 18, 2026 at 2:32 AM Mateus R. Costa
 wrote:
> Em sex., 17 de jul. de 2026, 19:32, Michal Schorm  escreveu:
> > For those interested in this topic, I compiled a set of packages that exactly:
> >   builds i686 && all binary RPMs are buildroot-only && leaf && NOT on
> > FESCo "protected" list
> >
> > https://mschorm.fedorapeople.org/ARCHIVE/i686-removal/koji-only-leaf-i686_20...
> >
> > If my method and understanding are both correct, we could add
> > 'ExcludeArch: %{ix86}' to each of these 3,400 packages with zero
> > impact on the rest of the packages and save some resources.
> >
> > What do you think?
>
> I noticed bign-handheld-thumbnailer made it to this list.
>
> Since that project is just a thumbnailer and preferably the version equivalent to the host os architecture should be installed (and there's no x86 32-bits Fedora anymore AFAIK), this makes me curious on something.
>
> It seems to me that you're saying "hey, we could remove 32-bits x86 versions from these!", as if a large portion of the community has to agree beforehand on whether it's a good choice.
>
> This brings it to my question: since to me I am almost sure nobody will ever install the x86_32 version, although it's perfectly buildable, what prevents me from, as a packager, to simply disable it for only that package?
>
> Is there a specific policy I should be aware of?
>
> Thanks for your time,
> Mateus Rodrigues Costa
> > Michal
> >
> > --
> >
> > Michal Schorm
> > Senior Software Engineer
> > Databases Team
> > Red Hat
> >
> > --
> >
> > --
> > _______________________________________________
> > devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail]
> > Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
>
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[Mateus R. Costa]

Em sex., 17 de jul. de 2026 às 22:03, Michal Schorm
 escreveu:
> On Sat, Jul 18, 2026 at 2:32 AM Mateus R. Costa
>  wrote:
> > This brings it to my question: since to me I am almost sure nobody will ever install the x86_32 version, although it's perfectly buildable, what prevents me from, as a packager, to simply disable it for only that package?
> >
> > Is there a specific policy I should be aware of?
>
> Hi Mateus,
> The current policy actually encourages package maintainers to drop the
> leaf i686 packages on their discretion:
>   https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval
> You can go for it right now.

You linked me to a Change, and specifically a Fedora 37 one.
When I learned packaging RPMs I don't specifically remember whatever
tutorial I read (which was probably on Fedora Docs) nor other RPM
documentation on Fedora Docs I don't really remember anything pushing
dropping x86_32 support.

So unless something was added between then and now, or that I simply
missed it, then potentially having the info to drop x86_32 if feasible
on newer packages intended to the Fedora repos probably is a good
idea.
This is mostly in the "let's not keep accumulating new packages".
Probably also interesting to bring up in package reviews for newer
packages or unretired ones.
> This thread's goal is to coordinate a larger independent effort - here
> I seek validation of my analysis, and assistance with realization.

I'm all for it, I am in favor of removing most 32-bits stuff except
for the most likely libs to be needed if I ever have to manually run
some 32-bit binary (which probably the FESCo list already covers).
Though today most usecases where I would need to actually do that I
probably can use flatpak or distrobox (even if in a non-Fedora
container).

So, I will handle bign-handheld-thumbnailer later. Though I will have
to check how well that ExcludeArch policy is advertised on the
packaging docs...

Thanks for your time,
Mateus Rodrigues Costa
> --
>
> Michal Schorm
> Senior Software Engineer
> Databases Team
> Red Hat
>
> --
>
> On Sat, Jul 18, 2026 at 2:32 AM Mateus R. Costa
>  wrote:
> > Em sex., 17 de jul. de 2026, 19:32, Michal Schorm  escreveu:
> > > For those interested in this topic, I compiled a set of packages that exactly:
> > >   builds i686 && all binary RPMs are buildroot-only && leaf && NOT on
> > > FESCo "protected" list
> > >
> > > https://mschorm.fedorapeople.org/ARCHIVE/i686-removal/koji-only-leaf-i686_20...
> > >
> > > If my method and understanding are both correct, we could add
> > > 'ExcludeArch: %{ix86}' to each of these 3,400 packages with zero
> > > impact on the rest of the packages and save some resources.
> > >
> > > What do you think?
> >
> > I noticed bign-handheld-thumbnailer made it to this list.
> >
> > Since that project is just a thumbnailer and preferably the version equivalent to the host os architecture should be installed (and there's no x86 32-bits Fedora anymore AFAIK), this makes me curious on something.
> >
> > It seems to me that you're saying "hey, we could remove 32-bits x86 versions from these!", as if a large portion of the community has to agree beforehand on whether it's a good choice.
> >
> > This brings it to my question: since to me I am almost sure nobody will ever install the x86_32 version, although it's perfectly buildable, what prevents me from, as a packager, to simply disable it for only that package?
> >
> > Is there a specific policy I should be aware of?
> >
> > Thanks for your time,
> > Mateus Rodrigues Costa
> > > Michal
> > >
> > > --
> > >
> > > Michal Schorm
> > > Senior Software Engineer
> > > Databases Team
> > > Red Hat
> > >
> > > --
> > >
> > > --
> > > _______________________________________________
> > > devel mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > 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/[e-mail]
> > > Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
> >
> > --
> > _______________________________________________
> > devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail]
> > Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
>
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[Michal Schorm]

On Sat, Jul 18, 2026 at 3:21 AM Mateus R. Costa
 wrote:
> Em sex., 17 de jul. de 2026 às 22:03, Michal Schorm
>  escreveu:
> > On Sat, Jul 18, 2026 at 2:32 AM Mateus R. Costa
> >  wrote:
> > > This brings it to my question: since to me I am almost sure nobody will ever install the x86_32 version, although it's perfectly buildable, what prevents me from, as a packager, to simply disable it for only that package?
> > >
> > > Is there a specific policy I should be aware of?
> >
> > Hi Mateus,
> > The current policy actually encourages package maintainers to drop the
> > leaf i686 packages on their discretion:
> >   https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval
> > You can go for it right now.
>
> You linked me to a Change, and specifically a Fedora 37 one.
> When I learned packaging RPMs I don't specifically remember whatever
> tutorial I read (which was probably on Fedora Docs) nor other RPM
> documentation on Fedora Docs I don't really remember anything pushing
> dropping x86_32 support.

Fedora i686: Quick Summary Timeline:

* F27 (2017) — First proposal to drop i686 kernels. Deferred by FESCo.
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels

* F31 (2019) — i686 kernels + standalone repos dropped. Multilib and
Koji builds kept.
https://fedoraproject.org/wiki/Changes/Noi686Repositories

* F37 (2022) — Leaf packages can add 'ExcludeArch: %{ix86}' freely.
~230 source packages baselined as "should stay."
https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval

* F44 (2025-06-24) — Comprehensive proposal to drop all i686 (multilib
+ Koji builds). ~400 comments, withdrawn 4 days later.
https://discussion.fedoraproject.org/t/f44-change-proposal-drop-i686-support...

* F44 (2025) — Narrow QEMU i686 drop accepted separately.
https://fedoraproject.org/wiki/Changes/DropQEMU32bitHostBuilds

Current state: multilib active, Koji i686 builds active, no FESCo
policy on long-term direction. Gaming (Steam/Wine) is the dominant
reason i686 stays. Wine WoW64 readiness unclear.

Key threads:

2022 FESCo survey (60+ replies):
https://lists.fedoraproject.org/archives/list/[e-mail]/...

i686 problem statement:
https://discussion.fedoraproject.org/t/i686-in-fedora-problem-statement/1570...

mock i686 cross-build (open since 2019):
https://github.com/rpm-software-management/mock/issues/340

--

Michal Schorm
Senior Software Engineer
Databases Team
Red Hat

--

On Sat, Jul 18, 2026 at 3:21 AM Mateus R. Costa
 wrote:
> Em sex., 17 de jul. de 2026 às 22:03, Michal Schorm
>  escreveu:
> > On Sat, Jul 18, 2026 at 2:32 AM Mateus R. Costa
> >  wrote:
> > > This brings it to my question: since to me I am almost sure nobody will ever install the x86_32 version, although it's perfectly buildable, what prevents me from, as a packager, to simply disable it for only that package?
> > >
> > > Is there a specific policy I should be aware of?
> >
> > Hi Mateus,
> > The current policy actually encourages package maintainers to drop the
> > leaf i686 packages on their discretion:
> >   https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval
> > You can go for it right now.
>
> You linked me to a Change, and specifically a Fedora 37 one.
> When I learned packaging RPMs I don't specifically remember whatever
> tutorial I read (which was probably on Fedora Docs) nor other RPM
> documentation on Fedora Docs I don't really remember anything pushing
> dropping x86_32 support.
>
> So unless something was added between then and now, or that I simply
> missed it, then potentially having the info to drop x86_32 if feasible
> on newer packages intended to the Fedora repos probably is a good
> idea.
> This is mostly in the "let's not keep accumulating new packages".
> Probably also interesting to bring up in package reviews for newer
> packages or unretired ones.
> > This thread's goal is to coordinate a larger independent effort - here
> > I seek validation of my analysis, and assistance with realization.
>
> I'm all for it, I am in favor of removing most 32-bits stuff except
> for the most likely libs to be needed if I ever have to manually run
> some 32-bit binary (which probably the FESCo list already covers).
> Though today most usecases where I would need to actually do that I
> probably can use flatpak or distrobox (even if in a non-Fedora
> container).
>
> So, I will handle bign-handheld-thumbnailer later. Though I will have
> to check how well that ExcludeArch policy is advertised on the
> packaging docs...
>
> Thanks for your time,
> Mateus Rodrigues Costa
> > --
> >
> > Michal Schorm
> > Senior Software Engineer
> > Databases Team
> > Red Hat
> >
> > --
> >
> > On Sat, Jul 18, 2026 at 2:32 AM Mateus R. Costa
> >  wrote:
> > > Em sex., 17 de jul. de 2026, 19:32, Michal Schorm  escreveu:
> > > > For those interested in this topic, I compiled a set of packages that exactly:
> > > >   builds i686 && all binary RPMs are buildroot-only && leaf && NOT on
> > > > FESCo "protected" list
> > > >
> > > > https://mschorm.fedorapeople.org/ARCHIVE/i686-removal/koji-only-leaf-i686_20...
> > > >
> > > > If my method and understanding are both correct, we could add
> > > > 'ExcludeArch: %{ix86}' to each of these 3,400 packages with zero
> > > > impact on the rest of the packages and save some resources.
> > > >
> > > > What do you think?
> > >
> > > I noticed bign-handheld-thumbnailer made it to this list.
> > >
> > > Since that project is just a thumbnailer and preferably the version equivalent to the host os architecture should be installed (and there's no x86 32-bits Fedora anymore AFAIK), this makes me curious on something.
> > >
> > > It seems to me that you're saying "hey, we could remove 32-bits x86 versions from these!", as if a large portion of the community has to agree beforehand on whether it's a good choice.
> > >
> > > This brings it to my question: since to me I am almost sure nobody will ever install the x86_32 version, although it's perfectly buildable, what prevents me from, as a packager, to simply disable it for only that package?
> > >
> > > Is there a specific policy I should be aware of?
> > >
> > > Thanks for your time,
> > > Mateus Rodrigues Costa
> > > > Michal
> > > >
> > > > --
> > > >
> > > > Michal Schorm
> > > > Senior Software Engineer
> > > > Databases Team
> > > > Red Hat
> > > >
> > > > --
> > > >
> > > > --
> > > > _______________________________________________
> > > > devel mailing list -- [e-mail]
> > > > To unsubscribe send an email to [e-mail]
> > > > 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/[e-mail]
> > > > Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
> > >
> > > --
> > > _______________________________________________
> > > devel mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > 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/[e-mail]
> > > Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
> >
> > --
> > _______________________________________________
> > devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail]
> > Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
>
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[Mattia Verga]

Il 18/07/26 03:02, Michal Schorm ha scritto:
> On Sat, Jul 18, 2026 at 2:32 AM Mateus R. Costa
>  wrote:
> > This brings it to my question: since to me I am almost sure nobody will ever install the x86_32 version, although it's perfectly buildable, what prevents me from, as a packager, to simply disable it for only that package?
> >
> > Is there a specific policy I should be aware of?
>
> Hi Mateus,
> The current policy actually encourages package maintainers to drop the
> leaf i686 packages on their discretion:
>    https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval
> You can go for it right now.
>
> This thread's goal is to coordinate a larger independent effort - here
> I seek validation of my analysis, and assistance with realization.

Perhaps it's time to file a new proposal and make i686 builds off by 
default?

If we have to add ExcludeArch to 3.400 packages + those which already 
exclude i686 builds, how many packages are left if we invert the logic 
and add some magic macro to enable i686 build?

Mattia

[Michal Schorm]

On Sat, Jul 18, 2026 at 9:07 AM Mattia Verga via devel
 wrote:
> If we have to add ExcludeArch to 3.400 packages + those which already
> exclude i686 builds, how many packages are left if we invert the logic
> and add some magic macro to enable i686 build?

Total source packages in Fedora: 23,245 src.rpm
Produce only noarch (i686 irrelevant): 12,620 src.rpm
Already ExcludeArch i686: 2,431 src.rpm

Currently producing i686 binary RPMs: 8,318 src.rpm / 19,306 bins

Proposed to remove (koji-only + leaf): 3,401 src.rpm / 3,557 bins
Would remain building i686: 4,917 src.rpm / 15,749 bins

In short: by applying this change, 2,431 (already exclude i686) +
3,401 (proposed to exclude i686) count would be larger than 4,917
(would remain i686), so we could invert the logic instead (disable
i686 by default + add 'Includearch: i686' to the 4,917).

An alternative way to reach the same result, with a benefit of new
packages having i686 off by default.

Michal

--

Michal Schorm
Senior Software Engineer
Databases Team
Red Hat

--

On Sat, Jul 18, 2026 at 9:07 AM Mattia Verga via devel
 wrote:
> Il 18/07/26 03:02, Michal Schorm ha scritto:
> > On Sat, Jul 18, 2026 at 2:32 AM Mateus R. Costa
> >  wrote:
> > > This brings it to my question: since to me I am almost sure nobody will ever install the x86_32 version, although it's perfectly buildable, what prevents me from, as a packager, to simply disable it for only that package?
> > >
> > > Is there a specific policy I should be aware of?
> >
> > Hi Mateus,
> > The current policy actually encourages package maintainers to drop the
> > leaf i686 packages on their discretion:
> >    https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval
> > You can go for it right now.
> >
> > This thread's goal is to coordinate a larger independent effort - here
> > I seek validation of my analysis, and assistance with realization.
>
> Perhaps it's time to file a new proposal and make i686 builds off by
> default?
>
> If we have to add ExcludeArch to 3.400 packages + those which already
> exclude i686 builds, how many packages are left if we invert the logic
> and add some magic macro to enable i686 build?
>
> Mattia
>
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[Gary Buhrmaster]

On Sat, Jul 18, 2026 at 8:11 AM Michal Schorm  wrote:
> Proposed to remove (koji-only + leaf): 3,401 src.rpm / 3,557 bins
> Would remain building i686: 4,917 src.rpm / 15,749 bins

If you ExcludeArch'ed the leaf packages
do you have any thoughts about how
many additional packages would become
a leaf package, and be able to be
ExcludeArch'ed in follow-on rounds of
the work?

[Michal Schorm]

On Sat, Jul 18, 2026 at 1:22 PM Miro Hrončok  wrote:
> I am unable to check your list right now (would rather like to review the
> script that generated it -- the methodology mentioned in the comment seems OK
> at a quick glance).

ACK, I will try to create a reproducible script.

On Sat, Jul 18, 2026 at 4:02 PM Gary Buhrmaster
 wrote:
> If you ExcludeArch'ed the leaf packages
> do you have any thoughts about how
> many additional packages would become
> a leaf package, and be able to be
> ExcludeArch'ed in follow-on rounds of
> the work?

Yes, roughly:
2nd round: ~ 187 src pkgs
3rd round: ~ 9 src pkgs
4rd round: none

I'll try to present reproducible evidence so we can apply this change
to those extra 187 + 9 packages too, right away.

Michal

--

Michal Schorm
Senior Software Engineer
Databases Team
Red Hat

--

[Michal Schorm]

I prepared the script, however, several things turned ugly and/or way
more complicated than anticipated. Who would have guessed, right? :)

TL;DR:
repo: https://codeberg.org/Faramos/fedora-i686-analysis
See the analysis matrix in other branches.
This result is likely closest to reality:
  https://codeberg.org/Faramos/fedora-i686-analysis/src/branch/rawhide/steam-o...
The good news is that I still have similar results. Slightly better, actually.

Longer version:

I'm sorry the script grew 850 lines long :( but I *tried* to at least
keep it friendly to read / audit.

Reproducibility:
 - The Rawhide repository data changes daily (and the F45 Mass Rebuild
is currently in progress)
 - The SPEC tarball is too large to include in the repo.
 - the analysis matrix grew
so I can't put the sources into the repository. I logged checksums,
but since there is no archive of the repo files, and no SPECfile
tarball for non-rawhide, so reproducibility is on the "trust me, bro"
basis. The best you can do is re-run the script and check how close
the result is to what I got. :(

Originally, I did not account for 'BuildRequires', when evaluating
whether a package is a leaf package.
Turns out >100 packages has to stay. But we are still at >3,400 ready to go.
Computation strategy got tricky, see "Forward pass" and "Backward
pass" comments in code.

Originally, I used the old F35 era FESCo list of "protected" packages.
I should have re-generated i myself.
Fabio's list is up-to-date, though it was still generated with DNF 3:
  https://forge.fedoraproject.org/packaging/i686-leafdrop
And also since F43 reportedly 'wine' no longer pull i686.
  https://forge.fedoraproject.org/packaging/i686-leafdrop/commit/0f4bed90f5779...
To be extra sure, I compared my script's run against the F35 FESCo
list, the current Rawhide Steam + Wine list and the current Rawhide
Steam only list and also against F44 - these are the branches in my
repo. It turns out that while the baselines differ, the resulting set
ready for removal stays exactly the same. In other words, all of the
wine or old (F35 list) packages are either multi-lib or non-leaf, thus
not affecting the set for removal.
With the up-to-date Rawhide FESCo "protected" list, and after tuning
my methodology (mostly thanks to summing up all removal iterations
together), the set of packages ready for removal grew to 3586.

The analysis also found:

4200 source packages should build for i686, but no corresponding
binary RPMs exist.
  'rust-*' (3,138), 'golang-*' (502) - Spec has no top-level
'BuildArch: noarch' but all produce only noarch '-devel' subpackages
  '*-fonts' (198)
  'ExclusiveArch: %{go_arches}' (24)
  The rest (351) likely consist of a mix of FTBFS and other corner cases

477 packages exist that have both 'ExcludeArch: %{ix86}' and
'BuildArch: noarch', meaning the 'ExcludeArch' has no effect.
  'ExclusiveArch: %{java_arches}' + 'BuildArch: noarch' (355) - ant,
maven, Java ecosystem
  'ExcludeArch: %{ix86} / i686' + 'BuildArch: noarch' (62) -
ansible-collection-*, VulkanMemoryAllocator
  'ExclusiveArch: x86_64' + 'BuildArch: noarch' (20) - ROCm, PyTorch,
HIP packages
  'ExclusiveArch: %{nodejs_arches}' + 'BuildArch: noarch' (18) -
nodejs-*, typescript
  'ExclusiveArch: %{rust_arches}' + 'BuildArch: noarch' (2) -
obs-service-rust2rpm, stratis-cli
  'ExclusiveArch: %{golang_arches}' +'BuildArch: noarch' (1) containers-common

Michal

--

Michal Schorm
Senior Software Engineer
Databases Team
Red Hat

--

On Sat, Jul 18, 2026 at 6:34 PM Michal Schorm  wrote:
> On Sat, Jul 18, 2026 at 1:22 PM Miro Hrončok  wrote:
> > I am unable to check your list right now (would rather like to review the
> > script that generated it -- the methodology mentioned in the comment seems OK
> > at a quick glance).
>
> ACK, I will try to create a reproducible script.
>
> On Sat, Jul 18, 2026 at 4:02 PM Gary Buhrmaster
>  wrote:
> > If you ExcludeArch'ed the leaf packages
> > do you have any thoughts about how
> > many additional packages would become
> > a leaf package, and be able to be
> > ExcludeArch'ed in follow-on rounds of
> > the work?
>
> Yes, roughly:
> 2nd round: ~ 187 src pkgs
> 3rd round: ~ 9 src pkgs
> 4rd round: none
>
> I'll try to present reproducible evidence so we can apply this change
> to those extra 187 + 9 packages too, right away.
>
> Michal
>
> --
>
> Michal Schorm
> Senior Software Engineer
> Databases Team
> Red Hat
>
> --

[Vít Ondruch]

Dne 18. 07. 26 v 9:06 Mattia Verga via devel napsal(a):
> Il 18/07/26 03:02, Michal Schorm ha scritto:
> > On Sat, Jul 18, 2026 at 2:32 AM Mateus R. Costa
> >  wrote:
> > > This brings it to my question: since to me I am almost sure nobody will ever install the x86_32 version, although it's perfectly buildable, what prevents me from, as a packager, to simply disable it for only that package?
> > >
> > > Is there a specific policy I should be aware of?
> >
> > Hi Mateus,
> > The current policy actually encourages package maintainers to drop the
> > leaf i686 packages on their discretion:
> >     https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval
> > You can go for it right now.
> >
> > This thread's goal is to coordinate a larger independent effort - here
> > I seek validation of my analysis, and assistance with realization.
>
> Perhaps it's time to file a new proposal and make i686 builds off by
> default?
>
> If we have to add ExcludeArch to 3.400 packages + those which already
> exclude i686 builds, how many packages are left if we invert the logic
> and add some magic macro to enable i686 build?

+1

If "inverted" way is technically possible, I would very much prefer it.

Even if majority packages should be initially explicitly enabled for 
i686, I think that is much better approach, because after the i686 
builders are removed, we will be forced to do the cleanup. Not leftover 
`ExcludeArch: %{ix86}` will stay behind.

BTW this likely mean that at the same time, the already existing 
`ExcludeArch: %{ix86}` should be removed, because they won't have any 
purpose (although I am sure that some maintainers might use these 
platforms also for other distributions).

Vít

[Miro Hrončok]

On 18. 07. 26 0:32, Michal Schorm wrote:
> For those interested in this topic, I compiled a set of packages that exactly:
>    builds i686 && all binary RPMs are buildroot-only && leaf && NOT on
> FESCo "protected" list
>
> https://mschorm.fedorapeople.org/ARCHIVE/i686-removal/koji-only-leaf-i686_20...
>
> If my method and understanding are both correct, we could add
> 'ExcludeArch: %{ix86}' to each of these 3,400 packages with zero
> impact on the rest of the packages and save some resources.
>
> What do you think?

I am unable to check your list right now (would rather like to review the 
script that generated it -- the methodology mentioned in the comment seems OK 
at a quick glance).

Huge YES to doing this once the list is verified. Thank you!

[Richard W.M. Jones]

On Sat, Jul 18, 2026 at 12:32:14AM +0200, Michal Schorm wrote:
> For those interested in this topic, I compiled a set of packages that exactly:
>   builds i686 && all binary RPMs are buildroot-only && leaf && NOT on
> FESCo "protected" list
>
> https://mschorm.fedorapeople.org/ARCHIVE/i686-removal/koji-only-leaf-i686_20...
>
> If my method and understanding are both correct, we could add
> 'ExcludeArch: %{ix86}' to each of these 3,400 packages with zero
> impact on the rest of the packages and save some resources.
>
> What do you think?

An i686 build found a 32 bit assumption in my code last week.  This
happens from time to time and I think it's still useful.  So even
though I don't think any of my packages are relevant on i686, for me
it's worth keeping (some of) them alive.

Having said that I obviously have no objection if a packger wishes to
drop i686 builds from their own package.

Rich.

[Michal Schorm]

On Mon, Jul 20, 2026 at 4:39 PM Richard W.M. Jones  wrote:
> An i686 build found a 32 bit assumption in my code last week.  This
> happens from time to time and I think it's still useful.  So even
> though I don't think any of my packages are relevant on i686, for me
> it's worth keeping (some of) them alive.

I see the same sentiment in the s390x discussions, and I'm simply not
convinced it's worth doing just for the sake of doing it.
But that's better left for an entirely different mail thread.
> Having said that I obviously have no objection if a packger wishes to
> drop i686 builds from their own package.

I can imagine having a single list of "package: maintainer [,
maintainer, ...]" format that keeps track of packages and packagers
who want to keep it building for i686 for any reason, and "steam:
FESCo" could be the first entry.
The list, and its dependencies would then be protected against i686
removal; at least from this particular effort.

That way we could move forward with removing unwanted i686 packages
and deal with this list later in the process.
Would that work for you?

Michal

--

Michal Schorm
Senior Software Engineer
Databases Team
Red Hat

--

On Mon, Jul 20, 2026 at 4:39 PM Richard W.M. Jones  wrote:
> On Sat, Jul 18, 2026 at 12:32:14AM +0200, Michal Schorm wrote:
> > For those interested in this topic, I compiled a set of packages that exactly:
> >   builds i686 && all binary RPMs are buildroot-only && leaf && NOT on
> > FESCo "protected" list
> >
> > https://mschorm.fedorapeople.org/ARCHIVE/i686-removal/koji-only-leaf-i686_20...
> >
> > If my method and understanding are both correct, we could add
> > 'ExcludeArch: %{ix86}' to each of these 3,400 packages with zero
> > impact on the rest of the packages and save some resources.
> >
> > What do you think?
>
> An i686 build found a 32 bit assumption in my code last week.  This
> happens from time to time and I think it's still useful.  So even
> though I don't think any of my packages are relevant on i686, for me
> it's worth keeping (some of) them alive.
>
> Having said that I obviously have no objection if a packger wishes to
> drop i686 builds from their own package.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-p2v converts physical machines to virtual machines.  Boot with a
> live CD or over the network (PXE) and turn machines into KVM guests.
> http://libguestfs.org/virt-v2v
>
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[Daniel P. Berrangé]

On Tue, Jul 21, 2026 at 11:24:43AM +0200, Michal Schorm wrote:
> On Mon, Jul 20, 2026 at 4:39 PM Richard W.M. Jones  wrote:
> > An i686 build found a 32 bit assumption in my code last week.  This
> > happens from time to time and I think it's still useful.  So even
> > though I don't think any of my packages are relevant on i686, for me
> > it's worth keeping (some of) them alive.
>
> I see the same sentiment in the s390x discussions, and I'm simply not
> convinced it's worth doing just for the sake of doing it.
> But that's better left for an entirely different mail thread.

At least in the s390x case, the architecture is still actively being
used and new machines sold. It may not be so compelling to Fedora as
to enterprise distros, but s390x portability is still relevant in
general to projects.  The same can't be said for i686. Portability
to 32-bit is largely an academic concern, especially as upstreams
increasingly drop 32-bit support.
> > Having said that I obviously have no objection if a packger wishes to
> > drop i686 builds from their own package.
>
> I can imagine having a single list of "package: maintainer [,
> maintainer, ...]" format that keeps track of packages and packagers
> who want to keep it building for i686 for any reason, and "steam:
> FESCo" could be the first entry.
> The list, and its dependencies would then be protected against i686
> removal; at least from this particular effort.

Trying to allow-list further packages per individual maintainer
desires is undesirable as you can't do that in isolation. It would
have a ripple effect on all dependencies, which would put a burden
on other maintainers.

If we're to make significant progress eliminating i686, IMHO we
need a use-case focused approach to package inclusion.

Produce a transitive list of RPMs needed for Steam (and other agreed
important 32-bit end user solutions, if any), then propose to drop
everything else.

With regards,
Daniel

[Fabio Valentini]

On Tue, Jul 21, 2026 at 11:43 AM Daniel P. Berrangé  wrote:
> On Tue, Jul 21, 2026 at 11:24:43AM +0200, Michal Schorm wrote:
> > On Mon, Jul 20, 2026 at 4:39 PM Richard W.M. Jones  wrote:
> > > An i686 build found a 32 bit assumption in my code last week.  This
> > > happens from time to time and I think it's still useful.  So even
> > > though I don't think any of my packages are relevant on i686, for me
> > > it's worth keeping (some of) them alive.
> >
> > I see the same sentiment in the s390x discussions, and I'm simply not
> > convinced it's worth doing just for the sake of doing it.
> > But that's better left for an entirely different mail thread.
>
> At least in the s390x case, the architecture is still actively being
> used and new machines sold. It may not be so compelling to Fedora as
> to enterprise distros, but s390x portability is still relevant in
> general to projects.  The same can't be said for i686. Portability
> to 32-bit is largely an academic concern, especially as upstreams
> increasingly drop 32-bit support.
> > > Having said that I obviously have no objection if a packger wishes to
> > > drop i686 builds from their own package.
> >
> > I can imagine having a single list of "package: maintainer [,
> > maintainer, ...]" format that keeps track of packages and packagers
> > who want to keep it building for i686 for any reason, and "steam:
> > FESCo" could be the first entry.
> > The list, and its dependencies would then be protected against i686
> > removal; at least from this particular effort.
>
> Trying to allow-list further packages per individual maintainer
> desires is undesirable as you can't do that in isolation. It would
> have a ripple effect on all dependencies, which would put a burden
> on other maintainers.
>
> If we're to make significant progress eliminating i686, IMHO we
> need a use-case focused approach to package inclusion.
>
> Produce a transitive list of RPMs needed for Steam (and other agreed
> important 32-bit end user solutions, if any), then propose to drop
> everything else.

This has been discussed previously, and it likely just won't work.
We would either need changes to koji for this, *or* add ExcludeArch:
i686 to 20000 packages.

There's also complications around what constitutes a closed,
self-hosted set of packages.
You need to consider not only dependencies, but also
build-dependencies, and transitive build-dependencies.
So the size of the closed, self-hosted set of packages you need for
i686 to keep working is surprisingly large.

Fabio

[Daniel P. Berrangé]

On Tue, Jul 21, 2026 at 01:26:08PM +0200, Fabio Valentini wrote:
> On Tue, Jul 21, 2026 at 11:43 AM Daniel P. Berrangé  wrote:
> > On Tue, Jul 21, 2026 at 11:24:43AM +0200, Michal Schorm wrote:
> > > On Mon, Jul 20, 2026 at 4:39 PM Richard W.M. Jones  wrote:
> > > > An i686 build found a 32 bit assumption in my code last week.  This
> > > > happens from time to time and I think it's still useful.  So even
> > > > though I don't think any of my packages are relevant on i686, for me
> > > > it's worth keeping (some of) them alive.
> > >
> > > I see the same sentiment in the s390x discussions, and I'm simply not
> > > convinced it's worth doing just for the sake of doing it.
> > > But that's better left for an entirely different mail thread.
> >
> > At least in the s390x case, the architecture is still actively being
> > used and new machines sold. It may not be so compelling to Fedora as
> > to enterprise distros, but s390x portability is still relevant in
> > general to projects.  The same can't be said for i686. Portability
> > to 32-bit is largely an academic concern, especially as upstreams
> > increasingly drop 32-bit support.
> > > > Having said that I obviously have no objection if a packger wishes to
> > > > drop i686 builds from their own package.
> > >
> > > I can imagine having a single list of "package: maintainer [,
> > > maintainer, ...]" format that keeps track of packages and packagers
> > > who want to keep it building for i686 for any reason, and "steam:
> > > FESCo" could be the first entry.
> > > The list, and its dependencies would then be protected against i686
> > > removal; at least from this particular effort.
> >
> > Trying to allow-list further packages per individual maintainer
> > desires is undesirable as you can't do that in isolation. It would
> > have a ripple effect on all dependencies, which would put a burden
> > on other maintainers.
> >
> > If we're to make significant progress eliminating i686, IMHO we
> > need a use-case focused approach to package inclusion.
> >
> > Produce a transitive list of RPMs needed for Steam (and other agreed
> > important 32-bit end user solutions, if any), then propose to drop
> > everything else.
>
> This has been discussed previously, and it likely just won't work.
> We would either need changes to koji for this, *or* add ExcludeArch:
> i686 to 20000 packages.

The stats quoted elsewhere in this thread were not as large as 20k:
> > > Total source packages in Fedora: 23,245 src.rpm
> > > Produce only noarch (i686 irrelevant): 12,620 src.rpm
> > > Already ExcludeArch i686: 2,431 src.rpm
> > > Currently producing i686 binary RPMs: 8,318 src.rpm / 19,306 bins
> > >
> > > Proposed to remove (koji-only + leaf): 3,401 src.rpm / 3,557 bins
> > > Would remain building i686: 4,917 src.rpm / 15,749 bins

So i guess what I'm asking is can we use knowledge of what is
used by Steam, to cut that 4917 down even more.

It was suggested we might invert the behaviour to opt-in to
i686, instead of opt-ing out. If we want an opt-in, then
getting that 4917 figure as small as possible appears pretty
beneficial.
> There's also complications around what constitutes a closed,
> self-hosted set of packages.
> You need to consider not only dependencies, but also
> build-dependencies, and transitive build-dependencies.

Yes, we need to recursively chase the deps.
> So the size of the closed, self-hosted set of packages you need for
> i686 to keep working is surprisingly large.

Yes, but hopefully still significantly smaller than the 4917 listed
above.

With regards,
Daniel

[Michal Schorm]

On Tue, Jul 21, 2026 at 1:27 PM Fabio Valentini  wrote:
> We would either need changes to koji for this, *or* add ExcludeArch:
> i686 to 20000 packages.

Only ~10,000 packages *can* produce i686 binary RPMs.
Only ~8,500 currently *do* produce them, and my proposal would cut the
number in half.

I can do the work if that's the problem. It's just one huge bulk operation.

Having 'ExcludeArch' in thousands of packages isn't the most elegant
solution, but the cost value effectivity specifically for the cut I
propose here is IMO great.
Especially since it requires zero build system changes and (close to
?) no maintainer disruption.

On Tue, Jul 21, 2026 at 11:44 AM Daniel P. Berrangé  wrote:
> Trying to allow-list further packages per individual maintainer
> desires is undesirable as you can't do that in isolation. It would
> have a ripple effect on all dependencies, which would put a burden
> on other maintainers.
>
> If we're to make significant progress eliminating i686, IMHO we
> need a use-case focused approach to package inclusion.

My personal goal here (which I believe is achievable) is to do a
one-time high-value cut of all the easy-to-cut packages.
I specifically do not want to dive deeper into the rabbit hole of full
i686 removal - I consciously took an easy task (in comparison) so we
make any progress at all, and I will leave the hard part of doing the
rest to others.

While definitely undesirable, if that were the only way to get
approval for this cut, I'd create such a list and keep the transitive
dependencies of those packages.
I'd honor the list for this cut, and again, leave the hard work of
figuring out what to do with the list in the future for someone else.
I'd sure be happier without the per-packager wish list though.

Michal

--

Michal Schorm
Senior Software Engineer
Databases Team
Red Hat

--

On Tue, Jul 21, 2026 at 1:42 PM Daniel P. Berrangé  wrote:
> On Tue, Jul 21, 2026 at 01:26:08PM +0200, Fabio Valentini wrote:
> > On Tue, Jul 21, 2026 at 11:43 AM Daniel P. Berrangé  wrote:
> > > On Tue, Jul 21, 2026 at 11:24:43AM +0200, Michal Schorm wrote:
> > > > On Mon, Jul 20, 2026 at 4:39 PM Richard W.M. Jones  wrote:
> > > > > An i686 build found a 32 bit assumption in my code last week.  This
> > > > > happens from time to time and I think it's still useful.  So even
> > > > > though I don't think any of my packages are relevant on i686, for me
> > > > > it's worth keeping (some of) them alive.
> > > >
> > > > I see the same sentiment in the s390x discussions, and I'm simply not
> > > > convinced it's worth doing just for the sake of doing it.
> > > > But that's better left for an entirely different mail thread.
> > >
> > > At least in the s390x case, the architecture is still actively being
> > > used and new machines sold. It may not be so compelling to Fedora as
> > > to enterprise distros, but s390x portability is still relevant in
> > > general to projects.  The same can't be said for i686. Portability
> > > to 32-bit is largely an academic concern, especially as upstreams
> > > increasingly drop 32-bit support.
> > > > > Having said that I obviously have no objection if a packger wishes to
> > > > > drop i686 builds from their own package.
> > > >
> > > > I can imagine having a single list of "package: maintainer [,
> > > > maintainer, ...]" format that keeps track of packages and packagers
> > > > who want to keep it building for i686 for any reason, and "steam:
> > > > FESCo" could be the first entry.
> > > > The list, and its dependencies would then be protected against i686
> > > > removal; at least from this particular effort.
> > >
> > > Trying to allow-list further packages per individual maintainer
> > > desires is undesirable as you can't do that in isolation. It would
> > > have a ripple effect on all dependencies, which would put a burden
> > > on other maintainers.
> > >
> > > If we're to make significant progress eliminating i686, IMHO we
> > > need a use-case focused approach to package inclusion.
> > >
> > > Produce a transitive list of RPMs needed for Steam (and other agreed
> > > important 32-bit end user solutions, if any), then propose to drop
> > > everything else.
> >
> > This has been discussed previously, and it likely just won't work.
> > We would either need changes to koji for this, *or* add ExcludeArch:
> > i686 to 20000 packages.
>
> The stats quoted elsewhere in this thread were not as large as 20k:
> > > > Total source packages in Fedora: 23,245 src.rpm
> > > > Produce only noarch (i686 irrelevant): 12,620 src.rpm
> > > > Already ExcludeArch i686: 2,431 src.rpm
> > > > Currently producing i686 binary RPMs: 8,318 src.rpm / 19,306 bins
> > > >
> > > > Proposed to remove (koji-only + leaf): 3,401 src.rpm / 3,557 bins
> > > > Would remain building i686: 4,917 src.rpm / 15,749 bins
>
> So i guess what I'm asking is can we use knowledge of what is
> used by Steam, to cut that 4917 down even more.
>
> It was suggested we might invert the behaviour to opt-in to
> i686, instead of opt-ing out. If we want an opt-in, then
> getting that 4917 figure as small as possible appears pretty
> beneficial.
> > There's also complications around what constitutes a closed,
> > self-hosted set of packages.
> > You need to consider not only dependencies, but also
> > build-dependencies, and transitive build-dependencies.
>
> Yes, we need to recursively chase the deps.
> > So the size of the closed, self-hosted set of packages you need for
> > i686 to keep working is surprisingly large.
>
> Yes, but hopefully still significantly smaller than the 4917 listed
> above.
>
> With regards,
> Daniel
> --
> |: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
> |: https://libvirt.org          ~~          https://entangle-photo.org :|
> |: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|
>
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

[Daniel P. Berrangé]

On Tue, Jul 21, 2026 at 03:51:44PM +0200, Michal Schorm wrote:
> On Tue, Jul 21, 2026 at 1:27 PM Fabio Valentini  wrote:
> > We would either need changes to koji for this, *or* add ExcludeArch:
> > i686 to 20000 packages.
>
> Only ~10,000 packages *can* produce i686 binary RPMs.
> Only ~8,500 currently *do* produce them, and my proposal would cut the
> number in half.
>
> I can do the work if that's the problem. It's just one huge bulk operation.
>
> Having 'ExcludeArch' in thousands of packages isn't the most elegant
> solution, but the cost value effectivity specifically for the cut I
> propose here is IMO great.
> Especially since it requires zero build system changes and (close to
> ?) no maintainer disruption.
>
> On Tue, Jul 21, 2026 at 11:44 AM Daniel P. Berrangé  wrote:
> > Trying to allow-list further packages per individual maintainer
> > desires is undesirable as you can't do that in isolation. It would
> > have a ripple effect on all dependencies, which would put a burden
> > on other maintainers.
> >
> > If we're to make significant progress eliminating i686, IMHO we
> > need a use-case focused approach to package inclusion.
>
> My personal goal here (which I believe is achievable) is to do a
> one-time high-value cut of all the easy-to-cut packages.
> I specifically do not want to dive deeper into the rabbit hole of full
> i686 removal - I consciously took an easy task (in comparison) so we
> make any progress at all, and I will leave the hard part of doing the
> rest to others.

Understood. I support your proposal to move us forward in removing
more i686.

With regards,
Daniel

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jul 21, 2026 at 04:42:22PM +0100, Daniel P. Berrangé wrote:
> On Tue, Jul 21, 2026 at 03:51:44PM +0200, Michal Schorm wrote:
> > On Tue, Jul 21, 2026 at 1:27 PM Fabio Valentini  wrote:
> > > We would either need changes to koji for this, *or* add ExcludeArch:
> > > i686 to 20000 packages.
> >
> > Only ~10,000 packages *can* produce i686 binary RPMs.
> > Only ~8,500 currently *do* produce them, and my proposal would cut the
> > number in half.
> >
> > I can do the work if that's the problem. It's just one huge bulk operation.
> >
> > Having 'ExcludeArch' in thousands of packages isn't the most elegant
> > solution, but the cost value effectivity specifically for the cut I
> > propose here is IMO great.
> > Especially since it requires zero build system changes and (close to
> > ?) no maintainer disruption.
> >
> > On Tue, Jul 21, 2026 at 11:44 AM Daniel P. Berrangé  wrote:
> > > Trying to allow-list further packages per individual maintainer
> > > desires is undesirable as you can't do that in isolation. It would
> > > have a ripple effect on all dependencies, which would put a burden
> > > on other maintainers.
> > >
> > > If we're to make significant progress eliminating i686, IMHO we
> > > need a use-case focused approach to package inclusion.
> >
> > My personal goal here (which I believe is achievable) is to do a
> > one-time high-value cut of all the easy-to-cut packages.
> > I specifically do not want to dive deeper into the rabbit hole of full
> > i686 removal - I consciously took an easy task (in comparison) so we
> > make any progress at all, and I will leave the hard part of doing the
> > rest to others.
>
> Understood. I support your proposal to move us forward in removing
> more i686.

Same here. Michal, you have my support!

I read the thread, and there are two proposals:
- Your proposal to add ExcludeArch to ~3k packages.
- The competing idea to make koji exlude i686 builds by default and
  convert to an opt-in scheme.

The second approach might be conceptually nicer, but:
- We don't have a mechanism like this, so we'd need to design it,
  implement in koji, deploy, and then start using it.
- This mechanism would need to not introduce any backward-compatible
  changes in spec files or elsewhere.
- It'd create a lot of churn too, since over time we'd want to stop
  building more packages, so we'd need to first add a big batch and
  then remove items from the opt-in list.

So unless somebody has an easy way to implement opt-in, I think the
opt-out approach with ExcludeArch is worth pursing.

To make this concrete, I'd propose the following workflow:
1. create a list of packages to be ExcludeArch'ed
2. file a Fedora 46 Change Proposal for this, with the list
3. (wait for the discussion and approval)
4. push the ExcludeArch additions after branching (Tue 2026-08-11),
   using provenpackager direct-push workflow.

(Why Change Proposal: this is how previous tranches was handled in the
past, it raises visibility and gives a good reference point for
people.

Why ProverPackager-push: with 3k+ packages, PRs would be too much
of an overhead. The additions to most packages will be a completely
trivial one-line change (+ few a lines entry for packages without
%autorelease/%autochangelog).

Why F46: it seems late for F45. We want to stabilize things and
by the time this could be pushed to F45, we'd be at code completion
deadlines and this change could create some disruption.)

Zbyszek

[Richard W.M. Jones]

On Tue, Jul 21, 2026 at 03:51:44PM +0200, Michal Schorm wrote:
> My personal goal here (which I believe is achievable) is to do a
> one-time high-value cut of all the easy-to-cut packages.

I'm still wondering why exactly.  How are you affected by other people
maintaining i686 packages?  What does this change achieve?
> I specifically do not want to dive deeper into the rabbit hole of full
> i686 removal - I consciously took an easy task (in comparison) so we
> make any progress at all, and I will leave the hard part of doing the
> rest to others.
>
> While definitely undesirable, if that were the only way to get
> approval for this cut, I'd create such a list and keep the transitive
> dependencies of those packages.
> I'd honor the list for this cut, and again, leave the hard work of
> figuring out what to do with the list in the future for someone else.
> I'd sure be happier without the per-packager wish list though.

Rich.

[Leigh Scott]

Daniel P. Berrangé wrote:
> If we're to make significant progress eliminating i686, IMHO we
> need a use-case focused approach to package inclusion.
> Produce a transitive list of RPMs needed for Steam (and other agreed
> important 32-bit end user solutions, if any), then propose to drop
> everything else.
> With regards,
> Daniel

Do we actually need to offer native support for 32bit apps, can't flatpak handle it instead?

[Richard W.M. Jones]

On Tue, Jul 21, 2026 at 11:24:43AM +0200, Michal Schorm wrote:
> On Mon, Jul 20, 2026 at 4:39 PM Richard W.M. Jones  wrote:
> > An i686 build found a 32 bit assumption in my code last week.  This
> > happens from time to time and I think it's still useful.  So even
> > though I don't think any of my packages are relevant on i686, for me
> > it's worth keeping (some of) them alive.
>
> I see the same sentiment in the s390x discussions, and I'm simply not
> convinced it's worth doing just for the sake of doing it.
> But that's better left for an entirely different mail thread.

I think there may be a time when we say that all software that we care
about is 64 bit (and little endian) but I'm not quite sure that time
is right now.

We've been here before, when software moved from 16 to 32 bit, and
16 bit was still relevant for a time, but now 16 bit is barely used
even at the very low end and rightly we no longer care about
portability.
> > Having said that I obviously have no objection if a packger wishes to
> > drop i686 builds from their own package.
>
> I can imagine having a single list of "package: maintainer [,
> maintainer, ...]" format that keeps track of packages and packagers
> who want to keep it building for i686 for any reason, and "steam:
> FESCo" could be the first entry.
> The list, and its dependencies would then be protected against i686
> removal; at least from this particular effort.
>
> That way we could move forward with removing unwanted i686 packages
> and deal with this list later in the process.
> Would that work for you?

If we keep i686 builders at all then we might as well leave it up to
individual packagers.  I'm not sure what we're trying to achieve by
unilaterally disabling the i686 subpackages, unless the plan is to
actually remove the architecture entirely.  If i686 subpackages break,
packagers can exclude them themselves.

Rich.

[Mattia Verga]

Il 21/07/26 19:37, Richard W.M. Jones ha scritto:
> I'm not sure what we're trying to achieve by
> unilaterally disabling the i686 subpackages, unless the plan is to
> actually remove the architecture entirely.

The question is: those 3,400 packages that are claimed to be leaf 
packages and not useful to build for i686, how much disk space in 
repositories (and network bandwith transfer for synch) and how much 
build time consume for nothing? I suspect that both are not 
negligible... yet there seem to be some reluctance to this change, while 
on the other end a proposal to enable x86_64v3 is struggling because "we 
don't have enough resources"...

Mattia

[Michal Schorm]

On Tue, Jul 21, 2026 at 7:38 PM Richard W.M. Jones  wrote:
> I'm not sure what we're trying to achieve by
> unilaterally disabling the i686 subpackages, unless the plan is to
> actually remove the architecture entirely.

As I see it, the plan has been in place for almost a decade, starting
with the F27 removal of i686 kernels, with various contributors moving
it forward incrementally. In recent years, the topic slowed down and
proved complex, but I don't see a community wish for reverting it, or
stopping it entirely, only to push forward, just without breaking (too
much) stuff.

The F44 Change to disable multilib entirely was too big of a bite, for now.

My goal is to contribute with two more reachable objectives:
1) Save resources (computational and disk). On 3.5k packages, that
could be noticeable. An extra argument is that there are zero
consumers of them (apart from you).
2) Clear the way for others to move this topic forward. With those
3.5k packages gone, the end goal is nearer, the size feels more
manageable, and the complicated parts become more visible and more
isolated.

In summary, this is more of a strategic move, with a smaller technical
benefit as a bonus.
I have no other motivation or better justification.

The fact that maintainers can drop i686 support themselves keeps us in
the status quo, not moving forward.
I'd rather move forward even if the step doesn't seem significant at the moment

On Tue, Jul 21, 2026 at 9:04 PM Mattia Verga via devel
 wrote:
> on the other end a proposal to enable x86_64v3 is struggling because "we
> don't have enough resources"...

Ha, that seems to be a solid argument for resources reclamation :)

Michal

--

Michal Schorm
Senior Software Engineer
Databases Team
Red Hat

--

[Kevin Fenzi]

On Tue, Jul 21, 2026 at 07:03:51PM +0000, Mattia Verga via devel wrote:
> Il 21/07/26 19:37, Richard W.M. Jones ha scritto:
> > I'm not sure what we're trying to achieve by
> > unilaterally disabling the i686 subpackages, unless the plan is to
> > actually remove the architecture entirely.
>
> The question is: those 3,400 packages that are claimed to be leaf 
> packages and not useful to build for i686, how much disk space in 
> repositories (and network bandwith transfer for synch) and how much

Well, we don't sync i686 repos anymore. Only those things that are in
the x86_64 repo/multilib are shipped. So, many of these dont likely
matter for that? Or it's a subset at least...
> build time consume for nothing? I suspect that both are not

Of course they are still built, so that does indeed matter.
> negligible... yet there seem to be some reluctance to this change, while 
> on the other end a proposal to enable x86_64v3 is struggling because "we 
> don't have enough resources"...

In that case the duplication is not worth the resources, IMHO.

kevin

[Richard W.M. Jones]

On Tue, Jul 21, 2026 at 07:03:51PM +0000, Mattia Verga via devel wrote:
> Il 21/07/26 19:37, Richard W.M. Jones ha scritto:
> > I'm not sure what we're trying to achieve by
> > unilaterally disabling the i686 subpackages, unless the plan is to
> > actually remove the architecture entirely.
>
> The question is: those 3,400 packages that are claimed to be leaf 
> packages and not useful to build for i686, how much disk space in 
> repositories (and network bandwith transfer for synch) and how much 
> build time consume for nothing? I suspect that both are not 
> negligible... yet there seem to be some reluctance to this change, while 
> on the other end a proposal to enable x86_64v3 is struggling because "we 
> don't have enough resources"...

I'm pretty sure it is negligible until we actually get rid of i686
altogether.

And compared to the gigantic build out of AI, or the general nonsense
that goes on in computing -- vast, wasteful CI; inefficient
interpreted code, etc etc -- a few thousand i686 subpackages are a
drop in the ocean.

Again, packagers themselves may decide to remove the leaf packages,
and that's fine.  Just don't force it on everyone.  This proposal *will*
cause silent bugs.

Rich.

[Daniel P. Berrangé]

On Tue, Jul 21, 2026 at 10:08:47PM +0100, Richard W.M. Jones wrote:
> On Tue, Jul 21, 2026 at 07:03:51PM +0000, Mattia Verga via devel wrote:
> > Il 21/07/26 19:37, Richard W.M. Jones ha scritto:
> > > I'm not sure what we're trying to achieve by
> > > unilaterally disabling the i686 subpackages, unless the plan is to
> > > actually remove the architecture entirely.
> >
> > The question is: those 3,400 packages that are claimed to be leaf 
> > packages and not useful to build for i686, how much disk space in 
> > repositories (and network bandwith transfer for synch) and how much 
> > build time consume for nothing? I suspect that both are not 
> > negligible... yet there seem to be some reluctance to this change, while 
> > on the other end a proposal to enable x86_64v3 is struggling because "we 
> > don't have enough resources"...
>
> I'm pretty sure it is negligible until we actually get rid of i686
> altogether.
>
> And compared to the gigantic build out of AI, or the general nonsense
> that goes on in computing -- vast, wasteful CI; inefficient
> interpreted code, etc etc -- a few thousand i686 subpackages are a
> drop in the ocean.
>
> Again, packagers themselves may decide to remove the leaf packages,
> and that's fine.  Just don't force it on everyone.  This proposal *will*
> cause silent bugs.

It shouldn't cause bugs for Fedora, since we're not shipping i686 as
a deliverable anymore beyond multi-lib packages.

It might result in i686 bugs going undetected for upstream projects
which are not running their own i686 CI jobs before release, and
thus dependent on Fedora to find i686 bugs. This is an upstream job
to solve though, if they genuinely care about 32-bit portability
still.

With regards,
Daniel

[Vít Ondruch]

Dne 21. 07. 26 v 23:08 Richard W.M. Jones napsal(a):
> On Tue, Jul 21, 2026 at 07:03:51PM +0000, Mattia Verga via devel wrote:
> > Il 21/07/26 19:37, Richard W.M. Jones ha scritto:
> > > I'm not sure what we're trying to achieve by
> > > unilaterally disabling the i686 subpackages, unless the plan is to
> > > actually remove the architecture entirely.
> >
> > The question is: those 3,400 packages that are claimed to be leaf
> > packages and not useful to build for i686, how much disk space in
> > repositories (and network bandwith transfer for synch) and how much
> > build time consume for nothing? I suspect that both are not
> > negligible... yet there seem to be some reluctance to this change, while
> > on the other end a proposal to enable x86_64v3 is struggling because "we
> > don't have enough resources"...
>
> I'm pretty sure it is negligible until we actually get rid of i686
> altogether.
>
> And compared to the gigantic build out of AI, or the general nonsense
> that goes on in computing -- vast, wasteful CI; inefficient
> interpreted code, etc etc -- a few thousand i686 subpackages are a
> drop in the ocean.
>
> Again, packagers themselves may decide to remove the leaf packages,
> and that's fine.

I go with default, which is having i686 packages. I assume that most 
others packagers do the same. That means that we keep the status quo and 
the number of i686 package is decreasing only very slowly if at all.

And no, I don't perceive guideline such as "You should include 
`ExcludeArch: %{ix86}` (for new packages)" changing the default.

So if we are able to change the default, then that is the step in right 
direction IMHO. Side effect of changing the default would be review of 
which packages we really need for i686 to re-enable those. And it would 
be sensible to re-enable reasonable small set of packages.

IOW, the idea is that ATM, you should still be able to re-enable i686 
for whatever purpose.
> Just don't force it on everyone.  This proposal *will*
> cause silent bugs.

I agree with this, but if they bother somebody, they will be fixed, 
won't they?

Vít
> Rich.

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jul 20, 2026 at 03:38:27PM +0100, Richard W.M. Jones wrote:
> On Sat, Jul 18, 2026 at 12:32:14AM +0200, Michal Schorm wrote:
> > For those interested in this topic, I compiled a set of packages that exactly:
> >   builds i686 && all binary RPMs are buildroot-only && leaf && NOT on
> > FESCo "protected" list
> >
> > https://mschorm.fedorapeople.org/ARCHIVE/i686-removal/koji-only-leaf-i686_20...
> >
> > If my method and understanding are both correct, we could add
> > 'ExcludeArch: %{ix86}' to each of these 3,400 packages with zero
> > impact on the rest of the packages and save some resources.
> >
> > What do you think?
>
> An i686 build found a 32 bit assumption in my code last week.  This
> happens from time to time and I think it's still useful.  So even
> though I don't think any of my packages are relevant on i686, for me
> it's worth keeping (some of) them alive.
>
> Having said that I obviously have no objection if a packger wishes to
> drop i686 builds from their own package.

Please consider the following:
even if it'd benefit me to drop the i686 build, as an individual
packager who doesn't care about i686 testing and is building the i686
mostly out of intertia, I'm very likely to not do this unless the i686
build actively breaks or there's another strong reason. As long as the
i686 builds pass, it's less effort to not do anything, not figure out
if there are any dependent packages, not look up the ExludeArch
syntax, etc.

But this also means that as a big group of packagers, we're stuck in a
local minimum, collectively doing a bunch of builds that we don't
actually care about. The proposed change would kick us out of the
local minimum.

Zbyszek

[Richard W.M. Jones]

On Wed, Jul 22, 2026 at 02:48:18PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jul 20, 2026 at 03:38:27PM +0100, Richard W.M. Jones wrote:
> > On Sat, Jul 18, 2026 at 12:32:14AM +0200, Michal Schorm wrote:
> > > For those interested in this topic, I compiled a set of packages that exactly:
> > >   builds i686 && all binary RPMs are buildroot-only && leaf && NOT on
> > > FESCo "protected" list
> > >
> > > https://mschorm.fedorapeople.org/ARCHIVE/i686-removal/koji-only-leaf-i686_20...
> > >
> > > If my method and understanding are both correct, we could add
> > > 'ExcludeArch: %{ix86}' to each of these 3,400 packages with zero
> > > impact on the rest of the packages and save some resources.
> > >
> > > What do you think?
> >
> > An i686 build found a 32 bit assumption in my code last week.  This
> > happens from time to time and I think it's still useful.  So even
> > though I don't think any of my packages are relevant on i686, for me
> > it's worth keeping (some of) them alive.
> >
> > Having said that I obviously have no objection if a packger wishes to
> > drop i686 builds from their own package.
>
> Please consider the following:
> even if it'd benefit me to drop the i686 build, as an individual
> packager who doesn't care about i686 testing and is building the i686
> mostly out of intertia, I'm very likely to not do this unless the i686
> build actively breaks or there's another strong reason. As long as the
> i686 builds pass, it's less effort to not do anything, not figure out
> if there are any dependent packages, not look up the ExludeArch
> syntax, etc.

I don't understand why this is a problem.  If at some point in future
the i686 build did break, the packager might take a look and find a 32
bit bug, or they might not bother and add 'ExcludeArch: %{ix86}'.  Or
the i686 build won't break.  Any of the 3 outcomes are fine by me.
> But this also means that as a big group of packagers, we're stuck in a
> local minimum, collectively doing a bunch of builds that we don't
> actually care about. The proposed change would kick us out of the
> local minimum.

Building a few extra packages doesn't really make any difference.  We
still need all of the i686 build infrastructure and machinery until
the day comes when we finally get rid of 32 bit architectures
altogether.

Rich.