https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
== Summary == Stop building i686 kernels, reduce the i686 package to a kernel-headers package that can be used to build 32bit versions of everything else.
== Owner == * Name: [[User:jforbes| Justin Forbes]] * Email: jforbes@fedoraproject.org
== Detailed Description == 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.
This was last proposed with Fedora 27, but it was deferred as an i686 SIG was to be created to handle issues going forward. That SIG has been largely unresponsive. The only thread so far this year has been a thread starting with "Hello, I noticed that the x86 group hasn't had any reports in a while. As the absentee sponsor of the group, I would like to remind people on the list and interested in keeping x86_32 in Fedora releases that there is general work which needs to be done by people interested. " And the only response was one person saying they would no longer have access to legacy i686 hardware as of August.
== Benefit to Fedora == More testable kernel updates, faster fixes for security bugs, and lowered exposure.
== Scope == * Proposal owners: Changes to the kernel spec to stop the actual i686 builds, but keep the kernel-headers package.
* Other developers: NA
* Release engineering: [https://pagure.io/releng/issue/8461] ** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: Drop i686 based images * Policies and guidelines: N/A (not needed for this change) * Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == 32bit i686 users will need to reinstall as x86_64 with the next release.
== How To Test == N/A Nothing to test, we simply stop producing a flavor of the kernel package. As there is no direct upgrade path from i686 -> x86_64, users with capable hardware will have to reinstall.
== User Experience == The few 32bit users will have the full lifecycle of Fedora 30 to choose a time to upgrade to a 64bit installation. Some old hardware will no longer be supported by fedora.
== Dependencies == 32 bit x86 images can no longer be built.
== Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Start building an i686 kernel again * Contingency deadline: As QA requires for image candidates * Blocks release? Yes * Blocks product? product Fedora 31
== Documentation == The lack of an i686 image will need to be documented.
On Fri, 21 Jun 2019 at 14:15, Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
== Summary == Stop building i686 kernels, reduce the i686 package to a kernel-headers package that can be used to build 32bit versions of everything else.
OK I think this has a followup change which is sort of buried below:
No more i686 kernels mean that the i686 compose (aka .iso/etc) do not happen. The only way would be for someone to engineer making anaconda install an x86_64 kernel and i686 user space work. That is a lot of work and probably a little late to start on. Howver as the below mentioned absentee sponsor of i686.. I have no problems with this.
== Owner ==
- Name: [[User:jforbes| Justin Forbes]]
- Email: jforbes@fedoraproject.org
== Detailed Description == 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.
This was last proposed with Fedora 27, but it was deferred as an i686 SIG was to be created to handle issues going forward. That SIG has been largely unresponsive. The only thread so far this year has been a thread starting with "Hello, I noticed that the x86 group hasn't had any reports in a while. As the absentee sponsor of the group, I would like to remind people on the list and interested in keeping x86_32 in Fedora releases that there is general work which needs to be done by people interested. " And the only response was one person saying they would no longer have access to legacy i686 hardware as of August.
== Benefit to Fedora == More testable kernel updates, faster fixes for security bugs, and lowered exposure.
== Scope ==
- Proposal owners:
Changes to the kernel spec to stop the actual i686 builds, but keep the kernel-headers package.
Other developers: NA
Release engineering: [https://pagure.io/releng/issue/8461]
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: Drop i686 based images
- Policies and guidelines: N/A (not needed for this change)
- Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == 32bit i686 users will need to reinstall as x86_64 with the next release.
== How To Test == N/A Nothing to test, we simply stop producing a flavor of the kernel package. As there is no direct upgrade path from i686 -> x86_64, users with capable hardware will have to reinstall.
== User Experience == The few 32bit users will have the full lifecycle of Fedora 30 to choose a time to upgrade to a 64bit installation. Some old hardware will no longer be supported by fedora.
== Dependencies == 32 bit x86 images can no longer be built.
== Contingency Plan ==
- Contingency mechanism: (What to do? Who will do it?) Start building
an i686 kernel again
- Contingency deadline: As QA requires for image candidates
- Blocks release? Yes
- Blocks product? product Fedora 31
== Documentation == The lack of an i686 image will need to be documented.
On Mon, Jun 24, 2019, 17:28 Stephen John Smoogen smooge@gmail.com wrote:
On Fri, 21 Jun 2019 at 14:15, Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
== Summary == Stop building i686 kernels, reduce the i686 package to a kernel-headers package that can be used to build 32bit versions of everything else.
OK I think this has a followup change which is sort of buried below:
No more i686 kernels mean that the i686 compose (aka .iso/etc) do not happen. The only way would be for someone to engineer making anaconda install an x86_64 kernel and i686 user space work. That is a lot of work and probably a little late to start on. Howver as the below mentioned absentee sponsor of i686.. I have no problems with this.
Does this affect i686 multilib support in x86_64?
Fabio
== Owner ==
- Name: [[User:jforbes| Justin Forbes]]
- Email: jforbes@fedoraproject.org
== Detailed Description == 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.
This was last proposed with Fedora 27, but it was deferred as an i686 SIG was to be created to handle issues going forward. That SIG has been largely unresponsive. The only thread so far this year has been a thread starting with "Hello, I noticed that the x86 group hasn't had any reports in a while. As the absentee sponsor of the group, I would like to remind people on the list and interested in keeping x86_32 in Fedora releases that there is general work which needs to be done by people interested. " And the only response was one person saying they would no longer have access to legacy i686 hardware as of August.
== Benefit to Fedora == More testable kernel updates, faster fixes for security bugs, and lowered exposure.
== Scope ==
- Proposal owners:
Changes to the kernel spec to stop the actual i686 builds, but keep the kernel-headers package.
Other developers: NA
Release engineering: [https://pagure.io/releng/issue/8461]
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: Drop i686 based images
- Policies and guidelines: N/A (not needed for this change)
- Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == 32bit i686 users will need to reinstall as x86_64 with the next release.
== How To Test == N/A Nothing to test, we simply stop producing a flavor of the kernel package. As there is no direct upgrade path from i686 -> x86_64, users with capable hardware will have to reinstall.
== User Experience == The few 32bit users will have the full lifecycle of Fedora 30 to choose a time to upgrade to a 64bit installation. Some old hardware will no longer be supported by fedora.
== Dependencies == 32 bit x86 images can no longer be built.
== Contingency Plan ==
- Contingency mechanism: (What to do? Who will do it?) Start building
an i686 kernel again
- Contingency deadline: As QA requires for image candidates
- Blocks release? Yes
- Blocks product? product Fedora 31
== Documentation == The lack of an i686 image will need to be documented.
-- Stephen J Smoogen.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Mon, Jun 24, 2019 at 10:41 AM Fabio Valentini decathorpe@gmail.com wrote:
On Mon, Jun 24, 2019, 17:28 Stephen John Smoogen smooge@gmail.com wrote:
On Fri, 21 Jun 2019 at 14:15, Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
== Summary == Stop building i686 kernels, reduce the i686 package to a kernel-headers package that can be used to build 32bit versions of everything else.
OK I think this has a followup change which is sort of buried below:
No more i686 kernels mean that the i686 compose (aka .iso/etc) do not happen. The only way would be for someone to engineer making anaconda install an x86_64 kernel and i686 user space work. That is a lot of work and probably a little late to start on. Howver as the below mentioned absentee sponsor of i686.. I have no problems with this.
Does this affect i686 multilib support in x86_64?
No, the kernel-headers package will still be built for i686, and 32bit userspace is still being built, we just stop producing the actual kernel, and bootable 32bit images.
Fabio
== Owner ==
- Name: [[User:jforbes| Justin Forbes]]
- Email: jforbes@fedoraproject.org
== Detailed Description == 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.
This was last proposed with Fedora 27, but it was deferred as an i686 SIG was to be created to handle issues going forward. That SIG has been largely unresponsive. The only thread so far this year has been a thread starting with "Hello, I noticed that the x86 group hasn't had any reports in a while. As the absentee sponsor of the group, I would like to remind people on the list and interested in keeping x86_32 in Fedora releases that there is general work which needs to be done by people interested. " And the only response was one person saying they would no longer have access to legacy i686 hardware as of August.
== Benefit to Fedora == More testable kernel updates, faster fixes for security bugs, and lowered exposure.
== Scope ==
- Proposal owners:
Changes to the kernel spec to stop the actual i686 builds, but keep the kernel-headers package.
Other developers: NA
Release engineering: [https://pagure.io/releng/issue/8461]
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: Drop i686 based images
- Policies and guidelines: N/A (not needed for this change)
- Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == 32bit i686 users will need to reinstall as x86_64 with the next release.
== How To Test == N/A Nothing to test, we simply stop producing a flavor of the kernel package. As there is no direct upgrade path from i686 -> x86_64, users with capable hardware will have to reinstall.
== User Experience == The few 32bit users will have the full lifecycle of Fedora 30 to choose a time to upgrade to a 64bit installation. Some old hardware will no longer be supported by fedora.
== Dependencies == 32 bit x86 images can no longer be built.
== Contingency Plan ==
- Contingency mechanism: (What to do? Who will do it?) Start building
an i686 kernel again
- Contingency deadline: As QA requires for image candidates
- Blocks release? Yes
- Blocks product? product Fedora 31
== Documentation == The lack of an i686 image will need to be documented.
-- Stephen J Smoogen.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Mon, Jun 24, 2019 at 11:11:41AM -0500, Justin Forbes wrote:
On Mon, Jun 24, 2019 at 10:41 AM Fabio Valentini decathorpe@gmail.com wrote:
On Mon, Jun 24, 2019, 17:28 Stephen John Smoogen smooge@gmail.com wrote:
On Fri, 21 Jun 2019 at 14:15, Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
== Summary == Stop building i686 kernels, reduce the i686 package to a kernel-headers package that can be used to build 32bit versions of everything else.
OK I think this has a followup change which is sort of buried below:
No more i686 kernels mean that the i686 compose (aka .iso/etc) do not happen. The only way would be for someone to engineer making anaconda install an x86_64 kernel and i686 user space work. That is a lot of work and probably a little late to start on. Howver as the below mentioned absentee sponsor of i686.. I have no problems with this.
Maybe the Change could be renamed to reflect the full impact: "No more i686 kernels or images"?
Zbyszek
On Mon, Jun 24, 2019 at 11:41 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Mon, Jun 24, 2019 at 11:11:41AM -0500, Justin Forbes wrote:
On Mon, Jun 24, 2019 at 10:41 AM Fabio Valentini decathorpe@gmail.com wrote:
On Mon, Jun 24, 2019, 17:28 Stephen John Smoogen smooge@gmail.com wrote:
On Fri, 21 Jun 2019 at 14:15, Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
== Summary == Stop building i686 kernels, reduce the i686 package to a kernel-headers package that can be used to build 32bit versions of everything else.
OK I think this has a followup change which is sort of buried below:
No more i686 kernels mean that the i686 compose (aka .iso/etc) do not happen. The only way would be for someone to engineer making anaconda install an x86_64 kernel and i686 user space work. That is a lot of work and probably a little late to start on. Howver as the below mentioned absentee sponsor of i686.. I have no problems with this.
Maybe the Change could be renamed to reflect the full impact: "No more i686 kernels or images"?
Changed on the wiki.
Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On 6/24/19 10:00 AM, Justin Forbes wrote:
On Mon, Jun 24, 2019 at 11:41 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
...snip...
Maybe the Change could be renamed to reflect the full impact: "No more i686 kernels or images"?
Changed on the wiki.
Note that as far as I recall, this also means containers, as we need a kernel to build those, right?
kevin
Once upon a time, Kevin Fenzi kevin@scrye.com said:
On 6/24/19 10:00 AM, Justin Forbes wrote:
On Mon, Jun 24, 2019 at 11:41 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
...snip...
Maybe the Change could be renamed to reflect the full impact: "No more i686 kernels or images"?
Changed on the wiki.
Note that as far as I recall, this also means containers, as we need a kernel to build those, right?
If there are no i686 images, and no i686 containers, and anaconda can't install i686 userspace with x86_64 kernel... is there any regular way to consume i686 applications? It seems like the only reason to continue building i686 RPMs would be for multilib (and their build dependencies), which is a small subset of the total RPMs.
On Mon, Jun 24, 2019 at 9:32 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, Kevin Fenzi kevin@scrye.com said:
On 6/24/19 10:00 AM, Justin Forbes wrote:
On Mon, Jun 24, 2019 at 11:41 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
...snip...
Maybe the Change could be renamed to reflect the full impact: "No more i686 kernels or images"?
Changed on the wiki.
Note that as far as I recall, this also means containers, as we need a kernel to build those, right?
If there are no i686 images, and no i686 containers, and anaconda can't install i686 userspace with x86_64 kernel... is there any regular way to consume i686 applications? It seems like the only reason to continue building i686 RPMs would be for multilib (and their build dependencies), which is a small subset of the total RPMs.
Third parties using the userspace with their own kernels, I know there were groups using a custom kernel with i686 for various OLPC use cases still.
On Mon, Jun 24, 2019 at 10:35:40AM -0700, Kevin Fenzi wrote:
On 6/24/19 10:00 AM, Justin Forbes wrote:
On Mon, Jun 24, 2019 at 11:41 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
...snip...
Maybe the Change could be renamed to reflect the full impact: "No more i686 kernels or images"?
Changed on the wiki.
Note that as far as I recall, this also means containers, as we need a kernel to build those, right?
I'm don't know about all the possible ways we build containers in Fedora, but intrinsically, there's certainly no reason to require an amd64 kernel to build a 32-bit image. (*)
Zbyszek
(*) E.g. dnf -y --releasever=31 --installroot=/var/lib/machines/f28-32 \ --disablerepo='*' --enablerepo=fedora --enablerepo=updates install \ systemd passwd dnf fedora-release vim-minimal --forcearch=i686 still works.
On 6/24/19 3:52 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jun 24, 2019 at 10:35:40AM -0700, Kevin Fenzi wrote:
On 6/24/19 10:00 AM, Justin Forbes wrote:
On Mon, Jun 24, 2019 at 11:41 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
...snip...
Maybe the Change could be renamed to reflect the full impact: "No more i686 kernels or images"?
Changed on the wiki.
Note that as far as I recall, this also means containers, as we need a kernel to build those, right?
I'm don't know about all the possible ways we build containers in Fedora, but intrinsically, there's certainly no reason to require an amd64 kernel to build a 32-bit image. (*)
Zbyszek
(*) E.g. dnf -y --releasever=31 --installroot=/var/lib/machines/f28-32 \ --disablerepo='*' --enablerepo=fedora --enablerepo=updates install \ systemd passwd dnf fedora-release vim-minimal --forcearch=i686 still works.
Sure, but thats not how we make official containers.
Also, what about the i686 tree on mirrors? Not producing that would save a fair bit of compose time...on the other hand, if we do produce it, users could upgrade from old releases.
kevin
Hi Fabio,
On Mon, Jun 24, 2019 at 6:35 PM Fabio Valentini decathorpe@gmail.com wrote:
On Mon, Jun 24, 2019, 17:28 Stephen John Smoogen smooge@gmail.com wrote:
On Fri, 21 Jun 2019 at 14:15, Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
== Summary == Stop building i686 kernels, reduce the i686 package to a kernel-headers package that can be used to build 32bit versions of everything else.
OK I think this has a followup change which is sort of buried below:
No more i686 kernels mean that the i686 compose (aka .iso/etc) do not happen. The only way would be for someone to engineer making anaconda install an x86_64 kernel and i686 user space work. That is a lot of work and probably a little late to start on. Howver as the below mentioned absentee sponsor of i686.. I have no problems with this.
Does this affect i686 multilib support in x86_64?
From what I understand, no. We will just stop building live images and such. But packages will be still built for i686 architecture and then shipped in repos (not completely sure if having i686-only repo is useful, but they will be in x86_64 repos definitely).
Fabio
== Owner ==
- Name: [[User:jforbes| Justin Forbes]]
- Email: jforbes@fedoraproject.org
== Detailed Description == 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.
This was last proposed with Fedora 27, but it was deferred as an i686 SIG was to be created to handle issues going forward. That SIG has been largely unresponsive. The only thread so far this year has been a thread starting with "Hello, I noticed that the x86 group hasn't had any reports in a while. As the absentee sponsor of the group, I would like to remind people on the list and interested in keeping x86_32 in Fedora releases that there is general work which needs to be done by people interested. " And the only response was one person saying they would no longer have access to legacy i686 hardware as of August.
== Benefit to Fedora == More testable kernel updates, faster fixes for security bugs, and lowered exposure.
== Scope ==
- Proposal owners:
Changes to the kernel spec to stop the actual i686 builds, but keep the kernel-headers package.
Other developers: NA
Release engineering: [https://pagure.io/releng/issue/8461]
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: Drop i686 based images
- Policies and guidelines: N/A (not needed for this change)
- Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == 32bit i686 users will need to reinstall as x86_64 with the next release.
== How To Test == N/A Nothing to test, we simply stop producing a flavor of the kernel package. As there is no direct upgrade path from i686 -> x86_64, users with capable hardware will have to reinstall.
== User Experience == The few 32bit users will have the full lifecycle of Fedora 30 to choose a time to upgrade to a 64bit installation. Some old hardware will no longer be supported by fedora.
== Dependencies == 32 bit x86 images can no longer be built.
== Contingency Plan ==
- Contingency mechanism: (What to do? Who will do it?) Start building
an i686 kernel again
- Contingency deadline: As QA requires for image candidates
- Blocks release? Yes
- Blocks product? product Fedora 31
== Documentation == The lack of an i686 image will need to be documented.
-- Stephen J Smoogen.
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Le lundi 24 juin 2019 à 18:50 +0200, Igor Gnatenko a écrit :
But packages will be still built for i686 architecture and then shipped in repos (not completely sure if having i686-only repo is useful, but they will be in x86_64 repos definitely).
It would be nice if they were finally split in an optional repo. That's a lot of files that are mirrored by default for x86_64, that x86_64 users have little use for
On Mon, Jun 24, 2019 at 1:39 PM Nicolas Mailhot via devel devel@lists.fedoraproject.org wrote:
Le lundi 24 juin 2019 à 18:50 +0200, Igor Gnatenko a écrit :
But packages will be still built for i686 architecture and then shipped in repos (not completely sure if having i686-only repo is useful, but they will be in x86_64 repos definitely).
It would be nice if they were finally split in an optional repo. That's a lot of files that are mirrored by default for x86_64, that x86_64 users have little use for
I would kind of expect over time that other packages would be excluded from 32bit i686 because there is little use for them, but this is that first step to getting there. Clearly the world is not ready for killing off all 32bit, Ubuntu has even supposedly reversed their decision there, but a lot of things can go away without ever being noticed when you aren't booting a 32bit kernel.
On 6/21/19 7:26 PM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
== Summary == Stop building i686 kernels, reduce the i686 package to a kernel-headers package that can be used to build 32bit versions of everything else.
How does this affect the i386 as secondary architecture?
Actually, I feel this proposal is a violoent cheat and should actually be entitled: Drop i386 as secondary architecture.
Ralf
On Mon, Jun 24, 2019 at 9:37 PM Ralf Corsepius rc040203@freenet.de wrote:
On 6/21/19 7:26 PM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
== Summary == Stop building i686 kernels, reduce the i686 package to a kernel-headers package that can be used to build 32bit versions of everything else.
How does this affect the i386 as secondary architecture?
Actually, I feel this proposal is a violoent cheat and should actually be entitled: Drop i386 as secondary architecture.
It is not a violent cheat. It was proposed this way 2 years ago. At the time a SIG was created to maintain i686 so that it could continue as a secondary arch. They are inactive. See the post in the SIG there. When a call for a status was made (as the only traffic on their list so far this year), it got a single reply from someone saying that they would no longer have 32bit hardware as of August.
Ralf _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Mon, Jun 24, 2019 at 23:17:30 -0500, Justin Forbes jmforbes@linuxtx.org wrote:
It is not a violent cheat. It was proposed this way 2 years ago. At the time a SIG was created to maintain i686 so that it could continue as a secondary arch. They are inactive. See the post in the SIG there. When a call for a status was made (as the only traffic on their list so far this year), it got a single reply from someone saying that they would no longer have 32bit hardware as of August.
I'm the one who responded.
I still have one machine that runs i686, but not x86_64. I'm hoping it keeps working until August, when I can afford to buy the rest of my power 9 based Blackbird to replace it.
I have one other machine that I use on occasion that boots with an i686 kernel, because I used that when I first got it to use the same arch for all of my machines at that time. And I have been deferring doing a cross arch upgrade, but will in August. In theory I have another laptop with a bad keyboard, that can't use x86_64, but that I think would run current Fedora i686 kernels. But I haven't powered it on in years.
I have done bisects for i686 issues in the past. I haven't had to in a while (at least a year for an i686 specific issue).
People will actually get until spring if this passes, if they don't use rawhide.
The hardware I have that is stuck on i686 is around 15 years old. I don't know other people who run hardware that old. I'm sure there are some, but probably not many. I would also expect new shiny software (i.e. Fedora) and ancient hardware is an odd combination.
On Tuesday, 25 June 2019 at 14:36, Bruno Wolff III wrote:
On Mon, Jun 24, 2019 at 23:17:30 -0500, Justin Forbes jmforbes@linuxtx.org wrote:
It is not a violent cheat. It was proposed this way 2 years ago. At the time a SIG was created to maintain i686 so that it could continue as a secondary arch. They are inactive. See the post in the SIG there. When a call for a status was made (as the only traffic on their list so far this year), it got a single reply from someone saying that they would no longer have 32bit hardware as of August.
I'm the one who responded.
FWIW, I still have two Asus EeePCs (900 and 1000) that are being used. They're Atom N270 based, so 32-bit only. I'd like to run the most recent Fedora on them, but I don't have much time to devote to debugging i686-specific issues.
Regards, Dominik
I - and a people around me - have plenty of 32-bit hardware.
In case of e.g. volunteer youth work. When you need a dozen or two of PCs where do you get them from? They are those old machines you no longer use; the one your uncle gave you when he bought new laptop; the friend's one that broke but you managed to paritally fix it ... that's how you accumulate dozens of machines through the years so you can use them now. Nobody will ever just buy you a bunch of modern laptops just because you prepared something cool for the kids. And I'd love to run Fedora on them, since I know the OS the best and I'm developing on it. I'm able to automatize "cluster" installations or configurations fo those machines without learning much new.
I already said I wouldn't like to see i686 support dropped, when the discussion was on the table last time. However I learned back then from someone's reply, what I think should be a golden rule around here.
There can't be a project without developer / maintainer. Do *YOU* want to maintain it? No? Then who should? We are a community of volunteers. You can't force anybody here to maintain it for you.
i686 will be missed by me. But I'm both not able to maintain & bugfix the (32-bit) kernel, nor I'm willing to devote it my time to learn and do it.
It's same as any other orphaned package. No one willing to maintain it? FTBFS? Say "bye" to that package. Pitiful, but easy as that.
--
Michal Schorm Software Engineer Core Services - Databases Team Red Hat
--
On Wed, Jun 26, 2019 at 12:16 AM Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
On Tuesday, 25 June 2019 at 14:36, Bruno Wolff III wrote:
On Mon, Jun 24, 2019 at 23:17:30 -0500, Justin Forbes jmforbes@linuxtx.org wrote:
It is not a violent cheat. It was proposed this way 2 years ago. At the time a SIG was created to maintain i686 so that it could continue as a secondary arch. They are inactive. See the post in the SIG there. When a call for a status was made (as the only traffic on their list so far this year), it got a single reply from someone saying that they would no longer have 32bit hardware as of August.
I'm the one who responded.
FWIW, I still have two Asus EeePCs (900 and 1000) that are being used. They're Atom N270 based, so 32-bit only. I'd like to run the most recent Fedora on them, but I don't have much time to devote to debugging i686-specific issues.
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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On 6/26/19 2:34 AM, Michal Schorm wrote:
I - and a people around me - have plenty of 32-bit hardware.
Just for the record, I've got a couple of AMD XP2400+, AMD XP2000+ machines, updated to recent Fedora versions and still usable.
Regards.
On Wed, Jun 26, 2019 at 9:24 AM Roberto Ragusa mail@robertoragusa.it wrote:
On 6/26/19 2:34 AM, Michal Schorm wrote:
I - and a people around me - have plenty of 32-bit hardware.
Just for the record, I've got a couple of AMD XP2400+, AMD XP2000+ machines, updated to recent Fedora versions and still usable.
So we should be clear here. The question is not "are people still using 32-bit hardware?" The question at hand is whether or not we believe it to be in Fedora's best interest to sustain that usecase, with all the effort required to do so. Of course there will always be people using it if it is done.
josh
Le 2019-06-26 16:07, Josh Boyer a écrit :
On Wed, Jun 26, 2019 at 9:24 AM Roberto Ragusa mail@robertoragusa.it wrote:
On 6/26/19 2:34 AM, Michal Schorm wrote:
I - and a people around me - have plenty of 32-bit hardware.
Just for the record, I've got a couple of AMD XP2400+, AMD XP2000+ machines, updated to recent Fedora versions and still usable.
So we should be clear here. The question is not "are people still using 32-bit hardware?" The question at hand is whether or not we believe it to be in Fedora's best interest to sustain that usecase, with all the effort required to do so.
No just in the best interest. Lots of things would be in Fedora's best interest.
Useful enough to motivate someones to donate the time and energy to keep it in a good shape. All year round. Doing a good enough job the project as a whole feels their use of shared resources (builders, releng, QA time, etc) is not a waste.
On Wed, Jun 26, 2019 at 12:17 AM Dominik 'Rathann' Mierzejewski < dominik@greysector.net> wrote:
On Tuesday, 25 June 2019 at 14:36, Bruno Wolff III wrote:
On Mon, Jun 24, 2019 at 23:17:30 -0500, Justin Forbes jmforbes@linuxtx.org wrote:
It is not a violent cheat. It was proposed this way 2 years ago. At the time a SIG was created to maintain i686 so that it could continue as a secondary arch. They are inactive. See the post in the SIG there. When a call for a status was made (as the only traffic on their list so far this year), it got a single reply from someone saying that they would no longer have 32bit hardware as of August.
I'm the one who responded.
FWIW, I still have two Asus EeePCs (900 and 1000) that are being used. They're Atom N270 based, so 32-bit only. I'd like to run the most recent Fedora on them, but I don't have much time to devote to debugging i686-specific issues.
If the proposal remains to be only about dropping i686 kernel (and image) builds, you should be able to get latest Fedora (userspace without latest kernel) by installing Fedora 30 and upgrading to whatever version you want in the future.
It's possible that amount of packages built for i686 will be somehow limited at some point, but I don't expect that to happen anytime soon.
Hi, Ralf,
one of the goals of the change process (mailing list announcements and discussion we have right here) is to identify various impacts of the change and also to find better wording for it (including the title). So you shouldn't feel cheated, just contribute your thoughts and suggest the corrections.
On Tue, Jun 25, 2019 at 4:36 AM Ralf Corsepius rc040203@freenet.de wrote:
On 6/21/19 7:26 PM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
== Summary == Stop building i686 kernels, reduce the i686 package to a kernel-headers package that can be used to build 32bit versions of everything else.
How does this affect the i386 as secondary architecture?
Actually, I feel this proposal is a violoent cheat and should actually be entitled: Drop i386 as secondary architecture.
I think that "No More i686 Kernels or bootable images" describes the change better.
I searched through docs [1], [2], [3] and didn't find the definition for the secondary architecture which would fit the current case, thus "Drop as secondary architecture" would be confusing here. We do keep the i686 user-space packages, which means that we don't drop the architecture completely. And I think it makes sense to highlight it, especially with the recent news on the topic from Ubuntu world.
[1] https://fedoraproject.org/wiki/Architectures#Structure [2] https://developer.fedoraproject.org/deployment/secondary_architectures/about... [3] https://fedoraproject.org/wiki/Architectures/x86
On Mon, 24 Jun 2019 at 23:25, Ralf Corsepius rc040203@freenet.de wrote:
On 6/21/19 7:26 PM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
== Summary == Stop building i686 kernels, reduce the i686 package to a kernel-headers package that can be used to build 32bit versions of everything else.
How does this affect the i386 as secondary architecture?
Actually, I feel this proposal is a violoent cheat and should actually be entitled: Drop i386 as secondary architecture.
Two years ago you complained bitterly that removing i686 was bad and you wanted it kept. We then did the work towards getting the i686 sub-committee set up and sponsored so that you and others could take it from there. At the time it was set up it was clearly outlined that if it wasn't kept up, if it didn't have regular meetings and reports like the ARM and other groups do.. it would go away. Since then very little has been done with no regular reports and little traffic when people asked for help.
This isn't a cheat. This is a clear consequence outlined 2 years ago.
https://lists.fedoraproject.org/archives/list/x86@lists.fedoraproject.org/th...
Ralf _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
I cross graded a laptop from i686 to x86_64 yesterday using dnf and it went pretty well without a reinstall. It also ran fine using an x86_64 kernel with i686 user space during the transition.
I noticed that at least with using --forcearch=x86_64 that installing two packages that had names differing only in arch was a problem, even when there shouldn't have been file conflicts. So that to get an x86_64 kernel installed, I needed to install a different version than any of the installed i686 kernels.
Initially I installed an x86_64 kernel and then booted into that. I assumed that x86_64 user space wouldn't work with an i686 kernel. (Though I didn't test that to be sure.) I didn't want an upgrade failing part way through, since it is a pain to clean up after that.
Then I got of list of i686 packages (skipping noarch packages). After playing around with how to get dnf to do the update in one go (since it seemed likely to break things to have i686 libraries removed early) I found that using yum shell and swap worked.
So you build a file with a swap line for each i686 to x86_64 conversion and then run yum shell with --forcearch=x86_64 specify that file and all the x86_64 packages get installed before the i686 packages get removed.
I ran the process using screen to protect against desktop crashes and script to keep a record of what was done to check over afterwards. But it ran to completion without problems.
wine is a special case. It couldn't be reinstalled in the mass cut over because it has dependencies on both x86_64 and i686 libs. So I had to reinstall afterwards.
I'm not sure how dnf decides what the arch is. I still needed to use --forcearch when running an x86_64 kernel and an i686 user space. I rebooted after the userspace update and was able to reinstall wine properly without having to use --forcearch any more.
So far things seem to be working normally, though in theory there might be some data that needs to get updated for an application.
This went a lot smoother than I was expecting. I have had worse experiences updating after mass rebuilds than this one.
Most of the articles on switching arches without full reinstalls are very old and describe more complicated processes. So I wanted to get something out there for other people that might have systems they want to switch over.