11:12 a.m.
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.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
12:21 p.m.
Once upon a time, Ben Cotton <bcotton(a)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?
--
Chris Adams <linux(a)cmadams.net>
12:30 p.m.
On Mon, Mar 7, 2022 at 7:22 PM Chris Adams <linux(a)cmadams.net> wrote:
Once upon a time, Ben Cotton <bcotton(a)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
1:07 p.m.
Once upon a time, Fabio Valentini <decathorpe(a)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.
--
Chris Adams <linux(a)cmadams.net>
1:14 p.m.
On 07. 03. 22 19:30, Fabio Valentini wrote:
On Mon, Mar 7, 2022 at 7:22 PM Chris Adams <linux(a)cmadams.net>
wrote:
>
> Once upon a time, Ben Cotton <bcotton(a)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?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1:36 p.m.
On Mon, Mar 7, 2022 at 8:15 PM Miro Hrončok <mhroncok(a)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_u...
Fabio
2:03 p.m.
On Mon, Mar 7, 2022 at 2:15 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 07. 03. 22 19:30, Fabio Valentini wrote:
> On Mon, Mar 7, 2022 at 7:22 PM Chris Adams <linux(a)cmadams.net> wrote:
>>
>> Once upon a time, Ben Cotton <bcotton(a)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
--
真実はいつも一つ！/ Always, there's only one truth!
3:54 p.m.
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.
4:08 p.m.
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
4:28 p.m.
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.
11:36 a.m.
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
4:42 p.m.
On Tue, Mar 8, 2022 at 3:09 PM Kevin Fenzi <kevin(a)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.
--
Jerry James
http://www.jamezone.org/
7:48 a.m.
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
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
2:59 p.m.
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(a)cmadams.net> wrote:
>>
>> Once upon a time, Ben Cotton <bcotton(a)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
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2:08 a.m.
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(a)cmadams.net>
wrote:
>
> Once upon a time, Ben Cotton <bcotton(a)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_...
We should amend the guidelines not to mandate opening the bugs for this
i686 retirement.
-- Petr
2:51 a.m.
On Tue, Mar 8, 2022 at 9:09 AM Petr Pisar <ppisar(a)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_...
> 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
3:14 a.m.
New subject: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)
Il 07/03/22 19:30, Fabio Valentini ha scritto:
On Mon, Mar 7, 2022 at 7:22 PM Chris Adams <linux(a)cmadams.net>
wrote:
> Once upon a time, Ben Cotton <bcotton(a)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
1:25 p.m.
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
1:32 p.m.
On Mon, Mar 7, 2022 at 8:25 PM Kevin Fenzi <kevin(a)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
2:01 p.m.
On Mon, 2022-03-07 at 20:32 +0100, Fabio Valentini wrote:
On Mon, Mar 7, 2022 at 8:25 PM Kevin Fenzi <kevin(a)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.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
11:56 a.m.
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(a)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.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
2:04 p.m.
Fabio Valentini <decathorpe(a)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
2:05 p.m.
On Mon, Mar 7, 2022 at 3:05 PM Robbie Harwood <rharwood(a)redhat.com> wrote:
Fabio Valentini <decathorpe(a)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.
--
真実はいつも一つ！/ Always, there's only one truth!
3:10 p.m.
Neal Gompa <ngompa13(a)gmail.com> writes:
On Mon, Mar 7, 2022 at 3:05 PM Robbie Harwood
<rharwood(a)redhat.com> wrote:
>
> Fabio Valentini <decathorpe(a)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
1:10 p.m.
On Mon, Mar 07, 2022 at 15:04:21 -0500,
Robbie Harwood <rharwood(a)redhat.com> wrote:
Fabio Valentini <decathorpe(a)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.
2:11 a.m.
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(a)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
--
|: 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 :|
2:59 a.m.
On Tue, Mar 8, 2022 at 9:11 AM Daniel P. Berrangé <berrange(a)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
3:14 a.m.
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(a)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/i68...
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
--
|: 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 :|
3:29 a.m.
* 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
3:30 a.m.
On Tue, Mar 8, 2022 at 10:14 AM Daniel P. Berrangé <berrange(a)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
3:40 a.m.
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(a)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
--
|: 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 :|
4:01 a.m.
On Tue, Mar 8, 2022 at 10:40 AM Daniel P. Berrangé <berrange(a)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
4:17 a.m.
On Tue, 8 Mar 2022 09:40:16 +0000
Daniel P. Berrangé <berrange(a)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(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
4:26 a.m.
On Tue, 8 Mar 2022 11:17:20 +0100
Dan Horák <dan(a)danny.cz> wrote:
On Tue, 8 Mar 2022 09:40:16 +0000
Daniel P. Berrangé <berrange(a)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(a)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
>
>
> 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(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
7:05 a.m.
Once upon a time, Fabio Valentini <decathorpe(a)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).
--
Chris Adams <linux(a)cmadams.net>
8:46 a.m.
On Tue, Mar 8, 2022 at 2:05 PM Chris Adams <linux(a)cmadams.net> wrote:
Once upon a time, Fabio Valentini <decathorpe(a)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
9:04 a.m.
On Tue, 8 Mar 2022 15:46:29 +0100
Fabio Valentini <decathorpe(a)gmail.com> wrote:
On Tue, Mar 8, 2022 at 2:05 PM Chris Adams <linux(a)cmadams.net>
wrote:
>
> Once upon a time, Fabio Valentini <decathorpe(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
9:56 a.m.
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(a)danny.cz> wrote:
On Tue, 8 Mar 2022 15:46:29 +0100
Fabio Valentini <decathorpe(a)gmail.com> wrote:
> On Tue, Mar 8, 2022 at 2:05 PM Chris Adams <linux(a)cmadams.net> wrote:
> >
> > Once upon a time, Fabio Valentini <decathorpe(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
1:27 p.m.
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
1:34 p.m.
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?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2:45 p.m.
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?
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
2:53 p.m.
On Mon, Mar 7, 2022 at 3:46 PM Adam Williamson
<adamwill(a)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.
--
真実はいつも一つ！/ Always, there's only one truth!
3:46 p.m.
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
4:31 p.m.
On Tue, Mar 8, 2022 at 4:47 PM Kevin Fenzi <kevin(a)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.
--
真実はいつも一つ！/ Always, there's only one truth!
4:36 a.m.
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.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
1:39 p.m.
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
1:55 p.m.
Once upon a time, Zbigniew Jędrzejewski-Szmek <zbyszek(a)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.
--
Chris Adams <linux(a)cmadams.net>
2:11 p.m.
On Tue, Mar 8 2022 at 01:55:47 PM -0600, Chris Adams
<linux(a)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.
2:43 p.m.
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.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2:57 p.m.
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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3:02 p.m.
Once upon a time, Miro Hrončok <mhroncok(a)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.
--
Chris Adams <linux(a)cmadams.net>
8:51 a.m.
On Tue, Mar 8, 2022 at 9:57 PM Miro Hrončok <mhroncok(a)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
9:06 a.m.
Once upon a time, Fabio Valentini <decathorpe(a)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.
--
Chris Adams <linux(a)cmadams.net>
9:13 a.m.
On Wed, Mar 9, 2022 at 4:06 PM Chris Adams <linux(a)cmadams.net> wrote:
Once upon a time, Fabio Valentini <decathorpe(a)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
10:06 a.m.
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(a)cmadams.net> wrote:
>>
>> Once upon a time, Fabio Valentini <decathorpe(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)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
11:04 a.m.
On Wed, Mar 9, 2022 at 10:09 AM Ben Beasley <code(a)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
11:09 a.m.
On Wed, Mar 9, 2022 at 6:05 PM Richard Shaw <hobbes1069(a)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
7:46 a.m.
On Wed, Mar 9, 2022 at 11:09 AM Fabio Valentini <decathorpe(a)gmail.com>
wrote:
On Wed, Mar 9, 2022 at 6:05 PM Richard Shaw
<hobbes1069(a)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
12:23 p.m.
On Wed, Mar 09, 2022 at 09:06:01 -0600,
Chris Adams <linux(a)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.
1:03 p.m.
On Wed, Mar 09, 2022 at 12:23:41 -0600,
Bruno Wolff III <bruno(a)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.
12:33 p.m.
On Wed, Mar 9, 2022 at 8:07 PM Bruno Wolff III <bruno(a)wolff.to> wrote:
On Wed, Mar 09, 2022 at 12:23:41 -0600,
Bruno Wolff III <bruno(a)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
2:03 p.m.
On 3/11/22 13:33, Fabio Valentini wrote:
On Wed, Mar 9, 2022 at 8:07 PM Bruno Wolff III <bruno(a)wolff.to>
wrote:
>
> On Wed, Mar 09, 2022 at 12:23:41 -0600,
> Bruno Wolff III <bruno(a)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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
1:58 p.m.
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?
4:06 p.m.
On Wed, Mar 09, 2022 at 19:58:30 -0000,
Leigh Scott <leigh123linux(a)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.
4:23 p.m.
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,
--
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
10:55 a.m.
On 09. 03. 22 15:51, Fabio Valentini wrote:
On Tue, Mar 8, 2022 at 9:57 PM Miro Hrončok
<mhroncok(a)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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
11:05 a.m.
On Wed, Mar 9, 2022 at 5:55 PM Miro Hrončok <mhroncok(a)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
4:27 p.m.
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(a)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
2:07 a.m.
On 09. 03. 22 18:05, Fabio Valentini wrote:
On Wed, Mar 9, 2022 at 5:55 PM Miro Hrončok
<mhroncok(a)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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
8:02 a.m.
On Thu, Mar 10, 2022 at 9:07 AM Miro Hrončok <mhroncok(a)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
3:56 p.m.
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
12:51 a.m.
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?
--
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.
1:41 a.m.
On Mon, 2022-03-07 at 12:12 -0500, Ben Cotton wrote:
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?
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
8:31 a.m.
On Fri, Mar 11, 2022 at 8:41 AM Leigh Scott <leigh123linux(a)gmail.com> wrote:
> On Mon, 2022-03-07 at 12:12 -0500, Ben Cotton wrote:
>
> 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?
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
10:51 a.m.
On Fri, 2022-03-11 at 15:31 +0100, Fabio Valentini wrote:
On Fri, Mar 11, 2022 at 8:41 AM Leigh Scott
<leigh123linux(a)gmail.com> wrote:
>
> > On Mon, 2022-03-07 at 12:12 -0500, Ben Cotton wrote:
> >
> > 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?
>
> 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.
--
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat, Inc.
12:39 p.m.
On Fri, Mar 11, 2022 at 5:51 PM Yaakov Selkowitz <yselkowi(a)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
545
days inactive
564
days old
76 comments
30 participants
participants (30)
-
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