F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval
== Summary ==
Package maintainers are encouraged to actively stop building their packages for i686, especially if supporting this architecture requires significant investment of time or resources, for no benefit. This will not apply to packages which are still depended on by other i686 packages, or which get used in a "multilib" context (i.e. for running 32-bit applications on x86_64).
== Owner ==
* Name: [[User:Decathorpe| Fabio Valentini]] * Email: decathorpe [AT] gmail [DOT] com
== Detailed Description ==
Fedora does no longer ship any deliverables for i686, not even RPM repositories for i686 are published any longer. The kernel package itself also [[Changes/Stop Building i686 Kernels|dropped support for i686]] in Fedora 31, so there has not been any way to run Fedora on 32-bit x86 systems for years. Only a tiny fraction of all packages that are built on i686 are actually used (i.e. "multilib" support for Wine, Steam, etc. on x86_64).
== Feedback ==
(none yet)
== Benefit to Fedora ==
Stopping to run unnecessary package builds on i686 will free up no small amount of resources. In particular, stopping to build for i686 could potentially free up almost half of the existing x86 builder resources in koji.
Additionally, support for building on 32-bit targets is starting to get dropped by upstream projects, and resource constraints of 32-bit architectures (i.e. per-process and total memory limits) also make building large libraries or applications increasingly difficult. With ARMv7 support having been removed from Fedora 37 already, i686 is the only remaining supported 32-bit architecture.
Encouraging package maintainers to drop i686 support from their packages (if possible), instead of requiring them to work around those resource constraints or missing upstream support, will significantly lower the maintenance burden, especially for some problematic packages.
== Scope ==
* Proposal owners:
Proposal owners will provide convenience scripts for checking whether a given package is a leaf package on i686, and will help with identifying potential candidate packages.
* Other developers:
Package maintainers who are affected by 32-bit architecture / i686 specific problems are encouraged to investigate dropping support for i686 entirely, instead of having to invest time to fix or work around those issues, for very little benefit to Fedora. This can be done incrementally, as dropping support for i686 from some packages will in turn make other packages leaves on i686.
* Release engineering: N/A
There are already no deliverables for i686, so there should be no impact on Release engineering.
* Policies and guidelines:
Packages that drop support for i686 will no longer need to file a tracking bug and block the [https://bugzilla.redhat.com/show_bug.cgi?id=179258 32-bit x86 ExcludeArch tracker bug].
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
This Change only affects unused / leaf packages that are never installed on user systems (particularly because it has not been possible to install i686-based Fedora for years).
== How To Test ==
The remaining use cases of i686 packages (i.e. "multilib") for popular 32-bit applications should continue to work. For example, installing the Steam client (steam.i686), Wine, or other applications that require 32-bit compatibility libraries should still be possible, and not fail due to broken dependencies.
== User Experience ==
N/A
== Dependencies ==
N/A
== Contingency Plan ==
This Change is supposed to only affect unused components / leaf packages. However, if a package maintainer accidentally stops building a package on i686 despite it still being required for something else, this should be easy to revert - by adding back i686 architecture support to the affected packages, in reverse order. Since removal of support for i686 will happen slowly and incrementally, this should be relatively straightforward.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Fedora packages will incrementally drop support for the i686 architecture (32-bit x86), where this support is no longer required. This is intended to reduce resource consumption of build servers. Additionally, it will make package maintenance for Fedora easier, because a growing number of projects already either no longer provide support for - or fail to build due to resource constraints on - 32-bit architectures.
Once upon a time, Ben Cotton bcotton@redhat.com said:
== Summary ==
Package maintainers are encouraged to actively stop building their packages for i686, especially if supporting this architecture requires significant investment of time or resources, for no benefit. This will not apply to packages which are still depended on by other i686 packages, or which get used in a "multilib" context (i.e. for running 32-bit applications on x86_64).
It's unclear what this actually means for packagers. Should ExcludeArch: lines be added to spec files?
On Mon, Mar 7, 2022 at 7:22 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Ben Cotton bcotton@redhat.com said:
== Summary ==
Package maintainers are encouraged to actively stop building their packages for i686, especially if supporting this architecture requires significant investment of time or resources, for no benefit. This will not apply to packages which are still depended on by other i686 packages, or which get used in a "multilib" context (i.e. for running 32-bit applications on x86_64).
It's unclear what this actually means for packagers. Should ExcludeArch: lines be added to spec files?
Ah, yes, thanks for catching that. This was indeed my intention: Packagers add "ExcludeArch: %{ix86}" to the package in question, if it is safe to do so (unused / leaf packages only). I forgot to add that detail to the proposal, will add it now.
As far as I can tell, any approach more sophisticated than that (like automatically determining the i686 packages we *need*) would require significantly more work, and probably be more error-prone, introduce more friction, and make it harder to revert errors.
Fabio
Once upon a time, Fabio Valentini decathorpe@gmail.com said:
As far as I can tell, any approach more sophisticated than that (like automatically determining the i686 packages we *need*) would require significantly more work, and probably be more error-prone, introduce more friction, and make it harder to revert errors.
Hmm, seems like it shouldn't be that hard... make a list of the buildroot packages plus the packages included in multilib, and then follow the build dependency trees.
On 07. 03. 22 19:30, Fabio Valentini wrote:
On Mon, Mar 7, 2022 at 7:22 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Ben Cotton bcotton@redhat.com said:
== Summary ==
Package maintainers are encouraged to actively stop building their packages for i686, especially if supporting this architecture requires significant investment of time or resources, for no benefit. This will not apply to packages which are still depended on by other i686 packages, or which get used in a "multilib" context (i.e. for running 32-bit applications on x86_64).
It's unclear what this actually means for packagers. Should ExcludeArch: lines be added to spec files?
Ah, yes, thanks for catching that. This was indeed my intention: Packagers add "ExcludeArch: %{ix86}" to the package in question, if it is safe to do so (unused / leaf packages only). I forgot to add that detail to the proposal, will add it now.
As far as I can tell, any approach more sophisticated than that (like automatically determining the i686 packages we *need*) would require significantly more work, and probably be more error-prone, introduce more friction, and make it harder to revert errors.
This begs several questions that would probably need to be clarified e.g. in the packaging guidelines. For example:
------
I am adding a brand new package to multiple Fedora releases. The package is not noarch. It successfully builds on i686. What am I supposed to do?
a) build it on i686, until it fails there b) excludearch %ix86 right away not to create a dead dep tree c) excludearch %ix86 on F37+ only, as this is a F37 change
-------
I am updating a package that no longer builds on i686. How do I know if I can exclude it safely? What checks do I run? Am I allowed to push this update to stable Fedora releases?
-------
My package is noarch but has multiple arched dependencies. How do I properly make Koji not attempt to build it on i686?
On Mon, Mar 7, 2022 at 8:15 PM Miro Hrončok mhroncok@redhat.com wrote:
Thanks for your feedback, I'll respond inline.
This begs several questions that would probably need to be clarified e.g. in the packaging guidelines. For example:
I am adding a brand new package to multiple Fedora releases. The package is not noarch. It successfully builds on i686. What am I supposed to do?
a) build it on i686, until it fails there b) excludearch %ix86 right away not to create a dead dep tree c) excludearch %ix86 on F37+ only, as this is a F37 change
I think new packages could probably exclude i686 on all branches, since with new packages, assuming the i686 packages are unused is always true. :)
I am updating a package that no longer builds on i686. How do I know if I can exclude it safely? What checks do I run? Am I allowed to push this update to stable Fedora releases?
If .spec files are maintained in a "use conditionals and merge everywhere" fashion, then the "ExcludeArch: i686" statement would need to be wrapped in a "%if %fedora >= 37" conditional. So no, in general the change for excluding i686 must not be pushed to stable branches.
My package is noarch but has multiple arched dependencies. How do I properly make Koji not attempt to build it on i686?
I think this case is already covered in the Packaging Guidelines for "noarch packages with unported dependencies": https://docs.fedoraproject.org/en-US/packaging-guidelines/#_noarch_with_unpo...
Fabio
On Mon, Mar 7, 2022 at 2:15 PM Miro Hrončok mhroncok@redhat.com wrote:
On 07. 03. 22 19:30, Fabio Valentini wrote:
On Mon, Mar 7, 2022 at 7:22 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Ben Cotton bcotton@redhat.com said:
== Summary ==
Package maintainers are encouraged to actively stop building their packages for i686, especially if supporting this architecture requires significant investment of time or resources, for no benefit. This will not apply to packages which are still depended on by other i686 packages, or which get used in a "multilib" context (i.e. for running 32-bit applications on x86_64).
It's unclear what this actually means for packagers. Should ExcludeArch: lines be added to spec files?
Ah, yes, thanks for catching that. This was indeed my intention: Packagers add "ExcludeArch: %{ix86}" to the package in question, if it is safe to do so (unused / leaf packages only). I forgot to add that detail to the proposal, will add it now.
As far as I can tell, any approach more sophisticated than that (like automatically determining the i686 packages we *need*) would require significantly more work, and probably be more error-prone, introduce more friction, and make it harder to revert errors.
This begs several questions that would probably need to be clarified e.g. in the packaging guidelines. For example:
I am adding a brand new package to multiple Fedora releases. The package is not noarch. It successfully builds on i686. What am I supposed to do?
a) build it on i686, until it fails there b) excludearch %ix86 right away not to create a dead dep tree c) excludearch %ix86 on F37+ only, as this is a F37 change
I am updating a package that no longer builds on i686. How do I know if I can exclude it safely? What checks do I run? Am I allowed to push this update to stable Fedora releases?
My package is noarch but has multiple arched dependencies. How do I properly make Koji not attempt to build it on i686?
A simpler solution would be to just default-off i686 and check-in some marker file that indicates the package needs to be built for multilib. This is how openSUSE does it today with the baselibs.conf file: https://code.opensuse.org/package/fdk-aac-free/blob/master/f/baselibs.conf
On 3/7/22 2:03 PM, Neal Gompa wrote:
A simpler solution would be to just default-off i686 and check-in some marker file that indicates the package needs to be built for multilib. This is how openSUSE does it today with the baselibs.conf file: https://code.opensuse.org/package/fdk-aac-free/blob/master/f/baselibs.conf
If Fedora wants to adopt "default i686 off" I am OK with that. I will gladly add an "IncludeArch" or whatever macro to wine, mingw-wine-gecko, wine-mono, wine-dxvk, and vkd3d to keep building Wine on Fedora. Yes, it is more than just the 'wine' package that is affected by this.
P.S. (this is directed at the mailing list): I have built wine for years. I've submitted wine patches. I engage with upstream. Please engage *me* when it comes to changes affecting wine. I'll be happy to answer questions and work with any changes required.
On Mon, Mar 07, 2022 at 03:54:25PM -0600, Michael Cronenworth wrote:
On 3/7/22 2:03 PM, Neal Gompa wrote:
A simpler solution would be to just default-off i686 and check-in some marker file that indicates the package needs to be built for multilib. This is how openSUSE does it today with the baselibs.conf file: https://code.opensuse.org/package/fdk-aac-free/blob/master/f/baselibs.conf
If Fedora wants to adopt "default i686 off" I am OK with that. I will gladly add an "IncludeArch" or whatever macro to wine, mingw-wine-gecko, wine-mono, wine-dxvk, and vkd3d to keep building Wine on Fedora. Yes, it is more than just the 'wine' package that is affected by this.
P.S. (this is directed at the mailing list): I have built wine for years. I've submitted wine patches. I engage with upstream. Please engage *me* when it comes to changes affecting wine. I'll be happy to answer questions and work with any changes required.
Perhaps you could share with the list how used/important wine.i686 is these days? Are most folks still using it? Slowly switching to wine.x86_64?
kevin
On 3/8/22 4:08 PM, Kevin Fenzi wrote:
Perhaps you could share with the list how used/important wine.i686 is these days? Are most folks still using it? Slowly switching to wine.x86_64?
Yes, wine.i686 is still important in the year 2022.
While I don't have a comprehensive list of all use cases stashed somewhere one area I can think of is the fact that Windows application installers may be 32-bit yet carry 64-bit binaries. Examples: 7Zip, Firefox, VirtualBox - Download the .exe files and run "file" on them.
There could also be a game or two that is still 32-bit only. I believe most are transitioning to 64-bit, but I remember a few times with Blizzard games (Starcraft 2, Diablo 3) where the 64-bit binary doesn't work under Wine and the 32-bit version works. I haven't checked lately, but the Windows Steam client may also be 32-bit only. The Linux client is 32-bit.
On Tue, Mar 08, 2022 at 04:28:58PM -0600, Michael Cronenworth wrote:
On 3/8/22 4:08 PM, Kevin Fenzi wrote:
Perhaps you could share with the list how used/important wine.i686 is these days? Are most folks still using it? Slowly switching to wine.x86_64?
Yes, wine.i686 is still important in the year 2022.
While I don't have a comprehensive list of all use cases stashed somewhere one area I can think of is the fact that Windows application installers may be 32-bit yet carry 64-bit binaries. Examples: 7Zip, Firefox, VirtualBox - Download the .exe files and run "file" on them.
There could also be a game or two that is still 32-bit only. I believe most are transitioning to 64-bit, but I remember a few times with Blizzard games (Starcraft 2, Diablo 3) where the 64-bit binary doesn't work under Wine and the 32-bit version works. I haven't checked lately, but the Windows Steam client may also be 32-bit only. The Linux client is 32-bit.
ok. So, this does indeed seem like a blocker to completely dropping i686 now.
But then perhaps we could (as suggested elsewhere in the list) figure out all the transitive things that are needed to support building wine.i686 and we could then know we could drop everything else?
But perhaps indeed the orig proposal is best for now (ie, it's ok to drop your leaf package from building on i686).
kevin
On Tue, Mar 8, 2022 at 3:09 PM Kevin Fenzi kevin@scrye.com wrote:
Perhaps you could share with the list how used/important wine.i686 is these days? Are most folks still using it? Slowly switching to wine.x86_64?
I use 32-bit wine at work a *lot*, due to 3rd parties who still, in 2022, ship their functionality in 32-bit form.
On Tuesday, 08 March 2022 at 23:08, Kevin Fenzi wrote:
On Mon, Mar 07, 2022 at 03:54:25PM -0600, Michael Cronenworth wrote:
On 3/7/22 2:03 PM, Neal Gompa wrote:
A simpler solution would be to just default-off i686 and check-in some marker file that indicates the package needs to be built for multilib. This is how openSUSE does it today with the baselibs.conf file: https://code.opensuse.org/package/fdk-aac-free/blob/master/f/baselibs.conf
If Fedora wants to adopt "default i686 off" I am OK with that. I will gladly add an "IncludeArch" or whatever macro to wine, mingw-wine-gecko, wine-mono, wine-dxvk, and vkd3d to keep building Wine on Fedora. Yes, it is more than just the 'wine' package that is affected by this.
P.S. (this is directed at the mailing list): I have built wine for years. I've submitted wine patches. I engage with upstream. Please engage *me* when it comes to changes affecting wine. I'll be happy to answer questions and work with any changes required.
Perhaps you could share with the list how used/important wine.i686 is these days? Are most folks still using it? Slowly switching to wine.x86_64?
My kid is using wine.i686 to play a certain MMORPG Windows game. I'd hate having to install Windows (even if dual-boot) on their PC just because Fedora dropped 32-bit x86. I'm not sure if I even have a Windows license laying around so that'd mean additional cost for me, too.
Regards, Dominik
On 07. 03. 22 20:14, Miro Hrončok wrote:
On 07. 03. 22 19:30, Fabio Valentini wrote:
On Mon, Mar 7, 2022 at 7:22 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Ben Cotton bcotton@redhat.com said:
== Summary ==
Package maintainers are encouraged to actively stop building their packages for i686, especially if supporting this architecture requires significant investment of time or resources, for no benefit. This will not apply to packages which are still depended on by other i686 packages, or which get used in a "multilib" context (i.e. for running 32-bit applications on x86_64).
It's unclear what this actually means for packagers. Should ExcludeArch: lines be added to spec files?
Ah, yes, thanks for catching that. This was indeed my intention: Packagers add "ExcludeArch: %{ix86}" to the package in question, if it is safe to do so (unused / leaf packages only). I forgot to add that detail to the proposal, will add it now.
As far as I can tell, any approach more sophisticated than that (like automatically determining the i686 packages we *need*) would require significantly more work, and probably be more error-prone, introduce more friction, and make it harder to revert errors.
This begs several questions that would probably need to be clarified e.g. in the packaging guidelines. For example:
I am adding a brand new package to multiple Fedora releases. The package is not noarch. It successfully builds on i686. What am I supposed to do?
a) build it on i686, until it fails there b) excludearch %ix86 right away not to create a dead dep tree c) excludearch %ix86 on F37+ only, as this is a F37 change
I am updating a package that no longer builds on i686. How do I know if I can exclude it safely? What checks do I run? Am I allowed to push this update to stable Fedora releases?
My package is noarch but has multiple arched dependencies. How do I properly make Koji not attempt to build it on i686?
Extra question:
Do I need to add Obsoletes of the i686 package(s) to the x86_64 one(s)?
a) always b) only when XYZ c) never
V Mon, Mar 07, 2022 at 07:30:44PM +0100, Fabio Valentini napsal(a):
On Mon, Mar 7, 2022 at 7:22 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Ben Cotton bcotton@redhat.com said:
== Summary ==
Package maintainers are encouraged to actively stop building their packages for i686, especially if supporting this architecture requires significant investment of time or resources, for no benefit. This will not apply to packages which are still depended on by other i686 packages, or which get used in a "multilib" context (i.e. for running 32-bit applications on x86_64).
It's unclear what this actually means for packagers. Should ExcludeArch: lines be added to spec files?
Ah, yes, thanks for catching that. This was indeed my intention: Packagers add "ExcludeArch: %{ix86}" to the package in question, if it is safe to do so (unused / leaf packages only). I forgot to add that detail to the proposal, will add it now.
Do you know that Packaging Guidelines require for each of this exclusion creating a tracking bug for the affected package in Bugzilla https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_build_failures?
We should amend the guidelines not to mandate opening the bugs for this i686 retirement.
-- Petr
On Tue, Mar 8, 2022 at 9:09 AM Petr Pisar ppisar@redhat.com wrote:
(...)
Do you know that Packaging Guidelines require for each of this exclusion creating a tracking bug for the affected package in Bugzilla https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_build_failures?
We should amend the guidelines not to mandate opening the bugs for this i686 retirement.
Oh, yes, I know about this. Which is why it's explicitly mentioned in the Change proposal, under Scope / Policies and guidelines ...
Fabio
Il 07/03/22 19:30, Fabio Valentini ha scritto:
On Mon, Mar 7, 2022 at 7:22 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Ben Cotton bcotton@redhat.com said:
== Summary ==
Package maintainers are encouraged to actively stop building their packages for i686, especially if supporting this architecture requires significant investment of time or resources, for no benefit. This will not apply to packages which are still depended on by other i686 packages, or which get used in a "multilib" context (i.e. for running 32-bit applications on x86_64).
It's unclear what this actually means for packagers. Should ExcludeArch: lines be added to spec files?
Ah, yes, thanks for catching that. This was indeed my intention: Packagers add "ExcludeArch: %{ix86}" to the package in question, if it is safe to do so (unused / leaf packages only). I forgot to add that detail to the proposal, will add it now.
As far as I can tell, any approach more sophisticated than that (like automatically determining the i686 packages we *need*) would require significantly more work, and probably be more error-prone, introduce more friction, and make it harder to revert errors.
So, are you going to identify all unused / leaf packages and open a bug for each asking the maintainer to add the ExcludeArch? Or will the proposal automatically add the ExcludeArch to all identified packages?
I think that simply adding a note to the packaging guidelines will result in no action for the 99% of packages/packagers.
Mattia
So, I'll go ahead and be a bad guy here:
Perhaps it's time to just retire i686 completely?
Steam is available as a flatpak, and old software thats 32bit only and can't be rebuilt could just be run from a f36 container?
This would save us:
* all the builder resources * all the multilib calculation time/space in composes
If we don't want to retire it now, when will we?
kevin
On Mon, Mar 7, 2022 at 8:25 PM Kevin Fenzi kevin@scrye.com wrote:
So, I'll go ahead and be a bad guy here:
Perhaps it's time to just retire i686 completely?
Steam is available as a flatpak, and old software thats 32bit only and can't be rebuilt could just be run from a f36 container?
This would save us:
- all the builder resources
- all the multilib calculation time/space in composes
If we don't want to retire it now, when will we?
I have considered this option, but I don't think we can do that yet.
For example, as far as I know, you need the 32-bit host libraries for running 32-bit Windows applications in Wine. Dropping that would make our Wine packages almost useless, since a large fraction of Windows software still isn't 64-bit.
But I could be wrong. And if we indeed don't need wine.i686 to run 32-bit Windows apps, retiring i686 entirely would be an option, I agree. (I myself am using the Steam flatpak you mentioned. It works well, and I don't need 32-bit libs on my host system at all, which is nice.)
Fabio
On Mon, 2022-03-07 at 20:32 +0100, Fabio Valentini wrote:
On Mon, Mar 7, 2022 at 8:25 PM Kevin Fenzi kevin@scrye.com wrote:
So, I'll go ahead and be a bad guy here:
Perhaps it's time to just retire i686 completely?
Steam is available as a flatpak, and old software thats 32bit only and can't be rebuilt could just be run from a f36 container?
This would save us:
- all the builder resources
- all the multilib calculation time/space in composes
If we don't want to retire it now, when will we?
I have considered this option, but I don't think we can do that yet.
For example, as far as I know, you need the 32-bit host libraries for running 32-bit Windows applications in Wine. Dropping that would make our Wine packages almost useless, since a large fraction of Windows software still isn't 64-bit.
But I could be wrong. And if we indeed don't need wine.i686 to run 32-bit Windows apps, retiring i686 entirely would be an option, I agree. (I myself am using the Steam flatpak you mentioned. It works well, and I don't need 32-bit libs on my host system at all, which is nice.)
Wouldn't wine problem be solved by providing the 32bit version as a flatpak if still needed for some corner cases?
Simo.
On Mon, Mar 07, 2022 at 03:01:32PM -0500, Simo Sorce wrote:
On Mon, 2022-03-07 at 20:32 +0100, Fabio Valentini wrote:
On Mon, Mar 7, 2022 at 8:25 PM Kevin Fenzi kevin@scrye.com wrote:
So, I'll go ahead and be a bad guy here:
Perhaps it's time to just retire i686 completely?
Steam is available as a flatpak, and old software thats 32bit only and can't be rebuilt could just be run from a f36 container?
This would save us:
- all the builder resources
- all the multilib calculation time/space in composes
If we don't want to retire it now, when will we?
I have considered this option, but I don't think we can do that yet.
For example, as far as I know, you need the 32-bit host libraries for running 32-bit Windows applications in Wine. Dropping that would make our Wine packages almost useless, since a large fraction of Windows software still isn't 64-bit.
But I could be wrong. And if we indeed don't need wine.i686 to run 32-bit Windows apps, retiring i686 entirely would be an option, I agree. (I myself am using the Steam flatpak you mentioned. It works well, and I don't need 32-bit libs on my host system at all, which is nice.)
Wouldn't wine problem be solved by providing the 32bit version as a flatpak if still needed for some corner cases?
I'd really prefer that we don't go down this static-linked blob route. There's a reason I'm using a proper distro.
Rich.
Fabio Valentini decathorpe@gmail.com writes:
For example, as far as I know, you need the 32-bit host libraries for running 32-bit Windows applications in Wine. Dropping that would make our Wine packages almost useless, since a large fraction of Windows software still isn't 64-bit.
Would it be possible to have package foo's x86_64 build produce a foo.i686.rpm, or even just a foo-32.x86_64.rpm for this? Wine is an important use case, but keeping the whole arch machinery around for it seems like overkill - just having the packages that are relevant for it build 32-bit variants as a special case seems a lot cleaner.
Be well, --Robbie
On Mon, Mar 7, 2022 at 3:05 PM Robbie Harwood rharwood@redhat.com wrote:
Fabio Valentini decathorpe@gmail.com writes:
For example, as far as I know, you need the 32-bit host libraries for running 32-bit Windows applications in Wine. Dropping that would make our Wine packages almost useless, since a large fraction of Windows software still isn't 64-bit.
Would it be possible to have package foo's x86_64 build produce a foo.i686.rpm, or even just a foo-32.x86_64.rpm for this? Wine is an important use case, but keeping the whole arch machinery around for it seems like overkill - just having the packages that are relevant for it build 32-bit variants as a special case seems a lot cleaner.
Koji normally filters out foreign arches from buildroot repos. There are ways around it, but none are usable in Fedora Koji.
Neal Gompa ngompa13@gmail.com writes:
On Mon, Mar 7, 2022 at 3:05 PM Robbie Harwood rharwood@redhat.com wrote:
Fabio Valentini decathorpe@gmail.com writes:
For example, as far as I know, you need the 32-bit host libraries for running 32-bit Windows applications in Wine. Dropping that would make our Wine packages almost useless, since a large fraction of Windows software still isn't 64-bit.
Would it be possible to have package foo's x86_64 build produce a foo.i686.rpm, or even just a foo-32.x86_64.rpm for this? Wine is an important use case, but keeping the whole arch machinery around for it seems like overkill - just having the packages that are relevant for it build 32-bit variants as a special case seems a lot cleaner.
Koji normally filters out foreign arches from buildroot repos. There are ways around it, but none are usable in Fedora Koji.
Good to know. Guess it'd have to be things like foo-32.x86_64.rpm then.
Be well, --Robbie
On Mon, Mar 07, 2022 at 15:04:21 -0500, Robbie Harwood rharwood@redhat.com wrote:
Fabio Valentini decathorpe@gmail.com writes:
For example, as far as I know, you need the 32-bit host libraries for running 32-bit Windows applications in Wine. Dropping that would make our Wine packages almost useless, since a large fraction of Windows software still isn't 64-bit.
Would it be possible to have package foo's x86_64 build produce a foo.i686.rpm, or even just a foo-32.x86_64.rpm for this? Wine is an important use case, but keeping the whole arch machinery around for it seems like overkill - just having the packages that are relevant for it build 32-bit variants as a special case seems a lot cleaner.
If cross building is used, that might cut down the buildrequires issue. You might eventually be able to just have this for packages required by wine and steam for i686.
On Mon, Mar 07, 2022 at 08:32:13PM +0100, Fabio Valentini wrote:
On Mon, Mar 7, 2022 at 8:25 PM Kevin Fenzi kevin@scrye.com wrote:
So, I'll go ahead and be a bad guy here:
Perhaps it's time to just retire i686 completely?
Steam is available as a flatpak, and old software thats 32bit only and can't be rebuilt could just be run from a f36 container?
This would save us:
- all the builder resources
- all the multilib calculation time/space in composes
If we don't want to retire it now, when will we?
I have considered this option, but I don't think we can do that yet.
For example, as far as I know, you need the 32-bit host libraries for running 32-bit Windows applications in Wine. Dropping that would make our Wine packages almost useless, since a large fraction of Windows software still isn't 64-bit.
How many examples of things like Wine & Steam do we actually have ? I feel it must be a pretty small list of things which are important to a large number of users and yet need 32-bit.
If we only consider Wine & Steam, we can make a clear list of exactly what small set of 32-bit libs are needed, we can declare everything obsolete. We could start by simply excluding all those unneeded RPM from the compose, and then let maintainers disable it in their RPM builds without fear of causing deps problem.
Regards, Daniel
On Tue, Mar 8, 2022 at 9:11 AM Daniel P. Berrangé berrange@redhat.com wrote:
(...)
How many examples of things like Wine & Steam do we actually have ? I feel it must be a pretty small list of things which are important to a large number of users and yet need 32-bit.
If we only consider Wine & Steam, we can make a clear list of exactly what small set of 32-bit libs are needed, we can declare everything obsolete. We could start by simply excluding all those unneeded RPM from the compose, and then let maintainers disable it in their RPM builds without fear of causing deps problem.
I have considered an approach like this. But as always, it's just not that simple.
One of the most problematic things are transitive BuildRequires: Even if you know you need to keep libfoo.i686 and libbar.i686, how do you determine the transitive dependencies that are needed to keep those packages around? And by that, I don't only mean Requires, but also transitive BuildRequires, i.e. if libfoo BuildRequires foolangc, which BuildRequires some other stuff, etc, all of which still needs to be there, or at some point, libfoo.i686 will either fail to build or fail to install.
I have thought about this issue for months before submitting this Change proposal, and it's the best I think we can do without breaking tons of stuff or requiring massive amounts of work from the Change owner (me). At this point, I do think that a safe and officially encouraged opt-out mechanism for individual package maintainers is the only way we can do this *safely* at all.
Of course, dropping i686 entirely will come eventually, but I don't think we can do that just yet. Too much 32-bit x86 software is still around.
Fabio
On Tue, Mar 08, 2022 at 09:59:07AM +0100, Fabio Valentini wrote:
On Tue, Mar 8, 2022 at 9:11 AM Daniel P. Berrangé berrange@redhat.com wrote:
(...)
How many examples of things like Wine & Steam do we actually have ? I feel it must be a pretty small list of things which are important to a large number of users and yet need 32-bit.
If we only consider Wine & Steam, we can make a clear list of exactly what small set of 32-bit libs are needed, we can declare everything obsolete. We could start by simply excluding all those unneeded RPM from the compose, and then let maintainers disable it in their RPM builds without fear of causing deps problem.
I have considered an approach like this. But as always, it's just not that simple.
One of the most problematic things are transitive BuildRequires: Even if you know you need to keep libfoo.i686 and libbar.i686, how do you determine the transitive dependencies that are needed to keep those packages around? And by that, I don't only mean Requires, but also transitive BuildRequires, i.e. if libfoo BuildRequires foolangc, which BuildRequires some other stuff, etc, all of which still needs to be there, or at some point, libfoo.i686 will either fail to build or fail to install.
Isn't that just a standard RPM dep solving problem, at least for stuff inside Fedora repos or well known 3rd party add-on repos ?
Take the minimal build root and run 'dnf install wine' and watch what is installed to get transitive runtime deps. Similarly use 'dnf builddep wine' to get transitive build deps. We can see the latter from koji logs
https://kojipkgs.fedoraproject.org/packages/wine/7.2/1.fc37/data/logs/i686/r...
It is a surprisingly large set - 522 packages as build deps, but none the less this is automated info, instead of having package maintainers try to figure out if their package is actually still needed or not.
With regards, Daniel
* Daniel P. Berrangé:
Isn't that just a standard RPM dep solving problem, at least for stuff inside Fedora repos or well known 3rd party add-on repos ?
The dependencies stored in the source RPM headers are architecture-specific. We'd have to rebuild source RPMs on i686 to get the correct data, and then it's just dependency solving.
Thanks, Florian
On Tue, Mar 8, 2022 at 10:14 AM Daniel P. Berrangé berrange@redhat.com wrote:
(...)
Isn't that just a standard RPM dep solving problem, at least for stuff inside Fedora repos or well known 3rd party add-on repos ?
It is not. There's no way to query recursive BuildRequires from repository metadata in one step (basicaly because the dependency graph is bipartite). You can only do that recursively manually.
Take the minimal build root and run 'dnf install wine' and watch what is installed to get transitive runtime deps. Similarly use 'dnf builddep wine' to get transitive build deps. We can see the latter from koji logs
No. That's not "transitive build deps". Those are *direct* build dependencies only, and does not in turn include the BuildRequires for building those build dependencies. But those transitive BuildRequires will still need to stay around to build wine (in this example), because if they're removed, one of wine's build deps wil fail to build, and will be removed.
Fabio
On Tue, Mar 08, 2022 at 10:30:33AM +0100, Fabio Valentini wrote:
On Tue, Mar 8, 2022 at 10:14 AM Daniel P. Berrangé berrange@redhat.com wrote:
(...)
Isn't that just a standard RPM dep solving problem, at least for stuff inside Fedora repos or well known 3rd party add-on repos ?
It is not. There's no way to query recursive BuildRequires from repository metadata in one step (basicaly because the dependency graph is bipartite). You can only do that recursively manually.
Take the minimal build root and run 'dnf install wine' and watch what is installed to get transitive runtime deps. Similarly use 'dnf builddep wine' to get transitive build deps. We can see the latter from koji logs
No. That's not "transitive build deps". Those are *direct* build dependencies only, and does not in turn include the BuildRequires for building those build dependencies. But those transitive BuildRequires will still need to stay around to build wine (in this example), because if they're removed, one of wine's build deps wil fail to build, and will be removed.
Oh yes, I simplified the build deps problem too much. Still feels like a task that is ripe for machine automation.
As written the proposal is effectively asking every maintainer to dep solve the build deps manually in their head to see if their pacakge is still needed by something. IMHO that is inevitably going to lead to mistakes and puts unnecessary burden on individual maintainers.
With regards, Daniel
On Tue, Mar 8, 2022 at 10:40 AM Daniel P. Berrangé berrange@redhat.com wrote:
(...)
Oh yes, I simplified the build deps problem too much. Still feels like a task that is ripe for machine automation.
Yes. I will provide a script so package maintainers can do:
$ can-i-add-excludearch-i686-to foo
Which will then either say - "YES, foo is a leaf package", or - "NO, foo-libs is still Required by X, Y, Z; foo-utils is still BuildRequired by W".
I noted this in the change proposal, under Scope / Proposal owners. I have the pieces ready on my local machine, I just need to put them together and publish the script somewhere.
As written the proposal is effectively asking every maintainer to dep solve the build deps manually in their head to see if their pacakge is still needed by something. IMHO that is inevitably going to lead to mistakes and puts unnecessary burden on individual maintainers.
Where in the proposal did you read that this will be mandatory? Or will need to be done in everyone's head? I explicitly mentioned a scripted approach, as noted above.
The whole point of the proposal is to create *less* work for package maintainers, so that they can stop building unused i686 support for packages *if it is causing them problems or they want to*, without creating useless bureaucracy or maintenance burden for them.
If somebody doesn't care about i686 and their packages build fine on i686, they will not notice this change at all, unless they maintain a leaf package that would be impacted by a potential removal of one of its dependencies. But in that case, this can be treated like any other breaking change in a package, with maintainers coordinating.
Fabio
On Tue, 8 Mar 2022 09:40:16 +0000 Daniel P. Berrangé berrange@redhat.com wrote:
On Tue, Mar 08, 2022 at 10:30:33AM +0100, Fabio Valentini wrote:
On Tue, Mar 8, 2022 at 10:14 AM Daniel P. Berrangé berrange@redhat.com wrote:
(...)
Isn't that just a standard RPM dep solving problem, at least for stuff inside Fedora repos or well known 3rd party add-on repos ?
It is not. There's no way to query recursive BuildRequires from repository metadata in one step (basicaly because the dependency graph is bipartite). You can only do that recursively manually.
Take the minimal build root and run 'dnf install wine' and watch what is installed to get transitive runtime deps. Similarly use 'dnf builddep wine' to get transitive build deps. We can see the latter from koji logs
No. That's not "transitive build deps". Those are *direct* build dependencies only, and does not in turn include the BuildRequires for building those build dependencies. But those transitive BuildRequires will still need to stay around to build wine (in this example), because if they're removed, one of wine's build deps wil fail to build, and will be removed.
Oh yes, I simplified the build deps problem too much. Still feels like a task that is ripe for machine automation.
I have to check my scripts' collection, but I think I had something to "compute" the transitive deps ...
Dan
As written the proposal is effectively asking every maintainer to dep solve the build deps manually in their head to see if their pacakge is still needed by something. IMHO that is inevitably going to lead to mistakes and puts unnecessary burden on individual maintainers.
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 on the list, report it: https://pagure.io/fedora-infrastructure
On Tue, 8 Mar 2022 11:17:20 +0100 Dan Horák dan@danny.cz wrote:
On Tue, 8 Mar 2022 09:40:16 +0000 Daniel P. Berrangé berrange@redhat.com wrote:
On Tue, Mar 08, 2022 at 10:30:33AM +0100, Fabio Valentini wrote:
On Tue, Mar 8, 2022 at 10:14 AM Daniel P. Berrangé berrange@redhat.com wrote:
(...)
Isn't that just a standard RPM dep solving problem, at least for stuff inside Fedora repos or well known 3rd party add-on repos ?
It is not. There's no way to query recursive BuildRequires from repository metadata in one step (basicaly because the dependency graph is bipartite). You can only do that recursively manually.
Take the minimal build root and run 'dnf install wine' and watch what is installed to get transitive runtime deps. Similarly use 'dnf builddep wine' to get transitive build deps. We can see the latter from koji logs
No. That's not "transitive build deps". Those are *direct* build dependencies only, and does not in turn include the BuildRequires for building those build dependencies. But those transitive BuildRequires will still need to stay around to build wine (in this example), because if they're removed, one of wine's build deps wil fail to build, and will be removed.
Oh yes, I simplified the build deps problem too much. Still feels like a task that is ripe for machine automation.
I have to check my scripts' collection, but I think I had something to "compute" the transitive deps ...
and here it is https://fedora.danny.cz/get-complete-buildroot.public
per the values in there it was last used for F-28, so YMMV
Dan
DanAs written the proposal is effectively asking every maintainer to dep solve the build deps manually in their head to see if their pacakge is still needed by something. IMHO that is inevitably going to lead to mistakes and puts unnecessary burden on individual maintainers.
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 on the list, report it: https://pagure.io/fedora-infrastructure
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 on the list, report it: https://pagure.io/fedora-infrastructure
Once upon a time, Fabio Valentini decathorpe@gmail.com said:
One of the most problematic things are transitive BuildRequires: Even if you know you need to keep libfoo.i686 and libbar.i686, how do you determine the transitive dependencies that are needed to keep those packages around? And by that, I don't only mean Requires, but also transitive BuildRequires, i.e. if libfoo BuildRequires foolangc, which BuildRequires some other stuff, etc, all of which still needs to be there, or at some point, libfoo.i686 will either fail to build or fail to install.
All the necessary info is in the source RPM BuildRequires. Yes, you'll need a script to build the list recursively, but... that's not that hard.
I have thought about this issue for months before submitting this Change proposal, and it's the best I think we can do without breaking tons of stuff or requiring massive amounts of work from the Change owner (me). At this point, I do think that a safe and officially encouraged opt-out mechanism for individual package maintainers is the only way we can do this *safely* at all.
There are almost 23,000 source RPMs in rawhide. You are proposing a change that puts virtually all the effort on the maintainers of the majority of those packages, rather than write a script yourself (which should not be "massive amounts of work").
It's easy to propose something when somebody else has to do the work; please instead put some work in yourself (or don't propose the change).
On Tue, Mar 8, 2022 at 2:05 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Fabio Valentini decathorpe@gmail.com said:
One of the most problematic things are transitive BuildRequires: Even if you know you need to keep libfoo.i686 and libbar.i686, how do you determine the transitive dependencies that are needed to keep those packages around? And by that, I don't only mean Requires, but also transitive BuildRequires, i.e. if libfoo BuildRequires foolangc, which BuildRequires some other stuff, etc, all of which still needs to be there, or at some point, libfoo.i686 will either fail to build or fail to install.
All the necessary info is in the source RPM BuildRequires. Yes, you'll need a script to build the list recursively, but... that's not that hard.
It's not that easy either.
For example, if you're not careful to avoid dependency loops, you'll create a program that will never terminate. You'll need to recursively query Requires from those BuildRequired packages, but you also need to map those their respective source packages, and continue with querying BuildRequires recursively.
I've tried to write a script that does that, but it doesn't provide correct results yet. If I manage to get it working, I can share it.
I have thought about this issue for months before submitting this Change proposal, and it's the best I think we can do without breaking tons of stuff or requiring massive amounts of work from the Change owner (me). At this point, I do think that a safe and officially encouraged opt-out mechanism for individual package maintainers is the only way we can do this *safely* at all.
There are almost 23,000 source RPMs in rawhide. You are proposing a change that puts virtually all the effort on the maintainers of the majority of those packages, rather than write a script yourself (which should not be "massive amounts of work").
It's easy to propose something when somebody else has to do the work; please instead put some work in yourself (or don't propose the change).
I would appreciate it if you actually read the proposal instead of making personal attacks like this: The proposal does not create a mandate for package maintainers for dropping i686 from packages at all.
The goal is to make it easier for maintainers if they are already thinking about dropping i686 from their package. I will also provide a list of potential candidate packages, but it will still be up to the maintainers whether they incorporate or ignore this change.
So I don't understand how this "puts virtually all the effort on the maintainers of the majority of those packages", if completely ignoring the Change and/or inaction are both perfectly valid choices.
Fabio
On Tue, 8 Mar 2022 15:46:29 +0100 Fabio Valentini decathorpe@gmail.com wrote:
On Tue, Mar 8, 2022 at 2:05 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Fabio Valentini decathorpe@gmail.com said:
One of the most problematic things are transitive BuildRequires: Even if you know you need to keep libfoo.i686 and libbar.i686, how do you determine the transitive dependencies that are needed to keep those packages around? And by that, I don't only mean Requires, but also transitive BuildRequires, i.e. if libfoo BuildRequires foolangc, which BuildRequires some other stuff, etc, all of which still needs to be there, or at some point, libfoo.i686 will either fail to build or fail to install.
All the necessary info is in the source RPM BuildRequires. Yes, you'll need a script to build the list recursively, but... that's not that hard.
It's not that easy either.
For example, if you're not careful to avoid dependency loops, you'll create a program that will never terminate. You'll need to recursively query Requires from those BuildRequired packages, but you also need to map those their respective source packages, and continue with querying BuildRequires recursively.
I've tried to write a script that does that, but it doesn't provide correct results yet. If I manage to get it working, I can share it.
please see my previous post, I have/had a solution for the transitive build requirements
Dan
I have thought about this issue for months before submitting this Change proposal, and it's the best I think we can do without breaking tons of stuff or requiring massive amounts of work from the Change owner (me). At this point, I do think that a safe and officially encouraged opt-out mechanism for individual package maintainers is the only way we can do this *safely* at all.
There are almost 23,000 source RPMs in rawhide. You are proposing a change that puts virtually all the effort on the maintainers of the majority of those packages, rather than write a script yourself (which should not be "massive amounts of work").
It's easy to propose something when somebody else has to do the work; please instead put some work in yourself (or don't propose the change).
I would appreciate it if you actually read the proposal instead of making personal attacks like this: The proposal does not create a mandate for package maintainers for dropping i686 from packages at all.
The goal is to make it easier for maintainers if they are already thinking about dropping i686 from their package. I will also provide a list of potential candidate packages, but it will still be up to the maintainers whether they incorporate or ignore this change.
So I don't understand how this "puts virtually all the effort on the maintainers of the majority of those packages", if completely ignoring the Change and/or inaction are both perfectly valid choices.
Fabio _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
Small technical concern:
i686 packages depending on each other as follows: A ---> B ---> C ---> D ---> E ---> F ---> G When a maintainer of package "D" decides to stop building the package "D" for i686 ("ExcludeArch: %{ix86}"), how do we ensure the packages "E", "F", "G" will also adopt the "ExcludeArch: %{ix86}" instead of FTBFS (or FTI) on i686 arch ?
The original change proposal is about _leaf_ packages, which I understand as only package "G" in my example. And the maintainer of "D" has to wait on the maintainer of "E" has to wait on the maintainer of "F" has to wait on the maintainer of "G" to stop building it for i686.
As voices appeared proposing to get rid of _all_ i686 but necessary instead (which has +1 from me), I'm unsure whether the goal of the original proposal changed.
I'm just asking to make sure whether that's somehow covered.
--
Michal Schorm Software Engineer Core Services - Databases Team Red Hat
--
On Tue, Mar 8, 2022 at 4:07 PM Dan Horák dan@danny.cz wrote:
On Tue, 8 Mar 2022 15:46:29 +0100 Fabio Valentini decathorpe@gmail.com wrote:
On Tue, Mar 8, 2022 at 2:05 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Fabio Valentini decathorpe@gmail.com said:
One of the most problematic things are transitive BuildRequires: Even if you know you need to keep libfoo.i686 and libbar.i686, how do you determine the transitive dependencies that are needed to keep those packages around? And by that, I don't only mean Requires, but also transitive BuildRequires, i.e. if libfoo BuildRequires foolangc, which BuildRequires some other stuff, etc, all of which still needs to be there, or at some point, libfoo.i686 will either fail to build or fail to install.
All the necessary info is in the source RPM BuildRequires. Yes, you'll need a script to build the list recursively, but... that's not that hard.
It's not that easy either.
For example, if you're not careful to avoid dependency loops, you'll create a program that will never terminate. You'll need to recursively query Requires from those BuildRequired packages, but you also need to map those their respective source packages, and continue with querying BuildRequires recursively.
I've tried to write a script that does that, but it doesn't provide correct results yet. If I manage to get it working, I can share it.
please see my previous post, I have/had a solution for the transitive build requirements
DanI have thought about this issue for months before submitting this Change proposal, and it's the best I think we can do without breaking tons of stuff or requiring massive amounts of work from the Change owner (me). At this point, I do think that a safe and officially encouraged opt-out mechanism for individual package maintainers is the only way we can do this *safely* at all.
There are almost 23,000 source RPMs in rawhide. You are proposing a change that puts virtually all the effort on the maintainers of the majority of those packages, rather than write a script yourself (which should not be "massive amounts of work").
It's easy to propose something when somebody else has to do the work; please instead put some work in yourself (or don't propose the change).
I would appreciate it if you actually read the proposal instead of making personal attacks like this: The proposal does not create a mandate for package maintainers for dropping i686 from packages at all.
The goal is to make it easier for maintainers if they are already thinking about dropping i686 from their package. I will also provide a list of potential candidate packages, but it will still be up to the maintainers whether they incorporate or ignore this change.
So I don't understand how this "puts virtually all the effort on the maintainers of the majority of those packages", if completely ignoring the Change and/or inaction are both perfectly valid choices.
Fabio _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
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 on the list, report it: https://pagure.io/fedora-infrastructure
On Tue, Mar 08, 2022 at 04:56:43PM +0100, Michal Schorm wrote:
Small technical concern:
i686 packages depending on each other as follows: A ---> B ---> C ---> D ---> E ---> F ---> G When a maintainer of package "D" decides to stop building the package "D" for i686 ("ExcludeArch: %{ix86}"), how do we ensure the packages "E", "F", "G" will also adopt the "ExcludeArch: %{ix86}" instead of FTBFS (or FTI) on i686 arch ?
The original change proposal is about _leaf_ packages, which I understand as only package "G" in my example. And the maintainer of "D" has to wait on the maintainer of "E" has to wait on the maintainer of "F" has to wait on the maintainer of "G" to stop building it for i686.
As voices appeared proposing to get rid of _all_ i686 but necessary instead (which has +1 from me), I'm unsure whether the goal of the original proposal changed.
I'm just asking to make sure whether that's somehow covered.
I think this is covered in the original proposal: - initially only G is candidate for exclusion - once G has been excluded, F becomes a candidate - once F has been excluded, E becomes a candidate …
The maintainer of D must take no action until D is a leaf.
Zbyszek
On 07. 03. 22 20:25, Kevin Fenzi wrote:
So, I'll go ahead and be a bad guy here:
Perhaps it's time to just retire i686 completely?
Steam is available as a flatpak, and old software thats 32bit only and can't be rebuilt could just be run from a f36 container?
This would save us:
- all the builder resources
- all the multilib calculation time/space in composes
If we don't want to retire it now, when will we?
Supporting i686 has only brought pain and misery on me and I have never really benefit from it in any way. So I can definitively relate to this, but I suppose we should really cmpile a lit of use cases for multilib before we pull the plug. Is it indeed just Steam (flatpak) and legacy stuff? Don't we also need it e.g. for plain Wine?
On Mon, 2022-03-07 at 11:25 -0800, Kevin Fenzi wrote:
So, I'll go ahead and be a bad guy here:
Perhaps it's time to just retire i686 completely?
Steam is available as a flatpak
Do we know how the flatpak is built and updated? Would Fedora ending i686 support affect *that* work?
On Mon, Mar 7, 2022 at 3:46 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2022-03-07 at 11:25 -0800, Kevin Fenzi wrote:
So, I'll go ahead and be a bad guy here:
Perhaps it's time to just retire i686 completely?
Steam is available as a flatpak
Do we know how the flatpak is built and updated? Would Fedora ending i686 support affect *that* work?
It would certainly affect *our* runtimes. And affect *our* ability to support applications natively, including native Linux games.
On Mon, Mar 07, 2022 at 12:45:36PM -0800, Adam Williamson wrote:
On Mon, 2022-03-07 at 11:25 -0800, Kevin Fenzi wrote:
So, I'll go ahead and be a bad guy here:
Perhaps it's time to just retire i686 completely?
Steam is available as a flatpak
Do we know how the flatpak is built and updated? Would Fedora ending i686 support affect *that* work?
Just FYI, the steam flatpak on flathub.org uses the freedesktop runtime, so it should be unaffected (at least directly) by whatever Fedora does.
kevin
On Tue, Mar 8, 2022 at 4:47 PM Kevin Fenzi kevin@scrye.com wrote:
On Mon, Mar 07, 2022 at 12:45:36PM -0800, Adam Williamson wrote:
On Mon, 2022-03-07 at 11:25 -0800, Kevin Fenzi wrote:
So, I'll go ahead and be a bad guy here:
Perhaps it's time to just retire i686 completely?
Steam is available as a flatpak
Do we know how the flatpak is built and updated? Would Fedora ending i686 support affect *that* work?
Just FYI, the steam flatpak on flathub.org uses the freedesktop runtime, so it should be unaffected (at least directly) by whatever Fedora does.
Native Steam is currently preferred for various reasons, so it would be affected by that. Also, Steam's runtime tooling prefers compatible host libraries when available for performance and compatibility purposes.
On 07/03/2022 18:12, Ben Cotton wrote:
Package maintainers are encouraged to actively stop building their packages for i686, especially if supporting this architecture requires significant investment of time or resources, for no benefit.
+1. Upstreams don't test i686 builds and ignore bugs.
On Mon, Mar 07, 2022 at 12:12:49PM -0500, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval == Scope ==
- Proposal owners:
Proposal owners will provide convenience scripts for checking whether a given package is a leaf package on i686, and will help with identifying potential candidate packages.
- Other developers:
Package maintainers who are affected by 32-bit architecture / i686 specific problems are encouraged to investigate dropping support for i686 entirely, instead of having to invest time to fix or work around those issues, for very little benefit to Fedora. This can be done incrementally, as dropping support for i686 from some packages will in turn make other packages leaves on i686.
What about the following instead: - We start with a filter list that includes glibc, wine, and other packages which we know should be excluded.
- The script is run automatically and identifies a list of leaf packages.
- For packages which are leafs not on the filter list, a pull request is opened to add ExcludeArch: %{ix86}.
- If the pull request is merged, fine. If it is closed w/o merge, also fine. If the maintainer doesn't react in a week, the request is merged automically and the package built.
Either way, the package is added to a filter list to not bother the maintainers again.
I think it should be possible to automatize steps 2–4. This way we'll not need to wait for maintainers to add ExcludeArch manually. Elsewhere in the thread people suggested that this would take forever if manual steps are required, and I fear that this is a valid assesment.
Zbyszek
Once upon a time, Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl said:
What about the following instead:
We start with a filter list that includes glibc, wine, and other packages which we know should be excluded.
The script is run automatically and identifies a list of leaf packages.
For packages which are leafs not on the filter list, a pull request is opened to add ExcludeArch: %{ix86}.
If the pull request is merged, fine. If it is closed w/o merge, also fine. If the maintainer doesn't react in a week, the request is merged automically and the package built.
Either way, the package is added to a filter list to not bother the maintainers again.
I think it should be possible to automatize steps 2–4. This way we'll not need to wait for maintainers to add ExcludeArch manually. Elsewhere in the thread people suggested that this would take forever if manual steps are required, and I fear that this is a valid assesment.
Rather than churn 20,000+ packages (plus add a new requirement for every new package to include an ExcludeArch), why not address this at the build system?
Writing a script to generate a list of the buildroot plus multilib packages, then find all the necessary source packages for those and their build dependencies, should not be that hard. I don't know how difficult it would be to then hook that in as a filter to the i686 build system, hopefully not too difficult?
I don't know how the current list of provided multilib packages is created though. I'd probably start with the above script querying all i686.rpm packages in the x86_64 repo (and working through their source packages, and those packages' build deps), and if the i686.rpm list is slimmed down, the above script would trim the deps automatically.
Then rather than churn almost every package in the distribution, current and future, fix it in one place. That place can then be updated as needed.
On Tue, Mar 8 2022 at 01:55:47 PM -0600, Chris Adams linux@cmadams.net wrote:
Rather than churn 20,000+ packages (plus add a new requirement for every new package to include an ExcludeArch), why not address this at the build system?
This makes sense to me. I don't think we should be changing spec files to implement this.
On Tue, Mar 08, 2022 at 02:11:14PM -0600, Michael Catanzaro wrote:
Rather than churn 20,000+ packages (plus add a new requirement for every new package to include an ExcludeArch), why not address this at the build system?
This makes sense to me. I don't think we should be changing spec files to implement this.
Yeah. I'd like to not be adding _more_ things spec files.
On 08. 03. 22 21:43, Matthew Miller wrote:
On Tue, Mar 08, 2022 at 02:11:14PM -0600, Michael Catanzaro wrote:
Rather than churn 20,000+ packages (plus add a new requirement for every new package to include an ExcludeArch), why not address this at the build system?
This makes sense to me. I don't think we should be changing spec files to implement this.
Yeah. I'd like to not be adding _more_ things spec files.
I think we are all misinterpreting the intention of this change proposal.
We are suggesting better ways to get rid of i686. And the arguments are valid. However, I now think that this change proposal was not proposed to get rid of i686, not even to get rid of most of the i686 packages. Indeed, there are more sophisticated ways to do that -- OTOH volunteers don't seem to exactly pile up.
I think this change proposal has a different goal in mind. A simpler goal. Goal that requires no volunteers:
Give maintainers a blanket approval to exclude i686 if it bothers them in any way and their package is a leaf i686 package. That is it. Will this speed up eventual i686 retirement? Possibly, but not much. But that is not the goal. The goal is to clearly communicate: It is OK to drop this, you don't need to ask for permissions or file bugzillas, just make sure you don't break anything (and here's how you check if you are not breaking anything).
Is that correct, Fabio?
If so, I think it is actually a good thing to do. It won't solve the big elephant in the room, but it has the potential to ease packaging for some.
Once upon a time, Miro Hrončok mhroncok@redhat.com said:
Give maintainers a blanket approval to exclude i686 if it bothers them in any way and their package is a leaf i686 package. That is it. Will this speed up eventual i686 retirement? Possibly, but not much. But that is not the goal. The goal is to clearly communicate: It is OK to drop this, you don't need to ask for permissions or file bugzillas, just make sure you don't break anything (and here's how you check if you are not breaking anything).
I guess I don't find that a particularly compelling proposal then. The first benefit listed is:
Stopping to run unnecessary package builds on i686 will free up no small amount of resources. In particular, stopping to build for i686 could potentially free up almost half of the existing x86 builder resources in koji.
Then lets actually stop unnecessary package builds, by filtering out the source packages that are neither delivered, nor required to build any delivered i686 package. I don't see any real reason to involve individual package maintainers in that, and especially no reason to update spec files for that. The packages are ALREADY not delivered, all that is needed to stop building them too.
On Tue, Mar 8, 2022 at 9:57 PM Miro Hrončok mhroncok@redhat.com wrote:
(snip)
I think we are all misinterpreting the intention of this change proposal.
We are suggesting better ways to get rid of i686. And the arguments are valid. However, I now think that this change proposal was not proposed to get rid of i686, not even to get rid of most of the i686 packages. Indeed, there are more sophisticated ways to do that -- OTOH volunteers don't seem to exactly pile up.
I think this change proposal has a different goal in mind. A simpler goal. Goal that requires no volunteers:
Give maintainers a blanket approval to exclude i686 if it bothers them in any way and their package is a leaf i686 package. That is it. Will this speed up eventual i686 retirement? Possibly, but not much. But that is not the goal. The goal is to clearly communicate: It is OK to drop this, you don't need to ask for permissions or file bugzillas, just make sure you don't break anything (and here's how you check if you are not breaking anything).
Is that correct, Fabio?
If so, I think it is actually a good thing to do. It won't solve the big elephant in the room, but it has the potential to ease packaging for some.
Yes. That's the whole point.
Package maintainers who would benefit from dropping i686 from their packages probably already know that i686 is painful for them. And this Proposal is supposed to make their life easier by saying "fine, drop it, assuming nothing depends on it". Stripping down the entire corpus of Fedora packages to the bare minimum of packages that are needed for multilib was never the goal here. We might reach that state over time, but it's not the goal here.
I thought about how we could implement some automatic filtering (possibly at the koji level, so we wouldn't need to touch tens of thousands of spec files), but I decided it was not worth it, at least not yet. Additionally, if there ever was an error in that automation, it might not even be possible to revert some catastrophic changes without doing an architecture bootstrap for i686, and I *really really* don't want that to become necessary.
I also don't have the time nor the koji / RPM knowledge required to implement automation like this. And given that the response to my proposal of "make package maintainer's jobs easier by giving them more power to do only do the things they want to do" has largely been "you're stupid and don't know what you're talking about", I'm not optimistic that anybody would step up to volunteer. :(
Fabio
Once upon a time, Fabio Valentini decathorpe@gmail.com said:
Package maintainers who would benefit from dropping i686 from their packages probably already know that i686 is painful for them.
So I guess this is the part I don't really understand (and I guess why I don't see this proposal as a "win") - how is i686 painful to package maintainers for non-delivered packages? Maybe I'm just missing something, but what causes issues?
Basically - why would I as a package maintainer care about excluding i686? The effort involved for some packages to make sure they're just a leaf (so it'd be okay to exclude i686) just doesn't really seem worth it, if there's no practical gain for the maintainer.
I apologize that my earlier email was attacking; my usual inclination is not to take small steps when there's really a bigger step that would be better in the big picture, and I didn't communicate that well.
On Wed, Mar 9, 2022 at 4:06 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Fabio Valentini decathorpe@gmail.com said:
Package maintainers who would benefit from dropping i686 from their packages probably already know that i686 is painful for them.
So I guess this is the part I don't really understand (and I guess why I don't see this proposal as a "win") - how is i686 painful to package maintainers for non-delivered packages? Maybe I'm just missing something, but what causes issues?
The problem is that those packages are painful to *build*. We don't ship most of them at all, but they're still *built*.
And given limitations of 32-bit architectures (especially per-process and total memory) and ever-more-complex software, this is starting to hit more and more packages.
For example, I already had to limit functionality or quality of debuginfo of some of my packages because otherwise they wouldn't compile in 32-bit environments *at all*. This is what's *painful* and makes no sense: Having to deal with architecture limitations, but for architectures where we don't even ship the resulting packages.
Fabio
The packaging effort is real; it’s just unevenly distributed across different types of packages, so some packagers might not have noticed it.
Packaging work that, with the demise of 32-bit ARM, can now be ascribed purely to these generally-unused i686 packages includes:
- As Fabio noted, occasionally disabling LTO or reducing debuginfo to keep compilers operating within 32-bit resource limitations.
- Debugging test failures related to 32-bit platforms—on which upstreams typically don’t or can’t test, so these are more and more common.
- Developing, testing, and submitting patches for 32-bit bugs.
- Creating, and seeing in the packager dashboard, mandatory ExcludeArch bugs that basically say “upstream doesn’t care about 32-bit architectures and never will, and the problems are too fundamental to fix downstream.” These are noise, since they will never be fixed.
- Creating even more ExcludeArch bugs for the dependent packages of libraries that don’t support 32-bit platforms.
- Making noarch Python packages arched because a dependency of an “extra” is 64-bit-only, so we need to conditionally produce the corresponding extras metapackage everywhere-but-i686.
- Conditionalizing weak or optional dependencies that don’t support 32-bit—again, forcing some noarch packages to become arched.
Some categories of packages seem to very rarely need this kind of work. In others, like scientific Python, 32-bit and big-endian issues are pervasive and can be the most labor-intensive aspect of many packages. Finding a way to cut out the 32-bit part of that really would make a difference.
On Wed, Mar 9, 2022, at 10:13 AM, Fabio Valentini wrote:
On Wed, Mar 9, 2022 at 4:06 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Fabio Valentini decathorpe@gmail.com said:
Package maintainers who would benefit from dropping i686 from their packages probably already know that i686 is painful for them.
So I guess this is the part I don't really understand (and I guess why I don't see this proposal as a "win") - how is i686 painful to package maintainers for non-delivered packages? Maybe I'm just missing something, but what causes issues?
The problem is that those packages are painful to *build*. We don't ship most of them at all, but they're still *built*.
And given limitations of 32-bit architectures (especially per-process and total memory) and ever-more-complex software, this is starting to hit more and more packages.
For example, I already had to limit functionality or quality of debuginfo of some of my packages because otherwise they wouldn't compile in 32-bit environments *at all*. This is what's *painful* and makes no sense: Having to deal with architecture limitations, but for architectures where we don't even ship the resulting packages.
Fabio _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
On Wed, Mar 9, 2022 at 10:09 AM Ben Beasley code@musicinmybrain.net wrote:
The packaging effort is real; it’s just unevenly distributed across different types of packages, so some packagers might not have noticed it.
Packaging work that, with the demise of 32-bit ARM, can now be ascribed purely to these generally-unused i686 packages includes:
- As Fabio noted, occasionally disabling LTO or reducing debuginfo to keep
compilers operating within 32-bit resource limitations.
- Debugging test failures related to 32-bit platforms—on which upstreams
typically don’t or can’t test, so these are more and more common.
- Developing, testing, and submitting patches for 32-bit bugs.
I'll add some context to these. I'm currently the primary maintainer of three major projects in the VFX stack, OpenImageIO, OpenColorIO, and OpenEXR. Do we really need i686/arm packages for these? No one is using the 32bit versions in industry. That being said, some of these are deps for end user packages that MIGHT be used on i686 or armv7 (Blender?), but if they are, it can't be a good experience.
Another major package is FreeCAD, which is a 3D solid modeling project. I seriously doubt anyone is running this on an ARM device (even 64 bit) until workstation level arm devices are widely available. There could be a few i686 users but not many.
The only package I can recall having 32bit issues with was OpenEXR, but it had some issues on s390 as well.
My plan would be to keep building them for i686 as long as it's "easy" but I like the overall proposal in that I could drop it if it becomes burdensome.
Thanks, Richard
On Wed, Mar 9, 2022 at 6:05 PM Richard Shaw hobbes1069@gmail.com wrote:
(snip)
I'll add some context to these. I'm currently the primary maintainer of three major projects in the VFX stack, OpenImageIO, OpenColorIO, and OpenEXR. Do we really need i686/arm packages for these? No one is using the 32bit versions in industry. That being said, some of these are deps for end user packages that MIGHT be used on i686 or armv7 (Blender?), but if they are, it can't be a good experience.
I wonder how you think those end user packages MIGHT be used on i686 on i686 or armv7? Given that 1) armv7 has been removed from F37+ entirely, and 2) we do not ship any i686 packages to users (except for multilib on x86_64)?
Another major package is FreeCAD, which is a 3D solid modeling project. I seriously doubt anyone is running this on an ARM device (even 64 bit) until workstation level arm devices are widely available. There could be a few i686 users but not many.
Again, how? We haven't even had i686 kernels (let alone installable Fedora images) since Fedora 31.
Fabio
On Wed, Mar 9, 2022 at 11:09 AM Fabio Valentini decathorpe@gmail.com wrote:
On Wed, Mar 9, 2022 at 6:05 PM Richard Shaw hobbes1069@gmail.com wrote:
(snip)
I'll add some context to these. I'm currently the primary maintainer of
three major projects in the VFX stack, OpenImageIO, OpenColorIO, and OpenEXR. Do we really need i686/arm packages for these? No one is using the 32bit versions in industry. That being said, some of these are deps for end user packages that MIGHT be used on i686 or armv7 (Blender?), but if they are, it can't be a good experience.
I wonder how you think those end user packages MIGHT be used on i686 on i686 or armv7? Given that 1) armv7 has been removed from F37+ entirely, and 2) we do not ship any i686 packages to users (except for multilib on x86_64)?
Another major package is FreeCAD, which is a 3D solid modeling project.
I seriously doubt anyone is running this on an ARM device (even 64 bit) until workstation level arm devices are widely available. There could be a few i686 users but not many.
Again, how? We haven't even had i686 kernels (let alone installable Fedora images) since Fedora 31.
Haha... I knew we didn't have installers but completely forgot about the kernel. I thought maybe people could still update if they had an i686 install and was doing upgrades.
So basically, there's zero reason to be building huge packages like FreeCAD for i686, and really 32-bit arm because I can't imagine anyone doing CAD work on that platform
Thanks for the reminder!
Richard
On Wed, Mar 09, 2022 at 09:06:01 -0600, Chris Adams linux@cmadams.net wrote:
So I guess this is the part I don't really understand (and I guess why I don't see this proposal as a "win") - how is i686 painful to package maintainers for non-delivered packages? Maybe I'm just missing something, but what causes issues?
The Fedora 36 beta is likely to slip because firefox was not building successfully on i686, but was on other arches.
On Wed, Mar 09, 2022 at 12:23:41 -0600, Bruno Wolff III bruno@wolff.to wrote:
On Wed, Mar 09, 2022 at 09:06:01 -0600,
The Fedora 36 beta is likely to slip because firefox was not building successfully on i686, but was on other arches.
It is actually more complicated than I remembered. Firefox needed a gcc fix, but gcc building is blocked on an i686 issue. And the delay in getting that fix combined with the long time for doing a gcc build is seemingly going to result in a slip because a firefox downgrade (from the f35 version) would cause problems for some testers.
On Wed, Mar 9, 2022 at 8:07 PM Bruno Wolff III bruno@wolff.to wrote:
On Wed, Mar 09, 2022 at 12:23:41 -0600, Bruno Wolff III bruno@wolff.to wrote:
On Wed, Mar 09, 2022 at 09:06:01 -0600,
The Fedora 36 beta is likely to slip because firefox was not building successfully on i686, but was on other arches.
It is actually more complicated than I remembered. Firefox needed a gcc fix, but gcc building is blocked on an i686 issue. And the delay in getting that fix combined with the long time for doing a gcc build is seemingly going to result in a slip because a firefox downgrade (from the f35 version) would cause problems for some testers.
So ... this sounds like firefox would be a good example of a package that would benefit from my proposal?
- It's already almost a leaf package (only some other GUI apps - that could also drop i686 support without any consequences - depend on it). - We already do not publish or ship firefox.i686 RPMs - or RPMs for the 4 dependent applications, for that matter - to anybody, so building them is just a waste of time and maintainer resources.
Fabio
On 3/11/22 13:33, Fabio Valentini wrote:
On Wed, Mar 9, 2022 at 8:07 PM Bruno Wolff III bruno@wolff.to wrote:
On Wed, Mar 09, 2022 at 12:23:41 -0600, Bruno Wolff III bruno@wolff.to wrote:
On Wed, Mar 09, 2022 at 09:06:01 -0600,
The Fedora 36 beta is likely to slip because firefox was not building successfully on i686, but was on other arches.
It is actually more complicated than I remembered. Firefox needed a gcc fix, but gcc building is blocked on an i686 issue. And the delay in getting that fix combined with the long time for doing a gcc build is seemingly going to result in a slip because a firefox downgrade (from the f35 version) would cause problems for some testers.
So ... this sounds like firefox would be a good example of a package that would benefit from my proposal?
It would be, yes.
On Wed, Mar 09, 2022 at 09:06:01 -0600, Chris Adams <linux(a)cmadams.net> wrote:
The Fedora 36 beta is likely to slip because firefox was not building successfully on i686, but was on other arches.
That is a very poor excuse for a slip, why would any one need it? Why not add an ExcludeArch to fix?
On Wed, Mar 09, 2022 at 19:58:30 -0000, Leigh Scott leigh123linux@gmail.com wrote:
On Wed, Mar 09, 2022 at 09:06:01 -0600, Chris Adams <linux(a)cmadams.net> wrote:
The Fedora 36 beta is likely to slip because firefox was not building successfully on i686, but was on other arches.
That is a very poor excuse for a slip, why would any one need it?
That is specified in the release criteria. I believe the rational is covered there if you are really interested. In this case it would have had people doing an upgrade to test things, downgrading firefox, and that breaks profiles. So shipping an old firefox wouldn't have been a good idea. I think firefox is the only browser that comes with Workstation, so not including it was going to be undesireable.
Why not add an ExcludeArch to fix?
As I stated in my followup things were a bit more complicated as the main i686 issue was in gcc. Firefox needed a new gcc to be built with a fix, so excludearch for firefox wouldn't have helped. Using excludearch for gcc would have had reprocussions and I don't see how that would have been practical.
On Wed, Mar 09, 2022 at 09:06:01AM -0600, Chris Adams wrote:
So I guess this is the part I don't really understand (and I guess why I don't see this proposal as a "win") - how is i686 painful to package maintainers for non-delivered packages? Maybe I'm just missing something, but what causes issues?
Some of the Facebook/Meta open source projects I maintain are written with only 64-bit platforms in mind, and I certainly appreciate the blanket approval to drop %{ix86} without having to file a tracking bug.
Best regards,
On 09. 03. 22 15:51, Fabio Valentini wrote:
On Tue, Mar 8, 2022 at 9:57 PM Miro Hrončok mhroncok@redhat.com wrote:
(snip)
I think we are all misinterpreting the intention of this change proposal.
We are suggesting better ways to get rid of i686. And the arguments are valid. However, I now think that this change proposal was not proposed to get rid of i686, not even to get rid of most of the i686 packages. Indeed, there are more sophisticated ways to do that -- OTOH volunteers don't seem to exactly pile up.
I think this change proposal has a different goal in mind. A simpler goal. Goal that requires no volunteers:
Give maintainers a blanket approval to exclude i686 if it bothers them in any way and their package is a leaf i686 package. That is it. Will this speed up eventual i686 retirement? Possibly, but not much. But that is not the goal. The goal is to clearly communicate: It is OK to drop this, you don't need to ask for permissions or file bugzillas, just make sure you don't break anything (and here's how you check if you are not breaking anything).
Is that correct, Fabio?
If so, I think it is actually a good thing to do. It won't solve the big elephant in the room, but it has the potential to ease packaging for some.
Yes. That's the whole point...
OK then, I can +1 that, but please: Make that more obvious in the proposal.
On Wed, Mar 9, 2022 at 5:55 PM Miro Hrončok mhroncok@redhat.com wrote:
(...)
OK then, I can +1 that, but please: Make that more obvious in the proposal.
Honest question: How do I do that? Do you have a suggestion?
The proposal already does not contain anything language that could be interpreted as "this will be mandatory", explicitly says that things can be done incrementally, and also mentions dropping the requirement for the ExcludeArch tracker bug.
The only thing I can imagine is that either 1) people didn't actually read the proposal, or 2) my non-native English is confusing. If 2) can be improved, I'm open to suggestions. If it's 1), then I can't do anything about it.
Fabio
On Wed, Mar 09, 2022 at 06:05:06PM +0100, Fabio Valentini wrote:
On Wed, Mar 9, 2022 at 5:55 PM Miro Hrončok mhroncok@redhat.com wrote:
(...)
OK then, I can +1 that, but please: Make that more obvious in the proposal.
Honest question: How do I do that? Do you have a suggestion?
Drop this part:
Stopping to run unnecessary package builds on i686 will free up no small amount of resources. In particular, stopping to build for i686 could potentially free up almost half of the existing x86 builder resources in koji.
If this effort only applies to some small subset of packages, this benefit will not be there.
In Detailed Description, you describe status quo, but don't say _anything_ about the proposal. Prefix the current text by: "Currently, ", and add a description of the proposal with a phrase like "only applies to the packages where maintainers see a benefit to opting out of the i686 builds".
The proposal already does not contain anything language that could be interpreted as "this will be mandatory", explicitly says that things can be done incrementally, and also mentions dropping the requirement for the ExcludeArch tracker bug.
The only thing I can imagine is that either 1) people didn't actually read the proposal, or 2) my non-native English is confusing. If 2) can be improved, I'm open to suggestions. If it's 1), then I can't do anything about it.
Zbyszek
On 09. 03. 22 18:05, Fabio Valentini wrote:
On Wed, Mar 9, 2022 at 5:55 PM Miro Hrončok mhroncok@redhat.com wrote:
(...)
OK then, I can +1 that, but please: Make that more obvious in the proposal.
Honest question: How do I do that? Do you have a suggestion?
Encourage Dropping Unused / Leaf Packages on i686
The word "encourage" is rather weird here. I am not a native speaker, but that sound to me like we are agitating for active removals. Like we go to the packagers and ask them: Could oyu please drop i686 from your leaf packages now?
Should this better say "allow"? Or "make it normal to".
Package maintainers are encouraged to actively stop building...
Package maintainers are allowed to stop building... without fuzz. Opening bugzillas or sending announcements is no longer required.
The *Detailed Description* section does not say what is changing.
In particular, stopping to build for i686 could potentially free up almost
half of the existing x86 builder resources in koji.
This sounds like a goal. Don't mention it. Focus on people instead: In particular, when packagers drop i686 they have more time to spend with their children :D
Fedora packages will incrementally drop support for the i686 architecture
(32-bit x86), where this support is no longer required. This is intended to reduce resource consumption of build servers.
Same thing.
On Thu, Mar 10, 2022 at 9:07 AM Miro Hrončok mhroncok@redhat.com wrote:
Thanks for your feedback!
The word "encourage" is rather weird here. I am not a native speaker, but that sound to me like we are agitating for active removals. Like we go to the packagers and ask them: Could oyu please drop i686 from your leaf packages now?
Should this better say "allow"? Or "make it normal to".
Yeah, I am not a native speaker either, but "encourage" was the best I could come up with at short notice. "Allow" doesn't seem right either, because this has technically always been "allowed".
Maybe "simplify" or "prefer" (though I prefer "prefer" out of those two).
Package maintainers are encouraged to actively stop building...
Package maintainers are allowed to stop building... without fuzz. Opening bugzillas or sending announcements is no longer required.
Sounds good. I'll adapt the text in the proposal.
The *Detailed Description* section does not say what is changing.
I'll add something here. Must have missed it when I filled out the template.
In particular, stopping to build for i686 could potentially free up almost
half of the existing x86 builder resources in koji.
This sounds like a goal. Don't mention it. Focus on people instead: In particular, when packagers drop i686 they have more time to spend with their children :D
Sure. "Almost half" is an aspirational goal. Not the goal of the proposal itself. I'll remove that.
Thanks again for your feedback. I sometimes struggle with technical documents as a non-native speaker.
Fabio
On Tue, Mar 08, 2022 at 01:55:47PM -0600, Chris Adams wrote:
Rather than churn 20,000+ packages (plus add a new requirement for every new package to include an ExcludeArch), why not address this at the build system?
Writing a script to generate a list of the buildroot plus multilib packages, then find all the necessary source packages for those and their build dependencies, should not be that hard. I don't know how difficult it would be to then hook that in as a filter to the i686 build system, hopefully not too difficult?
I would think it would be quite a lot of work because it's trying to make koji do something in a way that it's really not currently designed for.
If folks are willing to put in the work, I'm sure we would be happy to use it once it's available upstream.
I don't know how the current list of provided multilib packages is created though.
It's created by pungi / python-multilib at compose time using a number of rules and allow and block lists.
I'd probably start with the above script querying all i686.rpm packages in the x86_64 repo (and working through their source packages, and those packages' build deps), and if the i686.rpm list is slimmed down, the above script would trim the deps automatically.
Then rather than churn almost every package in the distribution, current and future, fix it in one place. That place can then be updated as needed.
I'm not sure this is going to be at all as easy as that.
:(
kevin
On Mon, 2022-03-07 at 12:12 -0500, Ben Cotton wrote:
== Detailed Description ==
Fedora does no longer ship any deliverables for i686, not even RPM repositories for i686 are published any longer. The kernel package itself also [[Changes/Stop Building i686 Kernels|dropped support for i686]] in Fedora 31, so there has not been any way to run Fedora on 32-bit x86 systems for years. Only a tiny fraction of all packages that are built on i686 are actually used (i.e. "multilib" support for Wine, Steam, etc. on x86_64).
Why isn't this as simple as:
1) Create an f37-multilib-build build tag with all supported arches + i686, and an f37-multilib{,-candidate} build targets to use it (with destination tag of f37-updates-candidate);
2) Drop i686 from f37-build tag;
3) Maintainers of wine and its deps etc. opt-in to i686 with a package.cfg:
[koji] targets = f37-multilib
(Yes, that would have to be updated after branch point, but that could possibly be automated.)
4) Everyone else leaves their spec files alone, no need to add ExcludeArch: i686.
Would that work?
On Mon, 2022-03-07 at 12:12 -0500, Ben Cotton wrote:
Why isn't this as simple as:
- Create an f37-multilib-build build tag with all supported arches + i686,
and an f37-multilib{,-candidate} build targets to use it (with destination tag of f37-updates-candidate);
Drop i686 from f37-build tag;
Maintainers of wine and its deps etc. opt-in to i686 with a package.cfg:
[koji] targets = f37-multilib
(Yes, that would have to be updated after branch point, but that could possibly be automated.)
- Everyone else leaves their spec files alone, no need to add ExcludeArch:
i686.
Would that work?
That works ok for rpmfusion.
https://koji.rpmfusion.org/koji/taginfo?tagID=483
fedpkg could be adapted as well, see
https://github.com/rpmfusion-infra/rfpkg/blob/master/rfpkg/__init__.py#L187
On Fri, Mar 11, 2022 at 8:41 AM Leigh Scott leigh123linux@gmail.com wrote:
On Mon, 2022-03-07 at 12:12 -0500, Ben Cotton wrote:
Why isn't this as simple as:
- Create an f37-multilib-build build tag with all supported arches + i686,
and an f37-multilib{,-candidate} build targets to use it (with destination tag of f37-updates-candidate);
Drop i686 from f37-build tag;
Maintainers of wine and its deps etc. opt-in to i686 with a package.cfg:
[koji] targets = f37-multilib
(Yes, that would have to be updated after branch point, but that could possibly be automated.)
- Everyone else leaves their spec files alone, no need to add ExcludeArch:
i686.
Would that work?
That works ok for rpmfusion.
https://koji.rpmfusion.org/koji/taginfo?tagID=483
fedpkg could be adapted as well, see
https://github.com/rpmfusion-infra/rfpkg/blob/master/rfpkg/__init__.py#L187
This might work for RPMFusion, but only because you have a limited set of packages, and because you can rely on the Fedora buildroot and dependencies always to be there. For Fedora itself, we do not have that luxury. We would need to know the packages that are needed to build and maintain the base buildroot plus everything needed to build multilib packages. As I said, this is not so easy. And then we're back to modifying (adding config files) all packages that need to be included (or maintaining a hard-coded list of required packages in fedpkg), so you don't gain anything at all, compared to the simple opt-out mechanism from this Proposal.
Fabio
On Fri, 2022-03-11 at 15:31 +0100, Fabio Valentini wrote:
On Fri, Mar 11, 2022 at 8:41 AM Leigh Scott leigh123linux@gmail.com wrote:
On Mon, 2022-03-07 at 12:12 -0500, Ben Cotton wrote:
Why isn't this as simple as:
- Create an f37-multilib-build build tag with all supported arches +
i686, and an f37-multilib{,-candidate} build targets to use it (with destination tag of f37-updates-candidate);
Drop i686 from f37-build tag;
Maintainers of wine and its deps etc. opt-in to i686 with a
package.cfg:
[koji] targets = f37-multilib
(Yes, that would have to be updated after branch point, but that could possibly be automated.)
- Everyone else leaves their spec files alone, no need to add
ExcludeArch: i686.
Would that work?
That works ok for rpmfusion.
https://koji.rpmfusion.org/koji/taginfo?tagID=483
fedpkg could be adapted as well, see
https://github.com/rpmfusion-infra/rfpkg/blob/master/rfpkg/__init__.py#L187
This might work for RPMFusion, but only because you have a limited set of packages, and because you can rely on the Fedora buildroot and dependencies always to be there. For Fedora itself, we do not have that luxury. We would need to know the packages that are needed to build and maintain the base buildroot plus everything needed to build multilib packages. As I said, this is not so easy. And then we're back to modifying (adding config files) all packages that need to be included (or maintaining a hard-coded list of required packages in fedpkg), so you don't gain anything at all, compared to the simple opt-out mechanism from this Proposal.
I don't see the opt-out as being "simple" at all, as IIUC all it would take is one maintainer not paying close enough attention to reverse dependencies to break the i686 buildroot. Not to mention that it ends up polluting the vast majority of packages with a spec file change that isn't technically accurate (since the package *could* be built for i686, we've just choosing not to, and the proper place to express that is in the build tag's arches).
Since the number of packages actually needed for i686 -- wine and its deps, plus deps for those RPM Fusion i686 library packages, it seems -- should be a small minority of the entire distribution, it should be those where the changes are made. Doesn't it make more sense to special-case the exception rather than the rule, as it requires fewer changes? (FWIW IMO package.cfg files should be better than hardcoding a list in fedpkg, as the former doesn't require the lag time involved in pushing an update when the list changes.)
It also avoids this becoming a piecemeal change, which will likely drag on for years if left to individual maintainers.
On Fri, Mar 11, 2022 at 5:51 PM Yaakov Selkowitz yselkowi@redhat.com wrote:
(snip)
I don't see the opt-out as being "simple" at all, as IIUC all it would take is one maintainer not paying close enough attention to reverse dependencies to break the i686 buildroot. Not to mention that it ends up polluting the vast majority of packages with a spec file change that isn't technically accurate (since the package *could* be built for i686, we've just choosing not to, and the proper place to express that is in the build tag's arches).
Since the number of packages actually needed for i686 -- wine and its deps, plus deps for those RPM Fusion i686 library packages, it seems -- should be a small minority of the entire distribution, it should be those where the changes are made. Doesn't it make more sense to special-case the exception rather than the rule, as it requires fewer changes? (FWIW IMO package.cfg files should be better than hardcoding a list in fedpkg, as the former doesn't require the lag time involved in pushing an update when the list changes.)
It also avoids this becoming a piecemeal change, which will likely drag on for years if left to individual maintainers.
Please stop moving goalposts. The goal of my proposal was never to drop support for i686 from *all* possible packages. It's about making it easy to drop unnecessary support for i686 from packages *where it matters to the maintainer*. And for this reason, I think a simple *opt-out* mechanism is the best solution.
If you want to talk about making it the norm to drop support for i686 unless the maintainer does *opt-in* to i686 for multilib, then that can be a follow-up Change that can build on top of this one. But please don't conflate the two things, as they are very different.
Fabio
-
Adam Williamson -
Ben Beasley -
Ben Cotton -
Bruno Wolff III -
Chris Adams -
Dan Horák -
Daniel P. Berrangé -
Demi Marie Obenour -
Dominik 'Rathann' Mierzejewski -
Fabio Valentini -
Florian Weimer -
Jerry James -
Kevin Fenzi -
Leigh Scott -
Matthew Miller -
Mattia Verga -
Michael Catanzaro -
Michael Cronenworth -
Michal Schorm -
Michel Alexandre Salim -
Miro Hrončok -
Neal Gompa -
Petr Pisar -
Richard Shaw -
Richard W.M. Jones -
Robbie Harwood -
Simo Sorce -
Vitaly Zaitsev -
Yaakov Selkowitz -
Zbigniew Jędrzejewski-Szmek