On Tue, Jun 24, 2025 at 1:49 PM Stephen Smoogen <ssmoo...@redhat.com> wrote: > On Tue, 24 Jun 2025 at 07:26, Michal Schorm <msch...@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 <ssmoo...@redhat.com> wrote: > > > > On Tue, 24 Jun 2025 at 07:26, Michal Schorm <msch...@redhat.com> wrote: >> >> On Tue, Jun 24, 2025 at 1:08 PM Daniel P. Berrangé <berra...@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é <berra...@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-le...@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-le...@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-le...@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-le...@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
