On Mon, Jun 24, 2019, 17:28 Stephen John Smoogen <smo...@gmail.com> wrote:
> > > On Fri, 21 Jun 2019 at 14:15, Ben Cotton <bcot...@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: jfor...@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-le...@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-le...@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
