2:21 p.m.
https://fedoraproject.org/wiki/Changes/Noi686Repositories
(Ben is on vacation, so I announcing this on his behalf.)
== Summary ==
Stop producing and distributing the Modular and Everything i686 repositories.
== Owner ==
* Name: Kevin Fenzi
* Email: kevin(a)scrye.com
== Current status ==
* Targeted release: [[Releases/31| Fedora 31 ]]
* Last updated: <!-- this is an automatic macro — you don't need to change this
line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
* Tracker bug: <will be assigned by the Wrangler>
* Release notes tracker: <will be assigned by the Wrangler>
== Detailed Description ==
With the dropping of the i686 kernel package it's no longer possible to directly
install Fedora 31 or later on i686 hardware, however, it is still possibly to
upgrade older releases as long as we continue to provide a repository. This will
leave those users with an old possibly vulnerable kernel installed.
The only other use/need for the repostories is to allow maintainers to debug and
test fixes for multilib shipped packages, but the koji buildroot repo can be
used for this use case.
== Benefit to Fedora ==
* users won't try and upgrade old i686 installs with insecure kernels.
* compose times will be decreased (no more gathering i686 packages up and
running createrepo on them).
* Updates push times will be reduced.
* disk size on mirrors will be reduced.
== Scope ==
* Proposal owners:
** modify pungi-fedora to no longer produce i386 repo for Everything and
Modular, modify bodhi config for f31+ to not make i386 repos for
updates/updates-testing.
** modify mock to use the koji buildroot for i686 for f31+ for those few users
that need to build i686 packages locally.
* Other developers: n/a
* Release engineering: [https://pagure.io/releng/issues 8529]
== Upgrade/compatibility impact ==
i686 users will not be able to upgrade, and will have to move to another
supported arch.
== How To Test ==
* Confirm that there are no trees under
https://dl.fedoraproject.org/pub/fedora-secondary/development/rawhide/Eve...
or
https://dl.fedoraproject.org/pub/fedora-secondary/development/rawhide/Mod...
* Confirm that there are no trees under
https://dl.fedoraproject.org/pub/fedora-secondary/updates/31/{Everything|...
or
https://dl.fedoraproject.org/pub/fedora-secondary/updates/testing/31/{Eve...
* Confirm that mock can init a chroot for fedora-i386-31 using the koji
buildroot repository.
== User Experience ==
* Users will get updates and rawhide and rc composes faster.
* Users will not be able to upgrade to a insecure Fedora configuration.
== Contingency Plan ==
i686 trees will just continue to be composed and published. Users can upgrade to
them (with an old kernel from f30).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3:15 p.m.
On Sun, Jul 14, 2019 at 4:10 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
https://fedoraproject.org/wiki/Changes/Noi686Repositories
(Ben is on vacation, so I announcing this on his behalf.)
== Summary ==
Stop producing and distributing the Modular and Everything i686 repositories.
== Owner ==
* Name: Kevin Fenzi
* Email: kevin(a)scrye.com
== Current status ==
* Targeted release: [[Releases/31| Fedora 31 ]]
* Last updated: <!-- this is an automatic macro — you don't need to change this
line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}
* Tracker bug: <will be assigned by the Wrangler>
* Release notes tracker: <will be assigned by the Wrangler>
== Detailed Description ==
With the dropping of the i686 kernel package it's no longer possible to directly
install Fedora 31 or later on i686 hardware, however, it is still possibly to
upgrade older releases as long as we continue to provide a repository. This will
leave those users with an old possibly vulnerable kernel installed.
The only other use/need for the repostories is to allow maintainers to debug and
test fixes for multilib shipped packages, but the koji buildroot repo can be
used for this use case.
== Benefit to Fedora ==
* users won't try and upgrade old i686 installs with insecure kernels.
* compose times will be decreased (no more gathering i686 packages up and
running createrepo on them).
* Updates push times will be reduced.
* disk size on mirrors will be reduced.
== Scope ==
* Proposal owners:
** modify pungi-fedora to no longer produce i386 repo for Everything and
Modular, modify bodhi config for f31+ to not make i386 repos for
updates/updates-testing.
** modify mock to use the koji buildroot for i686 for f31+ for those few users
that need to build i686 packages locally.
* Other developers: n/a
* Release engineering: [https://pagure.io/releng/issues 8529]
== Upgrade/compatibility impact ==
i686 users will not be able to upgrade, and will have to move to another
supported arch.
This will also make it impossible for people to locally do multilib
build/installs. It will remove COPR’s ability to do the same. For that
reason alone, I don’t particularly want this change to happen.
--
真実はいつも一つ！/ Always, there's only one truth!
3:32 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 7/14/19 1:15 PM, Neal Gompa wrote:
This will also make it impossible for people to locally do multilib
build/installs. It will remove COPR’s ability to do the same. For that
reason alone, I don’t particularly want this change to happen.
Can you expand on what you mean by 'locally do' ?
Current multilib packages will still be available in the x86_64 repo.
Users can still install them from there just fine.
If a user wants to locally build a i686 package, they can use mock
against the koji i686 buildroot repo to do so. They could then put that
package in a local repo with x86_64 packages and run createrepo on it.
It's true there would be no easily mirrored i386 for them to copy to
aviod the internet, but is that really a big use case?
Finally, if you would prefer this not happen now, is there a time when
you would further down the road? Whats the critera/goalpost/cutoff?
kevin
4:27 p.m.
On Sun, Jul 14, 2019 at 5:21 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
On 7/14/19 1:15 PM, Neal Gompa wrote:
> This will also make it impossible for people to locally do multilib
> build/installs. It will remove COPR’s ability to do the same. For that
> reason alone, I don’t particularly want this change to happen.
Can you expand on what you mean by 'locally do' ?
Current multilib packages will still be available in the x86_64 repo.
Users can still install them from there just fine.
If a user wants to locally build a i686 package, they can use mock
against the koji i686 buildroot repo to do so. They could then put that
package in a local repo with x86_64 packages and run createrepo on it.
It's true there would be no easily mirrored i386 for them to copy to
aviod the internet, but is that really a big use case?
Finally, if you would prefer this not happen now, is there a time when
you would further down the road? Whats the critera/goalpost/cutoff?
Building library packages and making your own multilib repo is
impossible without having both the i686 repo and the x86_64 repo, as
you need to build for both and then munge them together for a multilib
repo.
Historically, we really haven’t wanted people to pull from the Koji
repo, and we probably still don’t want to do that, since it’s not
mirrored and stressing it could cause more problems our already
overtaxed build system environment.
From my point of view, I don’t think it’s worth getting rid of the
32-bit x86 repo until we’re at the point where people would not need
to build their own multilib repositories. The cost of generating that
for mirroring isn’t that high relative to the amount of pain we’ll
cause for external folks trying to build off Fedora.
Think, for example, the repo that shall not be named. That project’s
Koji instance pulls in Fedora through the mirrored content as an
external source, which feeds its ability to do multilib builds.
I’m sorry, but I don’t see us getting rid of this for the foreseeable
future without breaking virtually all of our downstreams.
--
真実はいつも一つ！/ Always, there's only one truth!
5:36 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 7/14/19 2:27 PM, Neal Gompa wrote:
Building library packages and making your own multilib repo is
impossible without having both the i686 repo and the x86_64 repo, as
you need to build for both and then munge them together for a multilib
repo.
Sure. Do many people do that anymore?
Historically, we really haven’t wanted people to pull from the Koji
repo, and we probably still don’t want to do that, since it’s not
mirrored and stressing it could cause more problems our already
overtaxed build system environment.
I contend that the number of people who would want to do this is
miniscule and in the noise.
No one (sane) would start a 32bit app these days, so likely it's legacy
support. The cases I know of are steam and wine. I am sure there's 3rd
party items beyond that, but even rhel6 is going to go away soon, so
these folks are going to have to come up with some solution really soon.
>From my point of view, I don’t think it’s worth getting rid of
the
32-bit x86 repo until we’re at the point where people would not need
to build their own multilib repositories. The cost of generating that
for mirroring isn’t that high relative to the amount of pain we’ll
cause for external folks trying to build off Fedora.
Fair enough. I see it as already at the time when there are very few of
thoese people and we can keep them going for a while by asking them to
use the koji buildroot repo.
Think, for example, the repo that shall not be named. That project’s
Koji instance pulls in Fedora through the mirrored content as an
external source, which feeds its ability to do multilib builds.
Sure, they can repoint that to koji buildroot and keep going.
I’m sorry, but I don’t see us getting rid of this for the
foreseeable
future without breaking virtually all of our downstreams.
Those few that need to be 32bit applications still. I really don't think
this is "all of our downstreams".
kevin
2:17 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
Hello, Neal Gompa.
Sun, 14 Jul 2019 17:27:03 -0400 you wrote:
Building library packages and making your own multilib repo is
impossible without having both the i686 repo and the x86_64 repo, as
you need to build for both and then munge them together for a multilib
repo.
Most of Fedora users and developers don't need doing that. And if so,
you can build your package in Koji (scratch build), or use mock i686
config (it will include i686 Koji repositories).
Historically, we really haven’t wanted people to pull from the Koji
repo, and we probably still don’t want to do that, since it’s not
mirrored and stressing it could cause more problems our already
overtaxed build system environment.
I think the number of such users will be very few.
We should get rid of all 32-bit packages (excluding needed by Steam or
Wine32) ASAP.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
2:35 a.m.
It would be much clearer and user-friendly to move I*86 packages out of the 64 bit repos
and make the i*86 an optional add-on
Le July 14, 2019 9:27:03 PM UTC, Neal Gompa <ngompa13(a)gmail.com> a écrit :
On Sun, Jul 14, 2019 at 5:21 PM Kevin Fenzi <kevin(a)scrye.com>
wrote:
>
> On 7/14/19 1:15 PM, Neal Gompa wrote:
>
> > This will also make it impossible for people to locally do multilib
> > build/installs. It will remove COPR’s ability to do the same. For
that
> > reason alone, I don’t particularly want this change to happen.
>
> Can you expand on what you mean by 'locally do' ?
>
> Current multilib packages will still be available in the x86_64 repo.
> Users can still install them from there just fine.
>
> If a user wants to locally build a i686 package, they can use mock
> against the koji i686 buildroot repo to do so. They could then put
that
> package in a local repo with x86_64 packages and run createrepo on
it.
>
> It's true there would be no easily mirrored i386 for them to copy to
> aviod the internet, but is that really a big use case?
>
> Finally, if you would prefer this not happen now, is there a time
when
> you would further down the road? Whats the critera/goalpost/cutoff?
>
Building library packages and making your own multilib repo is
impossible without having both the i686 repo and the x86_64 repo, as
you need to build for both and then munge them together for a multilib
repo.
Historically, we really haven’t wanted people to pull from the Koji
repo, and we probably still don’t want to do that, since it’s not
mirrored and stressing it could cause more problems our already
overtaxed build system environment.
From my point of view, I don’t think it’s worth getting rid of the
32-bit x86 repo until we’re at the point where people would not need
to build their own multilib repositories. The cost of generating that
for mirroring isn’t that high relative to the amount of pain we’ll
cause for external folks trying to build off Fedora.
Think, for example, the repo that shall not be named. That project’s
Koji instance pulls in Fedora through the mirrored content as an
external source, which feeds its ability to do multilib builds.
I’m sorry, but I don’t see us getting rid of this for the foreseeable
future without breaking virtually all of our downstreams.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
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
--
Nicolas Mailhot
2:38 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
Hello, Nicolas Mailhot via devel.
Mon, 15 Jul 2019 07:35:09 +0000 you wrote:
It would be much clearer and user-friendly to move I*86 packages out
of the 64 bit repos and make the i*86 an optional add-on
It will break multilib.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
5:34 p.m.
Nicolas Mailhot via devel wrote:
It would be much clearer and user-friendly to move I*86 packages out
of
the 64 bit repos and make the i*86 an optional add-on
+1 to that suggestion.
Vitaly Zaitsev via devel replied:
It will break multilib.
Not really. It would break the legacy "install all packages as multilib if
available" mode, which has not been the default modus operandi of YUM for
years now. Does DNF even support this mode? (That mode would break because
the depsolver would attempt multilibbing all packages including ones which
are not intended to be multilib and hence contain multilib conflicts.) But
the default "install only the multilibs that are actually required by some
32-bit-only package" mode should work just fine with that setup (and IMHO,
that is the only multilib mode that makes sense anyway).
And it would remove the overhead of fetching the metadata for all those
multilib packages for all those users running pure 64-bit systems. (It would
increase the total metadata for the multilib users though, unless the
repository contains only multilib packages, in which case it would be
useless to build packages against, including those multilib packages
themselves.)
Kevin Kofler
7:20 p.m.
On Mon, Jul 15, 2019 at 7:22 PM Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Nicolas Mailhot via devel wrote:
> It would be much clearer and user-friendly to move I*86 packages out of
> the 64 bit repos and make the i*86 an optional add-on
+1 to that suggestion.
Vitaly Zaitsev via devel replied:
> It will break multilib.
Not really. It would break the legacy "install all packages as multilib if
available" mode, which has not been the default modus operandi of YUM for
years now. Does DNF even support this mode? (That mode would break because
the depsolver would attempt multilibbing all packages including ones which
are not intended to be multilib and hence contain multilib conflicts.) But
the default "install only the multilibs that are actually required by some
32-bit-only package" mode should work just fine with that setup (and IMHO,
that is the only multilib mode that makes sense anyway).
This is definitely supported, as this is how multilib works on Mageia
and OpenMandriva today, both of which use DNF too.
--
真実はいつも一つ！/ Always, there's only one truth!
4:45 a.m.
Neal Gompa wrote:
On Mon, Jul 15, 2019 at 7:22 PM Kevin Kofler wrote:
> Not really. It would break the legacy "install all packages as multilib
> if available" mode, which has not been the default modus operandi of YUM
> for years now. Does DNF even support this mode? (That mode would break
> because the depsolver would attempt multilibbing all packages including
> ones which are not intended to be multilib and hence contain multilib
> conflicts.) But the default "install only the multilibs that are actually
> required by some 32-bit-only package" mode should work just fine with
> that setup (and IMHO, that is the only multilib mode that makes sense
> anyway).
This is definitely supported, as this is how multilib works on Mageia
and OpenMandriva today, both of which use DNF too.
But that doesn't mean Fedora has to continue supporting the broken mode. ;-)
Why would you want to install all libraries as multilib even if nothing 32-
bit uses them? It's just a huge waste of bandwidth and disk space.
Kevin Kofler
1:09 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 7/15/19 12:35 AM, Nicolas Mailhot via devel wrote:
It would be much clearer and user-friendly to move I*86 packages out
of the 64 bit repos and make the i*86 an optional add-on
Well, the problem there would be that many folks wouldn't know to enable
that seperate repo for multilib, so perhaps it would need a dnf plugin?
also, you would need pungi changes in order to put the multilib i686
packages in a seperate repo instead of the x86_64 one. That might not be
too hard tho.
In the end tho, not sure what that gets us... I guess slightly smaller
metadata, but thats not that big a win.
kevin
8:30 a.m.
On Sun, 14 Jul 2019 at 18:16, Neal Gompa <ngompa13(a)gmail.com> wrote:
On Sun, Jul 14, 2019 at 5:21 PM Kevin Fenzi <kevin(a)scrye.com>
wrote:
>
> On 7/14/19 1:15 PM, Neal Gompa wrote:
>
> > This will also make it impossible for people to locally do multilib
> > build/installs. It will remove COPR’s ability to do the same. For that
> > reason alone, I don’t particularly want this change to happen.
>
> Can you expand on what you mean by 'locally do' ?
>
> Current multilib packages will still be available in the x86_64 repo.
> Users can still install them from there just fine.
>
> If a user wants to locally build a i686 package, they can use mock
> against the koji i686 buildroot repo to do so. They could then put that
> package in a local repo with x86_64 packages and run createrepo on it.
>
> It's true there would be no easily mirrored i386 for them to copy to
> aviod the internet, but is that really a big use case?
>
> Finally, if you would prefer this not happen now, is there a time when
> you would further down the road? Whats the critera/goalpost/cutoff?
>
Building library packages and making your own multilib repo is
impossible without having both the i686 repo and the x86_64 repo, as
you need to build for both and then munge them together for a multilib
repo.
Historically, we really haven’t wanted people to pull from the Koji
repo, and we probably still don’t want to do that, since it’s not
mirrored and stressing it could cause more problems our already
overtaxed build system environment.
From my point of view, I don’t think it’s worth getting rid of the
32-bit x86 repo until we’re at the point where people would not need
to build their own multilib repositories. The cost of generating that
for mirroring isn’t that high relative to the amount of pain we’ll
cause for external folks trying to build off Fedora.
Think, for example, the repo that shall not be named. That project’s
Koji instance pulls in Fedora through the mirrored content as an
external source, which feeds its ability to do multilib builds.
I’m sorry, but I don’t see us getting rid of this for the foreseeable
future without breaking virtually all of our downstreams.
The problem is:
1. We currently have no idea of who these downstreams are
2. We have no idea of what they want? [Do they need every package.. do they
need just N packages?]
The turn around of this argument is that we can never allow ANY
change/update in our infrastructure or to any package because it would
break some downstream sometime. And yet we do allow updates to gcc/kernel
as it is built into what we do.. aka we have decided already there is a
cut-off where people are going to be 'broken/left behind' for some reason
all the time. The expectation is that sometimes we will lose them
permanently but a lot of time they will catch up or get ahead of us.
We do stop some changes because we have a way to get a feeling that the
number of people affected by the change are too many to deal with. But we
have to have a way to measure what that is.. even if it is a back of the
envelope. How can we get an idea on these?
Because if we are going to start down the 'we can't change something
because it could break some unknown sized group' ... it will quickly morph
into Fedora 31 being our last release because we have enough rules lawyers
in Fedora to keep any and every update from happening because it could
break someone. 'Sorry you can't push that CVE, it breaks my hacking group
which uses these to break into systems.' will become the releng or fesco
ticket of the hour.
That said, I think the problem with this change is that everyone's mental
image of this change is different. From various other threads.. people have
different ideas of what multi-lib does, what it provides, who uses it, how
does it get built, what is required to build it, and what does an x86_64
user get of i686 packages.
--
Stephen J Smoogen.
4:35 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
Kevin Fenzi wrote:
Neal Gompa wrote:
[[snip]]
> This will also make it impossible for people to locally do
multilib
> build/installs. It will remove COPR’s ability to do the same. For that
> reason alone, I don’t particularly want this change to happen.
Can you expand on what you mean by 'locally do' ?
I want to run "gcc -m32 -o my_app-i686 *.o ..." locally on my own box
to build executables that run as 32-bit apps on multilib x86_64.
For some apps 2GB of malloc() arena is plenty, and they run faster
in 32-bit mode because a 64-byte cache line contains 16 pointers
instead of only 8.
[[snip]]
Finally, if you would prefer this not happen now, is there a time
when
you would further down the road? Whats the critera/goalpost/cutoff?
One year after Red Hat Enterprise Linux version 7 reaches end-of-support.
It would be handy for Fedora to have 32-bit *-devel packages until then.
5:50 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 7/14/19 2:35 PM, John Reiser wrote:
Kevin Fenzi wrote:
> Neal Gompa wrote:
[[snip]]
>> This will also make it impossible for people to locally do multilib
>> build/installs. It will remove COPR’s ability to do the same. For that
>> reason alone, I don’t particularly want this change to happen.
> Can you expand on what you mean by 'locally do' ?
I want to run "gcc -m32 -o my_app-i686 *.o ..." locally on my own box
to build executables that run as 32-bit apps on multilib x86_64.
For some apps 2GB of malloc() arena is plenty, and they run faster
in 32-bit mode because a 64-byte cache line contains 16 pointers
instead of only 8.
This should still work, unless there are libraries you use that are not
multilib.
[[snip]]
> Finally, if you would prefer this not happen now, is there a time when
> you would further down the road? Whats the critera/goalpost/cutoff?
One year after Red Hat Enterprise Linux version 7 reaches end-of-support.
It would be handy for Fedora to have 32-bit *-devel packages until then.
We will still have 32bit devel packages in the x86_64 repos after this
change. It doesn't affect multilib at all. It only stops building and
publishing the 'pure' i386 repos on the mirror network.
I don't think we can drop multilib until at least steam/wine are ready
for it at least.
kevin
1:59 a.m.
I don't think we can drop multilib until at least steam/wine are
ready
for it at least.
Will they ever be though? Thanks to Wine I can run an open source
game that cannot move to 64bit support because it's dragging binaries
for which it doesn't have source code. I reverse-engineered one of the
DLLs myself and helped them get closer to their goal, and it took
months, but I still don't know when the authors will finally manage
the transition without sacrificing features.
I can't imagine how someone would deal with 32bit Wine support going
away for a completely closed source game or application for which they
may have purchased a license years ago that will only run on Wine or
Windows. I'm certainly not opting for the latter...
Dridi
2:10 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
Hello, Dridi Boukelmoune.
Mon, 15 Jul 2019 06:59:33 +0000 you wrote:
game that cannot move to 64bit support because it's dragging
binaries
for which it doesn't have source code.
Wine64 can still emulate 32-bit WinPE executables.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
2:22 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 7/15/19 9:10 AM, Vitaly Zaitsev via devel wrote:
Hello, Dridi Boukelmoune.
Mon, 15 Jul 2019 06:59:33 +0000 you wrote:
> game that cannot move to 64bit support because it's dragging binaries
> for which it doesn't have source code.
Wine64 can still emulate 32-bit WinPE executables.
That is not enough. See what hapened to Ubuntu once they dropped i686
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
_______________________________________________
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
--
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek(a)redhat.com M: +420775390109
2:30 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
Hello, Jiri Vanek.
Mon, 15 Jul 2019 09:22:57 +0200 you wrote:
That is not enough. See what hapened to Ubuntu once they dropped i686
They decided to remove whole 32-bit support, including multilib support.
We need to drop 32-bit packages, except needed to run Steam and Wine32.
Third-party developers like Valve should start building native 64-bit
executables and stop using vulnerable ancient architectures.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
3:26 a.m.
On Mon, Jul 15, 2019 at 7:58 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
Hello, Dridi Boukelmoune.
Mon, 15 Jul 2019 06:59:33 +0000 you wrote:
> game that cannot move to 64bit support because it's dragging binaries
> for which it doesn't have source code.
Wine64 can still emulate 32-bit WinPE executables.
Emulate as in not run natively even though the hardware might be able to?
Thanks for the tip anyway, it might be worth giving a try.
Dridi
4:34 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
Hello, Dridi Boukelmoune.
Mon, 15 Jul 2019 08:26:59 +0000 you wrote:
Emulate as in not run natively even though the hardware might be able
to?
Sorry for misinformation. Wine64 is still require 32-bit libraries in
order to run legacy 32-bit Windows PE executables.
https://wiki.winehq.org/FAQ#Is_there_a_64_bit_Wine.3F
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
4:57 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 7/15/19 11:34 AM, Vitaly Zaitsev via devel wrote:
Hello, Dridi Boukelmoune.
Mon, 15 Jul 2019 08:26:59 +0000 you wrote:
> Emulate as in not run natively even though the hardware might be able to?
Sorry for misinformation. Wine64 is still require 32-bit libraries in
order to run legacy 32-bit Windows PE executables.
https://wiki.winehq.org/FAQ#Is_there_a_64_bit_Wine.3F
Exactly. I really do not understand this rush change. The original change, to remove only
32 kernel
is definitely the way to go. But This one, should be postponded to f32, with much better
contingency
plan.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
_______________________________________________
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
--
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek(a)redhat.com M: +420775390109
6:33 a.m.
On Mon, Jul 15, 2019 at 11:58 AM Jiri Vanek <jvanek(a)redhat.com> wrote:
On 7/15/19 11:34 AM, Vitaly Zaitsev via devel wrote:
> Hello, Dridi Boukelmoune.
>
> Mon, 15 Jul 2019 08:26:59 +0000 you wrote:
>
>> Emulate as in not run natively even though the hardware might be able
to?
>
> Sorry for misinformation. Wine64 is still require 32-bit libraries in
> order to run legacy 32-bit Windows PE executables.
>
> https://wiki.winehq.org/FAQ#Is_there_a_64_bit_Wine.3F
Exactly. I really do not understand this rush change. The original change,
to remove only 32 kernel
is definitely the way to go. But This one, should be postponded to f32,
with much better contingency
plan.
>
This proposal has nothing to do with wine/steam. They will continue to work
just fine, multilib will still work as it's mentioned in change proposal.
"multi-lib x86_64 repos will not be affected and all packages will still be
built for i686 for this use case."
All in all, I am +1 for this change. I don't even remember when I needed to
build something 32 bit on 64 bit system locally, and as it stands in the
proposal, it should still be doable.
7:43 a.m.
On Mon, Jul 15, 2019 at 12:45 PM Jiri Vanek <jvanek(a)redhat.com> wrote:
On 7/15/19 11:34 AM, Vitaly Zaitsev via devel wrote:
> Hello, Dridi Boukelmoune.
>
> Mon, 15 Jul 2019 08:26:59 +0000 you wrote:
>
>> Emulate as in not run natively even though the hardware might be able to?
>
> Sorry for misinformation. Wine64 is still require 32-bit libraries in
> order to run legacy 32-bit Windows PE executables.
>
> https://wiki.winehq.org/FAQ#Is_there_a_64_bit_Wine.3F
Exactly. I really do not understand this rush change. The original change, to remove only
32 kernel
is definitely the way to go. But This one, should be postponded to f32, with much better
contingency
plan.
I agree. No longer building kernels and composing bootable images for
i686 is a relatively small change with limited user impact.
But stopping to compose i686 repositories at all, which means adapting
multiple processes (mock, copr, etc.), is throwing out the baby with
the bathwater.
(I for one am still semi-regularly building stuff in the mock
fedora-rawhide-i686 chroots, especially for testing if things still
work on 32bit systems (be it armv7hl or i686) - I know that this will
probably continue to work somehow, but making it more complicated is
hostile to developers and packagers who care about their packages
working on all architectures.)
Fabio
> >
> >
> > --
> > Sincerely,
> > Vitaly Zaitsev (vitaly(a)easycoding.org)
> > _______________________________________________
> > 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
> >
>
>
> --
> Jiri Vanek
> Senior QE engineer, OpenJDK QE lead, Mgr.
> Red Hat Czech
> jvanek(a)redhat.com M: +420775390109
> _______________________________________________
> 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
11:46 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 7/15/19 5:43 AM, Fabio Valentini wrote:
(I for one am still semi-regularly building stuff in the mock
fedora-rawhide-i686 chroots, especially for testing if things still
work on 32bit systems (be it armv7hl or i686) - I know that this will
probably continue to work somehow, but making it more complicated is
hostile to developers and packagers who care about their packages
working on all architectures.)
Well, it wouldn't be more complicated. Mock would just download from a
different repo in that case.
Also, if it's 32bit you are testing, perhaps some cheap armv7 device
would be a better platform moving forward?
kevin
1:04 p.m.
On Mon, Jul 15, 2019, 19:33 Kevin Fenzi <kevin(a)scrye.com> wrote:
On 7/15/19 5:43 AM, Fabio Valentini wrote:
> (I for one am still semi-regularly building stuff in the mock
> fedora-rawhide-i686 chroots, especially for testing if things still
> work on 32bit systems (be it armv7hl or i686) - I know that this will
> probably continue to work somehow, but making it more complicated is
> hostile to developers and packagers who care about their packages
> working on all architectures.)
Well, it wouldn't be more complicated. Mock would just download from a
different repo in that case.
Also, if it's 32bit you are testing, perhaps some cheap armv7 device
would be a better platform moving forward?
kevin
I have a Raspberry Pi 2 Model B somewhere, but the experience of trying to
build some packages on it a while ago was ... testing my patience, let's
say. Maybe a faster SD card would help, but I'm guessing that using
"--forcearch armv7hl" to force qemu emulation in mock on my main PC's
pretty beefy CPU would still be a better experience. Additionally there's
no 32bit arm chroots supported in COPR, which complicates the situation for
32bit support even more.
But that's a bit beside the point I wanted to make. I've been struggling to
keep the Java stack building at all (mostly Stewardship SIG packages), and
the removal of 32bit support in eclipse has made that even more difficult.
Even still, dozens of Java packages either won't build or won't install on
32bit arches because of that (mostly because gradle isn't installable
anymore, because jgit is gone on 32bit). Even the modular Java packages
don't support 32bit arches anymore.
If we start to relegate i686 to a tertiary architecture only intended for
multilib use (which is basically the effect of this proposal), there'll be
even fewer reasons to fix things or keep things working on 32bit. I mean,
I'm already tempted to just start dropping things ... because, well, it's
not like anybody seems to care about those packages anyway.
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
2:06 p.m.
On Mon, 15 Jul 2019 at 14:53, Fabio Valentini <decathorpe(a)gmail.com> wrote:
On Mon, Jul 15, 2019, 19:33 Kevin Fenzi <kevin(a)scrye.com>
wrote:
> On 7/15/19 5:43 AM, Fabio Valentini wrote:
>
> > (I for one am still semi-regularly building stuff in the mock
> > fedora-rawhide-i686 chroots, especially for testing if things still
> > work on 32bit systems (be it armv7hl or i686) - I know that this will
> > probably continue to work somehow, but making it more complicated is
> > hostile to developers and packagers who care about their packages
> > working on all architectures.)
>
> Well, it wouldn't be more complicated. Mock would just download from a
> different repo in that case.
>
> Also, if it's 32bit you are testing, perhaps some cheap armv7 device
> would be a better platform moving forward?
>
> kevin
>
I have a Raspberry Pi 2 Model B somewhere, but the experience of trying to
build some packages on it a while ago was ... testing my patience, let's
say. Maybe a faster SD card would help, but I'm guessing that using
"--forcearch armv7hl" to force qemu emulation in mock on my main PC's
pretty beefy CPU would still be a better experience. Additionally there's
no 32bit arm chroots supported in COPR, which complicates the situation for
32bit support even more.
But that's a bit beside the point I wanted to make. I've been struggling
to keep the Java stack building at all (mostly Stewardship SIG packages),
and the removal of 32bit support in eclipse has made that even more
difficult.
Even still, dozens of Java packages either won't build or won't install on
32bit arches because of that (mostly because gradle isn't installable
anymore, because jgit is gone on 32bit). Even the modular Java packages
don't support 32bit arches anymore.
If we start to relegate i686 to a tertiary architecture only intended for
multilib use (which is basically the effect of this proposal), there'll be
even fewer reasons to fix things or keep things working on 32bit. I mean,
I'm already tempted to just start dropping things ... because, well, it's
not like anybody seems to care about those packages anyway.
The problem is that most upstreams have lost interest in 32 bit anymore so
the only people who are banging the drum on it are the maintainers who seem
to feel they have to keep it going. We are trying to say 'you don't have to
keep it going on an arch if you don't want to.' Anyone who starts
complaining that it is the maintainers job to make 32 bit work for them
needs to take the package over completely. You aren't paid to do this, and
it is meant to be something you enjoy doing. If there is no joy.. then
don't do it.
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
>
_______________________________________________
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
--
Stephen J Smoogen.
2:18 p.m.
On Mon, Jul 15, 2019 at 2:53 PM Fabio Valentini <decathorpe(a)gmail.com> wrote:
On Mon, Jul 15, 2019, 19:33 Kevin Fenzi <kevin(a)scrye.com> wrote:
>
> On 7/15/19 5:43 AM, Fabio Valentini wrote:
>
> > (I for one am still semi-regularly building stuff in the mock
> > fedora-rawhide-i686 chroots, especially for testing if things still
> > work on 32bit systems (be it armv7hl or i686) - I know that this will
> > probably continue to work somehow, but making it more complicated is
> > hostile to developers and packagers who care about their packages
> > working on all architectures.)
>
> Well, it wouldn't be more complicated. Mock would just download from a
> different repo in that case.
>
> Also, if it's 32bit you are testing, perhaps some cheap armv7 device
> would be a better platform moving forward?
>
> kevin
I have a Raspberry Pi 2 Model B somewhere, but the experience of trying to build some
packages on it a while ago was ... testing my patience, let's say. Maybe a faster SD
card would help, but I'm guessing that using "--forcearch armv7hl" to force
qemu emulation in mock on my main PC's pretty beefy CPU would still be a better
experience. Additionally there's no 32bit arm chroots supported in COPR, which
complicates the situation for 32bit support even more.
But that's a bit beside the point I wanted to make. I've been struggling to keep
the Java stack building at all (mostly Stewardship SIG packages), and the removal of 32bit
support in eclipse has made that even more difficult.
Even still, dozens of Java packages either won't build or won't install on 32bit
arches because of that (mostly because gradle isn't installable anymore, because jgit
is gone on 32bit). Even the modular Java packages don't support 32bit arches anymore.
If we start to relegate i686 to a tertiary architecture only intended for multilib use
(which is basically the effect of this proposal), there'll be even fewer reasons to
fix things or keep things working on 32bit. I mean, I'm already tempted to just start
dropping things ... because, well, it's not like anybody seems to care about those
packages anyway.
And honestly, i686 is our only useful 32-bit architecture from a
development standpoint. People can iterate quickly on it, and easily
test it.
It is incredibly difficult to deal with 32-bit only issues if armv7hl
is the only thing we have.
--
真実はいつも一つ！/ Always, there's only one truth!
3:51 p.m.
On Mon, 15 Jul 2019 at 16:07, Neal Gompa <ngompa13(a)gmail.com> wrote:
On Mon, Jul 15, 2019 at 2:53 PM Fabio Valentini
<decathorpe(a)gmail.com>
wrote:
>
> On Mon, Jul 15, 2019, 19:33 Kevin Fenzi <kevin(a)scrye.com> wrote:
>>
>> On 7/15/19 5:43 AM, Fabio Valentini wrote:
>>
>> > (I for one am still semi-regularly building stuff in the mock
>> > fedora-rawhide-i686 chroots, especially for testing if things still
>> > work on 32bit systems (be it armv7hl or i686) - I know that this will
>> > probably continue to work somehow, but making it more complicated is
>> > hostile to developers and packagers who care about their packages
>> > working on all architectures.)
>>
>> Well, it wouldn't be more complicated. Mock would just download from a
>> different repo in that case.
>>
>> Also, if it's 32bit you are testing, perhaps some cheap armv7 device
>> would be a better platform moving forward?
>>
>> kevin
>
>
> I have a Raspberry Pi 2 Model B somewhere, but the experience of trying
to build some packages on it a while ago was ... testing my patience, let's
say. Maybe a faster SD card would help, but I'm guessing that using
"--forcearch armv7hl" to force qemu emulation in mock on my main PC's
pretty beefy CPU would still be a better experience. Additionally there's
no 32bit arm chroots supported in COPR, which complicates the situation for
32bit support even more.
>
> But that's a bit beside the point I wanted to make. I've been struggling
to keep the Java stack building at all (mostly Stewardship SIG packages),
and the removal of 32bit support in eclipse has made that even more
difficult.
>
> Even still, dozens of Java packages either won't build or won't install
on 32bit arches because of that (mostly because gradle isn't installable
anymore, because jgit is gone on 32bit). Even the modular Java packages
don't support 32bit arches anymore.
>
> If we start to relegate i686 to a tertiary architecture only intended
for multilib use (which is basically the effect of this proposal), there'll
be even fewer reasons to fix things or keep things working on 32bit. I
mean, I'm already tempted to just start dropping things ... because, well,
it's not like anybody seems to care about those packages anyway.
>
>
And honestly, i686 is our only useful 32-bit architecture from a
development standpoint. People can iterate quickly on it, and easily
test it.
It is incredibly difficult to deal with 32-bit only issues if armv7hl
is the only thing we have.
OK could all the people who are so interested in i686 get onto the x86_32
mailing list and chime up there about what they are wanting to do? Also
start having regular sig meetings and other things which have been pretty
dead for about a year?
--
Stephen J Smoogen.
8:11 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 7/15/19 1:51 PM, Stephen John Smoogen wrote:
OK could all the people who are so interested in i686 get onto the
x86_32 mailing list and chime up there about what they are wanting to
do? Also start having regular sig meetings and other things which have
been pretty dead for about a year?
My guess is that most users are those using wine or steam and those
users are unlikely to see this. I've heard of a few who still have
32-bit only computers, but those are getting fewer. (e.g. I'm no longer
one of those.)
8:45 a.m.
On Mon, 15 Jul 2019 at 22:00, Samuel Sieb <samuel(a)sieb.net> wrote:
On 7/15/19 1:51 PM, Stephen John Smoogen wrote:
> OK could all the people who are so interested in i686 get onto the
> x86_32 mailing list and chime up there about what they are wanting to
> do? Also start having regular sig meetings and other things which have
> been pretty dead for about a year?
My guess is that most users are those using wine or steam and those
users are unlikely to see this. I've heard of a few who still have
32-bit only computers, but those are getting fewer. (e.g. I'm no longer
one of those.)
I am not looking for users to join this list. I am looking for the
developers who are saying we can't drop x86_32 to go there to help diagnose
and fix things. Currently there is an x86_32 problem with cpio and booting:
https://bugzilla.redhat.com/show_bug.cgi?id=1729382
https://bugzilla.redhat.com/show_bug.cgi?id=1730086
When problems like this happen on arm, ppc64le, or even s390x.. the people
who are on those sigs do work on them. There needs to be an equivalent
group to keep i686 working.
_______________________________________________
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
--
Stephen J Smoogen.
1:44 p.m.
I totally agree with that view. Making such decisions without public discussion is not
respecting user's freedom of choice. And this list doesn't count as a public
discussion. Nobody will know about it outside a very closed circle. If you don't know
exact numbers or reasons why people still use that architecture, then rushing to drastic
measures just won't have enough rationale and will be viewed as a lack of care.
The reasons to use 32-bit userland might be more than you think. There are different use
scenarios besides browsing Internet or virtualization. There could be a high cost of
upgrade (think about replacing many computers at once). There could be a unique peripheral
equipment. There could be compatibility concerns. And there could be just not enough
memory.
OTOH, what could justify removing repository entirely? Why not make it an option which
could be installed on demand? That would be better than leave everyone out on the cold. Is
the cost to build it really that high? Safety could not be a reason in a tightly contained
environment. Let users decide for themselves.
There is no black and white distinction: multilib or i686 kernel. There are reasons why
using x86_64 kernel with i686 userland might be a better option. Some older office
computers were manufactured with 64-bit CPU but without support for more than 4 GB RAM. In
such case using i686 userland on a x86_64 kernel provides much more free memory than using
64-bit userland. Such configuration is unsupported, but neither is i686. Giving users a
choice is always better than decide for them behind their backs.
And of course there is still an option to switch to another OS. Do I need to remind that
Linux and Red Hat were not created just to replace some other OS, but to respect freedom
of choice? What happened that this is not even mentioned in such discussions? Is this just
business as usual?
11:05 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Sat, 2019-09-07 at 18:44 +0000, Victor V. Shkamerda wrote:
And of course there is still an option to switch to another OS. Do I
need to remind that Linux and Red Hat were not created just to
replace some other OS, but to respect freedom of choice? What
happened that this is not even mentioned in such discussions? Is this
just business as usual?
Obligatory:
http://islinuxaboutchoice.com/
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
3:50 a.m.
That's nice to know Fedora's developers point of view on that subject. But I'm
not subscribing to that view. I'm with Richard Stallman. And now I clearly see why he
is opposed to OSS paradigm. Looks like I was in a wrong place for all these years. Time to
move elsewhere.
10:37 p.m.
On Sunday, September 8, 2019 1:50:17 AM MST vvs vvs wrote:
That's nice to know Fedora's developers point of view on that
subject. But
I'm not subscribing to that view. I'm with Richard Stallman. And now I
clearly see why he is opposed to OSS paradigm. Looks like I was in a wrong
place for all these years. Time to move elsewhere.
_______________________________________________
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
This is not "Fedora's developers point of view", it's the point of view
of ONE
contributor.
9:28 a.m.
Boy, am I glad you've said that. I was waiting for it.
But looks like you are mistaken. First of all, it's not one, but at least two of them.
Second, nobody else seems to be supporting your point.
9:33 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 9/9/19 9:28 AM, vvs vvs wrote:
Boy, am I glad you've said that. I was waiting for it.
But looks like you are mistaken. First of all, it's not one, but at least two of
them. Second, nobody else seems to be supporting your point.
E-mails to this list don't get work done. Code commits get work done.
Feel free to revive the x86 SIG and start building a i686 kernel and work with
releng to re-enable the i686 repos.
Continuing this discussion will be fruitless for you and the thousands of
subscribers that are not replying to you. There's a reason no one is replying. They
are not interested.
9:52 a.m.
May be there are more interested people that we know, but they are not reading that list.
There will just be just every man for himself and Fedora has failed to recognize that.
This requires time and effort too. Nobody will appear just by a miracle. I recognize that
there is much less people interested in this architecture but it's much more than
zero.
10:01 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
----- Original Message -----
From: "vvs vvs" <vvs009(a)gmail.com>
To: devel(a)lists.fedoraproject.org
Sent: Monday, September 9, 2019 4:52:07 PM
Subject: Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
May be there are more interested people that we know, but they are not
reading that list. There will just be just every man for himself and Fedora
has failed to recognize that.
This requires time and effort too. Nobody will appear just by a miracle. I
recognize that there is much less people interested in this architecture but
it's much more than zero.
_______________________________________________
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
Providing some imaginary numbers and anecdotes as facts doesn't really help the
"I am right, you are wrong" style of debating that is on going for some time in
this thread. No, Fedora hasn't failed to recognize something, it's a community
project. If noone is interested enough to step up and help with the effort, the work will
never be done, simple as that.
--
Regards,
Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
10:36 a.m.
There is no either right or wrong stance here. We are discussing possible alternatives to
"just drop it" attitude.
What work should be done? Please, be more specific. Right now I'm running a i686
userland and it works. If I would be able to build the whole repository myself I'm
pretty sure that most things will still work. If it won't work I might try to fix it
and contribute patches back. But without that repository I can't even try it in the
first place.
You are just pushing me and others away, so we should go use other distributions which
provide ready to run builds. And I'm not talking about i686 *kernel* anywhere. We are
talking about *userland* only. I'm running 64-bit CPU all along, but I have limited
memory. Others could use laptops with restricted memory which would be a performance hit
if they start using x86_64 userland.
You are not providing any alternative but starting to build everything ourselves or stop
using Fedora and move elsewhere.
11:58 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Mon, Sep 09, 2019 at 03:36:45PM -0000, vvs vvs wrote:
What work should be done? Please, be more specific.
Deja vu… please read https://pagure.io/fesco/issue/1737
(Proposal: i686 SIG needs to be functional by F27 release date or we
drop i686 kernel from F28) with all the links.
--
Tomasz .. oo o. oo o. .o .o o. o. oo o. ..
Torcz .. .o .o .o .o oo oo .o .. .. oo oo
o.o.o. .o .. o. o. o. o. o. o. oo .. .. o.
12:55 p.m.
First of all thanks for the link. It just proves that the SIG's expectations were too
high.
If I understand it all correctly, the main reason to drop i686 repo was the mailing list
inactivity? Is that right? So everyone interested in that architecture is now deprived
from using it on Fedora because some formalities were not met? And if I have no time to
participate in that list, I can't fix problems myself? Because without that repository
I'm forced to use other distribution.
That's just... weird.
1:11 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Mon, Sep 09, 2019 at 05:55:06PM -0000, vvs vvs wrote:
If I understand it all correctly, the main reason to drop i686 repo
was the mailing list inactivity? Is that right? So everyone interested
in that architecture is now deprived from using it on Fedora because
some formalities were not met? And if I have no time to participate in
that list, I can't fix problems myself? Because without that
repository I'm forced to use other distribution.
No, i686 was dropped for the same reason there was no traffic on the
mailing list -- Nobody was getting any of the necessary work done. For
the better part of two years.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
High Springs, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
1:23 p.m.
But how do you now that I'm not fixed it myself and forgot to post on that list? Or
that I'm even just used to live with that bug and just don't want to spend all my
time chasing it?
I'm pretty sure that I can point point out bugs in official Fedora repository that
were dormant for several years without any conclusion and nobody dropped support for all
those applications just for that reason.
Anyway, I'm not expecting that something will change because of that discussion. It is
just bad that the interests of users are of a lower priority then some purely bureaucratic
reasons.
1:32 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Mon, Sep 09, 2019 at 18:23:18 -0000,
vvs vvs <vvs009(a)gmail.com> wrote:
Anyway, I'm not expecting that something will change because of that discussion. It is
just bad that the interests of users are of a lower priority then some purely bureaucratic
reasons.
It isn't happening because of bureaucratic reasons, but because not enough
work is getting done to support i686, because people aren't volunteering to do
it (and actually doing the work).
1:58 p.m.
I would argue that it might be difficult to distinguish work needed to find out if it was
i686 specific when there already is similar bug on x86_64. Also, it's difficult to
rate bug importance for most users. As I've already said that I was completely
satisfied with the status quo and it was a big surprise for me to discover that I just
won't be able to upgrade to the next version. Also, this discovery was purely
accidental because there is no announcements anywhere I could see.
Anyway, I would be prepared to fix things myself if such possibility was given to me. But
alas there is no choice now.
11:37 p.m.
On Monday, September 9, 2019 11:58:08 AM MST vvs vvs wrote:
I would argue that it might be difficult to distinguish work needed
to find
out if it was i686 specific when there already is similar bug on x86_64.
Also, it's difficult to rate bug importance for most users. As I've already
said that I was completely satisfied with the status quo and it was a big
surprise for me to discover that I just won't be able to upgrade to the
next version. Also, this discovery was purely accidental because there is
no announcements anywhere I could see.
Anyway, I would be prepared to fix things myself if such possibility
was
given to me. But alas there is no choice now.
Agreed, most bugs that affect x86 also support x64.
10:12 a.m.
Even better. That means that you can still get support for x86 but it will require some
more work on the user's side. They should just check if that bug is indeed i686
specific.
I believe that all that argument for the lats three days was completely unnecessary and
should be blamed on an utterl failure of communication.
1:28 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 11 Sep 2019, at 16:12, vvs vvs <vvs009(a)gmail.com> wrote:
Even better. That means that you can still get support for x86 but it will require some
more work on the user's side. They should just check if that bug is indeed i686
specific.
I believe that all that argument for the lats three days was completely unnecessary and
should be blamed on an utterl failure of communication.
The fundamental thing here is that, when a package fails on S390 but not on x86-64, there
are motivated people in the S390 SIG who'll help me out with what's wrong,
explaining the differences between S390 and x86-64 in a useful format, and often just
fixing it if it's an S390-specific oddity, not a straight bug that happens not to
manifest on x86-64.
In contrast, the x86 SIG never got enough volunteers to do the same role - if a build was
an issue on x86 but not x86-64, then they'd not have the available manpower to help
the package maintainer (often the kernel maintainers, in x86's case) fix the build.
Had the x86 SIG been able to identify the root causes of bugs in packages that failed on
x86, like the kernel, and come up with usable workarounds and/or fixes, then Fedora would
not be considering dropping x86. As it is, though, it appears that nobody cares enough
about 32-bit kernels and binaries (although some x86-64 people care about 32-bit
libraries) to keep i686 builds going.
Fundamentally, this happens in volunteer projects - nobody wants to do the work, nobody is
willing to pay enough to get someone else to want to do the work, so it doesn't
happen.
--
Simon
3:03 p.m.
Yes, that's understandable. But this is beating of a dead horse.
But what matters now is that by doing some small investigation i686 users can still get
support for their bugs which are common for both platforms. This doesn't require any
formalities like SIG or commitments which they can't make and it is always available
for anyone who can afford to spend some additional time if such bug affects them bad
enough.
I think this could work better than previous attempts at keeping x86 SIG alive. Of course
nothing prevents some volunteers to do above work on behalf of other users or create
mirrors for distribution of i686 packages. But this is not critical to keep things
running.
9:45 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 11 Sep 2019, at 21:03, vvs vvs <vvs009(a)gmail.com> wrote:
Yes, that's understandable. But this is beating of a dead horse.
But what matters now is that by doing some small investigation i686 users can still get
support for their bugs which are common for both platforms. This doesn't require any
formalities like SIG or commitments which they can't make and it is always available
for anyone who can afford to spend some additional time if such bug affects them bad
enough.
That's literally all the x86 SIG was asked to do - get some small investigation work
going so that between all of them, packages that had i686-unique bugs could be fixed in a
timely fashion. They couldn't get enough interest going to even keep the kernel
building for i686 as well as x86-64.
Everything else, including commitments from individuals and the mailing list, was
secondary to that goal, and was only looked at because the x86 SIG was failing to help
resolve FTBFS bugs that were blocking S390, x86-64 and other arches.
I think this could work better than previous attempts at keeping x86
SIG alive. Of course nothing prevents some volunteers to do above work on behalf of other
users or create mirrors for distribution of i686 packages. But this is not critical to
keep things running.
The problem is that you're discussing what the x86 SIG was formed to do - the only
reason to form a SIG to begin with was so that there was a bit of Fedora infrastructure
(mailing lists etc) devoted to connecting packagers with i686-only problems to people who
were willing to try and solve them.
If no-one's willing to actually do anything to fix i686 FTBFS issues, then Fedora will
drop i686 support eventually. That's all that's happening here - no-one wants to
do anything to keep i686 alive as an architecture for Fedora, so Fedora is dropping i686.
5:38 p.m.
But there should be some reason for that lack of interested volunteers in Fedora. Right
now I'm looking at stats for other distributions which are not going to drop i686 any
time soon, e.g. Debian, NixOS, Gentoo. There must me some very fundamental difference with
how they operate. Of course one of the reasons might be that some are relying on users to
build packages themselves. OTOH they have their own CI, binary repositories/caches and
Debian only has binaries for its package management. Why the difference? I'm not
sure...
3:57 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 9/13/19 1:38 AM, vvs vvs wrote:
But there should be some reason for that lack of interested
volunteers in Fedora. Right now I'm looking at stats for other distributions which are
not going to drop i686 any time soon, e.g. Debian, NixOS, Gentoo. There must me some very
fundamental difference with how they operate.
Maybe in other distros, people interested in i686 support actually do
something about it instead of talking and talking and talking about it
on mailing lists?
- Panu -
4:42 a.m.
Maybe in other distros, people interested in i686 support actually
do
something about it instead of talking and talking and talking about it
on mailing lists?
Maybe someone with so much free time on their hands could maintain
such a kernel in Fedora by applying downstream packages of such a
distro.
That person'd need to find a distribution that goes at least as fast
Fedora when it comes to upgrading kernel packages... I very much doubt
we'll find one we could rely on.
Dridi
5:50 a.m.
Le ven. 13 sept. 2019 à 11:44, Dridi Boukelmoune
<dridi.boukelmoune(a)gmail.com> a écrit :
> Maybe in other distros, people interested in i686 support actually do
> something about it instead of talking and talking and talking about it
> on mailing lists?
Maybe someone with so much free time on their hands could maintain
such a kernel in Fedora by applying downstream packages of such a
distro.
Well... I don't qualify as a person with much free time but...
I'm toying with kernel-longterm in a copr for .4.19 branch, and I've
enabled i686 there.
The rebuilt is a semi-automated way.
This i686 build is totally untested, please send patch along to report
any issue (or report upstream if relevant).
https://copr.fedorainfracloud.org/coprs/kwizart/kernel-longterm-4.19/
Best regards.
--
-
Nicolas (kwizart)
10:16 a.m.
Hello Nicolas,
On Fri, Sep 13, 2019 at 10:51 AM Nicolas Chauvet <kwizart(a)gmail.com> wrote:
<snip>
Well... I don't qualify as a person with much free time but...
I'm toying with kernel-longterm in a copr for .4.19 branch, and I've
enabled i686 there.
The rebuilt is a semi-automated way.
This i686 build is totally untested, please send patch along to report
any issue (or report upstream if relevant).
https://copr.fedorainfracloud.org/coprs/kwizart/kernel-longterm-4.19/
While I appreciate the effort, this also doesn't work in the long term
(pun intended) once we start packaging or upgrading software that
relies on whatever Fedora's kernel provides that isn't in 4.19 we
break that piece of software...
Dridi
4:23 p.m.
On Friday, September 13, 2019 1:57:05 AM MST Panu Matilainen wrote:
On 9/13/19 1:38 AM, vvs vvs wrote:
> But there should be some reason for that lack of interested volunteers in
> Fedora. Right now I'm looking at stats for other distributions which are
> not going to drop i686 any time soon, e.g. Debian, NixOS, Gentoo. There
> must me some very fundamental difference with how they operate.
Maybe in other distros, people interested in i686 support actually do
something about it instead of talking and talking and talking about it
on mailing lists?
- Panu -
In other distros, working architectures aren't simply dropped at random.
1:42 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Mon, Sep 09, 2019 at 06:23:18PM -0000, vvs vvs wrote:
But how do you now that I'm not fixed it myself and forgot to
post on
that list? Or that I'm even just used to live with that bug and just
don't want to spend all my time chasing it?
It's simple; if you (and everyone else) doesn't say anything in the
public discusison channels, or generate _some_ sort of activity in other
project channels (eg bugzilla, irc, whatever) then it is a perfectly
reasonable assumption to make that you are not doing anything of general
relevance to Fedora.
I'm pretty sure that I can point point out bugs in official
Fedora
repository that were dormant for several years without any conclusion
and nobody dropped support for all those applications just for that
reason.
Every Fedora release has packages dropped due to failures to compile or
other problems that run afoul of packaging policies, with nobody
stepping up to fix them.
Anyway, I'm not expecting that something will change because of
that
discussion. It is just bad that the interests of users are of a lower
priority then some purely bureaucratic reasons.
I'm sorry you feel that way.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
High Springs, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
2:09 p.m.
Ok, now I see that Fedora is just for activists. If I'm not one of them then I
don't deserve any possibility to use it and should blame myself. Thanks for explaining
it to me.
2:16 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Mon, Sep 09, 2019 at 07:09:49PM -0000, vvs vvs wrote:
Ok, now I see that Fedora is just for activists. If I'm not one
of
them then I don't deserve any possibility to use it and should blame
myself. Thanks for explaining it to me.
If I may quote from the landing page on https://getfedora.org/
"Fedora creates an innovative, free, and open source platform for
hardware, clouds, and containers that enables software developers and
community members to build tailored solutions for their users."
...
"Fedora Workstation is a polished, easy to use operating system for
laptop and desktop computers, with a complete set of tools for
developers and makers of all kinds."
Using Fedora (or not) has always been your choice.
Good day,
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
High Springs, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
2:44 p.m.
"vvs vvs" <vvs009(a)gmail.com> writes:
Ok, now I see that Fedora is just for activists. If I'm not one
of
them then I don't deserve any possibility to use it and should blame
myself. Thanks for explaining it to me.
I think you're overreacting a bit, but there is some truth in this.
Fedora is created and maintained by the community. You are part of the
community. If enough of the community shares your needs, some fraction
of those will step up to do the work, and you all benefit. If your
needs aren't shared by enough of the community, either you need to do it
all yourself (or pay someone to act on your behalf), or your needs will
never get met.
This has nothing to do with "deserve" or "blame" - it's just
numbers.
Most people have switched to 64-bit, so most work is done for 64-bit,
even if not all the 64-bit users are also contributors.
The 32-bit community has shrunk to the point where there aren't enough
contributors to keep the builds building and the fixes fixing, and there
are real problems backing up because of that, even if they don't affect
you personally. When there are enough problems and no contributors,
what other choice do we have? It's broken and nobody is fixing it.
Thus comes the hard part of any project - put up or shut up. Harsh, but
it's the root of how things get done - they get done by people doing
them. Do or do not, there is no sit-on-the-mailing-list-and-hope.
Back when I started the DJGPP project, I had to do everything myself.
The community grew and there were lots of contributors. Then the
community shrunk until we're back down to 2 people doing all the work.
Thus is the cycle of projects, but I don't complain that not enough
people are still using DOS :-)
OTOH you won't hurt our feelings if you switch distros. Go where your
community is ;-)
2:57 p.m.
Well, thanks for sharing.
I'm not complaining that nobody wants to fix things for me. I'm complaining
because there is no possibility to fix things myself. After removing i686 repository
I'm either should start building it myself or switch to another distribution. I'm
not trying to hurt anyone's feelings, I just have no other choice. If there is no
possibility to keep that repository than it's fine, but I was not convinced that there
are other reasons for that decision aside bureaucratic ones and lack of empathy. If
putting that repository on some optional host for anyone to be able to fix it themselves
would severely harm the project then I was wrong all along and I'm really sorry.
3 p.m.
New subject: [EXT] Re: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Mon, Sep 09, 2019 at 07:57:20PM -0000, vvs vvs wrote:
Well, thanks for sharing.
I'm not complaining that nobody wants to fix things for me. I'm complaining
because there is no possibility to fix things myself. After removing i686 repository
I'm either should start building it myself or switch to another distribution. I'm
not trying to hurt anyone's feelings, I just have no other choice. If there is no
possibility to keep that repository than it's fine, but I was not convinced that there
are other reasons for that decision aside bureaucratic ones and lack of empathy. If
putting that repository on some optional host for anyone to be able to fix it themselves
would severely harm the project then I was wrong all along and I'm really sorry.
If you don't care about i686 not being "supported" but just want to have
access to the repositories so you can use/fix them yourself, then why don't you just
keep running Fedora 30 or 29 forever? The old bits will always be there (moved to
archive/ directory) and you can keep using them.
4:02 p.m.
New subject: [EXT] Re: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
And I thought that should be obvious, silly me. Just kidding.
Of course I would do it if there were no better choice. I'm just struggling to find
out if there is no other possibility whatsoever. There might be reasons why Fedora is just
unable to keep it updated that I don't know. And of course I could use another
repository provided by some other distribution. I'm just trying to find out what are
my options. I would prefer to keep using modern Fedora unless I'm forced not to.
Just in case. There is no reason to believe that I'm upset or frustrated. That's
just a conversation which might get heated at a time for various reasons which are not
directly related to the subject.
11:45 p.m.
New subject: [EXT] Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories
On Monday, September 9, 2019 1:00:51 PM MST Anderson, Charles R wrote:
On Mon, Sep 09, 2019 at 07:57:20PM -0000, vvs vvs wrote:
> Well, thanks for sharing.
>
> I'm not complaining that nobody wants to fix things for me. I'm
> complaining because there is no possibility to fix things myself. After
> removing i686 repository I'm either should start building it myself or
> switch to another distribution. I'm not trying to hurt anyone's feelings,
> I just have no other choice. If there is no possibility to keep that
> repository than it's fine, but I was not convinced that there are other
> reasons for that decision aside bureaucratic ones and lack of empathy. If
> putting that repository on some optional host for anyone to be able to
> fix it themselves would severely harm the project then I was wrong all
> along and I'm really sorry.
If you don't care about i686 not being "supported" but just want to have
access to the repositories so you can use/fix them yourself, then why don't
you just keep running Fedora 30 or 29 forever? The old bits will always be
there (moved to archive/ directory) and you can keep using them.
Please do not suggest things like that. That would mean that security updates
are not provided, bug fixes never make it in, and so on.
11:46 p.m.
On Monday, September 9, 2019 12:44:42 PM MST DJ Delorie wrote:
"vvs vvs" <vvs009(a)gmail.com> writes:
> Ok, now I see that Fedora is just for activists. If I'm not one of
> them then I don't deserve any possibility to use it and should blame
> myself. Thanks for explaining it to me.
I think you're overreacting a bit, but there is some truth in this.
Fedora is created and maintained by the community. You are part of the
community. If enough of the community shares your needs, some fraction
of those will step up to do the work, and you all benefit. If your
needs aren't shared by enough of the community, either you need to do it
all yourself (or pay someone to act on your behalf), or your needs will
never get met.
This has nothing to do with "deserve" or "blame" - it's just
numbers.
Most people have switched to 64-bit, so most work is done for 64-bit,
even if not all the 64-bit users are also contributors.
The 32-bit community has shrunk to the point where there aren't enough
contributors to keep the builds building and the fixes fixing, and there
are real problems backing up because of that, even if they don't affect
you personally. When there are enough problems and no contributors,
what other choice do we have? It's broken and nobody is fixing it.
Thus comes the hard part of any project - put up or shut up. Harsh, but
it's the root of how things get done - they get done by people doing
them. Do or do not, there is no sit-on-the-mailing-list-and-hope.
Back when I started the DJGPP project, I had to do everything myself.
The community grew and there were lots of contributors. Then the
community shrunk until we're back down to 2 people doing all the work.
Thus is the cycle of projects, but I don't complain that not enough
people are still using DOS :-)
OTOH you won't hurt our feelings if you switch distros. Go where your
community is ;-)
While most users on Intel/AMD based systems are now running x64 kernels, most
proprietary software released for various GNU/Linux distros are 32 bit.
5:19 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Tuesday, 10 September 2019 at 06:46, John M. Harris Jr. wrote:
[...]
While most users on Intel/AMD based systems are now running x64
kernels,
I might agree with the above...
most proprietary software released for various GNU/Linux distros are
32 bit.
... but not with this. Most of the proprietary Linux software that
I use is 64 bit.
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
1:58 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686 Repositorieso
On Mon 9. Sep 2019 at 21:45, DJ Delorie <dj(a)redhat.com> wrote:
"vvs vvs" <vvs009(a)gmail.com> writes:
> Ok, now I see that Fedora is just for activists. If I'm not one ofn
> them then I don't deserve any possibility to use it and should blame
> myself. Thanks for explaining it to me.
I think you're overreacting a bit, but there is some truth in this.
Fedora is created and maintained by the community. You are part of the
community. If enough of the community shares your needs, some fraction
of those will step up to do the work, and you all benefit. If your
needs aren't shared by enough of the community, either you need to do it
all yourself (or pay someone to act on your behalf), or your needs will
never get met.
This has nothing to do with "deserve" or "blame" - it's just
numbers.
Most people have switched to 64-bit, so most work is done for 64-bit,
even if not all the 64-bit users are also contributors.
The 32-bit community has shrunk to the point where there aren't enough
contributors to keep the builds building and the fixes fixing, and there
are real problems backing up because of that, even if they don't affect
you personally. When there are enough problems and no contributors,
what other choice do we have? It's broken and nobody is fixing it.
Thus comes the hard part of any project - put up or shut up. Harsh, but
it's the root of how things get done - they get done by people doing
them. Do or do not, there is no sit-on-the-mailing-list-and-hope.
Back when I started the DJGPP project, I had to do everything myself.
The community grew and there were lots of contributors. Then the
community shrunk until we're back down to 2 people doing all the work.
Thus is the cycle of projects, but I don't complain that not enough
people are still using DOS :-)
OTOH you won't hurt our feelings if you switch distros. Go where your
community is ;-)
_______________________________________________
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
--
Leslie Hawthorn
Sr. Principal Technical Program Manager
Open Source Programs Office
Office of the CTO
She / Her / Hers
http://community.redhat.com
http://twitter.com/lhawthorn
12:57 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686 Repositorieso
Hi, I think we lost your message when you sent it. The only thing that came
through was a quote of the previous few messages.
- -
John Harris
11:40 p.m.
On Monday, September 9, 2019 12:09:49 PM MST vvs vvs wrote:
Ok, now I see that Fedora is just for activists. If I'm not one
of them then
I don't deserve any possibility to use it and should blame myself. Thanks
for explaining it to me.
Please don't let the hostilities of this list get to you, there are those of
us in Fedora that want to help users like you. I'm one of them, and I'd be
more than happy to step up to the plate and get to work on "supporting" x86
based systems. I've got systems shipping out to me now from my old location.
6:41 a.m.
Thanks.
I wouldn't say there is a "hostility" here. It might be hubris at a time,
but mostly indifference. Though, that might frustrate anyone as well.
It's good to know that there are people like you here. But I'm afraid that the
cost of bureaucratic barriers is too high for any single person. And the primary reason
why that SIG initiative never worked is that the project didn't put any significant
efforts to make that happen. See, if I would join that list now there will be just one
person - me. And I don't have ability or time to actively search for and convince
other people to join that list. As time goes by I won't participate in that list too
often and others won't either. To keep being recognized by Fedora officials there are
just not enough activists out there. While we still can support that architecture
occasionally on a case by case basis, there is no possibility to meet FESCO approved
criteria. That means that there will never be official recognition despite the fact that
such interested people still exist.
There are just two options as I currently see it. Either we can be a low activity
grass-roots enthusiasts and find our own ways to contribute packages, e.g. COPR might be
useful. Or we can join more resourceful community, e.g. Debian. Or we can do both.
1:54 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
* vvs vvs [10/09/2019 11:41] :
And the primary reason why that SIG initiative never worked is that the
project didn't put any significant efforts to make that happen.
I'm going to disagree with you here.
Back in 2017, we went through a very long discussion which lead to the
creation of the x86 SIG. The discussion on the mailing list started off
at a reasonable rate and then slowed to a stop because it couldn't keep
its momentum going.
So the fault with the SIG not working really lies with the people who
wanted to keep x86_32 going not being able/willing to do the work necessary,
not all the other Fedora developers.
Either we can be a low activity grass-roots enthusiasts and find our
own ways to contribute packages, e.g. COPR might be useful.
This is pretty much the definition of a SIG.
Emmanuel
4:07 p.m.
No, of course I didn't mean that it was some random developer's fault. By
"the project" I definitely meant PR and HR in a broad sense. Expecting such
casual participants like me to self-organize is a wild idea. Even placing some
advertisement on Fedora's landing page would be a big help.
I suppose that SIG is a much formal entity than just a bunch of individuals performing
some non-regular activities. Even mailing list activity is part of that FESCo criteria.
And there are Bugzilla, etc. If that really was that simple then just subscribing to that
list would be enough to get support for x86 architecture and we wouldn't be here.
4:46 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
* vvs vvs [10/09/2019 21:07] :
I suppose that SIG is a much formal entity than just a bunch of
individuals performing some non-regular activities.
The PHP SIG is barely more than one person, the Perl SIG has no regular
meeting and the mailing list activity is not representative of the work
being done but thoses SIGS still do the work necessary to keep their
stack in the distribution.
If that really was that simple then just subscribing to that list
would be enough to get support for x86 architecture and we wouldn't
be here.
I think you're confusing cause and effect, here.
We look at Bugzilla stats and mailing-lists activity because
it's (supposed to be) indicative of the work being done. It's a by-product,
not the final outcome. Subscribing to a mailing-list (and even posting
to it) isn't going to improve the packages in the distribution by itself.
Emmanuel
6:28 p.m.
But that's actually the same that I was trying to say. Meeting that activity
statistics is the essence of such formal group. But grass-roots enthusiasts don't have
such commitments. They can do some work occasionally if time allows but there is no strict
agenda. This contradicts those expectations which you describe. So while there are people
ready to do some work sometimes they just don't meet those criteria and this is not
enough to be able to call them SIG.
2:21 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 9/10/19 4:28 PM, vvs vvs wrote:
But that's actually the same that I was trying to say. Meeting
that activity statistics is the essence of such formal group. But grass-roots enthusiasts
don't have such commitments. They can do some work occasionally if time allows but
there is no strict agenda. This contradicts those expectations which you describe. So
while there are people ready to do some work sometimes they just don't meet those
criteria and this is not enough to be able to call them SIG.
And that's the whole problem here. Those people are not able to do
enough work to keep i686 going. As has been said here many times, if
you can get enough people to do the necessary work, then there is no
need for the i686 repos to go away. But that just hasn't happened.
I don't think there are any requirement to create a SIG other than to
have a group of people interested in the topic. The SIG still exists,
but it isn't doing enough to be able to keep i686 alive.
7:27 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Tue, Sep 10, 2019 at 11:28:13PM -0000, vvs vvs wrote:
But that's actually the same that I was trying to say. Meeting
that
activity statistics is the essence of such formal group. But grass-roots
enthusiasts don't have such commitments. They can do some work
occasionally if time allows but there is no strict agenda. This
contradicts those expectations which you describe. So while there are
people ready to do some work sometimes they just don't meet those
criteria and this is not enough to be able to call them SIG.
Hopefully for the last time: the mailing list is not a requirement.
People checked the mailing list *after* the bugs were not fixed.
Fixing the bugs is the requirement.
G'luck,
Peter
--
Peter Pentchev roam(a){ringlet.net,debian.org,FreeBSD.org} pp(a)storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
10:09 a.m.
And even that might not be necessary at all because most bugs are common between 32 and
64-bit. Honestly, I don't think such SIG was really needed after all.
1:12 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Mon, Sep 09, 2019 at 17:55:06 -0000,
vvs vvs <vvs009(a)gmail.com> wrote:
First of all thanks for the link. It just proves that the SIG's
expectations were too high.
If I understand it all correctly, the main reason to drop i686 repo was the mailing list
inactivity? Is that right? So everyone interested in that architecture is now deprived
from using it on Fedora because some formalities were not met? And if I have no time to
participate in that list, I can't fix problems myself? Because without that repository
I'm forced to use other distribution.
There were announcements on other lists. This issue was brought to the
development list a long time ago. New people didn't do enough. Just
being on a mailing list doesn't make things get done. People needed to fix
problems or at least facilitate getting them fixed, and not enough of that
happened. So it isn't just a formallity causing the problem.
You can still use f30 until about May. It looks like CentOS 7 can be used
with i686, so you could probably use that a bit longer if you wanted to
stick with a similar distro.
Someone has to do the work and most of Fedora's work gets done by volunteers.
If no one volunteers for something, then that thing is unlikely to get done.
I was willing to do some work on i686 when I was forced to use it, but
shortly I won't be using any i686 systems and will be spending what little
time I use for Fedora on things that are more important and more practical
for me.
11:34 p.m.
On Monday, September 9, 2019 8:36:45 AM MST vvs vvs wrote:
There is no either right or wrong stance here. We are discussing
possible
alternatives to "just drop it" attitude.
What work should be done? Please, be more specific. Right now I'm
running a
i686 userland and it works. If I would be able to build the whole
repository myself I'm pretty sure that most things will still work. If it
won't work I might try to fix it and contribute patches back. But without
that repository I can't even try it in the first place.
You are just pushing me and others away, so we should go use other
distributions which provide ready to run builds. And I'm not talking about
i686 *kernel* anywhere. We are talking about *userland* only. I'm running
64-bit CPU all along, but I have limited memory. Others could use laptops
with restricted memory which would be a performance hit if they start using
x86_64 userland.
You are not providing any alternative but starting to build
everything
ourselves or stop using Fedora and move elsewhere.
There's no reason to drop x86 kernel builds either.
11:54 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 9/9/19 9:34 PM, John M. Harris Jr. wrote:
There's no reason to drop x86 kernel builds either.
Sure there are... from the change page:
"The i686 kernel is of limited use as most x86 hardware supports 64bit
these days. It has been in a status of "community supported" for several
Fedora releases now. As such, it gets very little testing, and issues
frequently appear upstream. These tend to go unnoticed for long periods
of time. When issues are found, it is often a long time before they are
fixed because they are considered low priority by most developers
upstream. This can leave other architectures waiting for important
updates, and provides a less than desirable experience for people
choosing to run a 32bit kernel. With this proposal, the i686 kernel will
no longer be built. A kernel headers package will still exist, and all
32bit packages should continue to build as normal. The main difference
is there would no longer be bootable 32bit images."
The lack of fixes for i686 kernels is slowing down all the other arches
that are supported (and thus all of fedora).
kevin
1:01 a.m.
On Tuesday, September 10, 2019 9:54:50 AM MST Kevin Fenzi wrote:
On 9/9/19 9:34 PM, John M. Harris Jr. wrote:
> There's no reason to drop x86 kernel builds either.
Sure there are... from the change page:
"The i686 kernel is of limited use as most x86 hardware supports 64bit
these days. It has been in a status of "community supported" for several
Fedora releases now. As such, it gets very little testing, and issues
frequently appear upstream. These tend to go unnoticed for long periods
of time. When issues are found, it is often a long time before they are
fixed because they are considered low priority by most developers
upstream. This can leave other architectures waiting for important
updates, and provides a less than desirable experience for people
choosing to run a 32bit kernel. With this proposal, the i686 kernel will
no longer be built. A kernel headers package will still exist, and all
32bit packages should continue to build as normal. The main difference
is there would no longer be bootable 32bit images."
The lack of fixes for i686 kernels is slowing down all the other arches
that are supported (and thus all of fedora).
kevin
The first sentence of that paragraph is simply incorrect, new hardware doesn't
change what old hardware supports, nor does the availability of new hardware
replace old hardware in itself.
- -
John Harris
2:28 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 9/10/19 11:01 PM, John M. Harris Jr. wrote:
On Tuesday, September 10, 2019 9:54:50 AM MST Kevin Fenzi wrote:
> Sure there are... from the change page:
>
> "The i686 kernel is of limited use as most x86 hardware supports 64bit
> these days. It has been in a status of "community supported" for several
[snip]
> The lack of fixes for i686 kernels is slowing down all the other
arches
> that are supported (and thus all of fedora).
The first sentence of that paragraph is simply incorrect, new hardware doesn't
change what old hardware supports, nor does the availability of new hardware
replace old hardware in itself.
It's not incorrect. Almost all x86 hardware is 64-bit capable,
therefore building a 32-bit is of very limited use. It is not easy to
find 32-bit only CPUs now. Yes, I know some still exist; I have one
embedded in my wall (NSC Geode). But the last paragraph is important.
Keeping the i686 kernel in Fedora is hurting everyone for the benefit of
an extremely small group of users.
2:50 a.m.
On Wednesday, September 11, 2019 12:28:31 AM MST Samuel Sieb wrote:
On 9/10/19 11:01 PM, John M. Harris Jr. wrote:
> On Tuesday, September 10, 2019 9:54:50 AM MST Kevin Fenzi wrote:
>
>> Sure there are... from the change page:
>>
>>
>>
>> "The i686 kernel is of limited use as most x86 hardware supports 64bit
>> these days. It has been in a status of "community supported" for
several
[snip]
>> The lack of fixes for i686 kernels is slowing down all the other arches
>> that are supported (and thus all of fedora).
>
>
> The first sentence of that paragraph is simply incorrect, new hardware
> doesn't change what old hardware supports, nor does the availability of
> new hardware replace old hardware in itself.
It's not incorrect. Almost all x86 hardware is 64-bit capable,
therefore building a 32-bit is of very limited use. It is not easy to
find 32-bit only CPUs now. Yes, I know some still exist; I have one
embedded in my wall (NSC Geode). But the last paragraph is important.
Keeping the i686 kernel in Fedora is hurting everyone for the benefit of
an extremely small group of users.
Again, it's completely false that "almost all x86 hardware is 64-bit
capable".
That may be true of newer hardware, but that does nothing to change existing
hardware. The laptop I'm typing this email on right now is 32 bit only, by the
way. It was manufactured in 2011.
I also fail to see how keeping the i686 kernel "is slowing down all other
arches that are supported", and I'd love to know why that's the case, so I
can
get to fixing it.
- -
John Harris
3:55 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 9/11/19 12:50 AM, John M. Harris Jr. wrote:
On Wednesday, September 11, 2019 12:28:31 AM MST Samuel Sieb wrote:
> It's not incorrect. Almost all x86 hardware is 64-bit capable,
> therefore building a 32-bit is of very limited use. It is not easy to
> find 32-bit only CPUs now. Yes, I know some still exist; I have one
> embedded in my wall (NSC Geode). But the last paragraph is important.
> Keeping the i686 kernel in Fedora is hurting everyone for the benefit of
> an extremely small group of users.
Again, it's completely false that "almost all x86 hardware is 64-bit
capable".
That may be true of newer hardware, but that does nothing to change existing
hardware. The laptop I'm typing this email on right now is 32 bit only, by the
way. It was manufactured in 2011.
I do understand that there are still a few 32-bit CPUs around, but if
you take all the currently functional in-use x86 hardware, what
percentage do you actually think is not 64-bit capable? You have to
look really hard to find any. I got a bunch of P4 computers from _2005_
for a school computer lab. They are 64-bit capable and with 2GB of RAM
they work great. I originally had some slightly older ones that might
have been 32-bit only, but those are long gone.
I also fail to see how keeping the i686 kernel "is slowing down
all other
arches that are supported", and I'd love to know why that's the case, so I
can
get to fixing it.
Because when there is a problem with the 32-bit kernel compile, it
breaks kernel updates for everyone. The issues take time to get fixed
because even upstream barely cares about it. And fixing those issues
takes developer time that would be more useful elsewhere.
6:26 a.m.
On Wed, Sep 11, 2019 at 2:51 AM John M. Harris Jr. <johnmh(a)splentity.com> wrote:
On Wednesday, September 11, 2019 12:28:31 AM MST Samuel Sieb wrote:
> On 9/10/19 11:01 PM, John M. Harris Jr. wrote:
>
> > On Tuesday, September 10, 2019 9:54:50 AM MST Kevin Fenzi wrote:
> >
> >> Sure there are... from the change page:
> >>
> >>
> >>
> >> "The i686 kernel is of limited use as most x86 hardware supports
64bit
> >> these days. It has been in a status of "community supported" for
several
>
>
> [snip]
>
>
> >> The lack of fixes for i686 kernels is slowing down all the other arches
> >> that are supported (and thus all of fedora).
> >
> >
> > The first sentence of that paragraph is simply incorrect, new hardware
> > doesn't change what old hardware supports, nor does the availability of
> > new hardware replace old hardware in itself.
>
>
> It's not incorrect. Almost all x86 hardware is 64-bit capable,
> therefore building a 32-bit is of very limited use. It is not easy to
> find 32-bit only CPUs now. Yes, I know some still exist; I have one
> embedded in my wall (NSC Geode). But the last paragraph is important.
> Keeping the i686 kernel in Fedora is hurting everyone for the benefit of
> an extremely small group of users.
Again, it's completely false that "almost all x86 hardware is 64-bit
capable".
That may be true of newer hardware, but that does nothing to change existing
hardware. The laptop I'm typing this email on right now is 32 bit only, by the
way. It was manufactured in 2011.
I also fail to see how keeping the i686 kernel "is slowing down all other
arches that are supported", and I'd love to know why that's the case, so I
can
get to fixing it.
People offered to "get to fixing it" 2 years ago when this was first
proposed. They organized, started a SIG, and then crickets. Turns out
the fixing it takes continuous effort. This isn't a one time thing,
it is issues that pop up regularly.
12:29 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Mon, Sep 09, 2019 at 14:52:07 -0000,
vvs vvs <vvs009(a)gmail.com> wrote:
May be there are more interested people that we know, but they are not
reading that list. There will just be just every man for himself and Fedora has failed to
recognize that.
This requires time and effort too. Nobody will appear just by a miracle. I recognize that
there is much less people interested in this architecture but it's much more than
zero.
I'm probably one of the few people still running Fedora on a machine that
uses i686, that can't use x86_64. The machine is around 15 years old and is
costly to get replacement parts for and I'm running out of spares. I was
supposed to replace the machine last month, but needed another month to save
up enough to buy the rest of the replacement. I've actually work with
upstream to get kernel bugs fixed for this machine.
Unfortunately I run rawhide and things got shut down a little sooner
than I hoped, so I'm not getting updates right now and don't want to go
back to f30 with the short horizon for retirement (though I did grab an
f30 kernel).
I don't think you are going to find many people who both run Fedora and
have to use i686.
There is a cost to keeping things running on i686 and it doesn't look like
it is worth paying right now. And things are looking to get worse rather than
better.
You have options. You can switch to another distro that will support i686
for a while yet. Use f30 until it's EOL (or beyond if the machines are
isolated). Or maintain your own distro. The tools for Fedora are open,
so you could set up your own koji instance drawing from Fedora and applying
your fixes where needed. Getting started will probably be hard, but once
things are running you'll be OK until there is a key bug you can't get
fixed.
1:06 p.m.
Yes, thanks. Sadly, I see that I have no choice but to switch to another distribution even
though I'm using 64-bit CPU. It's just that the memory can't be upgraded and
buying new computer just to keep running Fedora is not viable. It's 12 years old, is
in good condition and I'm completely satisfied with its performance for my needs. I
wonder what owners of thin terminals will do if they used Fedora, especially if there are
many of them. The cost of upgrading some old terminals for some school can be too high.
Maintaining my own distribution is a little too much for me at the moment.
1:27 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Mon, Sep 09, 2019 at 18:06:02 -0000,
vvs vvs <vvs009(a)gmail.com> wrote:
Yes, thanks. Sadly, I see that I have no choice but to switch to
another distribution even though I'm using 64-bit CPU. It's just that the memory
can't be upgraded and buying new computer just to keep running Fedora is not viable.
It's 12 years old, is in good condition and I'm completely satisfied with its
performance for my needs. I wonder what owners of thin terminals will do if they used
Fedora, especially if there are many of them. The cost of upgrading some old terminals for
some school can be too high.
It is probably very rare for someone to have just enough memory for a system to
run reasonably using i686, but tank when using x86_64. If there is some
key code that causes the problem, you might be able to rebuild that code to
use 32 bit addresses and save enough memory to make things work reasonably.
1:47 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Mon, 2019-09-09 at 13:27 -0500, Bruno Wolff III wrote:
On Mon, Sep 09, 2019 at 18:06:02 -0000,
vvs vvs <vvs009(a)gmail.com> wrote:
> Yes, thanks. Sadly, I see that I have no choice but to switch to another
distribution even though I'm using 64-bit
> CPU. It's just that the memory can't be upgraded and buying new computer
just to keep running Fedora is not viable.
> It's 12 years old, is in good condition and I'm completely satisfied with
its performance for my needs. I wonder
> what owners of thin terminals will do if they used Fedora, especially if there are
many of them. The cost of
> upgrading some old terminals for some school can be too high.
It is probably very rare for someone to have just enough memory for a system to
run reasonably using i686, but tank when using x86_64. If there is some
key code that causes the problem, you might be able to rebuild that code to
use 32 bit addresses and save enough memory to make things work reasonably.
Yeah,
I've recently switched an old Atom A330[0] based system[1] with 2 GB of RAM
(that's the maximum it supports)
from a 32-bit to a 64-bit based distro (after finding out it can actually run 64-bit
code).
It has been running just fine and actually feels a bit faster now.
[0]
https://ark.intel.com/content/www/us/en/ark/products/35641/intel-atom-pro...
[1]
https://ark.intel.com/content/www/us/en/ark/products/42491/intel-desktop-...
_______________________________________________
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 based
2:04 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Mon, Sep 09, 2019 at 08:47:24PM +0200, Martin Kolman wrote:
Yeah, I've recently switched an old Atom A330[0] based system[1]
with
2 GB of RAM (that's the maximum it supports) from a 32-bit to a 64-bit
based distro (after finding out it can actually run 64-bit code). It
has been running just fine and actually feels a bit faster now.
That's been my experience too; the architectural improvements for x86_64
over i686 yielded a noticable performance boost that more than offset
the memory usage penalty of larger pointer sizes, even for
traditionally-RAM-intensive stuff like cross-compiling.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
High Springs, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
2:21 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 9/9/19 11:47 AM, Martin Kolman wrote:
Yeah, I've recently switched an old Atom A330[0] based system[1]
with 2 GB of RAM (that's the maximum it supports)
from a 32-bit to a 64-bit based distro (after finding out it can actually run 64-bit
code).
It has been running just fine and actually feels a bit faster now.
I had a similar experience. I setup a bunch of old P4 desktops for a
school computer lab. Initially, I used a 32-bit install, but then I
discovered that they actually supported 64-bit. A Mate desktop runs
just fine in 2GB of RAM even with Firefox and Libreoffice.
2:01 p.m.
No, I don't think so. I'm using some (non Fedora related) applications which use
every bit of available memory. It's a bit stressed just as it is, but losing
additional couple of megabytes for no useful reason will be too much a hit. And I
can't change their code, because that codebase is big and complex (as usual) and I
just don't have enough time to do everything myself.
2:08 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Mon, Sep 09, 2019 at 07:01:59PM -0000, vvs vvs wrote:
No, I don't think so. I'm using some (non Fedora related)
applications
which use every bit of available memory. It's a bit stressed just as
it is, but losing additional couple of megabytes for no useful reason
will be too much a hit. And I can't change their code, because that
codebase is big and complex (as usual) and I just don't have enough
time to do everything myself.
Honestly, it sounds like your 12-year-old system is barely adequate
for your needs, and even a minimally-newer system capable of holding
more RAM would pay for itself pretty rapidly.
(Unless you don't value your own time or stress levels..)
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
High Springs, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
2:23 p.m.
I don't have time to search for it right now, but there is a law which states that no
matter how much resources you already get they will be stretched thin anyway.
I did upgrades many times but every time it was proved that it still wasn't enough.
It's a useless rat race. We have much more important things to do because life is too
short.
2:13 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Mon, Sep 09, 2019 at 19:01:59 -0000,
vvs vvs <vvs009(a)gmail.com> wrote:
No, I don't think so. I'm using some (non Fedora related)
applications which use every bit of available memory. It's a bit stressed just as it
is, but losing additional couple of megabytes for no useful reason will be too much a hit.
And I can't change their code, because that codebase is big and complex (as usual) and
I just don't have enough time to do everything myself.
Have you actually tested this? That is very odd behavior.
2:33 p.m.
No, just a memory bound behavior. It will eat all memory that you throw on it and one
gigabyte just for starters. After that it will start swapping but some careful
optimization management can avoid that. But if it starts swapping there will be a major
performance hit. And it isn't mission critical so I'm not inclined to take drastic
measures just for that reason. I know that upgrading will cost me much more time and
frustration.
11:24 p.m.
On Monday, September 9, 2019 10:29:23 AM MST Bruno Wolff III wrote:
On Mon, Sep 09, 2019 at 14:52:07 -0000,
vvs vvs <vvs009(a)gmail.com> wrote:
>May be there are more interested people that we know, but they are not
>reading that list. There will just be just every man for himself and
>Fedora has failed to recognize that.
>This requires time and effort too. Nobody will appear just by a
miracle. I
>recognize that there is much less people interested in this architecture
>but it's much more than zero.
I'm probably one of the few people still running Fedora on a machine that
uses i686, that can't use x86_64. The machine is around 15 years old and is
costly to get replacement parts for and I'm running out of spares. I was
supposed to replace the machine last month, but needed another month to
save up enough to buy the rest of the replacement. I've actually work with
upstream to get kernel bugs fixed for this machine.
Unfortunately I run rawhide and things got shut down a little sooner
than I hoped, so I'm not getting updates right now and don't want to go
back to f30 with the short horizon for retirement (though I did grab an
f30 kernel).
I don't think you are going to find many people who both run Fedora and
have to use i686.
There is a cost to keeping things running on i686 and it doesn't look like
it is worth paying right now. And things are looking to get worse rather
than better.
You have options. You can switch to another distro that will support i686
for a while yet. Use f30 until it's EOL (or beyond if the machines are
isolated). Or maintain your own distro. The tools for Fedora are open,
so you could set up your own koji instance drawing from Fedora and applying
your fixes where needed. Getting started will probably be hard, but once
things are running you'll be OK until there is a key bug you can't get
fixed.
There are at least 4 people in this thread alone that are running Fedora on
x86 systems.
7 a.m.
On Tue, Sep 10, 2019 at 12:24 AM John M. Harris Jr.
<johnmh(a)splentity.com> wrote:
On Monday, September 9, 2019 10:29:23 AM MST Bruno Wolff III wrote:
> On Mon, Sep 09, 2019 at 14:52:07 -0000,
> vvs vvs <vvs009(a)gmail.com> wrote:
>
> >May be there are more interested people that we know, but they are not
> >reading that list. There will just be just every man for himself and
> >Fedora has failed to recognize that.
> >This requires time and effort too. Nobody will appear just by a miracle. I
> >recognize that there is much less people interested in this architecture
> >but it's much more than zero.
>
> I'm probably one of the few people still running Fedora on a machine that
> uses i686, that can't use x86_64. The machine is around 15 years old and is
> costly to get replacement parts for and I'm running out of spares. I was
> supposed to replace the machine last month, but needed another month to
> save up enough to buy the rest of the replacement. I've actually work with
> upstream to get kernel bugs fixed for this machine.
>
> Unfortunately I run rawhide and things got shut down a little sooner
> than I hoped, so I'm not getting updates right now and don't want to go
> back to f30 with the short horizon for retirement (though I did grab an
> f30 kernel).
>
> I don't think you are going to find many people who both run Fedora and
> have to use i686.
>
> There is a cost to keeping things running on i686 and it doesn't look like
> it is worth paying right now. And things are looking to get worse rather
> than better.
>
> You have options. You can switch to another distro that will support i686
> for a while yet. Use f30 until it's EOL (or beyond if the machines are
> isolated). Or maintain your own distro. The tools for Fedora are open,
> so you could set up your own koji instance drawing from Fedora and applying
> your fixes where needed. Getting started will probably be hard, but once
> things are running you'll be OK until there is a key bug you can't get
> fixed.
There are at least 4 people in this thread alone that are running Fedora on
x86 systems.
Do these 4 people want to revive the x86 SIG and take on the work of
dealing with 32-bit x86 bugs? Because they *do* exist and do cause
problems...
--
真実はいつも一つ！/ Always, there's only one truth!
7:35 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Tue, 10 Sep 2019 08:00:52 -0400
Neal Gompa <ngompa13(a)gmail.com> wrote:
On Tue, Sep 10, 2019 at 12:24 AM John M. Harris Jr.
<johnmh(a)splentity.com> wrote:
>
> On Monday, September 9, 2019 10:29:23 AM MST Bruno Wolff III wrote:
> > On Mon, Sep 09, 2019 at 14:52:07 -0000,
> > vvs vvs <vvs009(a)gmail.com> wrote:
> >
[...]
>
[...]
> >
> > I'm probably one of the few people still running Fedora on a machine that
> > uses i686, that can't use x86_64. The machine is around 15 years old and
is
> > costly to get replacement parts for and I'm running out of spares. I was
> > supposed to replace the machine last month, but needed another month to
> > save up enough to buy the rest of the replacement. I've actually work with
> > upstream to get kernel bugs fixed for this machine.
> >
> > Unfortunately I run rawhide and things got shut down a little sooner
> > than I hoped, so I'm not getting updates right now and don't want to
go
> > back to f30 with the short horizon for retirement (though I did grab an
> > f30 kernel).
> >
> > I don't think you are going to find many people who both run Fedora and
> > have to use i686.
> >
> > There is a cost to keeping things running on i686 and it doesn't look like
> > it is worth paying right now. And things are looking to get worse rather
> > than better.
> >
> > You have options. You can switch to another distro that will support i686
> > for a while yet. Use f30 until it's EOL (or beyond if the machines are
> > isolated). Or maintain your own distro. The tools for Fedora are open,
> > so you could set up your own koji instance drawing from Fedora and applying
> > your fixes where needed. Getting started will probably be hard, but once
> > things are running you'll be OK until there is a key bug you can't get
> > fixed.
>
> There are at least 4 people in this thread alone that are running Fedora on
> x86 systems.
Do these 4 people want to revive the x86 SIG and take on the work of
dealing with 32-bit x86 bugs? Because they *do* exist and do cause
problems...
I'm also using several Fedora/i686 machines and I'd like to help keep
this branch. As often, the problem is with the lack of time and the fact
that I do not know the full range of work to be done. But if one of
the current experienced i686 maintainers is willing to continue, I'll join.
I have some experience with creating and managing RPM packages.
Can I register somewhere as interested in this job?
--
Thanks, Franta Hanzlik
4:14 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 9/7/19 8:44 PM, Victor V. Shkamerda wrote:
There are reasons why using x86_64 kernel with i686 userland might be
a better option.
Because i686 has tons of unresolved bugs: it has no upstream support, no
maintainers and even testers with real hardware.
Do **YOU** want to be a i686-arch Linux kernel maintainer?
In such case using i686 userland on a x86_64 kernel provides much
more free memory than using 64-bit userland.
And no security at all due to absent ASLR support.
And of course there is still an option to switch to another OS.
Another GNU/Linux distributions have either dropped i686 support (Arch),
or they will do it soon (Ubuntu).
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
5:57 a.m.
I'm sorry, but where did you saw that I said something about i686 *kernel*? I think
that I explicitly mentioned *x86_64* kernel with i686 userland and described why it could
be beneficial for some users with limited memory.
As for security, I don't think that running your own computer in a tightly controlled
environment should be *that* dangerous. At least many users did it for years without
problems. That looks like a scare. In either case it's the user who should decide
what's best for him. I don't think that educated grown-up people should be treated
like babies.
Other distributions might drop it or not, we'll see. At least Debian is not dropping
it yet. But this is a moot point now. After all those discussions I see that nobody really
cares about user interests here. At least in Debian's case they stated that their
users interests is of utmost priority to them in contrast to just useless technical
innovation. And I'm not a proponent of consumerism. So take it lightly.
4:20 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 9/8/19 3:57 AM, vvs vvs wrote:
Other distributions might drop it or not, we'll see. At least
Debian is not dropping it yet. But this is a moot point now. After all those discussions I
see that nobody really cares about user interests here. At least in Debian's case they
stated that their users interests is of utmost priority to them in contrast to just
useless technical innovation. And I'm not a proponent of consumerism. So take it
lightly.
You seem to be missing the point. This is a volunteer project and at
this time there is no one volunteering to maintain the i686
architecture. There appear to be some users, but very few.
https://admin.fedoraproject.org/mirrormanager/statistics/2019-09-08/archs
(Yes, I know about accuracy of these statistics, but the ratio is clear.)
4:28 p.m.
On Sun, Sep 8, 2019 at 7:00 AM vvs vvs <vvs009(a)gmail.com> wrote:
I'm sorry, but where did you saw that I said something about i686 *kernel*? I think
that I explicitly mentioned *x86_64* kernel with i686 userland and described why it could
be beneficial for some users with limited memory.
As for security, I don't think that running your own computer in a tightly controlled
environment should be *that* dangerous. At least many users did it for years without
problems. That looks like a scare. In either case it's the user who should decide
what's best for him. I don't think that educated grown-up people should be treated
like babies.
Other distributions might drop it or not, we'll see. At least Debian is not dropping
it yet. But this is a moot point now. After all those discussions I see that nobody really
cares about user interests here. At least in Debian's case they stated that their
users interests is of utmost priority to them in contrast to just useless technical
innovation. And I'm not a proponent of consumerism. So take it lightly.
You know, rather than complaining, you could revive the x86 SIG and
help us support it?
Richard Stallman, like many others, described freedom of choice
insofar as freedom to contribute and use. He often uses the phrases
"helping your neighbor" or "share with your neighbor", and this is a
core aspect of Free Software.
None of us will turn away assistance for maintaining i686 userland if
there is truly interest in it. It's being retired because no one
stepped up in the past 18 months to help maintain it.
Even I, who needs it in some circumstances, am already spread so
thinly that I cannot help with i686-specific issues very much, so I
did not become a member of the x86 SIG. But if this is something that
is important to you, then *please* help to restore it.
Proper architecture support does not come without effort, and no one
has been supplying any.
I promise you, *all* major Linux distributions, and many minor ones
have been having variations of this conversation. Expect to see more
distributions dropping 32-bit x86 support over the next year or so as
people stop helping to maintain the architecture.
--
真実はいつも一つ！/ Always, there's only one truth!
9:58 a.m.
I will do whatever I can and it's not much for ANY architecture, x86_64 is not an
exception. That's because I'm not very young and have a lot of other more
important activities which is not related to computers.
That said, I'm not expecting very much in return either. If it would somehow work on a
level which was usual for RMS era it would be enough for me. I've used Linux on my own
in many cases. The only thing that I expect from any Linux distribution is to just BUILD
it for me. Because it's impossible to rebuild so many packages with my very limited
resources. I'm not asking for full blow support, but leaving even semi-broken
repository intact would be a great help for me and may be others who know from which side
to use computers.
9:05 p.m.
On Sun, Sep 8, 2019 at 7:00 AM vvs vvs <vvs009(a)gmail.com> wrote:
I'm sorry, but where did you saw that I said something about i686 *kernel*? I think
that I explicitly mentioned *x86_64* kernel with i686 userland and described why it could
be beneficial for some users with limited memory.
And a child with no vaccines isn't that much of a danger to the
community. Until someone opens a window, or forgets to wash a glass,
and the *other* unvaccinated children form a wonderful way to spread
an infection.
As for security, I don't think that running your own computer in
a tightly controlled environment should be *that* dangerous. At least many users did it
for years without problems. That looks like a scare. In either case it's the user who
should decide what's best for him. I don't think that educated grown-up people
should be treated like babies.
There is "deciding what's best for him". There is also "supporting
them inem in an unmaintainable and unsecurable environment, at the
expense of disk space and mirror space and build time and bugzilla
resources for a dangerously obsolete architecture.
Other distributions might drop it or not, we'll see. At least
Debian is not dropping it yet. But this is a moot point now. After all those discussions I
see that nobody really cares about user interests here. At least in Debian's case they
stated that their users interests is of utmost priority to them in contrast to just
useless technical innovation. And I'm not a proponent of consumerism. So take it
lightly.
The heck? If you know of others who need or want i686 architecture for
reasons other than theoretical completeness, please encourage them to
speak up. And offer to do some of the work.
10:43 p.m.
On Sunday, September 8, 2019 7:05:39 PM MST Nico Kadel-Garcia wrote:
On Sun, Sep 8, 2019 at 7:00 AM vvs vvs <vvs009(a)gmail.com>
wrote:
>
>
> I'm sorry, but where did you saw that I said something about i686
> *kernel*? I think that I explicitly mentioned *x86_64* kernel with i686
> userland and described why it could be beneficial for some users with
> limited memory.
And a child with no vaccines isn't that much of a danger to the
community. Until someone opens a window, or forgets to wash a glass,
and the *other* unvaccinated children form a wonderful way to spread
an infection.
> As for security, I don't think that running your own computer in a tightly
> controlled environment should be *that* dangerous. At least many users
> did it for years without problems. That looks like a scare. In either
> case it's the user who should decide what's best for him. I don't think
> that educated grown-up people should be treated like babies.
There is "deciding what's best for him". There is also "supporting
them inem in an unmaintainable and unsecurable environment, at the
expense of disk space and mirror space and build time and bugzilla
resources for a dangerously obsolete architecture.
> Other distributions might drop it or not, we'll see. At least Debian is
> not dropping it yet. But this is a moot point now. After all those
> discussions I see that nobody really cares about user interests here. At
> least in Debian's case they stated that their users interests is of
> utmost priority to them in contrast to just useless technical innovation.
> And I'm not a proponent of consumerism. So take it lightly.
The heck? If you know of others who need or want i686 architecture for
reasons other than theoretical completeness, please encourage them to
speak up. And offer to do some of the work.
I fail to see how a comparison of x86 to a disease is really relevant. If you
really want to go that route, I'll tell you now that x86 is no more
"unsecurable" than x64, both arches have security issues, and it's
unavoidable. There are also vulnerabilities with specific implementations.
11:06 p.m.
On Sun, Sep 8, 2019 at 11:44 PM John M. Harris Jr. <johnmh(a)splentity.com> wrote:
On Sunday, September 8, 2019 7:05:39 PM MST Nico Kadel-Garcia wrote:
> On Sun, Sep 8, 2019 at 7:00 AM vvs vvs <vvs009(a)gmail.com> wrote:
>
> >
> >
> > I'm sorry, but where did you saw that I said something about i686
> > *kernel*? I think that I explicitly mentioned *x86_64* kernel with i686
> > userland and described why it could be beneficial for some users with
> > limited memory.
>
> And a child with no vaccines isn't that much of a danger to the
> community. Until someone opens a window, or forgets to wash a glass,
> and the *other* unvaccinated children form a wonderful way to spread
> an infection.
I fail to see how a comparison of x86 to a disease is really
relevant. If you
really want to go that route, I'll tell you now that x86 is no more
"unsecurable" than x64, both arches have security issues, and it's
unavoidable. There are also vulnerabilities with specific implementations.
You snipped the part about how few if any people, including primary
software authors, are supporting x86 architectures anymore, so they
will not be maintained or patched. Thus, they will not be protected
against attacks, even obsolete attacks. If there are more than a few
such machines, and they are not completely isolated, i.e. they are
permitted to play with the vaccinated children, they can form pools of
vulnerable hosts and defeat the "herd immunity" from the generally
better maintained and supported software.
It's the pool of unmaintained and unmaintainable software I'm
expressing a concern about. If you'd care to take on the task of
supporting the architecture, of porting patches and testing them,
well, the world has many freedoms and this is one of them. I just
don't think you'll have many clients as the architecture has almost
universally been discarded. There are few tools, like FreeDOS and
wine, for running quite obsolete software, that may still benefit from
the availability of x86 libraries in Fedora. Maybe even Xen? But not
many.
4:52 a.m.
On Sunday, September 8, 2019 9:06:43 PM MST Nico Kadel-Garcia wrote:
On Sun, Sep 8, 2019 at 11:44 PM John M. Harris Jr.
<johnmh(a)splentity.com>
wrote:
>
>
> On Sunday, September 8, 2019 7:05:39 PM MST Nico Kadel-Garcia wrote:
>
> > On Sun, Sep 8, 2019 at 7:00 AM vvs vvs <vvs009(a)gmail.com> wrote:
> >
> >
> >
> > >
> > >
> > >
> > > I'm sorry, but where did you saw that I said something about i686
> > > *kernel*? I think that I explicitly mentioned *x86_64* kernel with
> > > i686
> > > userland and described why it could be beneficial for some users with
> > > limited memory.
> >
> >
> >
> > And a child with no vaccines isn't that much of a danger to the
> > community. Until someone opens a window, or forgets to wash a glass,
> > and the *other* unvaccinated children form a wonderful way to spread
> > an infection.
> I fail to see how a comparison of x86 to a disease is really relevant. If
> you
really want to go that route, I'll tell you now that x86 is no more
> "unsecurable" than x64, both arches have security
issues, and it's
> unavoidable. There are also vulnerabilities with specific
> implementations.
You snipped the part about how few if any people, including primary
software authors, are supporting x86 architectures anymore, so they
will not be maintained or patched. Thus, they will not be protected
against attacks, even obsolete attacks. If there are more than a few
such machines, and they are not completely isolated, i.e. they are
permitted to play with the vaccinated children, they can form pools of
vulnerable hosts and defeat the "herd immunity" from the generally
better maintained and supported software.
It's the pool of unmaintained and unmaintainable software I'm
expressing a concern about. If you'd care to take on the task of
supporting the architecture, of porting patches and testing them,
well, the world has many freedoms and this is one of them. I just
don't think you'll have many clients as the architecture has almost
universally been discarded. There are few tools, like FreeDOS and
wine, for running quite obsolete software, that may still benefit from
the availability of x86 libraries in Fedora. Maybe even Xen? But not
many.
While I don't have statistics on that, all of the anecdotal evidence supports
that vendors are still "supporting" 32 bit software. In fact, nearly all
proprietary software for RHEL, for example, is 32 bit.
That's now how vulnerabilities work, and just being 64 bit doesn't solve any
security issue.
i686 has not been "discarded". I have no clue where this idea comes from.
5:40 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Mon, Sep 09, 2019 at 02:52:43AM -0700, John M. Harris Jr. wrote:
While I don't have statistics on that, all of the anecdotal
evidence supports
that vendors are still "supporting" 32 bit software. In fact, nearly all
proprietary software for RHEL, for example, is 32 bit.
The EDA tools I'm forced to use dropped support for 32-bit systems in
2015. Even before that, I recall my own testing showing that the 64-bit
versions were noticably faster, thanks to architectural improvements
inherent to x86_64.
That's now how vulnerabilities work, and just being 64 bit
doesn't solve any
security issue.
All else being equal, it allows ASLR to be considerably more effective.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
High Springs, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
6:43 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 9/9/19 11:52 AM, John M. Harris Jr. wrote:
That's now how vulnerabilities work, and just being 64 bit
doesn't solve any
security issue.
https://en.wikipedia.org/wiki/Address_space_layout_randomization
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
6:47 a.m.
On Monday, September 9, 2019 4:43:18 AM MST Vitaly Zaitsev via devel wrote:
On 9/9/19 11:52 AM, John M. Harris Jr. wrote:
> That's now how vulnerabilities work, and just being 64 bit doesn't solve
> any security issue.
https://en.wikipedia.org/wiki/Address_space_layout_randomization
ASLR has nothing to do with the wild claims made in that email, that having an
x86 system will somehow taint or 'infect' other systems. Additionally, you
don't need to run a 64 bit system to get ASLR.
7:16 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 9/9/19 1:47 PM, John M. Harris Jr. wrote:
ASLR has nothing to do with the wild claims made in that email, that
having an
x86 system will somehow taint or 'infect' other systems. Additionally, you
don't need to run a 64 bit system to get ASLR.
i686 app has only 4 GB of virtual address space (2 GB for user-space and
2 GB for kernel space), so ASLR is ineffective.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
8:22 a.m.
On Monday, September 9, 2019 5:16:23 AM MST Vitaly Zaitsev via devel wrote:
On 9/9/19 1:47 PM, John M. Harris Jr. wrote:
> ASLR has nothing to do with the wild claims made in that email, that
> having an
x86 system will somehow taint or 'infect' other systems.
> Additionally, you don't need to run a 64 bit system to get
ASLR.
i686 app has only 4 GB of virtual address space (2 GB for user-space and
2 GB for kernel space), so ASLR is ineffective.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
The system I'm sending this email from only has 4 GiB of memory in total. Does
that mean that this system makes ASLR completely ineffective? Should this arch
also be removed from Fedora, because of that?
8:42 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Mon, Sep 09, 2019 at 06:22:46AM -0700, John M. Harris Jr. wrote:
The system I'm sending this email from only has 4 GiB of memory
in
total. Does that mean that this system makes ASLR completely
ineffective? Should this arch also be removed from Fedora, because of
that?
*Address Space* is not the same as *Physical Memory*.
I suggest you educate yourself on the difference between the two, as
that distinction is perhaps the fundamental underpinning of memory
management.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
High Springs, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
11:20 a.m.
So, if I'd start to use Debian i686 instead of Fedora or will use ARM32 device instead
of ARM64 the world will be a safer place? Also, I was told that maintaining i686 Fedora
code base myself would be fine, but in the same time I'm told that it's not
acceptable from the safety point of view. Why I'm smelling a contradiction here? In
short: the decision to drop i686 support is supported by contradicting statements, while
at the same time if I want to be taken seriously, I should bring strong evidence.
That's very objective discussion.
11:21 p.m.
On Monday, September 9, 2019 6:42:35 AM MST Solomon Peachy wrote:
On Mon, Sep 09, 2019 at 06:22:46AM -0700, John M. Harris Jr. wrote:
> The system I'm sending this email from only has 4 GiB of memory in
> total. Does that mean that this system makes ASLR completely
> ineffective? Should this arch also be removed from Fedora, because of
> that?
*Address Space* is not the same as *Physical Memory*.
I suggest you educate yourself on the difference between the two, as
that distinction is perhaps the fundamental underpinning of memory
management.
- Solomon
I don't think you understand what I was getting at. Cheap joke, essentially.
ASLR is only one part of the many layers of security in modern systems. It's
not worth getting rid of support for one of the most popular architectures
just because ASLR may be slightly less effective than on other architectures.
7:20 a.m.
* John M. Harris, Jr.:
ASLR has nothing to do with the wild claims made in that email, that
having an x86 system will somehow taint or 'infect' other
systems. Additionally, you don't need to run a 64 bit system to get
ASLR.
I'm not saying that the analogy is appropriate, but it is just not true
that 32-bit support is isolated. We will have to patch lots of code to
support the new *_time64 system calls, and that will impact everyone,
even for applications that are never run on 32-bit systems.
(This assumes that we can magically fix the native linker issues on
32-bit architectures.)
Thanks,
Florian
10:38 p.m.
On Sunday, September 8, 2019 3:57:22 AM MST vvs vvs wrote:
I'm sorry, but where did you saw that I said something about i686
*kernel*?
I think that I explicitly mentioned *x86_64* kernel with i686 userland and
described why it could be beneficial for some users with limited memory.
As for security, I don't think that running your own computer in
a tightly
controlled environment should be *that* dangerous. At least many users did
it for years without problems. That looks like a scare. In either case it's
the user who should decide what's best for him. I don't think that educated
grown-up people should be treated like babies.
Other distributions might drop it or not, we'll see. At least
Debian is not
dropping it yet. But this is a moot point now. After all those discussions
I see that nobody really cares about user interests here. At least in
Debian's case they stated that their users interests is of utmost priority
to them in contrast to just useless technical innovation. And I'm not a
proponent of consumerism. So take it lightly.
If this distro drops i686 kernels, they're also going to drop the userland.
They also shouldn't drop the kernel, of course.
10:35 p.m.
On Saturday, September 7, 2019 11:44:59 AM MST Victor V. Shkamerda wrote:
I totally agree with that view. Making such decisions without public
discussion is not respecting user's freedom of choice. And this list
doesn't count as a public discussion. Nobody will know about it outside a
very closed circle. If you don't know exact numbers or reasons why people
still use that architecture, then rushing to drastic measures just won't
have enough rationale and will be viewed as a lack of care.
The reasons to use 32-bit userland might be more than you think.
There are
different use scenarios besides browsing Internet or virtualization. There
could be a high cost of upgrade (think about replacing many computers at
once). There could be a unique peripheral equipment. There could be
compatibility concerns. And there could be just not enough memory.
OTOH, what could justify removing repository entirely? Why not make
it an
option which could be installed on demand? That would be better than leave
everyone out on the cold. Is the cost to build it really that high? Safety
could not be a reason in a tightly contained environment. Let users decide
for themselves.
There is no black and white distinction: multilib or i686 kernel.
There are
reasons why using x86_64 kernel with i686 userland might be a better
option. Some older office computers were manufactured with 64-bit CPU but
without support for more than 4 GB RAM. In such case using i686 userland on
a x86_64 kernel provides much more free memory than using 64-bit userland.
Such configuration is unsupported, but neither is i686. Giving users a
choice is always better than decide for them behind their backs.
And of course there is still an option to switch to another OS. Do I
need to
remind that Linux and Red Hat were not created just to replace some other
OS, but to respect freedom of choice? What happened that this is not even
mentioned in such discussions? Is this just business as usual?
Wait, what happened to x86 becoming a secondary architecture? You know, there
are vendors that still create and sell x86 systems today.
12:36 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Sun, 2019-09-08 at 20:35 -0700, John M. Harris Jr. wrote:
Wait, what happened to x86 becoming a secondary architecture? You know, there
are vendors that still create and sell x86 systems today.
That already happened several releases ago. But secondary arches
failing blocks package builds in Fedora, and enough i686 package builds
fail now that it's become a problem, and - as Neal points out - part of
the deal with i686 being a secondary arch was that there would be an
active SIG to take care of arch-specific problems, like there is for
each of the *other* secondary arches. But that didn't really pan out:
the x86 list has had 38 mails, ever, most of which are people asking
for someone to look at an x86-specific problem and...no-one doing it.
Some folks did attempt to help, but there really wasn't enough
time+expertise there to make it viable.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9:41 a.m.
Ok, if that's so hard then I'm apologize for not recognizing the pain.
OTOH, if Debian has resources to maintain the support for at least next five years it
means one of two things: either they have more resources than Fedora, or something is
wrong with your assessment.
I'd help with maintaining 32-bit userland as much as I can. But I'm afraid
that's not much. From my point of view the only support I need is that damn thing
worked most of the time. And there no more bugs in i686 userland than in x86_64 one. If
you really need so much patching than I simply don't understand why it still works on
other supported 32-bit arches all over the world, e.g. ARM.
P.S. And what it's all supposed to do with "Linux is NOT about choice"? This
looks like just as an excuse to me for some other thing.
10:02 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Mon, Sep 09, 2019 at 02:41:15PM -0000, vvs vvs wrote:
OTOH, if Debian has resources to maintain the support for at least
next five years it means one of two things: either they have more
resources than Fedora, or something is wrong with your assessment.
Or (3) Debian defines "support" quite differently than Fedora.
P.S. And what it's all supposed to do with "Linux is NOT
about
choice"? This looks like just as an excuse to me for some other thing.
s/some other/more relevant/
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
High Springs, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
10:44 a.m.
I'm happy with any support no matter how it is defined. In fact I didn't get very
much support from Fedora either over more than 20 years, so my expectations are quite
low.
If there is something more relevant than freedom of choice, then there is no point arguing
further, because I value community relations over any technical reasons.
10:59 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Mon, Sep 09, 2019 at 03:44:49PM -0000, vvs vvs wrote:
If there is something more relevant than freedom of choice, then
there
is no point arguing further, because I value community relations over
any technical reasons.
You seem to forget that "freedom of choice" also applies to those
working on Fedora...
- Solomon
--
Solomon Peachy pizza at shaftnet dot org
High Springs, FL ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.
11:26 a.m.
No I didn't, but I must be sure that you speak on behalf of everyone before making my
choices.
11:50 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
vvs vvs píše v Po 09. 09. 2019 v 15:44 +0000:
I'm happy with any support no matter how it is defined. In fact
I
didn't get very much support from Fedora either over more than 20
years, so my expectations are quite low.
You seem to have a rather narrow view of support. It's not just someone
waiting for your email/phone call to help you with your issues, that's
just a small part of software support, it's mostly making sure that
bugs and primarily security issues get fixed and delivered to you (and
believe me it's not such a sure thing among Linux distros), and if
you've been using Fedora for 20 years, you have received a lot of that.
And you fail to understand it's something the Fedora Project is
currently not quite capable to deliver for x86.
If you expect the Fedora Project to just build packages for x86 and
throw them over the wall on users, then I'm sorry to disappoint you,
but that's not how Fedora has ever worked and I hope it never will.
So as others already suggested: if you want the x86 architecture back,
revive the x86 SIG, gather enough volunteers, make sure you can meet
expectations of support at least at the level of secondary
architectures, create a proposal backed by enough committed volunteers,
submit it to FESCo, and I'm pretty sure you'll have your beloved
architecture back.
Jiri
1:15 p.m.
Thanks for the suggestion. But I'm sure that I don't need so much bureaucracy just
to run my little errands. If that's how Fedora is operated, than it won't make
much difference for me to just using another distribution.
BTW, that just means that Fedora is refusing to provide much needed services even to a
people who are ready to accept most of that support burden themselves and I'm one of
them.
2:31 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 9/9/19 11:15 AM, vvs vvs wrote:
BTW, that just means that Fedora is refusing to provide much needed
services even to a people who are ready to accept most of that support burden themselves
and I'm one of them.
I don't understand how you keep completely missing the point. No one is
"refusing" to provide services. Fedora is maintained by VOLUNTEERS. If
there is no one interested in doing certain work, it doesn't get done.
At this time there is no one interested in i686 that has the time to
keep it going. It won't keep working if no one is involved. If you are
going to keep insisting that other people have to do what you want, then
please do find another distro.
Have you even tried running the 64-bit version to see if it really has
the problems you think it will?
4:15 p.m.
And why people are not reading all the answers? That was a rhethorical question.
I said it already several times, that I don't need volunteers to fix things for me! I
just need an already built repository which I could just use and fix things myself if
needed. But Fedora is refusing to provide such repository which was built automatically by
Koji. I don't care if something was broken in that repository as long as I can access
those binaries and fix them if needed.
But no matter how frequently I repeat it, I'm always get answers that I'm
insisting that somebody should work for me. No I'm not. If it's so difficult to
keep that repository around, then it's just fine with me and I'll find another
way. But that would be very unfortunate.
4:33 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 9/9/19 2:15 PM, vvs vvs wrote:
I said it already several times, that I don't need volunteers to
fix things for me! I just need an already built repository which I could just use and fix
things myself if needed. But Fedora is refusing to provide such repository which was built
automatically by Koji. I don't care if something was broken in that repository as long
as I can access those binaries and fix them if needed.
But that's just it, there is no automatically built repository. And
when there is a problem with a package not building for i686, it breaks
it for everyone.
You also didn't answer the question from my previous email:
Have you even tried running the 64-bit version to see if it really has
the problems you think it will?
5:35 p.m.
Oh, brother...
So, you are insisting that Koji just doesn't work without any assistance? And that
it's impossible to build a separate i686 repository without affecting all others? And
that you can't exclude that architecture for a specific package? If that's the
case then it's very different from what I already knew.
I didn't answered your other question because I've answered the same question
several times already. Yes, I have a use cases where I'll get a severe performance hit
if I was not careful. And this is related to available memory and swapping. And I
can't afford losing yet another hundred megabytes for no particular reason. And I
don't think that constantly upgrading my computer is the answer. I remember times when
it was possible to install Red Hat Linux on a computer with 32 MB of RAM. Going in that
direction I should do nothing but upgrade every now and then even though I don't want
my computer to affect my activities that hard. And some people thought that Windows 95 was
a memory hog!
Honestly, I'm tired. And I don't think that arguing further will be of any help.
I'm convinced that I really have no other choice but just use some Linux distribution
that doesn't requires me to spend so much time explaining to everyone why I need
things in my life to be the way I need it.
And it reminds me about some guy who maintains some quite popular software. He used some
old SUSE until he was forced to upgrade. After struggling with consequences he just bought
Apple computer with Mac OS. He explained that he is just too old to waste so much time on
unimportant things. I don't remember his name.
6:34 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 9/9/19 3:35 PM, vvs vvs wrote:
So, you are insisting that Koji just doesn't work without any
assistance? And that it's impossible to build a separate i686 repository without
affecting all others?
We used to build secondary architectures separately, using koji-shadow
to chase the primary builds. This had plenty of problems of its own. You
can read a bit below, and maybe others can provide more history.
https://fedoraproject.org/wiki/Architectures/RedefiningSecondaryArchitect...
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
And that you can't exclude that architecture for a specific
package?
You can, but if everyone gets free license to ignore i686, I think it
won't be long before you find yourself without some key packages.
6:35 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 9/9/19 3:35 PM, vvs vvs wrote:
I didn't answered your other question because I've answered
the same question several times already. Yes, I have a use cases where I'll get a
severe performance hit if I was not careful. And this is related to available memory and
swapping. And I can't afford losing yet another hundred megabytes for no particular
reason. And I don't think that constantly upgrading my computer is the answer. I
remember times when it was possible to install Red Hat Linux on a computer with 32 MB of
RAM. Going in that direction I should do nothing but upgrade every now and then even
though I don't want my computer to affect my activities that hard. And some people
thought that Windows 95 was a memory hog!
In all your emails, you have never said that you've tried to use a
64-bit userspace. You keep making this claim that if you did you would
lose "another hundred megabytes", but have you actually tried it?
You can still run Linux in an extremely limited amount of RAM. I do it
all the time with openwrt. But do you really want to go back to the
level of functionality you had back then?
6:55 a.m.
Did I? I thought that I've said that I'm using x86_64 kernel right now and that I
have my memory stretched to the limits already.
But yes, I've experimented with x86_64 userland some time ago, I don't remember
exact numbers but I think that I've lost 100-200 MB of memory. And I have not much
time to experiment every time something have changed.
You are right that I can reduce memory footprint by carefully tuning my system. But
that's what I've already did and Fedora breaks it just too often. I'm used to
work without GNOME on my other computer that have only 32-bit CPU. But it started to be
very painful to upgrade to newer Fedora releases. So, when I've got 64-bit computer
I've just went with the flow and don't customize parts I'm not really
interested in. I want to spend on it as little time as possible. Going for my own Linux
from scratch is just not viable.
2:41 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 9/10/19 7:55 AM, vvs vvs wrote:
Did I? I thought that I've said that I'm using x86_64 kernel
right now and that I have my memory stretched to the limits already.
But yes, I've experimented with x86_64 userland some time ago, I don't remember
exact numbers but I think that I've lost 100-200 MB of memory. And I have not much
time to experiment every time something have changed.
You are right that I can reduce memory footprint by carefully tuning my system. But
that's what I've already did and Fedora breaks it just too often. I'm used to
work without GNOME on my other computer that have only 32-bit CPU. But it started to be
very painful to upgrade to newer Fedora releases. So, when I've got 64-bit computer
I've just went with the flow and don't customize parts I'm not really
interested in. I want to spend on it as little time as possible. Going for my own Linux
from scratch is just not viable.
Wait---so you are using 32-bit Gnome on a 64-bit capable CPU running
64-bit kernel? If the reason is to save 200MB of memory, you should
definitely try one of the memory-thrifty desktop environments like xfce.
You also said that you're running a memory-hungry non-Fedora
application, which you presumably compile yourself.
Therefore, it looks to me that you should try a 64-bit Fedora with a
memory-saving xfce, install a 32-bit GCC toolchain and compile your app
in 32-bit mode.
4:19 p.m.
Yes, I've already answered that. It's surely possible, but my experience shows
that putting too much efforts in a too broad customization doesn't pay off in the end.
Every time you'll upgrade to a new version it breaks.
As for using another desktop, I should seriously consider it. Probably I was too careless
by using Fedora's default preferences. But again, as my experience shows using
anything other than Gnome gives you worse support from developers. But I have nothing to
lose anyway.
1:05 a.m.
On Tuesday, September 10, 2019 12:41:14 PM MST Przemek Klosowski via devel
wrote:
On 9/10/19 7:55 AM, vvs vvs wrote:
> Did I? I thought that I've said that I'm using x86_64 kernel right now and
> that I have my memory stretched to the limits already.
>
>
> But yes, I've experimented with x86_64 userland some time ago, I don't
> remember exact numbers but I think that I've lost 100-200 MB of memory.
> And I have not much time to experiment every time something have
> changed.
>
>
> You are right that I can reduce memory footprint by carefully tuning my
> system. But that's what I've already did and Fedora breaks it just too
> often. I'm used to work without GNOME on my other computer that have only
> 32-bit CPU. But it started to be very painful to upgrade to newer Fedora
> releases. So, when I've got 64-bit computer I've just went with the flow
> and don't customize parts I'm not really interested in. I want to spend
> on it as little time as possible. Going for my own Linux from scratch is
> just not viable.
Wait---so you are using 32-bit Gnome on a 64-bit capable CPU running
64-bit kernel? If the reason is to save 200MB of memory, you should
definitely try one of the memory-thrifty desktop environments like xfce.
You also said that you're running a memory-hungry non-Fedora
application, which you presumably compile yourself.
Therefore, it looks to me that you should try a 64-bit Fedora with a
memory-saving xfce, install a 32-bit GCC toolchain and compile your app
in 32-bit mode.
Compiling his app as 32 bit would require 32 bit repositories for the
libraries he plans on linking.
- -
John Harris
1:48 a.m.
On Wednesday, September 11, 2019, John M. Harris Jr. <johnmh(a)splentity.com>
wrote:
On Tuesday, September 10, 2019 12:41:14 PM MST Przemek Klosowski via
devel
wrote:
> On 9/10/19 7:55 AM, vvs vvs wrote:
>
> > Did I? I thought that I've said that I'm using x86_64 kernel right now
and
> > that I have my memory stretched to the limits already.
>
> >
> >
> > But yes, I've experimented with x86_64 userland some time ago, I don't
> > remember exact numbers but I think that I've lost 100-200 MB of memory.
> > And I have not much time to experiment every time something have
> > changed.
>
> >
> >
> > You are right that I can reduce memory footprint by carefully tuning my
> > system. But that's what I've already did and Fedora breaks it just too
> > often. I'm used to work without GNOME on my other computer that have
only
> > 32-bit CPU. But it started to be very painful to upgrade to newer
Fedora
> > releases. So, when I've got 64-bit computer I've just went with the
flow
> > and don't customize parts I'm not really interested in. I want to
spend
> > on it as little time as possible. Going for my own Linux from scratch
is
> > just not viable.
>
> Wait---so you are using 32-bit Gnome on a 64-bit capable CPU running
> 64-bit kernel? If the reason is to save 200MB of memory, you should
> definitely try one of the memory-thrifty desktop environments like xfce.
>
> You also said that you're running a memory-hungry non-Fedora
> application, which you presumably compile yourself.
>
> Therefore, it looks to me that you should try a 64-bit Fedora with a
> memory-saving xfce, install a 32-bit GCC toolchain and compile your app
> in 32-bit mode.
Compiling his app as 32 bit would require 32 bit repositories for the
libraries he plans on linking.
Multilib is still supported so libraries are present in the repositories.
- -
John Harris
_______________________________________________
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
2:11 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 9/10/19 11:48 PM, drago01 wrote:
On Wednesday, September 11, 2019, John M. Harris Jr.
<johnmh(a)splentity.com <mailto:johnmh@splentity.com>> wrote:
Compiling his app as 32 bit would require 32 bit repositories for the
libraries he plans on linking.
Multilib is still supported so libraries are present in the repositories.
And to be really clear about it, those 32-bit multilib libraries are in
the 64-bit repository, so for now they aren't going away even if the
32-bit repo does.
11:54 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Tue, 10 Sep 2019 15:41:14 -0400
Przemek Klosowski via devel <devel(a)lists.fedoraproject.org> wrote:
Wait---so you are using 32-bit Gnome on a 64-bit capable CPU running
64-bit kernel? If the reason is to save 200MB of memory, you should
definitely try one of the memory-thrifty desktop environments like
xfce.
You also said that you're running a memory-hungry non-Fedora
application, which you presumably compile yourself.
Therefore, it looks to me that you should try a 64-bit Fedora with a
memory-saving xfce, install a 32-bit GCC toolchain and compile your
app in 32-bit mode.
This, a perfectly adequate solution. Or LXDE or mate or LXQt or fvwm
or just X with a simple xterm that he uses to start his custom app. I
think cinnamon or KDE would be roughly the same size as Gnome, so
probably not viable alternatives to reduce memory usage.
He could also compile a custom kernel tuned to his hardware from the
x86_64 src.rpm, so it is smaller. The spec file could even be set up to
build a 686 kernel from the source, if that is what he wants. He would
have to fix any problems himself, though, to do that. He could share
his results in copr for anyone wanting such a kernel.
https://fedoraproject.org/wiki/Building_a_custom_kernel
koji for the kernel
https://koji.fedoraproject.org/koji/packageinfo?packageID=8
1:12 p.m.
I did test some of these desktops in the past. From my experience LXDT should be just
fine. Anyway, thanks for reminding me, because I was so used to standard Fedora desktop
that completely forgot about such alternatives.
12:15 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 9/9/19 2:15 PM, vvs vvs wrote:
And why people are not reading all the answers? That was a
rhethorical question.
I said it already several times, that I don't need volunteers to fix things for me! I
just need an already built repository which I could just use and fix things myself if
needed. But Fedora is refusing to provide such repository which was built automatically by
Koji. I don't care if something was broken in that repository as long as I can access
those binaries and fix them if needed.
You are welcome to use the koji buildroot repo for that.
https://kojipkgs.fedoraproject.org/repos/f30-build/latest
But no matter how frequently I repeat it, I'm always get answers
that I'm insisting that somebody should work for me. No I'm not. If it's so
difficult to keep that repository around, then it's just fine with me and I'll
find another way. But that would be very unfortunate.
It's more trouble than we think it's worth to compose a i686 repo and
distribute it to hundreds of mirrors and support bugs and issues in it.
kevin
2:08 p.m.
You are welcome to use the koji buildroot repo for that.
https://kojipkgs.fedoraproject.org/repos/f30-build/latest
Thanks. That would be just splendid, but won't it cease to exist after Fedora 30 EOL?
Then it's just a temporary workaround.
2:21 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 9/10/19 12:08 PM, vvs vvs wrote:
> You are welcome to use the koji buildroot repo for that.
> https://kojipkgs.fedoraproject.org/repos/f30-build/latest
Thanks. That would be just splendid, but won't it cease to exist after Fedora 30 EOL?
Then it's just a temporary workaround.
Yes, but then f31-build, f32-build, f33-build, etc will exist...
I don't think this will go away until we no long need multilib (ie,
steam and others move to 64bit).
kevin
2:01 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
In the interests of not making this thread a bunch longer, I am just
going to answer a number of things here in one place.
On 9/7/19 11:44 AM, Victor V. Shkamerda wrote:
I totally agree with that view. Making such decisions without public
discussion is not respecting user's freedom of choice. And this list doesn't count
as a public discussion. Nobody will know about it outside a very closed circle. If you
don't know exact numbers or reasons why people still use that architecture, then
rushing to drastic measures just won't have enough rationale and will be viewed as a
lack of care.
There was a lot of discussion on this list, in fesco tickets in fesco
meetings, on phoronix, etc.
I'm not sure what you mean by 'respecting users freedom of choice'. We
cannot possibly provide all choices that anyone wants or thinks they
want. Really it comes down to (in rough order of effectiveness):
* Try and convince people doing the work to provide/continue to provide
the thing you want, but realize that the people doing the work are under
no obligation here, you need to convince them there is some reason they
find compelling.
* Offer to do some / part / all of the work, but realize here too you
need to convince the people doing the work now that it's worth the time
/ resources to allow you to do the work (although this is a much better
'sell' than just convincing people.
It's pretty clear that i686 is dwindling as an arch. It was pretty clear
a few years ago when it was demoted to a alternative arch and the x86
sig was setup to try and work on issues that came up. No one really did
so, so it's time to take the next steps.
What work should be done? Please, be more specific. Right now
I'm
running a i686 userland and it works. If I would be able to build the
whole repository myself I'm pretty sure that most things will still
work. If it won't work I might try to fix it and contribute patches
back. But without that repository I can't even try it in the first place.
Lets step back a step here.
Why are you running a 32bit userspace? There's not really any advantage
(and some disadvantages) to doing so.
The koji buildroot repo will continue to be available if you want to
copy something, but as far as work to be done to move back to
distributing a i686 set of trees? I guess doing the release blocking
tests on i686 at Beta and Final might be a good start, but thats a ton
of work for one person... is there anyone else you have talked to that
wants to do this?
kevin
2:47 p.m.
I don't even know anyone whom I could address. I'm already spent too much time on
that list trying to convince everyone that I'm ready to take all the burden of using
unsupported packages, but was told that it's against Fedora policies. What much could
I do?
As for using i686 userland just look above in that thread, where I've already
explained that my memory is already stretched enough and I have not enough reasons to buy
a new computer just because some OS requirements. You should understand that computers are
not that important for many users. They have more important things in their life and using
Fedora is just a convenience. I can switch to another distribution if there is no other
choice, but the reasons for that decision are so obscure, that it required such a long
thread just to find it out. Also, it's not very convincing for end users when they get
a long description of bureaucratic reasons why they just can't use packages anymore
that they were already using and that other distribution happily provide.
I'm sorry if this caused a lot of traffic on this list, but I was not aware of that
problem up to the last moment. And you can expect some other users like me to complain
when they will be confronted with the fact. Just announcing it on the first page two years
ago would have avoided that problem.
3:24 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 9/9/19 12:47 PM, vvs vvs wrote:
I don't even know anyone whom I could address. I'm already
spent too much time on that list trying to convince everyone that I'm ready to take
all the burden of using unsupported packages, but was told that it's against Fedora
policies. What much could I do?
Having read the thread, you seem to miss the point that's been
repeatedly made: the packages occasionally fail to build, and someone
has to fix them. That act, fixing packages when they don't build is the
"support" that someone has to provide.
You can't use packages that don't exist. They don't exist unless
someone supports them. Therefore you can't use an unsupported package.
It's not because policy forbids it, it's because they don't exist
without the act of a human maintainer making them build (which is
described as "supporting" the package.)
Does that make sense?
4:21 p.m.
And if I don't use those packages, then why should I be unable to use everything else
just because there are some small problems? Especially because there are not much users of
that architecture anyway.
That happens all the time already and I see no big problem with that. If these packages
affect another architecture that would be a problem for them, but I think that decoupling
unsupported repositories should solve that problem. That would be good anyway for a number
of reasons.
2:11 a.m.
On 9/9/19 12:47 PM, vvs vvs wrote:
Having read the thread, you seem to miss the point that's been
repeatedly made: the packages occasionally fail to build, and someone
has to fix them. That act, fixing packages when they don't build is the
"support" that someone has to provide.
Koji still builds the i686 packages by default even on F32
You can't use packages that don't exist. They don't
exist unless
someone supports them. Therefore you can't use an unsupported package.
It's not because policy forbids it, it's because they don't exist
without the act of a human maintainer making them build (which is
described as "supporting" the package.)
Does that make sense?
No!
8:23 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
Dne 09. 09. 19 v 21:01 Kevin Fenzi napsal(a):
The koji buildroot repo will continue to be available if you want to
copy something, but as far as work to be done to move back to
distributing a i686 set of trees? I guess doing the release blocking
tests on i686 at Beta and Final might be a good start, but thats a ton
of work for one person... is there anyone else you have talked to that
wants to do this?
I want to state one consequence. As there is no compose, the mock configs fedora-31-i386
and fedora-rawhide-i386 will
point directly to Koji.
https://github.com/rpm-software-management/mock/commit/a0c5d493c362c993d6...
All local builds into this chroot will likely be slow.
And I will likely remove (or move to /etc/mock/eol/ ) those files in near future.
This may affect CI of 3rd parties.
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
3:26 a.m.
New subject: F31+ i386 chroots build against Koji buildroots [was Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories]
On Tuesday, September 10, 2019 3:23:29 PM CEST Miroslav Suchý wrote:
Dne 09. 09. 19 v 21:01 Kevin Fenzi napsal(a):
> The koji buildroot repo will continue to be available if you want to
> copy something, but as far as work to be done to move back to
> distributing a i686 set of trees? I guess doing the release blocking
> tests on i686 at Beta and Final might be a good start, but thats a ton
> of work for one person... is there anyone else you have talked to that
> wants to do this?
I want to state one consequence. As there is no compose, the mock configs fedora-31-i386
and fedora-rawhide-i386 will
point directly to Koji.
https://github.com/rpm-software-management/mock/commit/a0c5d493c362c993d6...
All local builds into this chroot will likely be slow.
And I will likely remove (or move to /etc/mock/eol/ ) those files in near future.
This may affect CI of 3rd parties.
FTR, we changed this in Copr as well - otherwise _all_ the builds in
fedora-31-i386+ would already fail. So please note that the fedora 31+
`i386` build chroot are _different_ from other architectures (in
copr/mock), and really re-consider whether you want to build against them.
Pavel
4:52 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
Hi Kevin,
On Sun, 2019-07-14 at 15:50 -0700, Kevin Fenzi wrote:
On 7/14/19 2:35 PM, John Reiser wrote:
> Kevin Fenzi wrote:
> > Neal Gompa wrote:
>
> [[snip]]
>
> > > This will also make it impossible for people to locally do multilib
> > > build/installs. It will remove COPR’s ability to do the same. For that
> > > reason alone, I don’t particularly want this change to happen.
> > Can you expand on what you mean by 'locally do' ?
>
> I want to run "gcc -m32 -o my_app-i686 *.o ..." locally on my own box
> to build executables that run as 32-bit apps on multilib x86_64.
> For some apps 2GB of malloc() arena is plenty, and they run faster
> in 32-bit mode because a 64-byte cache line contains 16 pointers
> instead of only 8.
This should still work, unless there are libraries you use that are not
multilib.
> [[snip]]
>
> > Finally, if you would prefer this not happen now, is there a time when
> > you would further down the road? Whats the critera/goalpost/cutoff?
>
> One year after Red Hat Enterprise Linux version 7 reaches end-of-support.
> It would be handy for Fedora to have 32-bit *-devel packages until then.
We will still have 32bit devel packages in the x86_64 repos after this
change. It doesn't affect multilib at all. It only stops building and
publishing the 'pure' i386 repos on the mirror network.
I don't think we can drop multilib until at least steam/wine are ready
for it at least.
Being able to build 32bit is useful during development too. It is much
easier to expose some memory issues. For example fuzzing some
applications is best done against the 32bit variant to reduce the
memory search space. So imho making sure Fedora is a good developer
distro makes sure multilib gcc -m32 keeps working. So you need at least
the foobar-devel.i686 libraries in your x86_64 repository.
Could you explain a bit more how this (keeps) working? I think my
mental model of how Fedora repositories work in the case of multilib
devel packages is a bit flawed. At first I assumed that this suggestion
would kill that. Because I was under the impression that it worked by
having the i386 repository be part of the x86_64 package repository. So
removing the i686 repositories would mean removing all 32bit packages
from x86_64. But from your explanation above it seems that is not how
it works. So if there are no i686 repositories, then where/how do the
32bit multilib packages come from?
I think I am mixing up buildroots, koji targets, repositories in my
mind.
For example I maintain two packages that provide 32bit multilib
binaries. They are produced by the i686 koji target. Then elfutils-
devel.i686 (to create 32bit multilib binaries) and valgrind.i686 (to
run 32bit multilib binaries) are provided to the user because the i686
repository is part of the x86_64 repository (if I understand things
correctly). Will this just keep working, or will I have to make changes
to my packages to keep this working after the disappearance of the i686
repository?
Thanks,
Mark
9:56 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On Mon, Jul 15, 2019 at 11:52:50AM +0200, Mark Wielaard wrote:
Could you explain a bit more how this (keeps) working? I think my
mental model of how Fedora repositories work in the case of multilib
devel packages is a bit flawed. At first I assumed that this suggestion
would kill that. Because I was under the impression that it worked by
having the i386 repository be part of the x86_64 package repository. So
removing the i686 repositories would mean removing all 32bit packages
from x86_64. But from your explanation above it seems that is not how
it works. So if there are no i686 repositories, then where/how do the
32bit multilib packages come from?
I think I am mixing up buildroots, koji targets, repositories in my
mind.
Let me second that request. It would be great if somebody could
summarize the steps that lead to 32bit packages being installable on
amd64 machines. I know how the beginning (compilation in the
appropriate chroot), and the end (dnf install foo.i686), but the
middle is hazy.
For example I maintain two packages that provide 32bit multilib
binaries. They are produced by the i686 koji target. Then elfutils-
devel.i686 (to create 32bit multilib binaries) and valgrind.i686 (to
run 32bit multilib binaries) are provided to the user because the i686
repository is part of the x86_64 repository (if I understand things
correctly). Will this just keep working, or will I have to make changes
to my packages to keep this working after the disappearance of the i686
repository?
Zbyszek
10:08 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 15/07/2019 15:56, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jul 15, 2019 at 11:52:50AM +0200, Mark Wielaard wrote:
> Could you explain a bit more how this (keeps) working? I think my
> mental model of how Fedora repositories work in the case of multilib
> devel packages is a bit flawed. At first I assumed that this suggestion
> would kill that. Because I was under the impression that it worked by
> having the i386 repository be part of the x86_64 package repository. So
> removing the i686 repositories would mean removing all 32bit packages
> from x86_64. But from your explanation above it seems that is not how
> it works. So if there are no i686 repositories, then where/how do the
> 32bit multilib packages come from?
>
> I think I am mixing up buildroots, koji targets, repositories in my
> mind.
Let me second that request. It would be great if somebody could
summarize the steps that lead to 32bit packages being installable on
amd64 machines. I know how the beginning (compilation in the
appropriate chroot), and the end (dnf install foo.i686), but the
middle is hazy.
It definitely doesn't work as Mark thinks because only a subset
of the i686 packages are present in the x86_64 repository.
I've never really been sure how it decides what packages to
include but certainly the idea here that every 32 bit package
that you might need on a 64 bit system is present is false
because I actually have a list of additional packages that
get copied over in my local mirror ;-)
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
12:05 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 7/15/19 8:08 AM, Tom Hughes wrote:
On 15/07/2019 15:56, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jul 15, 2019 at 11:52:50AM +0200, Mark Wielaard wrote:
>> Could you explain a bit more how this (keeps) working? I think my
>> mental model of how Fedora repositories work in the case of multilib
>> devel packages is a bit flawed. At first I assumed that this suggestion
>> would kill that. Because I was under the impression that it worked by
>> having the i386 repository be part of the x86_64 package repository. So
>> removing the i686 repositories would mean removing all 32bit packages
>> from x86_64. But from your explanation above it seems that is not how
>> it works. So if there are no i686 repositories, then where/how do the
>> 32bit multilib packages come from?
>>
>> I think I am mixing up buildroots, koji targets, repositories in my
>> mind.
>
> Let me second that request. It would be great if somebody could
> summarize the steps that lead to 32bit packages being installable on
> amd64 machines. I know how the beginning (compilation in the
> appropriate chroot), and the end (dnf install foo.i686), but the
> middle is hazy.
It definitely doesn't work as Mark thinks because only a subset
of the i686 packages are present in the x86_64 repository.
I've never really been sure how it decides what packages to
include but certainly the idea here that every 32 bit package
that you might need on a 64 bit system is present is false
because I actually have a list of additional packages that
get copied over in my local mirror ;-)
So, this is how it works (as far as I recall off the top of my head):
You build a archfull package in koji. It's built for x86_64 and i686
(and the other arches).
pungi runs to compose things. It has a config (in pungi-fedora or bodhi
config) that tells it what to do for multilib. It has also config that
tells it what tag(s) to use for the compose, so it talks to koji and
asks about/gathers packages based on that tag.
Currently for rawhide that is:
multilib = [
('^Everything$', {
'x86_64': ['devel', 'runtime'],
})
]
# format: {arch|*: [packages]}
multilib_blacklist = {
'*': ['kernel', 'kernel-PAE*', 'kernel*debug*',
'dmraid-devel', 'kdeutils-devel', 'mkinitrd-devel',
'php-devel', 'java-*',
'httpd-devel', 'tomcat-native', 'php*', 'httpd',
'krb5-server', 'krb5-server-ldap', 'mod_*',
'ghc-*'
],
}
# format: {arch|*: [packages]}
multilib_whitelist = {
'*': ['libgnat', 'wine', 'lmms-vst',
'nspluginwrapper',
'libflashsupport', 'valgrind', 'perl-libs',
'redhat-lsb',
'yaboot', 'syslinux-extlinux-nonlinux',
'syslinux-nonlinux',
'syslinux-tftpboot', 'nosync', '*-static',
'apitrace-libs',
'fakeroot-libs', 'postgresql-odbc',
'mysql-connector-odbc',
'fakechroot-libs','mesa-vdpau-drivers', 'p11-kit-trust',
'mariadb-connector-odbc', 'compiler-rt',
'nvidia-query-resource-opengl-lib',
'ibus-libs', 'ibus-gtk2', 'ibus-gtk3',
'glib-networking'
],
}
So, that says to use the 'runtime' method of multilib, and then
explicitly add some packages and explicitly remove some. The orig idea
of 'runtime' was to allow runtime for i686 binaries on x86_64 platforms.
Pungi uses in turn the python-multilib package to do the actual
computations here, which you can see in:
https://pagure.io/releng/python-multilib/blob/master/f/multilib/multilib....
Basically it looks to see if a package has files in specific directories
(mostly runtime libraries) and returns a true or false if the package
should be multilibed. There is a bunch of cruft and corner cases in
there as well.
pungi then puts those i686 packages that are marked true into the x86_64
tree and creates the repo. x86_64 users can then install those i686
packages easily because they are in the x86_64 repos they already use.
None of the above needs a public, mirrored i686 repository tree. The
computation is done by pungi at compose time looking at all the i686
packages built in koji and tagged with the appropriate tag.
Did that help? Or make things worse... happy to try and expand or answer
any other questions about it.
kevin
4:20 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 15/07/2019 18:05, Kevin Fenzi wrote:
So, this is how it works (as far as I recall off the top of my
head):
You build a archfull package in koji. It's built for x86_64 and i686
(and the other arches).
pungi runs to compose things. It has a config (in pungi-fedora or bodhi
config) that tells it what to do for multilib. It has also config that
tells it what tag(s) to use for the compose, so it talks to koji and
asks about/gathers packages based on that tag.
Currently for rawhide that is:
multilib = [
('^Everything$', {
'x86_64': ['devel', 'runtime'],
})
]
# format: {arch|*: [packages]}
multilib_blacklist = {
'*': ['kernel', 'kernel-PAE*', 'kernel*debug*',
'dmraid-devel', 'kdeutils-devel', 'mkinitrd-devel',
'php-devel', 'java-*',
'httpd-devel', 'tomcat-native', 'php*',
'httpd',
'krb5-server', 'krb5-server-ldap', 'mod_*',
'ghc-*'
],
}
# format: {arch|*: [packages]}
multilib_whitelist = {
'*': ['libgnat', 'wine', 'lmms-vst',
'nspluginwrapper',
'libflashsupport', 'valgrind', 'perl-libs',
'redhat-lsb',
'yaboot', 'syslinux-extlinux-nonlinux',
'syslinux-nonlinux',
'syslinux-tftpboot', 'nosync', '*-static',
'apitrace-libs',
'fakeroot-libs', 'postgresql-odbc',
'mysql-connector-odbc',
'fakechroot-libs','mesa-vdpau-drivers',
'p11-kit-trust',
'mariadb-connector-odbc', 'compiler-rt',
'nvidia-query-resource-opengl-lib',
'ibus-libs', 'ibus-gtk2', 'ibus-gtk3',
'glib-networking'
],
}
So, that says to use the 'runtime' method of multilib, and then
explicitly add some packages and explicitly remove some. The orig idea
of 'runtime' was to allow runtime for i686 binaries on x86_64 platforms.
Looking at that it seems all the packages I was special casing
in my local mirror are whitelisted now and they do indeed appear
to be present in the x86_64 repos in current releases so I guess
that I can remove my hack now...
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
2:20 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
Hello, John Reiser.
Sun, 14 Jul 2019 14:35:46 -0700 you wrote:
For some apps 2GB of malloc() arena is plenty, and they run faster
in 32-bit mode because a 64-byte cache line contains 16 pointers
instead of only 8.
And such applications became extremely vulnerable due to missing ASLR
support. Also they cannot allocate and use more than 2 GB of RAM.
One year after Red Hat Enterprise Linux version 7 reaches
end-of-support.
Fedora's development cycle is not related to RHEL's.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
1:46 a.m.
* Miro Hrončok:
The only other use/need for the repostories is to allow maintainers
to
debug and test fixes for multilib shipped packages, but the koji
buildroot repo can be used for this use case.
** modify mock to use the koji buildroot for i686 for f31+ for those
few users that need to build i686 packages locally.
Due to lack of debuginfo packages in Koji, this results in a worse user
experience. (See <https://pagure.io/koji/issue/540>.)
I also think all architectures should behave consistently in mock. It's
odd that after the proposed change, only on i686, mock will be affected
by buildroot overrides in the default configuration, for instance.
Thanks,
Florian
11:44 a.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 7/14/19 11:46 PM, Florian Weimer wrote:
* Miro Hrončok:
> The only other use/need for the repostories is to allow maintainers to
> debug and test fixes for multilib shipped packages, but the koji
> buildroot repo can be used for this use case.
> ** modify mock to use the koji buildroot for i686 for f31+ for those
> few users that need to build i686 packages locally.
Due to lack of debuginfo packages in Koji, this results in a worse user
experience. (See <https://pagure.io/koji/issue/540>.)
Yeah, that is a downside. :(
Last updated a year ago... wonder where it is on the roadmap.
Will ask.
I also think all architectures should behave consistently in mock.
It's
odd that after the proposed change, only on i686, mock will be affected
by buildroot overrides in the default configuration, for instance.
Also true.
I just don't think the number of people who do local i686 builds is all
that large, so it having some issues and corner cases to help out the
vast majority of folks seems like a good trade off to me.
kevin
5:11 p.m.
Kevin Fenzi wrote:
I just don't think the number of people who do local i686 builds
is all
that large, so it having some issues and corner cases to help out the
vast majority of folks seems like a good trade off to me.
Removing something does not "help out" anybody, ever. The people who'd
better not use the repo can just opt to not use it. You don't have to delete
it under them. And those who will use it probably have a good reason to use
it.
Kevin Kofler
12:59 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 7/15/19 3:11 PM, Kevin Kofler wrote:
Kevin Fenzi wrote:
> I just don't think the number of people who do local i686 builds is all
> that large, so it having some issues and corner cases to help out the
> vast majority of folks seems like a good trade off to me.
Removing something does not "help out" anybody, ever. The people who'd
better not use the repo can just opt to not use it. You don't have to delete
it under them. And those who will use it probably have a good reason to use
it.
This argument is absurd. Removing something definitely helps out the
people who were producing it, if they no longer wish to spend resources
making it. If the people using it wish it to stay around, they would
have to take over producing it.
kevin
4:25 a.m.
* Kevin Fenzi:
> I also think all architectures should behave consistently in
mock. It's
> odd that after the proposed change, only on i686, mock will be affected
> by buildroot overrides in the default configuration, for instance.
Also true.
I just don't think the number of people who do local i686 builds is all
that large, so it having some issues and corner cases to help out the
vast majority of folks seems like a good trade off to me.
On the other hand, it's *really* annoying when things that you need only
every couple of months behave in a way that is different from everything
else.
Thanks,
Florian
5:15 p.m.
Miro Hrončok wrote:
With the dropping of the i686 kernel package it's no longer
possible to
directly install Fedora 31 or later on i686 hardware, however, it is still
possibly to upgrade older releases as long as we continue to provide a
repository. This will leave those users with an old possibly vulnerable
kernel installed.
But what if they deliberately want that setup? They can be getting a kernel
from somewhere else. Maybe CentOS AltArch? (Running Fedora on a CentOS
kernel used to mostly work, at least.) Maybe from some other distro, if they
install the kernel manually? Or maybe they just compile the kernel
themselves? Why are you attempting to second-guess your users that way?
Kevin Kofler
1:04 p.m.
New subject: Fedora 31 System-Wide Change proposal (late): No i686
Repositories
On 7/15/19 3:15 PM, Kevin Kofler wrote:
Miro Hrončok wrote:
> With the dropping of the i686 kernel package it's no longer possible to
> directly install Fedora 31 or later on i686 hardware, however, it is still
> possibly to upgrade older releases as long as we continue to provide a
> repository. This will leave those users with an old possibly vulnerable
> kernel installed.
But what if they deliberately want that setup? They can be getting a kernel
from somewhere else. Maybe CentOS AltArch? (Running Fedora on a CentOS
kernel used to mostly work, at least.) Maybe from some other distro, if they
install the kernel manually? Or maybe they just compile the kernel
themselves? Why are you attempting to second-guess your users that way?
We cannot continue to provide everything we ever provided in case
someone somewhere has some use case for it. If someone has a use case
for it and we stop producing it, it's up to them to produce it, or
convince us to do so again/continue to.
I personally don't think this is a use case we want to provide resources
for.
kevin
1678
days inactive
1747
days old
165 comments
48 participants
participants (48)
-
Adam Williamson -
Anderson, Charles R -
Bruno Wolff III -
Charalampos Stratakis -
DJ Delorie -
Dominik 'Rathann' Mierzejewski -
drago01 -
Dridi Boukelmoune -
Emmanuel Seyman -
Fabio Valentini -
Florian Weimer -
Franta Hanzlík -
Frantisek Zatloukal -
Gordon Messmer -
Jiri Eischmann -
Jiri Vanek -
John M. Harris Jr. -
John Reiser -
Josh Stone -
Justin Forbes -
Kevin Fenzi -
Kevin Kofler -
Leigh Scott -
Leslie Hawthorn -
Mark Wielaard -
Martin Kolman -
Michael Cronenworth -
Miro Hrončok -
Miroslav Suchý -
Neal Gompa -
Nico Kadel-Garcia -
Nicolas Chauvet -
Nicolas Mailhot -
Panu Matilainen -
Pavel Raiskup -
Peter Pentchev -
Przemek Klosowski -
Samuel Sieb -
Simon Farnsworth -
Solomon Peachy -
stan -
Stephen John Smoogen -
Tom Hughes -
Tomasz Torcz -
Victor V. Shkamerda -
Vitaly Zaitsev -
vvs vvs
-
Zbigniew Jędrzejewski-Szmek