Wiki - https://fedoraproject.org/wiki/Changes/StratisAnacondaSupport
Discussion thread -
https://discussion.fedoraproject.org/t/f45-change-proposal-stratis-storage-…
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 aims to add support for installing Fedora on
[https://stratis-storage.github.io/ Stratis] filesystems. This
includes support in [[Anaconda/Kickstart|Kickstart]] for automated
installation and manual partitioning in the Anaconda WebUI using
[https://cockpit-project.org/ Cockpit Storage].
== Owner ==
* Name: [[User:vtrefny|Vojtech Trefny]]
* Email: `vtrefny AT redhat.com`
== Detailed Description ==
Stratis is a local storage management solution that simplifies
filesystem feature orchestration by combining the block-layer and XFS
filesystem into a unified CLI and D-Bus API control plane. Stratis has
robust features such as, thin-provisioning, thin-safeguards,
snapshots, cache tiers, and encryption.
This change will make Stratis a bootable, installer-supported solution
for Fedora. While Stratis has been available in Fedora for several
years, this change integrates native Kickstart support to allow users
to configure Stratis as their default, end-to-end storage management
implementation for both the primary root (/) filesystem and
supplementary filesystems.
== Feedback ==
Stratis has been available in Fedora since
[[Changes/StratisStorage|Fedora 28]] with new versions being added
over the years, but support for using Stratis for the root filesystem
is not yet available which limits our ability to gather feedback.
We've seen [https://discussion.fedoraproject.org/t/f37-server-kickstarter-example-to-en…
some interest in using Stratis on Fedora] and there is
[https://github.com/bmr-cymru/stratify a third-party tool] that allows
manual installation on Stratis, but without support in the installer,
we cannot really judge the popularity or potential of a new storage
technology like this.
== Benefit to Fedora ==
Stratis provides modern storage features such as thin provisioning,
snapshots, cache tiers, and encryption, through a single, unified
management layer. Achieving a comparable feature set requires manually
layering multiple technologies, each with its own tooling and
configuration. Stratis simplifies this into a single tool.
While Stratis has been available in Fedora since Fedora 28, the lack
of installer support has been a significant barrier to adoption: users
could not use Stratis for their root filesystem without resorting to
manual, unsupported workarounds. This change removes this barrier
making Stratis a first-class installation option alongside Btrfs and
LVM.
== Scope ==
* Proposal owners:
** Kickstart: New kickstart commands for creating Stratis pools and
filesystems will be added. Similar to the existing `volgroup` and
`logvol` commands for creating LVM Volume Groups and Logical Volumes.
** Anaconda: New automatic partitioning "type" will be added for Stratis.
** Blivet: Blivet already supports Stratis, some small changes might
be needed for the automatic partitioning support.
* Other developers:
** The scope of this change is limited to the installer and its
dependencies ([[Blivet]] and pykickstart). We are also coordinating
with the Stratis project developers in case some changes or fixes are
needed in Stratis itself.
* Release engineering:
[https://forge.fedoraproject.org/releng/tickets/issues/13395 #13395]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
This change does not affect upgrades. Only new installations will be
affected by this change.
== Early Testing (Optional) ==
<!-- This is an optional step for system-wide changes to avail of. If
you would like to build an initial proof of concept of your change and
have a member of Fedora QA help you write and/or run some initial
basic tests on your code, please email tests(a)fedoraproject.org and
include the link to your change proposal. This step is *optional*. -->
Do you require 'QA Blueprint' support? No
Early images for testing can be provided by the developers. Once
Stratis is included on the installation images, manual installation
using Cockpit or mountpoint assignment as described below, can be
tested.
== How To Test ==
=== WebUI ===
The WebUI itself doesn't allow for selecting the storage technology
which will be used for automated or guided partitioning. Stratis
layout can be created through the external Cockpit storage editor. The
installer will automatically use Stratis devices created this way.
Preexisting Stratis filesystems can be also used in the mount point
assignment installation method. Generic documentation for storage
configuration in Anaconda can be found
[https://anaconda-installer.readthedocs.io/en/latest/anaconda-webui/docs/ins…
here].
# On the ''Installation method'' page start Cockpit storage editor
using the ''Launch storage editor'' option from the menu.
# Create partitions required for booting (`/boot` and `/boot/efi` or
`biosboot`).
# Create Stratis pool.
# Create Stratis filesystems for `/` and `/home` (and other
filesystems as needed).
# Return to the installer.
# Newly created layout should be recognized and the ''Use configured
storage'' option should be selected.
# Finish the installation.
[[File:Stratis1.png|thumb|center]][[File:Stratis2.png|thumb|center]]
=== Kickstart ===
Below are snippets of kickstart files with storage configuration.
These are only examples and the exact syntax of the commands might
change. Full example kickstart files for testing will be provided
later.
==== Automatic partitioning ====
autopart --type=stratis
Automatic partitioning with Stratis. The exact storage layout will be
determined by the installer based on the available disk space. This
doesn't differ from automatic partitioning with LVM or Btrfs.
==== Manual partitioning ====
part bd.01 --size=18000 --ondisk=vda
part bd.02 --size=18000 --ondisk=vdb
stratispool mypool bd.01 bd.02
stratisfs / --size=10000 --name=root --pool=mypool
stratisfs /home --size=1 --grow --name=home --pool=mypool
Example of manual Stratis configuration in kickstart. Two 18 GB
partitions will be created on vda and vdb disks (`/boot` and other
partitions needed for booting are not shown here). One new Stratis
pool named `mypool` and two filesystems: 10 GB `root` for `/` and ~26
GB `home` for `/home` (remaining free space after creating the root
filesystem) will be created.
== User Experience ==
Users who are not using advanced storage configuration or are not
interested in trying Stratis shouldn't notice any changes. Default
behavior of the installer, storage type and layout will remain the
same, as configured for the specific Fedora variant.
For users that want to use Stratis, this will be a major
simplification of the process. Stratis will be included on the Fedora
images and users will be able to use Stratis for their root filesystem
without any additional manual steps needed. Kickstart support is aimed
mostly at advanced users, but with the Cockpit support in the WebUI,
Stratis can be configured and used the same way as any other
non-default storage technology.
Note that there is no plan for including support for Stratis in the
old GTK-based Anaconda interface.
== Dependencies ==
Directly affected packages: blivet (`python3-blivet`), pykickstart
(`python3-kickstart`), anaconda.
We don't expect any other packages to be affected by this change and
we don't require assistance from other packagers.
`stratisd`, `stratis-cli` and `stratisd-dracut` packages will be added
as new dependencies to Anaconda. Total installation size on Fedora
Workstation Live image is 28 MiB. The resulting boot ISO image grows
from about 1193 MiB to 1206 MiB with these packages included.
== Contingency Plan ==
* Contingency mechanism: Reverting the changes in pykickstart and anaconda.
* Contingency deadline: beta freeze
* Blocks release? No
== Documentation ==
The newly added kickstart commands will be documented in the
[https://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#chapter-2-…
pykickstart documentation]. Documentation for Stratis can be found on
the [https://stratis-storage.github.io/ project website].
Previous articles about Stratis are also available on Fedora Magazine:
* [https://fedoramagazine.org/getting-started-with-stratis-up-and-running/
Getting started with Stratis – up and running]
* [https://fedoramagazine.org/getting-started-with-stratis-encryption/
Getting started with Stratis – encryption]
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/Ruby_on_Rails_8.1
Discussion thread -
https://discussion.fedoraproject.org/t/f45-change-proposal-ruby-on-rails-8-…
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 ==
Ruby on Rails 8.1 is the latest version of well known web framework
written in Ruby.
== Owner ==
* Name: [[User:vondruch | Vít Ondruch]]
* Email: vondruch(a)redhat.com, ruby-sig(a)lists.fedoraproject.org
== Detailed Description ==
The Ruby on Rails stack is evolving quickly and Fedora needs to keep
pace with it.
Therefore the whole Ruby on Rails stack should be updated from 8.0 in
Fedora 44 to 8.1 (latest version) in Fedora 45.
This will ensure that all the Ruby developers using Fedora have the
latest and greatest RPM-packaged Ruby on Rails.
== Feedback ==
== Benefit to Fedora ==
This update will keep Fedora up-to-date and will ensure that the
current Ruby on Rails developers stay with us as they will get support
for system-packaged Ruby on Rails of the latest version. Update to
Rails 8.1 contains hundreds of fixes and improvements across all the
frameworks. For new features, please see [[#User_Experience|User
Experience]].
== Scope ==
* Proposal owners:
** The whole Rails stack has to be updated.
** Some dependencies of the Rails stack will need update.
** Current development state can be observed in
[https://copr.fedorainfracloud.org/coprs/vondruch/ror81/
vondruch/ror81] COPR repository.
* Other developers: Update Rails dependent packages to be working with
Ruby on Rails 8.1
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: ?
== Upgrade/compatibility impact ==
Web applications build above Ruby on Rails framework might need to be
updated. Official upstream upgrade guide might come handy:
http://guides.rubyonrails.org/upgrading_ruby_on_rails.html
== How To Test ==
* No special hardware is needed.
* Not all dependencies for default app are available in Fedora. Drop
those dependencies or grab them from RubyGems repo.
=== To test only Rails itself ===
dnf install rubygem-rails
rails new app
cd app && rails s
* Go to http://127.0.0.1:3000/ and make sure you are running Rails 8.1.x
=== To test the complete feature including generating a new Rails app
using RPM ===
dnf group install 'Ruby on Rails'
rails new app --skip-bundle && cd app
rails s
* Go to http://127.0.0.1:3000/ and make sure you are running Rails 8.1.x
=== Rails app with Fedora only dependencies ===
dnf group install 'Ruby on Rails'
rails new app --skip-bundle --skip-kamal --skip-solid --skip-brakeman
--skip-rubocop --skip-thruster --skip-bootsnap --skip-hotwire
cd app
rails s
* Go to http://127.0.0.1:3000/ and make sure you are running Rails 8.1.x
== User Experience ==
* New version of Ruby on Rails (8.1) available
* The most significant Rails 8.1 features:
** Active Job Continuations — long-running jobs can be broken into
discrete steps that resume from the last completed step after a
restart, rather than from the beginning.
** Structured Event Reporting — a new unified <code>Rails.event</code>
interface for producing structured, machine-readable events suitable
for post-processing and observability tooling.
** Local CI — a built-in CI declaration DSL defined in
<code>config/ci.rb</code> and run via <code>bin/ci</code>, enabling
developer machines to serve as local CI runners.
** Markdown Rendering — first-class support for responding to and
rendering Markdown content directly from controllers via
<code>format.md { render markdown: @object }</code>.
** Deprecated Associations — Active Record associations can now be
individually marked as deprecated (<code>deprecated: true</code>),
causing usage to be reported via warn, raise, or notify modes.
== Dependencies ==
* Ruby on Rails framework consists of multiple packages, which all
needs to be updated at once.
== Contingency Plan ==
* Contingency mechanism: None needed. Rails stack won't be updated
until all its dependencies are in Rawhide. After that, it will be a
simple matter of updating the core packages (and their dependencies)
via side-tag.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
* http://api.rubyonrails.org/
== Release Notes ==
* https://rubyonrails.org/2025/10/22/rails-8-1
* https://guides.rubyonrails.org/8_1_release_notes.html
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/BashColorPrompt_1.0
Discussion thread -
https://discussion.fedoraproject.org/t/f45-change-proposal-bash-color-promp…
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 ==
`bash-color-prompt` (BCP) version 1.0 is a rewrite of the
[[Changes/Color_Bash_Prompt]] (introduced in Fedora 39) with a new
cleaner simple design, which leans on bash `PROMPT_COMMAND` for
updating dynamic prompts. The default system prompt (still green) is
much simpler now and there is only one predefined function, which
enables optional customization.
== Owner ==
* Name: [[User:Petersen|Jens Petersen]]
* Email: <petersen(a)redhat.com>
== Detailed Description ==
This is a major update of the current bash-color-prompt package with a
cleaner more declarative "builder pattern"-style approach, which makes
it much easier for users to create their own highly customizable bash
prompts just by sequencing various helper functions.
Users can enable customization by add `bcp_setup` to their
`~/.bashrc`, which sets up `PROMPT_COMMAND` for dynamic prompts by
appending the `_bcp_build_prompt` function. Users can then define
`bcp_layout()` to create a custom prompt if they so wish, with
features like: timestamps, git branch, last command duration/exitcode,
shell level, container prefix, etc.
== Feedback ==
== Benefit to Fedora ==
Shell prompts are an important part of a terminal shell and this
change will improve Fedora's Bash prompt user experience.
== Scope ==
* Proposal owners:
** (optional) Rename the source package to `bash-color-prompt`
(instead of `shell-color-prompt`) - less confusing for users
*** submit a package review.
** Build new version
** Document how to configure
** Fix issues from feedback and improve the experience.
* Other developers: N/A
* Release engineering:
[https://forge.fedoraproject.org/releng/tickets/issues #Releng issue
number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
* Users who just use the default bash-color-prompt system
configuration should not notice any difference nor not need to change
anything.
* Simple user configs using `PROMPT_COLOR` and `PROMPT_DIR_COLOR` for
changing the default color prompt will continue to work, but more
complex custom bash-color-prompt's will need to be reworked.
* The new version makes creating custom prompts considerable easier,
more flexible, and easily extensible.
* There is no change to the default color prompt.
== How To Test ==
Alpha version can be tested today from this copr repo:
<https://copr.fedorainfracloud.org/coprs/petersen/bash-color-prompt/>
(which I have been running locally since January.)
More detailed instructions will come here.
See also:
* [https://github.com/juhp/bash-color-prompt/blob/main/example.bashrc.sh
an example custom config]
* https://github.com/juhp/bash-color-prompt
== User Experience ==
Users who are happy with the default (green) prompt do not need to do
anything. The opting out or disabling experience is unchanged.
Users will be able to create arbitrary custom bash prompts much more
easily than with the more rigid older bash-color-prompt.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism:
** owner to revert bash-color-prompt to the current old version from F44
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
The main documentation will be the README, which will be further
flexed out by the code completion.
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/oo7_Secrets_Service_Provider
Discussion thread -
https://discussion.fedoraproject.org/t/f45-change-proposal-oo7-secrets-serv…
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 ==
Switch the default Secrets Service provider for Fedora desktops from
KWallet and GNOME Keyring to oo7.
== Owner ==
* Name: [[User:ngompa| Neal Gompa]], [[User:decathorpe| Fabio
Valentini]], [[User:salimma| Michel Lind]]
* Email: ngompa13(a)gmail.com, decathorpe(a)gmail.com, michel(a)michel-slm.name
== Detailed Description ==
A new universal secrets storage system has been developed in the form
of [https://github.com/linux-credentials/oo7 oo7] that replaces
KWallet's backend and GNOME Keyring. Package up
<code>oo7-daemon</code> and associated support code and change the
Fedora default secrets storage backend to it across all desktops.
== Feedback ==
== Benefit to Fedora ==
The idea with this new secrets storage system is to support a new
model for credentials where scoped authorization is possible for
applications and services. Additionally, it opens the door for
mediating access to FIDO2-based authentication mechanisms. This lends
itself well to enabling limited trust to secrets for sandboxed
applications, among other things. KDE Plasma, COSMIC, and GNOME (among
others) are all converging on this and so enabling this allows Fedora
to remain at the forefront of supporting desktop technologies.
== Scope ==
* Proposal owners:
** Package <code>oo7-daemon</code>, PAM module, and other support code
** Add oo7 PAM module to relevant PAM configs where gnome-keyring and
kwallet PAM modules are listed
** Adjust comps to replace gnome-keyring with oo7-daemon
** Adjust dependencies in desktops to use oo7 instead of gnome-keyring
* Other developers: N/A (not needed for this Change)
* Release engineering:
[https://forge.fedoraproject.org/releng/tickets/issues/13405 #13405]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The oo7 service will automatically migrate existing data from GNOME
Keyring and KWallet, so no user interaction is required to handle the
transition.
== How To Test ==
Once oo7-daemon and related code are packaged and updated
configuration lands in Rawhide, users can test this simply by
upgrading and using things that leverage the secrets service like
normal.
== User Experience ==
This is expected to be fairly transparent to the user.
== Dependencies ==
This will involve updating the PAM configuration files for the
desktops and login managers used across Fedora deliverables.
== Contingency Plan ==
* Contingency mechanism: Revert swap to oo7 and defer to the next release
* Contingency deadline: Beta freeze
* Blocks release? Yes
== Documentation ==
More information about oo7 is present in [https://docs.rs/oo7/ the
upstream project documentation].
== Release Notes ==
Fedora Linux now uses the oo7 as the default secrets service provider,
replacing older solutions like GNOME Keyring. This brings enhanced
security to secrets management, particularly for sandboxed
applications, and enables FIDO2 authentication secrets.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/GNUToolchainF45
Discussion thread -
https://discussion.fedoraproject.org/t/f45-change-proposal-gnu-toolchain-up…
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 45 GNU Toolchain to gcc 16.2, binutils 2.47, glibc
2.44 and gdb 17.2.
'''Please note the related change request that includes enabling
Shadow Stack support by default in glibc, which is described as a
separate [https://fedoraproject.org/wiki/Changes/ShadowStack "Shadow
Stack" system-wide change request] for Fedora 45.'''
The set of core GNU Toolchain packages for Fedora 45 are as follows:
* GNU C Compiler 16.2
** Associated runtimes for C++ (libstdc++), Go (gccgo), OpenMP (gomp),
Fortran (gfortran), D (phobos), Objective C/C++.
* GNU Binary Utilities 2.47
* GNU C Library 2.44
* GNU Debugger 17.2 (immediately available in all Fedora releases)
The gcc 16.2 change will be tracked in this top-level GNU Toolchain
system-wide change request.
The binutils 2.47 change will be tracked in this top-level GNU
Toolchain system-wide change request.
The glibc 2.44 change will be tracked in this top-level GNU Toolchain
system-wide change request.
The gdb 17.2 update will be 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.
<!-- Use this text for a GCC update: -->
The GNU Compiler Collection is expected to release version 16.2,
before the Fedora 45 release. It will contain many new features,
documented here: https://gcc.gnu.org/gcc-16/changes.html.
<!-- Use this text for a BINUTILS update: -->
The GNU Binutils version 2.47 will be released before Fedora 45; and
we have already been using this version of binutils in Fedora Rawhide
to successfully build the distribution. Given the present schedule for
Fedora 45 we will continue to use Binutils 2.47.
<!-- Use this text for a GLIBC update: -->
The GNU C Library version 2.44 is expected to be released before
Fedora 45; we have started closely tracking the glibc 2.44 development
code in Fedora Rawhide and are addressing any issues as they arise.
Given the present schedule Fedora 45 will branch after the release of
glibc 2.44. However, the mass rebuild schedule means Fedora 45 will
mass rebuild before the final release of glibc 2.44, but after the ABI
is frozen.
<!-- Use this text for a GDB update: -->
The GNU Debugger version 17.2 will be 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 ==
* Proposal owners: Fedora Toolchain Team (gcc, glibc, binutils, gdb,
...) developers need to ensure that gcc, glibc, binutils, and gdb in
rawhide are stable and ready for the Fedora 45 branch.
* Other developers: Given that glibc is backwards compatible and we
have been testing the new glibc in rawhide it should make very little
impact when updated, except for the occasional deprecation warnings
and removal of legacy interfaces from public header files.
* Release engineering: A mass rebuild is strongly encouraged;
[https://forge.fedoraproject.org/releng/tickets/issues/13388 #13388]
* Policies and guidelines: N/A (not needed for this Change)
* 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.
<!-- Use this text for a GCC X update: We want to call out the CHANGES
URL from upstream. -->
<!-- Some source changes may be required for gcc X rebase:
https://gcc.gnu.org/gcc-X/changes.html -->
Any source level changes required for glibc 2.44 will be noted here:
https://sourceware.org/glibc/wiki/Release/2.44#Packaging_Changes
== How To Test ==
<!-- Use this text for a GCC update: -->
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.
<!-- Use this text for a GLIBC update: -->
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.
<!-- Use this text for a BINUTILS update: -->
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.
<!-- Use this text for a GDB update: -->
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 ==
<!-- TODO: Talk about any new GNU Toolchain user experience updates. -->
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 45 cycle. The mass rebuild would ensure all packages can be
built with the newer compiler and core runtimes.
== Contingency Plan ==
<!-- Use this text for a GCC update: -->
<!-- For Minor GCC updates -->
* Contingency mechanism for gcc: Since we are only updating to a point
release there is no contingency mechanism. It is expected that the
point release is not a disruptive event. We could revert to the
previous point release without difficulty.
* Contingency mechanism binutils: If binutils 2.47 proves too
distruptive to assembling and linking the distribution we could revert
to 2.46, but given that Rawhide is using 2.47, 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 glibc: If glibc 2.44 proves too disruptive to
compiling the distribution we could revert to 2.43, but given that
Rawhide has started tracking glibc 2.44, no show-stopper problems are
expected. At this point we can still revert to upstream version 2.43
if insurmountable problems appear, but to do so may require a mass
rebuild to remove new symbols from the ABI/API.
* Contingency mechanism gdb: We don't expect gdb updates to be
disruptive, but since code generation and runtime are not impacted
(except for debuginfo modification in the build process) it is
relatively low cost to revert to a previous version.
<!-- No comments needed because GDB updates asynchornously. -->
* Contingency deadline: Fedora mass rebuild on YYYY-MM-DD.
* Blocks release?
** No, upgrading to gcc 16.2 does block the release.
** Yes, upgrading to binutils 2.47 does block the release.
** Yes, upgrading to glibc 2.44 does block the release.
** No, upgrading to gdb 17.2 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 ==
<!-- Use this text for GCC updates: -->
See https://gcc.gnu.org/gcc-16/changes.html for the GNU Compiler
Collection version 16.2 release notes.
<!-- Use this text for BINUTILS updates: -->
The GNU Binary Utilities version 2.47 will be released August 2026.
The current release notes will be sent to the developer mailing list.
<!-- Use this text for GLIBC updates: -->
The GNU C Library version 2.44 will be released at the beginning of
August 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
<!-- Use this text for GDB updates: -->
The GNU Debugger version 17.2 was released May 2026. The release notes
can be seen here:
https://inbox.sourceware.org/gdb-announce/20260510153212.6F3B1160057@takama…
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/Fontconfig2.18
Discussion thread -
https://discussion.fedoraproject.org/t/f45-change-proposal-fontconfig-2-18-…
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 fontconfig package in Fedora from 2.17 to 2.18.
== Owner ==
* Name: [[User:Tagoh| Akira TAGOH]]
* Email: tagoh AT redhat DOT com
== Detailed Description ==
This aims to upgrade fontconfig package from 2.17 to 2.18. The
highlight of changes in 2.18 is available
[https://lists.freedesktop.org/archives/fontconfig/2026-May/007334.html
here].
== Feedback ==
== Benefit to Fedora ==
Fedora ships the latest release of fontconfig. Also, the safe guard in
new cache format to avoid updating from older versions of fontconfig.
== Scope ==
* Proposal owners:
** Submit PR for appstream and python-fontconfig to update the code
because they use freetype-dependent API without fcfreetype.h
* Other developers:
** The above package owners may need to apply a patch before
mass-reubuild. Otherwise it may simply fails.
* Release engineering:
[https://forge.fedoraproject.org/releng/tickets/issues/13404 #13404]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
2.18 should be basically compatible with 2.17. However, if users has
own fonts installed, they may see different font matching behavior. In
that case, users may need to have extra config rule to get it back to
normal for a short term.
Steps to check:
<ol>
<li>Run `fc-scan -f "%{genericfamily}\n" /path/to/fontdir/fontfile`</li>
<li>If the result shows 0:</li>
<li>Create a config file and store it to
$HOME/.config/fontconfig/conf.d, e.g. 0-'''familyname'''-scan.conf:
<div style="white-space: pre; font-family: monospace; background:
#f8f9fa; border: 1px solid #eaecf0; padding: 1em;">
<fontconfig>
<match target="scan">
<test name="family">
<string><b>Family Name</b></string>
</test>
<edit name="genericfamily" mode="assign_replace">
<const><b>Generic Alias Name such as sans-serif, serif,
monospace</b></const>
</edit>
</match>
</fontconfig>
</div></li>
<li>Regenerate a cache with `fc-cache -rv /path/to/fontdir`</li>
</ol>
== Early Testing (Optional) ==
== How To Test ==
Try upgrading fontconfig to 2.18 and your favarite GUI applications if
the font selection works as expected.
== User Experience ==
The font matching behavior for fallback should be better than 2.17.x.
== Dependencies ==
Nope more than the above packages requring some source code change.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Maintainer
will revert fontconfig to 2.17.x
* Contingency deadline: 100% Code Complete Deadline
* Blocks release? No
== Documentation ==
* https://lists.freedesktop.org/archives/fontconfig/2026-May/007334.html
* https://gitlab.freedesktop.org/fontconfig/fontconfig/-/releases
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/DisableVendorChangeByDefault
Discussion thread -
https://discussion.fedoraproject.org/t/f45-change-proposal-disable-vendor-c…
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 ==
Change the default configuration of '''DNF5/libdnf5''' by setting
<code>allow_vendor_change=False</code> via the distribution defaults
file <code>/usr/share/dnf5/libdnf.conf.d/20-fedora-defaults.conf</code>.
This prevents ''libdnf5'' from automatically replacing an installed
package from one vendor with a package from another vendor during any
transaction (such as upgrades, downgrades, or dependency resolution),
unless explicitly requested by the user or allowed by
''VendorChangeManager'' rules.
== Owner ==
* Name: [[User:jrohel| Jaroslav Rohel]],
[[Subprojects/ReleaseEngineering|Fedora Release Engineering /
Maintainers]]
* Email: <jrohel(a)redhat.com>, <fedora-release-maintainers(a)fedoraproject.org>
== Detailed Description ==
By default, ''libdnf5'' allows packages to switch vendors if a
repository provides a different version or release of a package with a
different <code>VENDOR</code> tag that satisfies a transaction. While
this can sometimes resolve dependencies automatically, it can lead to
unexpected behavior in multi-vendor setups (e.g., mixing packages
between official Fedora Project, RPM Fusion, Copr, or third-party
corporate repositories).
For instance, an essential multimedia package or a proprietary driver
supplied by a specific vendor could be silently overwritten or
downgraded by a package from another vendor during system updates or
dependency resolution, potentially breaking user setups.
By introducing <code>allow_vendor_change = false</code> into Fedora's
default distribution configuration for DNF5, Fedora will achieve
strict vendor isolation by default. A package will only be modified if
the replacement package originates from the same vendor as the
currently installed package, ensuring predictable behavior across all
package operations.
Any intentional vendor transitions (such as stock Fedora packages
being replaced by enhanced versions from RPM Fusion) will be handled
either explicitly by the user via CLI configuration overrides or
managed gracefully via ''VendorChangeManager'' rules defined in
configuration drop-ins.
== Feedback ==
'''Existing User Requests:'''
There have been long-standing community requests and discussions
regarding making vendor sticky behavior (in other words, disabling
vendor changes by default) the standard configuration in Fedora.
'''Vendor Equivalence & Advanced Rules:'''
During previous discussions, a common and critical requirement was the
ability to define vendor equivalence classes or establish special
transition rules for specific sets of vendors or packages. To address
this, ''libdnf5'' has been extended to support granular control over
vendor sticky behavior out of the box through its newly designed
''VendorChangeManager'' architecture.
'''Allowing Vendor Change for Specific Packages:'''
Community feedback emphasized that users must retain the flexibility
to intentionally switch vendors for specific packages without globally
disabling the vendor sticky protection. To support this use case,
''libdnf5'' has been enhanced, and the ''DNF5'' command-line interface
now includes a dedicated <code>--from-vendor=</code> argument. This
allows users to explicitly specify a set of permitted vendors for
specific packages during a given transaction, ensuring safe and
targeted package migrations.
'''Vendor Verification Override for Command-Line Packages:'''
An edge case raised in discussions involved local package
installations, where users requested that vendor restrictions be
ignored for packages explicitly provided via a direct file system
path. This requirement will be addressed as part of the scope of this
change. A configuration file
<code>/usr/share/dnf5/vendors.d/allow-cmdline.conf</code> will be
shipped with the following content, leveraging the
''VendorChangeManager'' to automatically permit vendor changes for
locally injected packages:
<pre>
version = '1.1'
[[incoming_packages]]
filters = [
{ filter = 'cmdline_repo', value = 'true' }
]
</pre>
== Benefit to Fedora ==
* '''System Stability:''' Reduces the risk of accidental vendor swaps
across all package operations (upgrades, downgrades, and dependency
resolution).
* '''Granular Control:''' Leverages DNF5's advanced architecture
(''VendorChangeManager'') to allow explicit, trusted vendor
transitions while keeping the general system safe from accidental
overwrites.
== Scope ==
* Proposal owners:
** Add <code>allow_vendor_change=False</code> to
<code>/usr/share/dnf5/libdnf.conf.d/20-fedora-defaults.conf</code> in
the <code>fedora-release-common</code> package.
** Ship a new <code>/usr/share/dnf5/vendors.d/allow-cmdline.conf</code>
in the <code>fedora-release-common</code> package, with the following
content:
<pre>
version = '1.1'
[[incoming_packages]]
filters = [
{ filter = 'cmdline_repo', value = 'true' }
]
</pre>
* Other developers:
N/A. This change is confined to the <code>fedora-release-common</code>
package. No changes to packaging guidelines, RPM spec files, or build
processes are required from other package maintainers.
* Release engineering:
[https://forge.fedoraproject.org/releng/tickets/issues/13394 #13394]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
This proposal does not directly target any specific Fedora Strategy
2028 theme, but it improves the reliability of the package management
foundation on which all Fedora variants build.
== Upgrade/compatibility impact ==
* '''Existing installations upgrading to Fedora 45:''' Will
automatically inherit this safety feature via the updated dnf5
defaults, unless the user has explicitly overridden
<code>allow_vendor_change = true</code> – e.g. in system configuration
files in <code>/etc/dnf/libdnf5.conf.d/</code> drop-in directory or
<code>/etc/dnf/dnf.conf</code>.
* '''User intervention for intentional changes:''' If a user
explicitly wants to switch a package to a different
<code>VENDOR</code> (and no ''VendorChangeManager'' rule applies),
they will need to use the <code>--from-vendor=VENDOR</code> or
<code>--setopt=allow_vendor_change=1</code> (which completely disables
vendor change control for all packages, not just for the package
listed in the command line) for that specific transaction.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? No
== How To Test ==
=== Test Scenario A: Preventing unwanted vendor change via Upgrade ===
# Install a <code>PACKAGE</code> with a specific <code>VENDOR</code>
tag (e.g., from a Copr repository).
# Enable another repository containing the same package name with a
higher version/release but with a different <code>VENDOR</code> tag,
ensuring no ''VendorChangeManager'' rule allows a transition between
these two specific vendors.
# Run <code>dnf5 upgrade PACKAGE</code>.
# '''Expected result:''' DNF5 should not replace the package with the
one from the new vendor. It should keep the current package and either
skip the update or fail with a dependency conflict.
# '''Verification of override:''' Running <code>dnf5
--setopt=allow_vendor_change=1 upgrade PACKAGE</code> should
successfully allow the transaction and change the vendor.
=== Test Scenario B: Preventing unwanted vendor change via Downgrade ===
# Install a <code>PACKAGE</code> with a specific <code>VENDOR</code>
tag (e.g., from a Copr repository).
# Enable another repository containing the same package name with a
lower version/release but with a different <code>VENDOR</code> tag,
ensuring no ''VendorChangeManager'' rule allows a transition between
these two specific vendors.
# Run <code>dnf5 downgrade PACKAGE</code>.
# '''Expected result:''' DNF5 should not swap the package vendor to
perform the downgrade. It should refuse the transaction or fail with a
dependency conflict.
# '''Verification of override:''' Running <code>dnf5
--setopt=allow_vendor_change=1 downgrade PACKAGE</code> should
successfully allow the transaction and change the vendor.
== User Experience ==
* '''Users with only official Fedora repositories:''' No noticeable
change. Packages should originate from the same vendor, so no vendor
change conflicts should arise during updates.
* '''Users with packages from multiple sources (RPM Fusion, Copr,
corporate repositories, etc.):''' DNF5 will no longer silently replace
a package installed from one source with a version from a different
source. If a system update or dependency resolution would result in
such a replacement, DNF5 will decline the transaction and inform the
user about the conflict, instead of making the change without notice.
* '''Installing a local RPM file:''' Installing a package directly
from a file (e.g. <code>dnf5 install ./package.rpm</code>) will
continue to work as before, without requiring any additional options.
* '''Intentional vendor switch:''' Users who deliberately want to
replace a package with a version from a different source can use the
new <code>--from-vendor=VENDOR</code> option to allow that specific
switch for the duration of the transaction.
== Dependencies ==
This change requires that ''libdnf5'' with full
''VendorChangeManager'' support, the <code>allow_vendor_change</code>
configuration option, and the <code>--from-vendor=</code> CLI argument
is available in Fedora 45. This requirement is already satisfied: the
necessary ''libdnf5'' version is available in Fedora 44 updates and
will be present in Fedora 45.
== Contingency Plan ==
* Contingency mechanism: Revert the shipped configuration.
* Contingency deadline: the beta freeze.
* Blocks release? No.
== Documentation ==
* The <code>allow_vendor_change</code> configuration option is
documented in the
[https://dnf5.readthedocs.io/en/latest/dnf5.conf.5.html DNF5
Configuration Reference].
* The ''VendorChangeManager'' rule file format (used for the
<code>/usr/share/dnf5/vendors.d/</code> drop-in directory) is
documented in the
[https://dnf5.readthedocs.io/en/latest/dnf5.conf-vendorpolicy-v1_1.5.html
DNF5 Vendor Change Policy File Reference - v1.1].
* The <code>--from-vendor=</code> CLI argument is documented per
individual command, for example in the
[https://dnf5.readthedocs.io/en/latest/commands/install.8.html Install
Command] reference.
== Release Notes ==
Starting with Fedora Linux 45, '''DNF5/libdnf5''' no longer
automatically replaces an installed package with a version from a
different vendor during updates, downgrades, or dependency resolution.
If you have packages from third-party repositories (such as RPM
Fusion, Copr, or corporate repositories), '''DNF5/libdnf5''' will
refuse transactions that would silently switch those packages to a
different vendor and will notify you of the conflict instead.
To allow a vendor change for specific packages in a given transaction,
use the <code>--from-vendor=VENDOR</code> option. To disable this
protection entirely for a single transaction, use
<code>--setopt=allow_vendor_change=1</code>. To restore the previous
behavior permanently, set <code>allow_vendor_change = true</code> in a
drop-in configuration file under
<code>/etc/dnf/libdnf5.conf.d/</code>.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Planned Outage - download-ib01, torrent, people outage - 2026-06-25 20:00 UTC
There will be an outage starting at 2026-06-25 20:00UTC,
which will last approximately 1 hour.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2026-06-25 20:00 UTC'
Reason for outage:
We will be reinstalling the virthost that runs download-ib01, torrent.fedoraproject.org and fedorapeople.org.
During the outage these sites will be down.
Affected Services:
download-ib01 - rsync/http mirror
torrent - fedora torrent seed/tracker
fedorapeople - fedora people services
Ticket Link:
https://forge.fedoraproject.org/infra/tickets/issue/13431
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/