Hello folks,
There will be an outage starting at 2025-12-03 21:00UTC,
which will last approximately 2 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2025-12-03 21UTC'
Reason for outage:
We will be migrating pagure.io to a new network in our rdu3 datacenter. All services on pagure.io will be taken down, all data synced, and then services will be restored on the new server/datacenter.
IP addresses for pagure.io, docs.pagure.org will be updated. We will try and keep the outage as short as possible.
Affected Services:
- pagure.io
- docs.pagure.org
Ticket Link: https://pagure.io/fedora-infrastructure/issue/12928
Please join #admin:fedoraproject.org / #noc:fedoraproject.org on matrix.
or add comments to this ticket for more information or feedback.
Updated status for this outage may be available at
https://www.fedorastatus.org/
Thanks!
Greg
Wiki: https://fedoraproject.org/wiki/Changes/Helm4
Discussion Thread: https://discussion.fedoraproject.org/t/174934
**This is a proposed Change for Fedora Linux.**
This document represents a proposed Change. As part of the Changes process,
proposals are publicly announced in order to receive community feedback.
This proposal will only be implemented if approved by the Fedora
Engineering Steering Committee.
== Summary ==
Helm 4 has been released upstream with intentional backwards-incompatible
changes relative to Helm 3. To ensure a smooth transition for Fedora and
EPEL users, this Change introduces Helm 4 as the default `helm` package in
Fedora Rawhide, while providing a parallel-installable `helm3` package for
users and tooling that still rely on Helm 3.
Helm 3 will continue to be available and maintained as `helm3` in Fedora
and EPEL, while the `helm` package will track the latest major release
(Helm 4 going forward).
== Owner ==
* Name: [[User:mikelo2| Mikel Olasagasti]]
* Email: mikel(a)olasagasti.info
== Detailed Description ==
Upstream Helm 4 introduces breaking changes in CLI behavior, chart
handling, and release workflow compatibility compared to Helm 3. Many users
in CI/CD, Kubernetes automation, and cluster operators still depend on Helm
3’s behavior and may not be immediately able to migrate.
Upstream has committed to maintaining Helm 3 with bug fixes until
2026-07-08 and with security fixes until 2026-11-11. To provide Fedora
users with a stable transition period, both versions will be shipped in
parallel until upstream support ends.
Package Version Binary name Notes
helm Helm 4 helm Default package (tracks latest major upstream)
helm3 Helm 3 helm3 Maintained in Fedora until upstream support ends
=== Planned retirement schedule ===
Helm 3 will remain available in Fedora until upstream ends security support.
Given current Fedora release cadence, this means:
* `helm3` will continue to be shipped through Fedora 44.
* Once Fedora 44 is branched from Rawhide (expected mid-2026), `helm3` may
be retired from Rawhide and will not appear in Fedora 45+.
== Feedback ==
== Benefit to Fedora ==
* Keeps Fedora up to date with the latest upstream technology.
* Preserves backward compatibility via `helm3`.
* Reduces upgrade friction for cluster operators and CI/CD automation.
* Allows gradual migration and testing of Helm 4.
* Aligns Fedora with Kubernetes ecosystem direction.
== Scope ==
* Proposal owner (packager):
** Create `helm3` spec based on existing Helm 3 sources.
** Update existing `helm` spec to Helm 4.
** Ensure parallel installability (no conflicting binaries/files).
** Provide clear documentation in package descriptions.
* Release engineering:
** Normal review and acceptance of Change.
** No mass rebuild required.
* Policies and guidelines: No
** This is a Self-Contained Change.
** No system-wide impact beyond the Helm ecosystem.
== Upgrade/compatibility impact ==
* Users upgrading Fedora may find helm now provides Helm 4.
* Scripts and automation depending on Helm 3 must explicitly install
`helm3`.
The intent is not to break existing Helm 3 workflows, but to allow Fedora
users to adopt Helm 4 when ready.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? No
== How To Test ==
<pre>
dnf install helm
helm version # should report Helm 4
dnf install helm3
helm3 version # should report Helm 3
</pre>
Both versions must be installable simultaneously and functional without
file conflicts.
== User Experience ==
Users get the latest major upstream version by default. Those requiring
Helm 3 can run:
<pre>
sudo dnf install helm3
</pre>
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: *Not a System-Wide Change.*
** If packaging or testing of Helm 4 is not completed in time, the helm
package will remain on Helm 3 and the Helm 4 update will be deferred to the
next Fedora release cycle.
** If creation of the helm3 compatibility package is delayed, helm must
remain on Helm 3 to avoid breaking user workflows and expectations.
** No forced migration, no Obsoletes/Provides, and no package replacement
will occur under contingency.(What to do? Who will do it?) N/A (not a
System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Wiki:
https://fedoraproject.org/wiki/Changes/Restrict_ptrace_for_unprivileged_use…
Discussion Thread: https://discussion.fedoraproject.org/t/174493
**This is a proposed Change for Fedora Linux.**
This document represents a proposed Change. As part of the Changes process,
proposals are publicly announced in order to receive community feedback.
This proposal will only be implemented if approved by the Fedora
Engineering Steering Committee.
== Summary ==
The package elfutils-default-yama-scope will be removed in order to
system-wide set `kernel.yama.ptrace_scope` to the kernel default `1` (like
ArchLinux,openSuSE,Ubuntu,...), enabling `ptrace_scope` to mitigate attack
vectors that can rise through vulnerable/untrusted/unupdated
software/packages or user actions. If preferred, users can temporarily or
permanently disable `ptrace_scope` with one command. To raise awareness and
allow users more easily to further decrease potential for attack vectors if
they want it, the file `10-harden-yama-ptrace.conf` (containing
`kernel.yama.ptrace_scope = 2` and references/links with a short
elaboration) will be added to [
https://src.fedoraproject.org/rpms/systemd/tree/rawhide systemd] and added
to systemd.spec (line `Source27: 10-harden-yama-ptrace.conf`), but
NOT enabled/installed by default.
== Owner ==
* Name: [[User:py0xc3| py0xc3]]
* Email: py0xc3(a)fedoraproject.org
== Detailed Description ==
'''Background of kernel.yama.ptrace_scope in general and on Fedora:'''
About 10 years ago the upstream kernel community enabled the function
`kernel.yama.ptrace_scope` by default with the setting `1` in order to
increase user protection against processes that are vulnerable or malicious
and thus might be used to access/steal data from other processes (e.g.,
steal credentials and other private data from the Firefox process while
its, e.g., passwords are unencrypted in the process's memory). See
documentation below for links to technical documentation of
`kernel.yama.ptrace_scope` (kernel docs & arch wiki).
Especially on Fedora many user groups we target as users, and to whom we
actively market Fedora, might be prone to the need to enable third-party
repositories or install software manually (without considering implications
about the source or without considering that manual installations do not
get any updates automatically at all). Also, given the complexity and
workload to maintain packages, Fedora repositories are not resilient
against packages that accidentally get not updated for longer periods as
well.
However, the setting was disabled shortly after its introduction because it
broke tools like `gdb` and `strace`, which are used by software developers
to analyze other processes (e.g., to identify bugs). Nevertheless, the bug
tickets (see documentation) of back then show that developers experiencing
the issue were searching documentation of the issue rather than asking for
disabling the function. Compared to the introduction through the upstream
community back then, we can provide sufficient documentation & provision of
information for Fedora users this time: most important might be expressive
release notes and keeping `gdb` and `strace` (and other) maintainers
informed to handle bug tickets appropriately and without wasting time.
Fedora should emphasize security by default rather than disabling a
security feature like this for all. Even for software developers affected
by this, we cannot determine for sure if all of them want this feature to
be disabled permanently: we can expect software developers working with
such tools to end up either at release notes or in (self-created) bug
tickets at the tools' maintainers. We should provide all means to allow
affected users to quickly identify and solve the issue for their very use
case / situation, but the decision which mitigation to use should remain
theirs, tailored to their very circumstances.
''' Raising awareness and simplifying the enabling of ptrace_scope setting
`2` without installing/enabling it by default:'''
Raising awareness for the ptrace_scope setting `2` and simplifying its
enabling process (see summary) might be useful for some users with a
related security interest, who might not become aware or capable of
implementing this otherwise (it also simplifies Docs pages that refer to
that means & how to enable it for those interested). While this will not
make a major difference for most use cases, it will have no user impact on
itself: the file for enabling ptrace_scope with `2` NOT be
enabled/installed by default, but only added to systemd so that users can
enable it manually.
---------------------------------------
See the documentation in the Kernel Docs and Arch Wiki for technical
details along with the two devel mailing list discussions (links in the
"documentation" section of this proposal).
---------------------------------------
'''Mitigations for users affected by this change in a negative way:'''
While one command can temporarily disable ptrace_scope easily (e.g.,
`sysctl kernel.yama.ptrace_scope=0`; see "How To Test" section for
details), Fedora is already shipped with a standardized way to also disable
ptrace_scope permanently for those who prefer it that way (see the "Docs
pages as mitigation" sub-section below or the suggested release notes below
for information about the file
`/usr/share/doc/systemd/20-yama-ptrace.conf`, or review the file on your
system or in the [https://src.fedoraproject.org/rpms/systemd/tree/rawhide
systemd] repo). Permanently disabling ptrace_scope can be done by one
command as well.
First, the proposal owner will keep the maintainers of `gdb` and `strace`
(the package maintainer reported this to also affect `valgrind
vgdb`/`eu-stack`/`elfutils libdw`, whose maintainers will be informed as
well) informed about this feature and provide the means to mitigate its
impact in order to avoid that bug tickets waste their time and that bug
tickets get resolved immediately with a short copy/paste-like response
containing the details of the release notes or Docs reference. Given that
10 years ago several users thought this to be a SELinux-related issue, the
owner will also inform the selinux-policy maintainer about this before its
actual introduction. The proposal owner would be open to handle such
tickets if the maintainers choose to involve him.
Several software developers already replied in the earlier proposal that
the release notes will make a difference for them if they are expressive:
the below release notes are aligned with their feedback.
'''Docs pages as mitigation for users affected by this change, if
developers want it and provide some data:'''
As promised in an earlier discussion, the change owner will be happy to
implement Docs pages for the affected software developers: the earlier bug
tickets of 2015 [3] indicate that affected developers were seeking related
Docs pages, and some also checked out SELinux troubleshooting (assuming
this is SELinux related): it is already agreed with the Docs team that we
can create a gdb/strace troubleshooting page and add a reference about this
issue to the SELinux troubleshooting page. However, due to a lack of time &
lack of the perspective of the affected user group, the change owner
depends on affected users (= regular `gdb`/`strace` users) to provide the
raw data to him for the dedicated gdb/strace troubleshooting Docs page: no
Docs-specific formatting or Docs-specific preparations needed, but the raw
content needs to be there if this mitigation is wanted (sufficient & clear
elaboration of the issue from a developer's perspective, error outputs,
other implications relevant for developers; the solution can be already
contained but the change owner can also add a section himself elaborating
the intended solution though the temporary sysctl command or the existing
`20-yama-ptrace.conf` that just needs to be enabled with systemd for
permanent disabling of ptrace_scope). A section with short elaboration and
reference to the gdb/strace troubleshooting within the SELinux
troubleshooting page will then be created by the proposal owner as well if
the gdb/strace troubleshooting page is implemented.
If the Docs pages are created, and given the increased use of Discourse and
its well search-engine optimization, the owner will also provide a
Discourse topic in ask.fedora with a solution that links to the Docs pages.
On the long term, community members who regularly use `gdb`/`strace` have
already mentioned interest in contributing to `gdb` and `strace` to make
the tools to immediately output appropriate information when impacted by
ptrace_scope, but so far no one can predict when they will have time: so
this cannot be considered/guaranteed at this time.
== Feedback ==
This proposal considers the feedback from many users, software developers
(including regular `gdb`/`strace` users of the community) and FESCo
members, but also was presented about 4 weeks before publishing to the
Fedora maintainers of `gdb` and `strace`. Feedback has been considered as
far as provided. An exchange with an `elfutils-default-yama-scope`
maintainer took place, while their preference is to keep the
`elfutils-default-yama-scope` package the way it is. They added their
points to the feedback section, which I quote as they wrote it:
(begin citation)
-------------------------------------------
> /No investigation has been done which other tools (eu-stack, valgrind
vgdb, elfutils-libs users) are broken by this change. Fedora isn't a user
appliance distro, but one that encourages admins to become developers. So
it should not have observability (profilers, debuggers, tracers, etc.)
tools broken out of the box. Enabling these tools would require running
commands as root. This is probably a bigger security risk. Running these
tools as root should be discouraged. Why not look for a solution where user
space keeps working by default, but some system calls/proc file system
usage might be disabled if the system doesn't install certain admin and
developer tools (e.g. some yama-scope package depenencies are fixed or
moved from Required to Suggested)? In general it does seem that adding yama
support is a somewhat broken approach for what you seem to want since it
impacts user space globally. It is a "solution" if you want to restrict
users so they cannot easily admin or develop their systems, making them
hard to observe. Other LSMs provide mechanisms to implement a real policy.
Yama only provides one global on/of like switch. Maybe adjust yama to have
a more flexible policy and/or look into an selinux based policy?/
-------------------------------------------
(end citation)
The proposal owner confirms that no investigation specific to tools like
eu-stack etc. has been done, but refers to the vast feedback before, during
and after the first proposal including much feedback from users of affected
tools (see documentation), and the conclusion that can be drawn from Arch
Linux, OpenSuSE and Ubuntu, who did not disable ptrace_scope in the 10
years in which it has been kernel default.
With regards to using SELinux to achieve the outcome of ptrace_scope: this
would relate to SELinux's "confined users", and the Security SIG and
Confined Users SIG have been working on this for 2 years. Yet, confining
user accounts by default would break a lot, and it would bring widespread
changes in the behaviors especially within graphical user accounts (e.g.,
cockpit regularly breaks after updates when SELinux-confinement is enabled;
Firefox video conferencing remains broken for long). Many maintainers would
have to permanently consider this in their actions and continuously
contribute in order to make a confined user account work by default.
Flatpak remains effectively broken in confined user accounts as well.
Therefore, the proposal owner dismissed this possibility due to high risks
of regular denials of service.
If other tools like `gdb`, `strace`, (and `valgrind vgdb`, `eu-stack`,
`elfutils libdw`) are around that are affected, feel free to inform the
change owner so that he can inform these tools' maintainers before the
introduction along with the `gdb`/`strace` maintainers.
== Benefit to Fedora ==
Users, especially average users, who often depend on introducing third
party software without knowing all implications of third party repositories
or manual installations and implications around sources of the code they
introduce, will have more security by default: processes are better
isolated from each other, which mitigates impacts from packages that are
vulnerable, malicious or not updated/maintained for long.
Also, Fedora aligns closer with the upstream kernel (and its behaviors) and
with other Linux distributions that already use this change for long,
adopting what is already a de-facto-standard.
With regards to raising awareness and simplifying to set ptrace_scope to
`2`, users (who have an interest to increase their security by reducing
potential for related attack vectors) might become more likely aware of it,
and have a simplified means to implement it. This also simplifies providing
Docs pages about ptrace_scope with `2`.
== Scope ==
* Proposal owners: For the setting `1`, the owner's activities would be
limited to providing the mentioned means for mitigation, and support in
removing the package `elfutils-default-yama-scope` as far as that is
possible / useful. For the setting `2` (which will not be installed/enabled
by default), the owner will provide the pull request for [
https://src.fedoraproject.org/rpms/systemd/tree/rawhide systemd] (see
summary section for the content of the pull request).
* Other developers: Support will be necessary to remove the package
`elfutils-default-yama-scope` from other packages' dependencies and from
the repositories at all.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] -> Exchanging with RelEng might be useful to coordinate the
introduction of the feature in the very release, but they do not need to
consider this feature beyond knowing that it has to be added.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
Fedora actively targets and markets its OS towards average users. This
means we take the responsibility to anticipate the mistakes of average
users and mitigate them as far as possible, especially as the lack of
(patented and other) packages on Fedora might make them more prone
(compared to other Linux distributions) to install third-party repositories
or software (e.g., manual installation of software that will never be
updated or is vulnerable/malicious at all) without understanding all
implications.
Most other Linux distributions do this already with ptrace_scope being set
to `1`. This proposal also aligns with "security by default" and the
current strategy's goal to improve security.
== Upgrade/compatibility impact ==
The settings should be updated also on installations with earlier Fedora
releases when they are upgraded to the release of this proposal. So it
should not only be the default for new installations, but also for upgraded
installations. However, it might be more stable/secure to introduce it only
to installations that are upgraded to the next release (or installed with
the next release), but not introduced through normal "daily" updates within
earlier releases: on one hand, given that it can break work flows
temporarily for gdb/strace users, they are likely to be prepared to spend
some time to tackle some issue on an upgrade rather than being surprised
after a daily update. On the other hand, if the issue occurs after a
release upgrade, developers are more likely to check the release notes and
consider this to be linked to a new feature rather than immediately
anticipating a bug (there is feedback from software developers in the
earlier proposal confirming this).
== How To Test ==
Testing the kernel default of ptrace_scope (`1` & `2`) is easy and it can
be done temporarily (reset to the package's ptrace_scope=`0` after reboot)
or permanently by several means. The easiest and for now most transparent
ways are the following:
Temporarily: `sysctl kernel.yama.ptrace_scope=1` (as long as the package is
installed, it will be reset to `0` after rebooting)
Permanently: `echo "kernel.yama.ptrace_scope = 1" >> /etc/sysctl.conf`
(while the package overrides the kernel default, this line will
subsequently override the value set by the package: this can be undone just
by removing the line again from `/etc/sysctl.conf`).
If the setting `2` is to be tested, just replace the `1` in the above
commands with `2` (this change proposal will NOT enable/install `2` by
default!).
The very value of ptrace_scope can be checked / verified at all times with
`cat /proc/sys/kernel/yama/ptrace_scope`
'''Please do not test ptrace_scope with the setting `3` unless you read
about its implications''', as the implications differ to `1` and `2`. I
expect `3` is not relevant for Fedora.
== User Experience ==
Except for people who aim to debug running applications by attaching tools
like `gdb` or `strace`, there should be no measurable/perceived impact: the
setting `1` is well understood through most Linux distributions already
using it by default for about 10 years (e.g., openSuSE, Arch Linux, Ubuntu).
With regards to raising awareness and simplifying to set ptrace_scope to
`2`, users (who have an interest to increase their security by reducing
potential for related attack vectors) might become more likely aware of it,
and have a simplified means to implement it. This also simplifies providing
Docs pages about ptrace_scope with `2`.
This change should decrease the likelihood that people experience attacks /
exploitations of vulnerabilities / stealing of data related to ptrace.
== Dependencies ==
There are no technical or package dependencies. But the owner depends on
others to remove the package `elfutils-default-yama-scope` from the
repositories.
== Contingency Plan ==
* Contingency mechanism: if the feature cannot be implemented on time, it
can just be postponed to the then-next release.
* Contingency deadline: to be determined by FESCo/RelEng
* Blocks release? No.
== Documentation ==
'''kernel.yama.ptrace_scope:'''
https://wiki.archlinux.org/title/Security#ptrace_scopehttps://docs.kernel.org/admin-guide/LSM/Yama.html
'''Earlier related discussions before and during the first proposal:'''
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
(most recent discussion in devel mailing list)
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
(devel mailing list discussion of preceding, withdrawn proposal)
https://discussion.fedoraproject.org/t/f44-change-proposal-mitigate-vulnera…
(discourse discussion of preceding, withdrawn proposal)
https://discussion.fedoraproject.org/t/increase-security-by-adjusting-kerne…
(discourse discussion of the time before the preceding, withdrawn proposal)
'''Agreement with Docs team & elaboration of proposed Docs pages:'''
https://discussion.fedoraproject.org/t/new-quick-docs-page-necessary-for-ch…
'''Bug tickets of 2015 documenting parts of the issue handling that lead to
the original disabling of `kernel.yama.ptrace_scope` after it was enabled
by the upstream kernel:'''
https://bugzilla.redhat.com/show_bug.cgi?id=1196825https://bugzilla.redhat.com/show_bug.cgi?id=1209492https://bugzilla.redhat.com/show_bug.cgi?id=1234951https://bugzilla.redhat.com/show_bug.cgi?id=1250079
== Release Notes ==
If the package is removed & ptrace_scope set to the kernel default, the
Fedora release no longer containing this package should contain the
following in the release notes if the Docs pages are implemented:
''The security-relevant kernel setting `kernel.yama.ptrace_scope` is reset
from `0` to the kernel default `1` (see [
https://docs.kernel.org/admin-guide/LSM/Yama.html upstream Docs of the
setting]) through removing the package `elfutils-default-yama-scope`:
kernel.yama.ptrace_scope can break some functions of tools like gdb or
strace (debugger tools) if the functions are related to attaching the tool
to other processes. Documentation to mitigate the debugger issues is
provided in the Quick Docs' "Troubleshooting" section: it might be
necessary to disable kernel.yama.ptrace_scope temporarily or permanently
when attaching gdb or other tools to processes, depending on user
preferences. Keep in mind that this is an important security function to
protect processes and contained data.''
An alternative if the Docs pages are not implemented, is:
''The security-relevant kernel setting `kernel.yama.ptrace_scope` is reset
from `0` to the kernel default `1` (see [
https://docs.kernel.org/admin-guide/LSM/Yama.html upstream Docs of the
setting]) through removing the package `elfutils-default-yama-scope`:
kernel.yama.ptrace_scope can break some functions of tools like gdb or
strace (debugger tools) if the functions are related to attaching the tool
to other processes. It might be necessary to disable
kernel.yama.ptrace_scope temporarily when attaching gdb or other tools to
processes that are not child processes with `sysctl
kernel.yama.ptrace_scope=0` (default is 1, undone automatically after
reboot). Permanent disabling is possible as well (read the file
`/usr/share/doc/systemd/20-yama-ptrace.conf` for instructions), but keep in
mind that this is an important security function to protect processes and
contained data.''
Wiki: https://fedoraproject.org/wiki/Changes/GNUToolchainF44
Discussion Thread: https://discussion.fedoraproject.org/t/174483
**This is a proposed Change for Fedora Linux.**
This document represents a proposed Change. As part of the Changes process,
proposals are publicly announced in order to receive community feedback.
This proposal will only be implemented if approved by the Fedora
Engineering Steering Committee.
== Summary ==
Update the Fedora 44 GNU Toolchain to gcc 16.0, binutils 2.46, glibc 2.43
and gdb 16.3.
The set of core GNU Toolchain packages for Fedora 44 are as follows:
* GNU C Compiler 16.0
** Associated runtimes for C++ (libstdc++), Go (gccgo), OpenMP (gomp),
Fortran (gfortran), D (phobos), Objective C/C++.
* GNU Binary Utilities 2.46
* GNU C Library 2.43
* GNU Debugger 16.3 (immediately available in Fedora 43)
The gcc 16.0 change will be tracked in this top-level GNU Toolchain
system-wide change request.
The binutils 2.46 change will be tracked in this top-level GNU Toolchain
system-wide change request.
The glibc 2.43 change will be tracked in this top-level GNU Toolchain
system-wide change request.
The gdb 16.3 update was rolled out across all Fedora releases and the move
to newer versions will be handled in the same fashion. The debugger is
capable of debugging the binary artifacts produced by the rest of the
system toolchain.
== Owner ==
* Name: [[User:codonell|Carlos O'Donell]]
* Email: carlos(a)redhat.com
== Detailed Description ==
The GNU Compiler Collection, GNU Binary Utilities, GNU C Library, and the
GNU Debugger make up the core part of the GNU Toolchain and it is useful
for our users to transition these components as a complete implementation
when making a new release of Fedora.
The GNU Compiler Collection is expected to release version 16.0, before the
Fedora 44 release. It will contain many new features, documented here:
https://gcc.gnu.org/gcc-16/changes.html. The latest point release for gcc
16 will be included in Fedora 44, this will most probably be 16.0 or 16.1.
The GNU Binutils version 2.46 will be released before Fedora 44; and we
have already been using this version of binutils in Fedora Rawhide to
successfully build the distribution. Given the present schedule for Fedora
44 we will continue to use Binutils 2.46.
The GNU C Library version 2.43 is expected to be released before Fedora 44;
we have started closely tracking the glibc 2.43 development code in Fedora
Rawhide and are addressing any issues as they arise. Given the present
schedule Fedora 44 will branch before the release of glibc 2.43. However,
the mass rebuild schedule means Fedora 44 will mass rebuild before the
final release of glibc 2.43, but after the ABI is frozen.
The GNU Debugger version 16.3 has already been rolled out across all Fedora
releases at the same time.
== Benefit to Fedora ==
Stays up to date with latest features, improvements, security and bug fixes
from gcc, glibc, binutils, and gdb upstream.
The goal is to track and transition to the latest components of the GNU
Toolchain.
== Scope ==
* Release engineering: A mass rebuild is strongly encouraged; [
https://forge.fedoraproject.org/releng/tickets/issues/13102 #13102]
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
The compiler, the static linker and the the library are backwards
compatible with the previous version of Fedora.
Some source changes may be required for gcc 16 rebase:
https://gcc.gnu.org/gcc-16/changes.html
Any source level changes required for glibc 2.43 will be noted here:
https://sourceware.org/glibc/wiki/Release/2.43#Packaging_Changes
== How To Test ==
The GNU Compiler Collection has its own test suite which is run during the
package build and examined by the gcc developers before being uploaded.
The GNU C Library has its own test suite which is run during the package
build and examined by the glibc developers before being uploaded. This test
suite has over 6200 tests that run to verify the correct operation of the
library. In the future we may also run the microbenchmark to look for
performance regressions.
The GNU Binutils has its own test suite which is run during the package
build and examined by binutils developers before being uploaded. The
regression test suite is run to verify the correct operation of the static
linker and attendant utilities.
The GNU Debugger has its own test suite which is run during the package
build and examined by gdb developers before being uploaded. The regression
test suite is run to verify the correct operation of the debugger.
== User Experience ==
Upgrading the 4 main GNU Toolchain components (gcc, binutils, glibc, and
gdb) ensures that users have an up to date working system compiler,
assembler, static linker, core language runtimes (C, C++, etc), dyanmic
linker, and debugger. All of these components are being updated to provide
support for newer language features, and hardware features; enabling users
to make use of these features for their applications. In some cases the
components are updated in a synchronized fashion if a feature requires
support across the components that constitute the implementation e.g.
compiler feature that requires language library support.
== Dependencies ==
All packages do not need to be rebuilt due to backwards compatibility.
However, it is advantageous if a mass rebuild is performed during the
Fedora 44 cycle. The mass rebuild would ensure all packages can be built
with the newer compiler and core runtimes.
== Contingency Plan ==
* Contingency mechanism glibc: If glibc 2.43 proves too disruptive to
compiling the distribution we could revert to 2.42, but given that Rawhide
has started tracking glibc 2.43, no show-stopper problems are expected. At
this point we can still revert to upstream version 2.42 if insurmountable
problems appear, but to do so may require a mass rebuild to remove new
symbols from the ABI/API.
* Contingency mechanism binutils: If binutils 2.46 proves too distruptive
to assembling and linking the distribution we could revert to 2.45, but
given that Rawhide is using 2.46, no show-stopper problems are expected. At
this point we can still revert if insurmountable problems appear, but to do
so may require a mass rebuild if the defects involve generated binaries.
* Contingency mechanism for gcc: If gcc 16 proves too disruptive to
compiling the distribution we could revert to gcc 15, but given that we are
executing a [https://gitlab.com/fedora/packager-tools/mass-prebuild
mass-prebuild] using COPR we expect to have advance warning of any serious
problems.
* Blocks release?
** Yes, upgrading to gcc 16.0 does block the release.
** Yes, upgrading to binutils 2.46 does block the release.
** Yes, upgrading to glibc 2.43 does block the release.
** No, upgrading to gdb 16.3 does not block the release.
== Documentation ==
The gcc manual contains the documentation for the release and doesn't need
any more additional work.
The binutils manual contains the documentation for the release and doesn't
need any more additional work.
The glibc manual contains the documentation for the release and doesn't
need any more additional work.
The gdb manual contains the documentation for the release and doesn't need
any more additional work.
== Release Notes ==
See https://gcc.gnu.org/gcc-16/changes.html for the GNU Compiler Collection
version 16 release notes.
The GNU C Library version 2.43 will be released at the beginning of
February 2026. The current NEWS notes can be seen here as they are added:
https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD
The GNU Binary Utilities version 2.46 will be released February 2026. The
current release notes will be sent to the developer mailing list.
The GNU Debugger version 16.3 was released April 2026. The release notes
can be seen here:
https://inbox.sourceware.org/gdb-announce/20250420180058.6F0538065D@takamak…
Wiki: https://fedoraproject.org/wiki/Changes/Budgie_10.10
Discussion Post:
https://discussion.fedoraproject.org/t/f44-change-proposal-budgie-10-10-sel…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process,
proposals are publicly announced in order to receive community feedback.
This proposal will only be implemented if approved by the Fedora
Engineering Steering Committee.
== Summary ==
Budgie 10.10 is the latest of Budgie 10 series by Buddies of Budgie. Budgie
10.10 migrates from X11 to Wayland.
== Owner ==
* Name: [[User:Joshstrobl| Joshua Strobl]], [[User:Ngompa| Neal Gompa]]
* Email: joshua(a)buddiesofbudgie.org, ngompa13(a)gmail.com
== Detailed Description ==
Budgie 10.10 is the latest release of Budgie Desktop. Budgie 10.10 migrates
from X11 to Wayland, ensuring a viable long-term user experience for Fedora
Budgie users and laying the groundwork for the next major Budgie release.
Budgie 10.10 uses labwc as its default compositor, offering a “labwc”
bridge which facilitates an out-of-the-box experience such as:
* Default keyboard shortcuts for common actions
* Input acceleration
* Setting default theming and synchronizing with system changes (gsettings
changes via Budgie Control Center and Budgie Desktop Settings)
* Window rules, snapping, and switcher
To provide an end-to-end Wayland experience, Fedora Budgie Spin will ship
with SDDM (which uses a Wayland compositor by default). Therefore, the
Fedora Budgie spin will be Wayland-native from startup to shutdown.
Budgie 10.10 ships alongside important updated components, including two
new components:
* Budgie Control Center: Trimmed or removed panels that are no longer
relevant or portable (for example, display configuration hooked into our
“Magpie” soft-fork of Mutter, which will not be supported or leveraged)
* Budgie Desktop View: This provides a desktop icons implementation and has
been updated to support Wayland (layer shell and use of libxfce4windowing)
* (NEW) Budgie Desktop Services: This is a new daemon that will be used
across Budgie 10.10 and future Budgie releases (11), initially providing
functionality for display configuration (over DBus).
* (NEW) Budgie Display Configurator: This is a new Qt6-based application
for configuring outputs (displays / monitors), hooking into Budgie Desktop
Services to provide a more user-friendly interface compared to typical
configuration under wlroots-based compositors (e.g. CLI or more
configuration-driven tools such as wlr-randr and kanshi)
With Budgie’s migration to Wayland, the budgie-screensaver (screen locker)
and magpie (window manager) packages will be retired for Fedora 44. In the
case of budgie-screensaver, gtklock will be used as a Wayland-friendly
screen locking solution.
== Feedback ==
N/A
== Benefit to Fedora ==
Fedora is an innovation hub for Linux development, especially in its
adoption of the Wayland protocol to improve security of end users’ systems,
encourage cross-organizational collaboration, and promote generalized or
userspace solutions to the benefit of users.
Budgie 10.10’s migration to Wayland follows in the same vein as KDE Plasma
and GNOME Shell’s defaulting to Wayland, helping to push adoption of
Wayland-centric solutions.
== Scope ==
* Proposal owners:
** fedora-comps: TBA
** livesys-scripts: [https://pagure.io/livesys-scripts/pull-request/31 Update
for switch to SDDM]
* Other developers: N/A (not needed for change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The upgrade to Budgie 10.10 should be mostly transparent. There are
limitations with regards to screensharing and screenshots due to the usage
of xdg-desktop-portal-wlr not offering support for per-window capture.
Budgie 10.10 still supports X11 applications through Xwayland.
== Early Testing (Optional) ==
N/A
== How To Test ==
To test the Budgie Spin:
# Boot the Fedora Budgie ISO image either on bare-metal or in a virtual
machine.
# Confirm successful boot into the Budgie Desktop environment.
# Launch Anaconda installer from the Budgie Menu (accessible in the left
corner of the bottom panel or pressing Super / Windows key) or from the
desktop icon.
# Confirm no issues with Budgie Desktop Settings (used for personalizing
Budgie Desktop). Budgie Desktop should have consistent iconography through
Papirus Icon Theme and GTK applications should use Pocillo. Confirm
functional system tray.
# Confirm functional and accessible Raven (pressing Super / Windows key + A
or Super / Windows key + N).
== User Experience ==
Much of the user experience should be the same as in previous releases,
with some notable exceptions:
* LightDM will be replaced with SDDM
* Display configuration is no longer in Budgie Control Center, but now a
separate Budgie Display Configurator application
* Bluetooth is no longer included in Budgie Control Center, but now a
separate “Bluejay” Bluetooth management / pairing application. While not
strictly related to Budgie 10.10, we will be taking the opportunity to
reduce dependency on old libraries (e.g. gnome-bluetooth3.34) to improve
long-term maintenance.
* Screencasting/screensharing and screenshotting will invoke a portal
** Due to the limitations with screenshotting, Budgie Screenshot does not
support window capture in the Wayland implementation, however it does
support region-based screenshot which should serve as a sufficient
workaround for end users.
** Screen recording / streaming has also been tested using Pipewire support
in OBS Studio
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Fedora Budgie SIG will roll back Budgie Desktop
and related components to Budgie 10.9.x, as well as unretiring
budgie-screensaver and magpie.
* Contingency deadline: Beta Freeze
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
User documentation is not yet available upstream, as Budgie 10.10 is not
yet released. Developer documentation is available at:
[https://docs.buddiesofbudgie.org/10.10/developer/introhttps://docs.buddiesofbudgie.org/10.10/developer/intro]
== Release Notes ==
Fedora Linux now ships Budgie 10.10, the latest release from Buddies of
Budgie. Budgie 10.10 offers its users a Wayland-centric user experience,
however X11 applications are still supported.
--
*Allison King*
Senior Technical Project Manager, In-Vehicle OS
Red Hat <https://www.redhat.com/>
alking(a)redhat.com
<https://red.ht/sig>
Wiki: https://fedoraproject.org/wiki/Changes/Ansible13
Discussion Thread: https://discussion.fedoraproject.org/t/172894
**This is a proposed Change for Fedora Linux.**
This document represents a proposed Change. As part of the Changes process,
proposals are publicly announced in order to receive community feedback.
This proposal will only be implemented if approved by the Fedora
Engineering Steering Committee.
== Summary ==
Update to from Ansible 11 and Ansible Core 2.18 to Ansible 13 and Ansible
Core 2.20, which includes major robustness and security fixes to the
templating engine which could break existing playbooks that had incorrect
behavior that was silently ignored in previous releases.
== Owner ==
* Name: [[User:gotmax23| Maxwell G]]; [[User:nirik| Kevin Fenzi]]
* Email: maxwell(a)gtmx.me; kevin(a)scrye.com
== Detailed Description ==
The premise of the change proposal is simple — a major version update from
Ansible 11 ({{package|ansible}}) / Ansible Core 2.18
({{package|ansible-core}}) to Ansible 13 / Ansible Core 2.20. This is being
filed as a Change proposal instead of a standard update due to major
internal changes.
These changes include major robustness and security enhancements to the
templating engine that were introduced in Ansible Core 2.19 which could
break existing playbooks that had incorrect behavior that was silently
ignored in previous releases. Error handling in general has been greatly
improved as a result of the templating changes. There is also the
`INJECT_FACTS_AS_VARS` deprecation introduced in Ansible Core 2.20. See the
[
https://docs.ansible.com/projects/ansible/devel/porting_guides/porting_guid…
Ansible 12 (core 2.19)] and [
https://docs.ansible.com/projects/ansible/devel/porting_guides/porting_guid…
Ansible 13 (core 2.20)] porting guides for more information.
== Feedback ==
== Benefit to Fedora ==
Fedora will have the latest version of Ansible and the latest features and
enhancements and continue receiving upstream support.
== Scope ==
* Proposal owners:
** Update the ansible and ansible-core packages
** Ensure Ansible Collections packages in Fedora are up to date and
compatible with the latest Ansible Core version.
** Ensure Ansible Collections packages in Fedora that are maintained by
packagers other than the Change owners are up to date and compatible with
the latest Ansible Core version.
== Upgrade/compatibility impact ==
See above.
== How To Test ==
Install the latest ansible/ansible-core packages once they arrive in the
Fedora repos and ensure that your existing playbooks and installed
collections and roles continue to function.
== User Experience ==
Users will have the latest version of Ansible and Ansible Core.
== Dependencies ==
Ansible Collection packages in Fedora should be tested against the new
ansible-core release.
== Contingency Plan ==
* Contingency mechanism: Revert ansible-core and ansible updates
== Documentation ==
* [
https://docs.ansible.com/projects/ansible/devel/porting_guides/porting_guid…
Ansible 12 Porting Guide]
* [
https://docs.ansible.com/projects/ansible/devel/porting_guides/porting_guid…
Ansible 13 Porting Guide]
== Release Notes ==
Update to Ansible 13 and Ansible Core 2.20, which includes major changes to
the playbook jinja2 templating engine.
There will be an outage starting at 2025-11-20 22:00 UTC,
which will last approximately 5 hours.
To convert UTC to your local time, take a look at:
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
...or run:
date -d '2025-11-20 22:00 UTC'
Reason for outage:
We will be applying all updates to servers and rebooting them.
Affected Services:
Many services will be affected, but most should only be down for a
short time as their particular resources are rebooted.
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/12894
Please join #admin:fedoraproject.org / #noc:fedoraproject.org on
matrix. Or add comments to the above ticket for more information or
feedback.
Updated status for this outage will be available at:
https://www.fedorastatus.org/
Wiki: https://fedoraproject.org/wiki/Changes/UseKmsconVTConsole
Discussion Thread: https://discussion.fedoraproject.org/t/172602
**This is a proposed Change for Fedora Linux.**
This document represents a proposed Change. As part of the Changes process,
proposals are publicly announced in order to receive community feedback.
This proposal will only be implemented if approved by the Fedora
Engineering Steering Committee.
== Summary ==
This change is to replace the kernel console '''fbcon''' with the userspace
console '''kmscon''' in Fedora, to provide an enhanced and more secure
console for Fedora users.
The long term goal is also to deprecate fbcon/fbdev emulation in the
kernel, and this is the first step in this direction.
== Owner ==
* Name: [[User:jfalempe| Jocelyn Falempe]]
* Email: <jfalempe(a)redhat.com>
== Detailed Description ==
'''fbcon''' is a terminal emulator in the kernel, which is not well
maintained (it lost scrolling support a few years ago due to a CVE), and
requires a fbdev emulation layer in the kernel, as all GPU drivers are
using the newer drm interface. It still requires userspace executable like
getty and bash to be useful.
'''kmscon''' is a simple terminal emulator based on linux kernel mode
setting (KMS). It can replace fbcon for VT console, and provide better
keyboard support, and better security.
This change will do the following:
Install kmscon by default, and update the symbolic link
/usr/lib/systemd/system/autovt@.service to point to kmsconvt@.service, to
start kmscon by default when switching VT.
kmscon should be the default also on non-graphical installation, as it
doesn't require any graphic library (only libdrm, to access the
framebuffer).
This change won't affect the installation, the boot process (like
encryption password fallback), as fbcon will still be compiled in the
kernel.
User can still revert to fbcon if they want, or if kmscon has issue on
their setup.
If kmscon fails to launch, it will fallback to getty/fbcon.
Currently kmscon depends on opengl/mesa, because it has an optional opengl
backend. But we don't want that on non-graphical server installation. I
will split the package in two, having something like kmscon and kmscon-gl
for the optional gl renderer.
== Feedback ==
== Benefit to Fedora ==
kmscon is more configurable, and has more features than fbcon:
* Uses xkbcommon for keyboard layout, so it supports multiple layout, and
switching between them with configurable shortcut.
* Has better unicode support.
* Can use pango for font rendering, and has better compatibility with
double-width character https://github.com/Aetf/kmscon/pull/135.
* Scrolling.
* Better security, as it's a userspace program, compared to fbcon running
in the kernel.
* A crash in kmscon will make the systemd service to restart it. A crash in
fbcon triggers a kernel panic.
Before F44 it may also have these additional features:
* Rotation support (with keyboard shortcut to rotate it at runtime)
https://github.com/Aetf/kmscon/pull/147
* Basic mouse/touchpad support, with copy/paste
https://github.com/Aetf/kmscon/pull/149
== Scope ==
* Proposal owners:
** Add kmscon in default installation target.
** Enable kmscon systemd service, for all tty, by changing the symbolic
link /usr/lib/systemd/system/autvt@.service, to point to kmsconvt@.service
** Split the kmscon package in 2, to avoid direct dependencies on egl.
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
== Early Testing (Optional) ==
== How To Test ==
Press Ctrl+alt+F3 to switch to the VT console.
Login and check if it's running kmscon with ''ps aux | grep tty3''
Check that you can scroll back with page up/page down.
Check that you can increase the font size with "ctrl +" and decrease with
"ctrl -"
== User Experience ==
==== Improvements ====
* The look & feel of the VT console, will be much better.
* Users will be able to configure special fonts, and use more unicode
characters.
* Users will have the same keyboard layout has what they have in graphical
environment. (Currently the kernel keyboard layout are different).
* Users will be able to scroll in the console.
==== Caveats ====
* Starting graphical application from the console (like "startx") won't
work, but you can work around it by using the script ''kmscon-launch-gui
startx''
== Dependencies ==
No dependencies.
== Contingency Plan ==
It should be easy to revert, just not install kmscon, and fbcon with getty
service will be the default.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Wiki: https://fedoraproject.org/wiki/Changes/DropQEMU32bitHostBuilds
Discussion Thread: https://discussion.fedoraproject.org/t/172601
**This is a proposed Change for Fedora Linux.**
This document represents a proposed Change. As part of the Changes process,
proposals are publicly announced in order to receive community feedback.
This proposal will only be implemented if approved by the Fedora
Engineering Steering Committee.
== Summary ==
The QEMU upstream project deprecated support for 32-bit host builds and
will start removing this in a near-term forthcoming release. It is not
practical for Fedora to re-enable 32-bit support over the long term, as
QEMU's intent with dropping 32-bit support code is to enable code to be
changed to assume 64-bit atomic ops in all builds.
Fedora will thus stop building the QEMU package on the i686 architecture.
== Owner ==
* Name: [[User:berrange| Daniel Berrangé]]
* Email: berrange(a)redhat.com
== Detailed Description ==
The QEMU upstream project deprecated support for 32-bit host builds for
system emulator binaries in its 8.0.0 release (April 2023), and
subsequently deprecated all support for 32-bit host builds in its 10.0.0
release (April 2025).
The QEMU deprecation policy (
https://www.qemu.org/docs/master/about/deprecated.html) requires the
deprecation notice to be present for a minimum of 2 release before the
feature is removed. It is thus possible that some aspects of 32-bit host
support will be removed in 10.2.0 (Dec 2025) with full removal likely in
11.0.0 (April 2026).
It will not be practical for Fedora to re-enable support for 32-bit builds
with downstream patches, as QEMU intends to change its code to assume the
support of 64-bit atomic ops.
Fedora thus has to discontinue builds of QEMU on the i686 architecture, and
any packages which rely on QEMU provided binaries need to ensure they
exclude the i686 architecture.
Aside from upstream support, Fedora maintainers continue to expend (waste)
effort debugging koji build problems on i686 for binaries that will never
be present on any end user installation of Fedora, since QEMU has no
multilib components. The only place where the i686 binaries may get used is
in koji build roots for i686 builds via build dependencies.
=== Removed RPMs on i686 ===
* qemu
* qemu-audio-alsa
* qemu-audio-dbus
* qemu-audio-jack
* qemu-audio-oss
* qemu-audio-pa
* qemu-audio-pipewire
* qemu-audio-sdl
* qemu-audio-spice
* qemu-block-blkio
* qemu-block-curl
* qemu-block-dmg
* qemu-block-gluster
* qemu-block-iscsi
* qemu-block-nfs
* qemu-block-rbd
* qemu-block-ssh
* qemu-char-baum
* qemu-char-spice
* qemu-common
* qemu-device-display-qxl
* qemu-device-display-vhost-user-gpu
* qemu-device-display-virtio-gpu
* qemu-device-display-virtio-gpu-ccw
* qemu-device-display-virtio-gpu-gl
* qemu-device-display-virtio-gpu-pci
* qemu-device-display-virtio-gpu-pci-gl
* qemu-device-display-virtio-gpu-pci-rutabaga
* qemu-device-display-virtio-gpu-rutabaga
* qemu-device-display-virtio-vga
* qemu-device-display-virtio-vga-gl
* qemu-device-display-virtio-vga-rutabaga
* qemu-device-uefi-vars
* qemu-device-usb-host
* qemu-device-usb-redirect
* qemu-device-usb-smartcard
* qemu-docs
* qemu-guest-agent
* qemu-img
* qemu-kvm
* qemu-kvm-core
* qemu-pr-helper
* qemu-rdp
* qemu-sanity-check
* qemu-sanity-check-nodeps
* qemu-system-aarch64
* qemu-system-aarch64-core
* qemu-system-alpha
* qemu-system-alpha-core
* qemu-system-arm
* qemu-system-arm-core
* qemu-system-avr
* qemu-system-avr-core
* qemu-system-hppa
* qemu-system-hppa-core
* qemu-system-loongarch64
* qemu-system-loongarch64-core
* qemu-system-m68k
* qemu-system-m68k-core
* qemu-system-microblaze
* qemu-system-microblaze-core
* qemu-system-mips
* qemu-system-mips-core
* qemu-system-or1k
* qemu-system-or1k-core
* qemu-system-ppc
* qemu-system-ppc-core
* qemu-system-riscv
* qemu-system-riscv-core
* qemu-system-rx
* qemu-system-rx-core
* qemu-system-s390x
* qemu-system-s390x-core
* qemu-system-sh4
* qemu-system-sh4-core
* qemu-system-sparc
* qemu-system-sparc-core
* qemu-system-tricore
* qemu-system-tricore-core
* qemu-system-x86
* qemu-system-x86-core
* qemu-system-xtensa
* qemu-system-xtensa-core
* qemu-tests
* qemu-tools
* qemu-ui-curses
* qemu-ui-dbus
* qemu-ui-egl-headless
* qemu-ui-gtk
* qemu-ui-opengl
* qemu-ui-sdl
* qemu-ui-spice-app
* qemu-ui-spice-core
* qemu-user
* qemu-user-binfmt
* qemu-user-static
* qemu-user-static-aarch64
* qemu-user-static-alpha
* qemu-user-static-arm
* qemu-user-static-hexagon
* qemu-user-static-hppa
* qemu-user-static-loongarch64
* qemu-user-static-m68k
* qemu-user-static-microblaze
* qemu-user-static-mips
* qemu-user-static-or1k
* qemu-user-static-ppc
* qemu-user-static-riscv
* qemu-user-static-s390x
* qemu-user-static-sh4
* qemu-user-static-sparc
* qemu-user-static-x86
* qemu-user-static-xtensa
* libvirt-daemon-qemu
* libvirt-daemon-driver-qemu
=== Removed binaries on i686 ===
* /usr/bin/qemu-aarch64
* /usr/bin/qemu-aarch64_be
* /usr/bin/qemu-aarch64_be-static
* /usr/bin/qemu-aarch64-static
* /usr/bin/qemu-alpha
* /usr/bin/qemu-alpha-static
* /usr/bin/qemu-arm
* /usr/bin/qemu-armeb
* /usr/bin/qemu-armeb-static
* /usr/bin/qemu-arm-static
* /usr/bin/qemu-edid
* /usr/bin/qemu-ga
* /usr/bin/qemu-hexagon
* /usr/bin/qemu-hexagon-static
* /usr/bin/qemu-hppa
* /usr/bin/qemu-hppa-static
* /usr/bin/qemu-i386
* /usr/bin/qemu-i386-static
* /usr/bin/qemu-img
* /usr/bin/qemu-io
* /usr/bin/qemu-keymap
* /usr/bin/qemu-kvm
* /usr/bin/qemu-loongarch64
* /usr/bin/qemu-loongarch64-static
* /usr/bin/qemu-m68k
* /usr/bin/qemu-m68k-static
* /usr/bin/qemu-microblaze
* /usr/bin/qemu-microblazeel
* /usr/bin/qemu-microblazeel-static
* /usr/bin/qemu-microblaze-static
* /usr/bin/qemu-mips
* /usr/bin/qemu-mips64
* /usr/bin/qemu-mips64el
* /usr/bin/qemu-mips64el-static
* /usr/bin/qemu-mips64-static
* /usr/bin/qemu-mipsel
* /usr/bin/qemu-mipsel-static
* /usr/bin/qemu-mipsn32
* /usr/bin/qemu-mipsn32el
* /usr/bin/qemu-mipsn32el-static
* /usr/bin/qemu-mipsn32-static
* /usr/bin/qemu-mips-static
* /usr/bin/qemu-nbd
* /usr/bin/qemu-or1k
* /usr/bin/qemu-or1k-static
* /usr/bin/qemu-ppc
* /usr/bin/qemu-ppc64
* /usr/bin/qemu-ppc64le
* /usr/bin/qemu-ppc64le-static
* /usr/bin/qemu-ppc64-static
* /usr/bin/qemu-ppc-static
* /usr/bin/qemu-pr-helper
* /usr/bin/qemu-rdp
* /usr/bin/qemu-riscv32
* /usr/bin/qemu-riscv32-static
* /usr/bin/qemu-riscv64
* /usr/bin/qemu-riscv64-static
* /usr/bin/qemu-s390x
* /usr/bin/qemu-s390x-static
* /usr/bin/qemu-sanity-check
* /usr/bin/qemu-sh4
* /usr/bin/qemu-sh4eb
* /usr/bin/qemu-sh4eb-static
* /usr/bin/qemu-sh4-static
* /usr/bin/qemu-sparc
* /usr/bin/qemu-sparc32plus
* /usr/bin/qemu-sparc32plus-static
* /usr/bin/qemu-sparc64
* /usr/bin/qemu-sparc64-static
* /usr/bin/qemu-sparc-static
* /usr/bin/qemu-storage-daemon
* /usr/bin/qemu-system-aarch64
* /usr/bin/qemu-system-alpha
* /usr/bin/qemu-system-arm
* /usr/bin/qemu-system-avr
* /usr/bin/qemu-system-hppa
* /usr/bin/qemu-system-i386
* /usr/bin/qemu-system-loongarch64
* /usr/bin/qemu-system-m68k
* /usr/bin/qemu-system-microblaze
* /usr/bin/qemu-system-microblazeel
* /usr/bin/qemu-system-mips
* /usr/bin/qemu-system-mips64
* /usr/bin/qemu-system-mips64el
* /usr/bin/qemu-system-mipsel
* /usr/bin/qemu-system-or1k
* /usr/bin/qemu-system-ppc
* /usr/bin/qemu-system-ppc64
* /usr/bin/qemu-system-riscv32
* /usr/bin/qemu-system-riscv64
* /usr/bin/qemu-system-rx
* /usr/bin/qemu-system-s390x
* /usr/bin/qemu-system-sh4
* /usr/bin/qemu-system-sh4eb
* /usr/bin/qemu-system-sparc
* /usr/bin/qemu-system-sparc64
* /usr/bin/qemu-system-tricore
* /usr/bin/qemu-system-x86_64
* /usr/bin/qemu-system-x86_64.rpm
* /usr/bin/qemu-system-xtensa
* /usr/bin/qemu-system-xtensaeb
* /usr/bin/qemu-trace-stap
* /usr/bin/qemu-vmsr-helper
* /usr/bin/qemu-x86_64
* /usr/bin/qemu-x86_64-static
* /usr/bin/qemu-xtensa
* /usr/bin/qemu-xtensaeb
* /usr/bin/qemu-xtensaeb-static
* /usr/bin/qemu-xtensa-static
== Feedback ==
TBD
== Benefit to Fedora ==
Fedora QEMU maintainers no longer have to waste effort debugging periodic
failures on i686 builds, which are never installed by Fedora users.
Fedora QEMU maintainers will not have to hold QEMU back on an outdated
upstream release to retain i686 support. Such an outdated release will
accumulate CVEs and miss out on new features.
== Scope ==
=== Proposal owners ===
* Submit PRs to any Fedora RPMs that pull in QEMU packages in i686 build
roots to "ExcludeArch: i686"
* Add 'ExcludeArch: i686' to QEMU
=== Other developers ===
* Merge any PRs submitted to their packages which depend on QEMU in i686
build roots. (Most are already merged)
=== Release engineering ===
N/A
=== Policies and guidelines ===
N/A
=== Trademark approval===
N/A
=== Alignment with the Fedora Strategy ===
N/A
== Upgrade/compatibility impact ==
Fedora already dropped i686 as an installable architecture many releases
ago. i686 packages are only consumed in multilib context, and QEMU does not
have any binaries that are relevant to multilib. Thus there should be no
impact on end user deployments of Fedora from dropping of i686 builds for
QEMU.
Downstream maintainers who consume Fedora content (eg Copr, RPM Fusion) who
rely on i686 QEMU builds as dependencies in a build root will have to add
`ExcludeArch: i686` to any affected RPM spec files.
== Early Testing (Optional) ==
leafdrop is used to identify all packages which need adapting before QEMU
is made to ExcludeArch. Final validation will be a lack of any new FTBFS
after QEMU excludes i686.
== How To Test ==
* Observe that there are no i686 packages of QEMU in the koji builds in
rawhide after the exclusion of i686.
* Observe that there are no newly discovered FTBFS issue reported after the
exclusion of QEMU on i686.
== User Experience ==
i686 is not a deployment architecture for Fedora any more so no deployment
experience changes.
Developers relying on QEMU in i686 build roots will have to add ExcludeArch.
== Dependencies ==
Most dependencies which pull QEMU into i686 build roots have already had an
'ExcludeArch: i686' added. Currently identified remaining deps on QEMU
(direct & indirect) are:
* appliance-tools - [PR blocked pending acceptance of livecd-tools PR]
* condor - https://src.fedoraproject.org/rpms/condor/pull-request/5 ✅
* fence-agents -
https://src.fedoraproject.org/rpms/fence-agents/pull-request/7 ✅
* genimage - https://src.fedoraproject.org/rpms/genimage/pull-request/1 ✅
* gnome-boxes -
https://src.fedoraproject.org/rpms/gnome-boxes/pull-request/18 ✅
* kiwi - https://src.fedoraproject.org/rpms/kiwi/pull-request/12
* libvirt - libvirt-daemon-driver-qemu & libvirt-daemon-qemu sub-RPMs to be
disabled
* libvirt-sandbox -
https://src.fedoraproject.org/rpms/libvirt-sandbox/pull-request/2
* livecd-tools -
https://src.fedoraproject.org/rpms/livecd-tools/pull-request/5
* nbdkit - https://src.fedoraproject.org/rpms/nbdkit/pull-request/10 ✅
* rubygem-ruby-libvirt -
https://src.fedoraproject.org/rpms/rubygem-ruby-libvirt/pull-request/4 ✅
* vhostmd - https://src.fedoraproject.org/rpms/vhostmd/pull-request/5 ✅
== Contingency Plan ==
== Documentation ==
This change proposal is sufficient documentation for the removal of i686
builds.
== Release Notes ==
i686 builds of QEMU are no longer available.