1:47 p.m.
Hi everybody,
The announcement of the Change proposal to drop armv7 support with F37
has reminded me of something that I wanted to ask about some time ago:
How we could work towards reducing the number of packages we build for
i686.
Our current approach, which is to "build everything but ship almost
nothing" - just to keep x86_64 / i686 multilib working - is, frankly,
very wasteful of computing and storage resources, as well as a burden
on maintainers of big packages, which frequently run up against limits
of 32-bit architectures.
I think it should be possible to figure out a way to limit the number
of packages that need to be built for the common multilib usecases
(Wine + Steam ... am I forgetting something?), and just ... not build
anything else for i686.
This would probably involve the following steps:
1. determine the packages that need to be built on i686 for common
multilib scenarios
2. determine recursive install-time and build-time dependencies of
those packages
3. if necessary, update this list with any new build-or install-time
dependencies that are added to the package set
As for how to implement this, I'm not sure about the details yet
(which is why I'm sending this as an RFC and not filing a Change
proposal yet).
Since it's not practical to modify almost all Fedora packages to add
"ExcludeArch: %{ix86}" to them, we'd probably need a different
machanism for this. I have a vague idea:
- include the list of packages to be built ... somewhere (maybe in the
default buildroot?)
- if a package name matches a list entry, build it on i686. if it
doesn't, then don't.
As for the second step, I'm not sure how to do that yet - does
injecting ExcludeArch headers at SRPM build time in koji work, maybe
with some RPM macro that's included in every package anyway? Or could
we somehow influence the chroots that builds in koji are launched for?
Then the spec or SRPM wouldn't even have to be modified.
As I said, I'm not sure about the details yet, but we should be able
to figure out a way to do this, and make building Fedora packages less
wasteful. Consider this my "request for comments". :)
Fabio
2:05 p.m.
Fabio Valentini <decathorpe(a)gmail.com> writes:
Since it's not practical to modify almost all Fedora packages to
add
"ExcludeArch: %{ix86}" to them, we'd probably need a different
machanism for this. I have a vague idea:
Is it really not? This seems the easiest way to go about it, honestly -
just have it be permitted for maintainers to opt their stuff out of
building on x86 and let the problem take care of itself recursively.
Be well,
--Robbie
2:14 p.m.
>>>> Robbie Harwood <rharwood(a)redhat.com> writes:
Fabio Valentini <decathorpe(a)gmail.com> writes:
> Since it's not practical to modify almost all Fedora packages to add
> "ExcludeArch: %{ix86}" to them, we'd probably need a different
> machanism for this.
Is it really not? This seems the easiest way to go about it,
honestly
- just have it be permitted for maintainers to opt their stuff out of
building on x86 and let the problem take care of itself recursively.
I have to say that it would be nicer if building for i686 were opt-in
instead of opt-out. Just figure out what we really need to build to
support the few things we want to support, let maintainers build
additional things if they want to do so, and have a mechanism for asking
someone to add an i686 build.
Basically not much different from EPEL.
- J<
4:53 a.m.
On Tue, Nov 16, 2021 at 03:05:37PM -0500, Robbie Harwood wrote:
Fabio Valentini <decathorpe(a)gmail.com> writes:
> Since it's not practical to modify almost all Fedora packages to add
> "ExcludeArch: %{ix86}" to them, we'd probably need a different
> machanism for this. I have a vague idea:
Is it really not? This seems the easiest way to go about it, honestly -
just have it be permitted for maintainers to opt their stuff out of
building on x86 and let the problem take care of itself recursively.
Yeah, I think I'd go this way too. Instead of trying to maintain this
centrally in koji, do it at package level, using proven-packager privileges
to smooth the initial process.
I.e. something like: OK, we don't want to build libreoffice for i686.
libreoffice is annotated with "ExcludeArch: %{ix86}", and *at the same time*
any packages which (transitively) BR:libreoffice, are also annotated.
(They don't even need to be rebuild.)
And then repeat for another "big" package.
I think this way to go is OK because we mostly care about some of the
"big" packages that take a long time to build. Most low-level packages
build just fine on i686 so we don't care if they are built unnecessarily.
And obviously the advantage is that this can be done now, and doesn't
require any new infra or maintenance. The only trick would be how to
figure out the transitive BR tree, but apparently there are some scripts
that people have.
Zbyszek
4:54 a.m.
On Wed, Nov 17, 2021 at 10:53:30AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Nov 16, 2021 at 03:05:37PM -0500, Robbie Harwood wrote:
> Fabio Valentini <decathorpe(a)gmail.com> writes:
>
> > Since it's not practical to modify almost all Fedora packages to add
> > "ExcludeArch: %{ix86}" to them, we'd probably need a different
> > machanism for this. I have a vague idea:
>
> Is it really not? This seems the easiest way to go about it, honestly -
> just have it be permitted for maintainers to opt their stuff out of
> building on x86 and let the problem take care of itself recursively.
Yeah, I think I'd go this way too. Instead of trying to maintain this
centrally in koji, do it at package level, using proven-packager privileges
to smooth the initial process.
I.e. something like: OK, we don't want to build libreoffice for i686.
libreoffice is annotated with "ExcludeArch: %{ix86}", and *at the same time*
any packages which (transitively) BR:libreoffice, are also annotated.
(They don't even need to be rebuild.)
And then repeat for another "big" package.
I think this way to go is OK because we mostly care about some of the
"big" packages that take a long time to build. Most low-level packages
build just fine on i686 so we don't care if they are built unnecessarily.
And obviously the advantage is that this can be done now, and doesn't
require any new infra or maintenance. The only trick would be how to
figure out the transitive BR tree, but apparently there are some scripts
that people have.
s/people/Fabio/ ;)
> Zbyszek
10:59 p.m.
Nov 17, 2021 4:56:36 AM Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl>:
On Wed, Nov 17, 2021 at 10:53:30AM +0000, Zbigniew Jędrzejewski-Szmek
wrote:
[...]
>
> And obviously the advantage is that this can be done now, and doesn't
> require any new infra or maintenance. The only trick would be how to
> figure out the transitive BR tree, but apparently there are some scripts
> that people have.
s/people/Fabio/ ;)
Fabio,
Can you please provide a link to your script?
Thanks,
Maxwell
--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8
gotmax(a)e.email
9:29 a.m.
On Thu, Nov 18, 2021 at 5:59 AM Maxwell G (@gotmax23) <gotmax(a)e.email> wrote:
Nov 17, 2021 4:56:36 AM Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl>:
> On Wed, Nov 17, 2021 at 10:53:30AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> [...]
>>
>> And obviously the advantage is that this can be done now, and doesn't
>> require any new infra or maintenance. The only trick would be how to
>> figure out the transitive BR tree, but apparently there are some scripts
>> that people have.
>
> s/people/Fabio/ ;)
Fabio,
Can you please provide a link to your script?
Not yet. I still need to fix it up and verify that it actually
provides correct results.
However, consider it to be the "inverse" process that I usef for
determining (SIG) leaf packages for the stewardship-sig,
java-maint-sig, and rust-sig, so in theory the algorithm used *should*
be sound and complete (albeit not very fast).
Fabio
5:17 a.m.
On Wed, Nov 17, 2021 at 11:53 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
On Tue, Nov 16, 2021 at 03:05:37PM -0500, Robbie Harwood wrote:
(small snip)
> Is it really not? This seems the easiest way to go about it,
honestly -
> just have it be permitted for maintainers to opt their stuff out of
> building on x86 and let the problem take care of itself recursively.
Yeah, I think I'd go this way too. Instead of trying to maintain this
centrally in koji, do it at package level, using proven-packager privileges
to smooth the initial process.
I.e. something like: OK, we don't want to build libreoffice for i686.
libreoffice is annotated with "ExcludeArch: %{ix86}", and *at the same time*
any packages which (transitively) BR:libreoffice, are also annotated.
(They don't even need to be rebuild.)
And then repeat for another "big" package.
I think this way to go is OK because we mostly care about some of the
"big" packages that take a long time to build. Most low-level packages
build just fine on i686 so we don't care if they are built unnecessarily.
And obviously the advantage is that this can be done now, and doesn't
require any new infra or maintenance. The only trick would be how to
figure out the transitive BR tree, but apparently there are some scripts
that people have.
I really *don't* think a manual, individual opt-out like this is a good idea.
Imagine the scenario where a package maintaner unilaterally adds
"ExcludeArch: %{ix68}" to one of their packages. This might be an
honest mistake, for example, because the repoquery was not done
correctly, or because they thought that nothing depends on that
package. Then, this results in cascading build failures of all
dependent packages, because a broken build on any arch fails the whole
build, requiring cascading changes to all packages in the dependency
tree, more work for all manitainers that are involved.
Because I think we should respect package maintainers' time, I don't
think I should put the burden of figuring this out and fixing
breakages on them, which is why I suggested a centralized approach
that will not put more work on *every single package maintainer*.
Fabio
5:27 a.m.
I see your point, I am a part of the Quality Assurance team here.
+1 Making it easier on package maintainers
+1 On retiring all i686 (32 Bit Systems)
On Wed, 17 Nov 2021, 11:18 Fabio Valentini, <decathorpe(a)gmail.com> wrote:
On Wed, Nov 17, 2021 at 11:53 AM Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
>
> On Tue, Nov 16, 2021 at 03:05:37PM -0500, Robbie Harwood wrote:
(small snip)
> > Is it really not? This seems the easiest way to go about it, honestly
-
> > just have it be permitted for maintainers to opt their stuff out of
> > building on x86 and let the problem take care of itself recursively.
>
> Yeah, I think I'd go this way too. Instead of trying to maintain this
> centrally in koji, do it at package level, using proven-packager
privileges
> to smooth the initial process.
>
> I.e. something like: OK, we don't want to build libreoffice for i686.
> libreoffice is annotated with "ExcludeArch: %{ix86}", and *at the same
time*
> any packages which (transitively) BR:libreoffice, are also annotated.
> (They don't even need to be rebuild.)
> And then repeat for another "big" package.
>
> I think this way to go is OK because we mostly care about some of the
> "big" packages that take a long time to build. Most low-level packages
> build just fine on i686 so we don't care if they are built unnecessarily.
>
> And obviously the advantage is that this can be done now, and doesn't
> require any new infra or maintenance. The only trick would be how to
> figure out the transitive BR tree, but apparently there are some scripts
> that people have.
I really *don't* think a manual, individual opt-out like this is a good
idea.
Imagine the scenario where a package maintaner unilaterally adds
"ExcludeArch: %{ix68}" to one of their packages. This might be an
honest mistake, for example, because the repoquery was not done
correctly, or because they thought that nothing depends on that
package. Then, this results in cascading build failures of all
dependent packages, because a broken build on any arch fails the whole
build, requiring cascading changes to all packages in the dependency
tree, more work for all manitainers that are involved.
Because I think we should respect package maintainers' time, I don't
think I should put the burden of figuring this out and fixing
breakages on them, which is why I suggested a centralized approach
that will not put more work on *every single package maintainer*.
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
5:35 a.m.
On Wed, Nov 17, 2021 at 11:27:13AM +0000, Ahmed Almeleh wrote:
I see your point, I am a part of the Quality Assurance team here.
+1 On retiring all i686 (32 Bit Systems)
Did you see the part where we are using those packages for multilib?
This would immediately kill Wine, Steam, and 32-bit development
on Fedora.
The fact that we're discussing a complicated way is because the complicated
way is needed to avoid breaking use cases that we care about, not because
we like complexity for complexity's sake.
Zbyszek
5:39 a.m.
On Wed, Nov 17, 2021 at 12:17:30PM +0100, Fabio Valentini wrote:
I really *don't* think a manual, individual opt-out like this is
a good idea.
Imagine the scenario where a package maintaner unilaterally adds
"ExcludeArch: %{ix68}" to one of their packages. This might be an
honest mistake, for example, because the repoquery was not done
correctly, or because they thought that nothing depends on that
package. Then, this results in cascading build failures of all
dependent packages, because a broken build on any arch fails the whole
build, requiring cascading changes to all packages in the dependency
tree, more work for all manitainers that are involved.
Because I think we should respect package maintainers' time, I don't
think I should put the burden of figuring this out and fixing
breakages on them, which is why I suggested a centralized approach
that will not put more work on *every single package maintainer*.
I agree that a centralized approach would be nice. The question is
whether we can make it happen within a reasonable time frame and without
too much work. I don't really grok koji internals, so I don't know how
hard it would be to feed it an updateable list of packages to skip.
Zbyszek
11:58 a.m.
> > Since it's not practical to modify almost all Fedora
packages to add
> > "ExcludeArch: %{ix86}" to them, we'd probably need a different
> > machanism for this. I have a vague idea:
>
> Is it really not? This seems the easiest way to go about it, honestly -
> just have it be permitted for maintainers to opt their stuff out of
> building on x86 and let the problem take care of itself recursively.
Yeah, I think I'd go this way too. Instead of trying to maintain this
centrally in koji, do it at package level, using proven-packager privileges
to smooth the initial process.
I.e. something like: OK, we don't want to build libreoffice for i686.
libreoffice is annotated with "ExcludeArch: %{ix86}", and *at the same time*
any packages which (transitively) BR:libreoffice, are also annotated.
(They don't even need to be rebuild.)
And then repeat for another "big" package.
I think this way to go is OK because we mostly care about some of the
"big" packages that take a long time to build. Most low-level packages
build just fine on i686 so we don't care if they are built unnecessarily.
And obviously the advantage is that this can be done now, and doesn't
require any new infra or maintenance. The only trick would be how to
figure out the transitive BR tree, but apparently there are some scripts
that people have.
I know it's been discussed, and I don't really care enough to read old
threads TBH, but I suppose the question is what is mlutilib actually
used for. The usual reply is "legacy and proprietary apps". And of
course it's fine to continue to support them but how many actually are
there?
From a RHEL perspective, RHEL-9 has now forked off, and that will be
supported for 10+ years for "enterprise" even after RHEL-10 in ~ 3
years so enterprise has means of running them in a supported manner
until 2032 if they so wish so does Red Hat still need i686?
What else is there that people care about in Fedora that's only i686?
3:06 p.m.
On Wednesday, 17 November 2021 at 18:58, Peter Robinson wrote:
[...]
What else is there that people care about in Fedora that's only
i686?
There are some old proprietary games with i686-only binaries. I'll check
which packages are required by the ones I have.
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
3:44 p.m.
On Wed, Nov 17, 2021 at 10:07 PM Dominik 'Rathann' Mierzejewski
<dominik(a)greysector.net> wrote:
On Wednesday, 17 November 2021 at 18:58, Peter Robinson wrote:
[...]
> What else is there that people care about in Fedora that's only i686?
There are some old proprietary games with i686-only binaries. I'll check
which packages are required by the ones I have.
I think the easy answer here is, indeed, "games". And for some Fedora
users, that might not be an important use case.
But given the increased interest in "Gaming on Linux" (even though
some tech YouTubers still consider Fedora a hat meme distro), I think
this is something Fedora as an increasingly popular "mainstream" linux
distribution should definitely continue to support.
However, wine, as packaged for Fedora - I assume to support running
both 32-bit and 64-bit windows applications - requires both x86_64 and
i686 libraries on x86_64:
$ sudo dnf repoquery --requires wine --resolve --recursive | grep i686 | wc -l
255
So, wine needs i686 multilib packages on x86_64 even if you don't want
to use it to run games, but just for running *any* Windows
application.
Additionally, the steam RPM (as provided by the opt-in third-party
repository that comes installed by default with Fedora Workstation) is
a i686-only package (sad face), and hence also pulls in i686
libraries:
$ sudo dnf repoquery --requires steam --resolve --recursive | grep i686 | wc -l
221
And any "older" games you want to play from Steam (or GOG, or
wherever) will also require i686 libraries, as they're probably 32-bit
only applications (if they're even linux native binaries, otherwise
they'll require wine, which *also* pulls in i686 libraries).
Considering there's a big overlap between those two package sets
(steam + wine dependencies) and that some of those i686-arch packages
are actually subpackages of the same source package, the number of
i686 packages we need to support for the two only important use cases
of i686 multilib should be around 200, plus their build-only
dependencies.
Two Hundred (or even make it 300) packages - that's around 1% of the
whole corpus of Fedora packages (with almost 23000 source packages in
rawhide).
Which I think confirms my suspicion that just building *everything*
for i686 is 99% wasteful ...
(Yes, yes, I know that some of those 23000 packages are noarch, like
python or perl stuff ... don't go fetching your torches and pitchforks
just yet.)
Fabio
2:37 a.m.
On Wed, Nov 17, 2021 at 10:44:25PM +0100, Fabio Valentini wrote:
On Wed, Nov 17, 2021 at 10:07 PM Dominik 'Rathann'
Mierzejewski
<dominik(a)greysector.net> wrote:
>
> On Wednesday, 17 November 2021 at 18:58, Peter Robinson wrote:
> [...]
> > What else is there that people care about in Fedora that's only i686?
>
> There are some old proprietary games with i686-only binaries. I'll check
> which packages are required by the ones I have.
I think the easy answer here is, indeed, "games". And for some Fedora
users, that might not be an important use case.
(snip)
I'm not much of a gamer myself, but I think this *is* an important use
case that we simply have to cater to, if we want to be more than a niche
distro. We already take a big hit on not having patent-encumbered codecs
by default, and not being able to run Wine or Steam would be a bad label
to have.
I'll share my own use case too: I use the 32 bit libs to test compilation
of programs. Most often systemd, but others too on occasion. It works like
this: after installing i686 versions of the build deps,
PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig meson build-32 -Dc_args=-m32 \
-Dc_link_args=-m32 -Dcpp_args=-m32 -Dcpp_link_args=-m32 && \
ninja -C build-32
I will also use armv7-*.fedorainfracloud.org as another 32-bit arch, but
it's better to test for i686 too.
If Fedora drops i686 multilib, it'll be much harder to do this kind of
upstream development of C projects.
Two Hundred (or even make it 300) packages - that's around 1% of
the
whole corpus of Fedora packages (with almost 23000 source packages in
rawhide).
Which I think confirms my suspicion that just building *everything*
for i686 is 99% wasteful ...
+1.
Zbyszek
11:58 a.m.
Le jeu. 18 nov. 2021 à 03:33, Fabio Valentini <decathorpe(a)gmail.com> a écrit :
Additionally, the steam RPM (as provided by the opt-in third-party
repository that comes installed by default with Fedora Workstation) is
a i686-only package (sad face), and hence also pulls in i686
The RPM Fusion package
is built as a i686 library despite been
"mainly" noarch scripts (bash, python3).
The "mainly" is because there is a 32bit bootstrap client that really
is about to download the fuller stream client from upstream.
Not having any 32bit runtime capability is going to break here (but
it's certainly fixable if upstream would also bundle a 64bit bootstrap
client).
Then most processes from stream {before} running any program show
steamwebhelper are using a 64bit ubuntu 12.04 userspace.
But we likely assume some program are 32bit only and because of that
the our package assume the 32bit capabilities {can} be needed, it
justs assume to install the needed libraries (specially the system
libGL.i686 and others)
It seems to me that assuming 64bit only userspace with steam is wrong
and will lead some users to crash.
If any additional question, please report an issue to
https://bugzilla.rpmfusion.org. Simone will be able to answer or
forward/ask upstream.
Thanks in advance.
> libraries:
> $ sudo dnf repoquery --requires steam --resolve --recursive | grep i686 | wc -l
> 221
4:38 p.m.
Dne 17. 11. 21 v 22:44 Fabio Valentini napsal(a):
So, wine needs i686 multilib packages on x86_64 even if you don't
want
to use it to run games, but just for running*any* Windows
application
Beside games that is: accounting SW, photobook creation, legal sw, logistic sw, ....
I just checked several SWs which I used to use under WINE and even the recent versions
(windows only) are distributed as
WIN32 binaries.
Miroslav
4:55 a.m.
On Wednesday, 17 November 2021 at 22:06, Dominik 'Rathann' Mierzejewski wrote:
On Wednesday, 17 November 2021 at 18:58, Peter Robinson wrote:
[...]
> What else is there that people care about in Fedora that's only i686?
There are some old proprietary games with i686-only binaries. I'll check
which packages are required by the ones I have.
So, for example, Tetrobot & Co and ABC Murders are both distributed as
i686 binaries only and they seem to have the following direct
dependencies:
glibc
libX11
libXcursor
libXext
libgcc
libglvnd-glx
libstdc++
mesa-dri-drivers
mesa-libGLU
pulseaudio-libs
Regards,
--
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
4:27 p.m.
On Wed, Nov 17, 2021 at 05:58:43PM +0000, Peter Robinson wrote:
What else is there that people care about in Fedora that's only i686?
Well, wine? I don't know how much 32bit wine is used these days.
And not 'in fedora', but people always bring up steam when these
disccussions happen. I wonder why they are sticking with 32bit?
kevin
11:26 a.m.
On 11/17/21 2:27 PM, Kevin Fenzi wrote:
And not 'in fedora', but people always bring up steam when
these
disccussions happen. I wonder why they are sticking with 32bit?
Is that just for the steam client, or also for its many legacy games?
ISTR it provides its own platform libraries for games, only relying on
system libs for stuff like mesa, but I'm not sure how the rpm is really
packaged. Personally, I've moved to the flatpak.
12:15 p.m.
On Thu, Nov 18, 2021 at 12:27 PM Josh Stone <jistone(a)redhat.com> wrote:
On 11/17/21 2:27 PM, Kevin Fenzi wrote:
> And not 'in fedora', but people always bring up steam when these
> disccussions happen. I wonder why they are sticking with 32bit?
Is that just for the steam client, or also for its many legacy games?
ISTR it provides its own platform libraries for games, only relying on
system libs for stuff like mesa, but I'm not sure how the rpm is really
packaged. Personally, I've moved to the flatpak.
All of it is 32-bit (client, games, runtime). Steam also offers a
64-bit runtime, but not many games I own use it.
--
真実はいつも一つ！/ Always, there's only one truth!
1:41 p.m.
On 11/18/21 10:15 AM, Neal Gompa wrote:
On Thu, Nov 18, 2021 at 12:27 PM Josh Stone
<jistone(a)redhat.com> wrote:
>
> On 11/17/21 2:27 PM, Kevin Fenzi wrote:
>> And not 'in fedora', but people always bring up steam when these
>> disccussions happen. I wonder why they are sticking with 32bit?
>
> Is that just for the steam client, or also for its many legacy games?
> ISTR it provides its own platform libraries for games, only relying on
> system libs for stuff like mesa, but I'm not sure how the rpm is really
> packaged. Personally, I've moved to the flatpak.
All of it is 32-bit (client, games, runtime). Steam also offers a
64-bit runtime, but not many games I own use it.
Sure, but with a private runtime they can run whatever 32-bit code they
want, as long as our kernel has CONFIG_COMPAT_32=y. But I'm wondering
how much of Fedora's 32-bit userspace is used by that stuff.
The question "why they are sticking with 32bit?" is easily answered for
games, because they simply aren't under active development. That doesn't
mean we're still providing libraries for all of those.
1:51 p.m.
On Thu, Nov 18, 2021 at 2:41 PM Josh Stone <jistone(a)redhat.com> wrote:
On 11/18/21 10:15 AM, Neal Gompa wrote:
> On Thu, Nov 18, 2021 at 12:27 PM Josh Stone <jistone(a)redhat.com> wrote:
>>
>> On 11/17/21 2:27 PM, Kevin Fenzi wrote:
>>> And not 'in fedora', but people always bring up steam when these
>>> disccussions happen. I wonder why they are sticking with 32bit?
>>
>> Is that just for the steam client, or also for its many legacy games?
>> ISTR it provides its own platform libraries for games, only relying on
>> system libs for stuff like mesa, but I'm not sure how the rpm is really
>> packaged. Personally, I've moved to the flatpak.
>
> All of it is 32-bit (client, games, runtime). Steam also offers a
> 64-bit runtime, but not many games I own use it.
Sure, but with a private runtime they can run whatever 32-bit code they
want, as long as our kernel has CONFIG_COMPAT_32=y. But I'm wondering
how much of Fedora's 32-bit userspace is used by that stuff.
The question "why they are sticking with 32bit?" is easily answered for
games, because they simply aren't under active development. That doesn't
mean we're still providing libraries for all of those.
I usually gut the Steam runtime and have it use the Fedora libraries,
since they're *better* in a lot of cases.
--
真実はいつも一つ！/ Always, there's only one truth!
12:09 p.m.
On 11/17/21 16:27, Kevin Fenzi wrote:
On Wed, Nov 17, 2021 at 05:58:43PM +0000, Peter Robinson wrote:
>
> What else is there that people care about in Fedora that's only i686?
Well, wine? I don't know how much 32bit wine is used these days.
Quite a lot. In fact, it's best to think of Windows programs as being
exclusively 32-bit. Even 64-bit Windows programs usually ship with
32-bit installers, because otherwise they'd have no way to control what
happens on a 32-bit machine.
For what it's worth, we are trying to avoid depending on 32-bit host
libraries (except for some 32-bit MinGW libraries), but it's a long and
difficult process.
2:54 p.m.
On 11/18/21 00:27, Kevin Fenzi wrote:
On Wed, Nov 17, 2021 at 05:58:43PM +0000, Peter Robinson wrote:
> What else is there that people care about in Fedora that's only i686?
Well, wine? I don't know how much 32bit wine is used these days.
And not 'in fedora', but people always bring up steam when these
disccussions happen. I wonder why they are sticking with 32bit?
Pretty much all Windows applications (including 64-bit ones) are usually
distributed as a self-installing 32-bit .exe, using one of the popular
installer packages, such as InnoSetup, the Nullsoft installer, etc.
That's why 64-bit Windows will probably never drop support for their
win32 compatibility layer.
Nikolay
7:35 a.m.
On Wed, Nov 17, 2021 at 05:58:43PM +0000, Peter Robinson wrote:
What else is there that people care about in Fedora that's only
i686?
It's not a big deal, but we're using gcc -m32 as a convenient way to
check that various packages still build on 32-bit (as part of CI).
The aim is to catch 32/64-bit assumptions in C code. Example
regression found recently:
https://gitlab.com/nbdkit/nbdkit/-/commit/fe6538aafe5f8d6fc6b90ae8f6d3686...
As 32-bit becomes less and less relevant the problem will naturally
solve itself, so I'm not greatly worried by this, but it might be nice
to keep smaller, pure C libraries building.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
2:27 p.m.
On 16. 11. 21 20:47, Fabio Valentini wrote:
Hi everybody,
The announcement of the Change proposal to drop armv7 support with F37
has reminded me of something that I wanted to ask about some time ago:
How we could work towards reducing the number of packages we build for
i686.
Our current approach, which is to "build everything but ship almost
nothing" - just to keep x86_64 / i686 multilib working - is, frankly,
very wasteful of computing and storage resources, as well as a burden
on maintainers of big packages, which frequently run up against limits
of 32-bit architectures.
I think it should be possible to figure out a way to limit the number
of packages that need to be built for the common multilib usecases
(Wine + Steam ... am I forgetting something?), and just ... not build
anything else for i686.
Have you seen this discussion?
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
This would probably involve the following steps:
1. determine the packages that need to be built on i686 for common
multilib scenarios
2. determine recursive install-time and build-time dependencies of
those packages
3. if necessary, update this list with any new build-or install-time
dependencies that are added to the package set
As for how to implement this, I'm not sure about the details yet
(which is why I'm sending this as an RFC and not filing a Change
proposal yet).
See for example my idea for implementation:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
However, I am not sure it is worth the trouble.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
2:40 p.m.
On Tue, Nov 16, 2021 at 9:27 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 16. 11. 21 20:47, Fabio Valentini wrote:
> Hi everybody,
>
> The announcement of the Change proposal to drop armv7 support with F37
> has reminded me of something that I wanted to ask about some time ago:
> How we could work towards reducing the number of packages we build for
> i686.
>
> Our current approach, which is to "build everything but ship almost
> nothing" - just to keep x86_64 / i686 multilib working - is, frankly,
> very wasteful of computing and storage resources, as well as a burden
> on maintainers of big packages, which frequently run up against limits
> of 32-bit architectures.
>
> I think it should be possible to figure out a way to limit the number
> of packages that need to be built for the common multilib usecases
> (Wine + Steam ... am I forgetting something?), and just ... not build
> anything else for i686.
Have you seen this discussion?
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
> This would probably involve the following steps:
>
> 1. determine the packages that need to be built on i686 for common
> multilib scenarios
> 2. determine recursive install-time and build-time dependencies of
> those packages
> 3. if necessary, update this list with any new build-or install-time
> dependencies that are added to the package set
>
> As for how to implement this, I'm not sure about the details yet
> (which is why I'm sending this as an RFC and not filing a Change
> proposal yet).
See for example my idea for implementation:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
However, I am not sure it is worth the trouble.
Yes, I remember that thread, but I thought it was started longer than
just two months ago ... time flies :|
The steps you outlined in your linked message mostly align with what I
was thinking of, as well. However, I don't think that we should just
keep *all* multilib packages, as most of them aren't needed or used at
all.
I already have a script lying around for resolving dependency trees
across both build- and runtime requires, so I could reuse them for the
purpose of determining the initial "minimal i686 core", considering
which packages get pulled in by, for example, wine + steam. I can
compute that list of packages, if it would help for the discussion.
As for "So it goes back to -- is it worth to burn people-energy on
this when we can just burn machine-energy?", I'd say, it's worth it,
considering that I myself am already head-butting my desk frequently
because of i686 build issues, so I'd consider this a worthwhile effort
indeed, especially since this problem isn't going away anytime soon
(and is probably only going to get worse). I'd even volunteer to
maintain that list and help with bootstrapping new i686 dependencies
...
Fabio
2:07 a.m.
On 16/11/2021 20:47, Fabio Valentini wrote:
Our current approach, which is to "build everything but ship
almost
nothing" - just to keep x86_64 / i686 multilib working - is, frankly,
very wasteful of computing and storage resources, as well as a burden
on maintainers of big packages, which frequently run up against limits
of 32-bit architectures.
+1. It's time to retire all 32-bit architectures.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
6:14 a.m.
Hi,
another subject that can be related
In thread "I think we should stop building i686 packages we're not
shipping" we are alerted for builds for i686 that aren't publish .
Following the tip , I found some packages that we aren't shipped are
needed to allow mock start the buildroot for example tar-1.34-
2.fc35.i686.rpm, tar is only available on koji local repo (1).
I think we should have all i686 packages, that are needed to start a
buildrooot, published. i.e. available on x86_64 repos. To allow mock
build i686 packages without need to access to internal koji local repo
(which may not be public) .
But for packages that aren't shipped , I agree not build for i686, we
already got the concept of multilib package and only multilib packages
should be build for i686 , I think.
(1)
https://kojipkgs.fedoraproject.org/repos/f35-build/latest/i386/pkglist
On Tue, 2021-11-16 at 20:47 +0100, Fabio Valentini wrote:
Hi everybody,
The announcement of the Change proposal to drop armv7 support with F37
has reminded me of something that I wanted to ask about some time ago:
How we could work towards reducing the number of packages we build for
i686.
Our current approach, which is to "build everything but ship almost
nothing" - just to keep x86_64 / i686 multilib working - is, frankly,
very wasteful of computing and storage resources, as well as a burden
on maintainers of big packages, which frequently run up against limits
of 32-bit architectures.
I think it should be possible to figure out a way to limit the number
of packages that need to be built for the common multilib usecases
(Wine + Steam ... am I forgetting something?), and just ... not build
anything else for i686.
This would probably involve the following steps:
1. determine the packages that need to be built on i686 for common
multilib scenarios
2. determine recursive install-time and build-time dependencies of
those packages
3. if necessary, update this list with any new build-or install-time
dependencies that are added to the package set
As for how to implement this, I'm not sure about the details yet
(which is why I'm sending this as an RFC and not filing a Change
proposal yet).
Since it's not practical to modify almost all Fedora packages to add
"ExcludeArch: %{ix86}" to them, we'd probably need a different
machanism for this. I have a vague idea:
- include the list of packages to be built ... somewhere (maybe in the
default buildroot?)
- if a package name matches a list entry, build it on i686. if it
doesn't, then don't.
As for the second step, I'm not sure how to do that yet - does
injecting ExcludeArch headers at SRPM build time in koji work, maybe
with some RPM macro that's included in every package anyway? Or could
we somehow influence the chroots that builds in koji are launched for?
Then the spec or SRPM wouldn't even have to be modified.
As I said, I'm not sure about the details yet, but we should be able
to figure out a way to do this, and make building Fedora packages less
wasteful. Consider this my "request for comments". :)
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
--
Sérgio M. B.
9:27 a.m.
On Thu, Nov 18, 2021 at 1:14 PM Sérgio Basto <sergio(a)serjux.com> wrote:
Hi,
another subject that can be related
In thread "I think we should stop building i686 packages we're not
shipping" we are alerted for builds for i686 that aren't publish .
Following the tip , I found some packages that we aren't shipped are
needed to allow mock start the buildroot for example tar-1.34-
2.fc35.i686.rpm, tar is only available on koji local repo (1).
I think we should have all i686 packages, that are needed to start a
buildrooot, published. i.e. available on x86_64 repos. To allow mock
build i686 packages without need to access to internal koji local repo
(which may not be public) .
This would break all sorts of things.
It's also not compatible with the current packaging guidelines,
because packages must not conflict with each other unless they have an
explicit Conflicts tag and a good reason to do so. in this case,
tar.x86_64 and tar.i686 would conflict with each other (both providing
/usr/bin/tar, among other files), so that's out of the question.
That's exactly the reason why complex heuristics are applied to which
i686 packages are allowed into the x86_64 repositories as "multilib"
packages.
But for packages that aren't shipped , I agree not build for
i686, we
already got the concept of multilib package and only multilib packages
should be build for i686 , I think.
Fabio
10:02 a.m.
On Thu, 2021-11-18 at 16:27 +0100, Fabio Valentini wrote:
On Thu, Nov 18, 2021 at 1:14 PM Sérgio Basto
<sergio(a)serjux.com>
wrote:
>
> Hi,
> another subject that can be related
>
> In thread "I think we should stop building i686 packages we're not
> shipping" we are alerted for builds for i686 that aren't publish .
> Following the tip , I found some packages that we aren't shipped
> are
> needed to allow mock start the buildroot for example tar-1.34-
> 2.fc35.i686.rpm, tar is only available on koji local repo (1).
>
> I think we should have all i686 packages, that are needed to start
> a
> buildrooot, published. i.e. available on x86_64 repos. To allow
> mock
> build i686 packages without need to access to internal koji local
> repo
> (which may not be public) .
This would break all sorts of things.
It's also not compatible with the current packaging guidelines,
because packages must not conflict with each other unless they have
an
explicit Conflicts tag and a good reason to do so. in this case,
tar.x86_64 and tar.i686 would conflict with each other (both
providing
/usr/bin/tar, among other files), so that's out of the question.
no it want , we just can't install tar.i686 and tar.x86_64
and `dnf install tar` just install tar.x86_64
That's exactly the reason why complex heuristics are applied to
which
i686 packages are allowed into the x86_64 repositories as "multilib"
packages.
> But for packages that aren't shipped , I agree not build for i686,
> we
> already got the concept of multilib package and only multilib
> packages
> should be build for i686 , I think.
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
--
Sérgio M. B.
12:32 p.m.
Hi,
On 11/18/21 16:27, Fabio Valentini wrote:
On Thu, Nov 18, 2021 at 1:14 PM Sérgio Basto
<sergio(a)serjux.com> wrote:
>
> Hi,
> another subject that can be related
>
> In thread "I think we should stop building i686 packages we're not
> shipping" we are alerted for builds for i686 that aren't publish .
> Following the tip , I found some packages that we aren't shipped are
> needed to allow mock start the buildroot for example tar-1.34-
> 2.fc35.i686.rpm, tar is only available on koji local repo (1).
>
> I think we should have all i686 packages, that are needed to start a
> buildrooot, published. i.e. available on x86_64 repos. To allow mock
> build i686 packages without need to access to internal koji local repo
> (which may not be public) .
This would break all sorts of things.
It's also not compatible with the current packaging guidelines,
because packages must not conflict with each other unless they have an
explicit Conflicts tag and a good reason to do so. in this case,
tar.x86_64 and tar.i686 would conflict with each other (both providing
/usr/bin/tar, among other files)
Ah, I see it has been so long ago since we made the switch that
some people no longer know the intricate details of how multilib
works :) Elf binaries are treated specially by rpm and are what
rpm calls colored IIRC. Not sure why it is called that, but the way
it works is that you can install both an i686 and x86_64 /usr/bin/tar
file with rpm and if you install i686 first then it will get replaced
with the x86_64 binary when you install that and if you install x86_64
first then that binary will stay in place (*).
This is done so that some package containing mainly a few .so.x libs
but also some small utils can be installed in multi-lib form without
need to split out the /usr/bin/utils into a separate package.
so that's out of the question.
Not necessarily, note some files under e.g. /usr/share could still
conflict, but typically they do not.
Regards,
Hans
*) And I must admit I have no idea what happens if you remove the
x86_64 pkg while you still have the i686 pkg installed, maybe an
error ?
7:43 a.m.
On Thu, 2021-11-18 at 16:27 +0100, Fabio Valentini wrote:
On Thu, Nov 18, 2021 at 1:14 PM Sérgio Basto
<sergio(a)serjux.com> wrote:
>
> Hi,
> another subject that can be related
>
> In thread "I think we should stop building i686 packages we're not
> shipping" we are alerted for builds for i686 that aren't publish .
> Following the tip , I found some packages that we aren't shipped are
> needed to allow mock start the buildroot for example tar-1.34-
> 2.fc35.i686.rpm, tar is only available on koji local repo (1).
>
> I think we should have all i686 packages, that are needed to start a
> buildrooot, published. i.e. available on x86_64 repos. To allow mock
> build i686 packages without need to access to internal koji local
> repo
> (which may not be public) .
This would break all sorts of things.
It's also not compatible with the current packaging guidelines,
because packages must not conflict with each other unless they have an
explicit Conflicts tag and a good reason to do so. in this case,
tar.x86_64 and tar.i686 would conflict with each other (both providing
/usr/bin/tar, among other files), so that's out of the question.
That's exactly the reason why complex heuristics are applied to which
i686 packages are allowed into the x86_64 repositories as "multilib"
packages.
I think that is the way, only multilib package should build for i686 ,
and all packages that we need to start a build (buildroot) should be
multilib .
As is it done on RPMFusion, multilib packages have a special koji
target that is set on rfpkg [1] and maybe this need to be set on a
configuration file somewhere , I'd like that you give me suggestions,
thank you.
[1]
https://github.com/rpmfusion-infra/rfpkg/blob/master/rfpkg/__init__.py#L194
> But for packages that aren't shipped , I agree not build for
i686, we
> already got the concept of multilib package and only multilib
> packages
> should be build for i686 , I think.
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
--
Sérgio M. B.
886
days inactive
892
days old
33 comments
20 participants
participants (20)
-
Ahmed Almeleh -
Dominik 'Rathann' Mierzejewski -
Fabio Valentini -
Hans de Goede -
Jason L Tibbitts III -
Josh Stone -
Kevin Fenzi -
Maxwell G (＠gotmax23) -
Miro Hrončok -
Miroslav Suchý -
Neal Gompa -
Nicolas Chauvet -
Nikolay Nikolov -
Peter Robinson -
Richard W.M. Jones -
Robbie Harwood -
Sérgio Basto -
Vitaly Zaitsev -
Zbigniew Jędrzejewski-Szmek -
Zebediah Figura