Wiki - https://fedoraproject.org/wiki/Changes/PostgreSQL_18
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-postgresql-18-se…
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 of default PostgreSQL stream (`postgresql` and `libpq`
components) in Fedora from version 16 to version 18. This continues
the versioned packaging structure introduced in Fedora 40.
== Owner ==
* Name: [[User:ndavidov| Nikola Davidová]]
* Email: ndavidov(a)redhat.com
== Detailed Description ==
Following the Fedora 40+ PostgreSQL packaging model, each major
version of PostgreSQL is delivered as a separate SRPM. The default
PostgreSQL stream is selected by naming the packages as postgresql,
postgresql-server, etc., while non-default versions use versioned
names like postgresql17.
For Fedora 43, the PostgreSQL 18 SRPM will provide the default
PostgreSQL implementation. The following mapping will apply:
postgresql SRPM -> deprecated
postgresql16 SRPM -> postgresql16, postgresql16-server, ...<br>
postgresql17 SRPM -> postgresql17, postgresql17-server, ...<br>
postgresql18 SRPM -> postgresql, postgresql-server, ...<br>
This also involves updating and rebuilding the PostgreSQL plugins that
depend on postgresql server.
== Feedback ==
== Benefit to Fedora ==
The latest stable software is provided for Fedora users.
== Scope ==
* Proposal owners:
<!-- What work do the feature owners have to accomplish to complete
the feature in time for release? Is it a large change affecting many
parts of the distribution or is it a very isolated change? What are
those changes?-->
**Prepare PostgreSQL 18 as the default stream
**Prepare PostgreSQL 16 as a non-default stream
**Check software that requires or depends on `postgresql-server` or
`libpq` packages for incompatibilities
**Build PostgreSQL 18 (postgresql and libpq) for Rawhide
**Build PostgreSQL 16 for Rawhide
**Rebuild dependent packages against PostgreSQL 18
* Other developers:
* Release engineering: [https://pagure.io/releng/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 Fedora Strategy:
== Upgrade/compatibility impact ==
The PostgreSQL client library (libpq component) is compatible. So,
there shouldn't be any compatibility issues, but rebuild of the
dependent components is recommended.
Server plugins might require a newer version update because they
sometimes have explicit server requirements.
== How To Test ==
All PG server plugins should be installable.
`postgresql-setup --upgrade` command should succeed.
Test that all other software runs well with PostgreSQL 18.
== User Experience ==
The users will have to upgrade their databases the same way as between
major PostgreSQL versions, aka `postgresql-setup --upgrade` after
installing PostgreSQL 18 server packages.
If users want to stick with PostgreSQL 16 for a little longer, there
will be PostgreSQL 16 as nondefault PostgreSQL stream
== Dependencies ==
There are some packages (mostly server plugins), that build on top of
PostgreSQL. Since the separation of PostgreSQL client library (libpq
component), only packages that build server plugins should use
postgresql package in BuildRequires. Others should use libpq. In the
case of Postgresql-server, a rebuild should be done to ensure all
potential binary incompatibilities are handled.
* PostgreSQL server dependecies
** perl-DBD-Pg
** pgaudit
** qt
** qt3
** qt5-qtbase
** postgres-decoderbufs
** gambas3
** kdb
** kea
** libpqxx
** openvas-manager
** orafce
** pg-semver
** pgRouting
** pgadmin3
** pgsphere
** postgis
** postgresql-ip4r
** postgresql-pgpool-II
** qt3
** rdkit
** rhdb-utils
** timescaledb
** pg_repack
== Contingency Plan ==
* Contingency mechanism: N/A (not a System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
Revert the changes and provide PostgreSQL 16 only.
== Documentation ==
Upgrade strategy: https://www.postgresql.org/docs/18/upgrading.html
N/A (not a System Wide Change)
== Release Notes ==
Release notes for PostgreSQL 18 release:
https://www.postgresql.org/docs/18/index.html
Overall overview of the changes and improvements:
https://www.postgresql.org/docs/18/release-18.html
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/NodejsAlternativesSystem
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-use-update-alter…
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 ==
We aim to move away from manual management of
<code>/usr/bin/node</code>, <code>/usr/bin/npm</code>, and similar
symlinks to leveraging update-alternatives system.
== Owners ==
* Name: [[User:aradchen|Andrei Radchenko]]
* Email: aradchen(a)redhat.com
* Name: [[User:jstanek|Jan Stanek]]
* Email: jstanek(a)redhat.com
* Name: [[User:tjuhasz|Tomas Juhasz]]
* Email: tjuhasz(a)redhat.com
== Detailed Description ==
This is a part of a larger iteration in a way we package NodeJS for
Fedora and RHEL. The other parts are [[Changes/NodejsNodeModulesPath]]
and [[Changes/NodeJSMetapackages]].
This change deals specifically with the management of the
non-versioned symlinks in system paths.
Currently, the NodeJS packages (streams) provided in Fedora are all
installable in parallel,
by virtue of moving any potentially conflicting bits into versioned
equivalents and/or versioned directories.
For one example of many:
<pre>
%install
mv %{buildroot}%{_bindir}/node %{buildroot}%{_bindir}/node-%{node_version_major}
...
</pre>
One of the streams is designed as the "default" one, and that stream
then ships manually created non-versioned symlinks to the renamed
paths:
<pre>
%if 0%{nodejs_is_default}
ln -srf %{buildroot}%{_bindir}/node-%{node_version_major}
%{buildroot}%{_bindir}/node
...
%endif
</pre>
By using update-alternatives, we can iterate on this idea and gain
several benefits outlined below.
== Feedback ==
== Benefit to Fedora ==
# No matter which stream you install, you'll always have
<code>/usr/bin/node</code> and other non-versioned names available.
The versioned names will be also present, if you want to be specific
in your scripts.
# There is no "official Fedora endorsement" on which NodeJS stream
should be "best" or "default"; if you as a system administrator have
multiple streams installed, the decision of which should be the
default is up to you.
The second item will also give us the maintainers greater freedom in
introducing new streams and obsoleting the old ones without worrying
too much about how to switch the "default" in the middle of the
distribution life cycle.
This is not a big pain point for Fedora, where the length of the life
of a single version matches the length of upstream NodeJS LTO support
pretty closely,
but becomes much more important in longer-living downstream
distributions (e.g. RHEL).
== Scope ==
* Proposal owners:
** Port the manual symlink creation and management to update-alternatives.
** Ensure the streams behave consistently and no conflict is introduced.
== User Experience ==
* Users will be able to install any number of streams and switch
between default one rather easy by just running `update-alternatives
--config node'.
== Dependencies ==
* Should not cause any problems to dependant packages.
== Contingency Plan ==
* Contingency mechanism: Revert back to manual symlink management and
go back to the design phase.
* Contingency deadline: Beta Freeze.
* Blocks release? We aim to do the rebuilds in Koji side tag and merge
it atomically; so NO.
== Documentation ==
* This is a downstream change; this page is the initial documentation.
* [https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/
Fedora Alternatives]
== Release Notes ==
TODO
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/BuildFCOSUsingContainerfile
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-build-fedora-cor…
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 ==
Define Fedora CoreOS as a `Containerfile` and build it using `podman
build`. The `Containerfile` will build `FROM` the Fedora bootc image.
== Owners ==
* Name/Email: [[User:jlebon|Jonathan Lebon]], jonathan(a)jlebon.com
* Name/Email: [[User:jbtrystram|JB Trystram]], jbtrystram(a)redhat.com
== Detailed Description ==
Currently, Fedora CoreOS (FCOS) is built using `rpm-ostree compose
tree` to build an OSTree commit which is then converted into an OCI
image.
The goal of this enhancement is to switch FCOS to be built via a
Containerfile instead.
=== Relationship to Fedora bootc ===
FCOS is already today sharing manifest definitions with Fedora bootc
via a git submodule. This change will make FCOS instead more
explicitly build `FROM` the Fedora bootc image using the
[https://docs.fedoraproject.org/en-US/bootc/building-from-scratch/
"from scratch" flow]. One can think of this change then as switching
from Fedora bootc and FCOS being siblings, to FCOS becoming a child of
Fedora bootc.
== Feedback ==
== Benefit to Fedora ==
This makes the FCOS build process become a standard container image
build, as advocated by the Fedora bootc project. Currently, building
FCOS requires using a custom tool,
[https://github.com/coreos/coreos-assembler CoreOS Assembler]. With
this change, anyone with `podman` installed would be able to build
FCOS. This in turn means that it's easier for both users and pipelines
to build it. A concrete example is our future plans to build FCOS in
the Fedora Konflux instance.
== Scope ==
* Proposal owners: describe FCOS as a Containerfile, adapt tooling and
pipelines support building FCOS via this Containerfile.
* Other developers: Hopefully nothing!
* Release engineering: Hopefully nothing!
* Alignment with the Fedora Strategy: yes, this falls under the
"Technical Innovation" theme, which lists Image Mode as a Focus Area.
== Upgrade/compatibility impact ==
Ideally none. The goal is to have no end user-visible changes. Fedora
CoreOS content will not meaningfully change.
== How To Test ==
Once ready, booting or updating to an FCOS built via Containerfile.
== User Experience ==
This change should not be visible to end users.
== Contingency Plan ==
* Contingency mechanism: Proposal owners will keep building FCOS using
the current approach (calling `rpm-ostree compose tree` directly).
Note that the way this is implemented, _both_ approaches will be
supported simultaneously as we work on rolling out this change in our
build processes.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
== Documentation ==
Main discussion in https://github.com/coreos/fedora-coreos-tracker/issues/1861.
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/AutomaticBootloaderUpdatesBootc
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-enable-automatic…
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 ==
We will enable automatic updates of the bootloader (GRUB) and shim for
Bootable Container systems (bootc base images, Fedora CoreOS).
== Owner ==
* Name/Email: [[User:hhei| Huijing Hei]], hhei(a)fedoraproject.org
* Name/Email: [[User:Siosm| Timothée Ravier]], siosm(a)fedoraproject.org
* Name/Email: [[User:Walters| Colin Walters]], walters(a)fedoraproject.org
== Detailed Description ==
Currently, Bootable Container systems (bootc base images, Fedora
CoreOS) do not perform bootloader updates automatically during OS
upgrades. This means the GRUB and shim binaries on disk may become
outdated even after a user performs an upgrade. Instead, the user is
responsible for manually updating the bootloader using `bootupctl
update` or `systemctl start bootloader-update.service`.
With this change, users do not need to manually update the bootloader
- it is handled automatically after upgrades. When a new deployment is
created (e.g., via `bootc update` or `rpm-ostree upgrade`), and if the
new image contains updated bootloader artifacts (shim, grub, etc.), a
systemd unit (`bootloader-update.service`) runs on the next boot to
apply the update.
This feature has been enabled by default at boot for both UEFI and
BIOS systems on Fedora Atomic Desktops starting since Fedora 41. For
details, see the approved change proposal:
[https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd
FedoraSilverblueBootupd], and the configuration in
[https://pagure.io/workstation-ostree-config/blob/f41/f/bootupd.yaml
bootupd.yaml].
While bootupd updates are generally safe across both UEFI and BIOS
systems, UEFI is the modern and preferred boot mechanism. On UEFI
systems, the `EFI System Partition (ESP)` is updated safely using a
temporary directory and an atomic `RENAME_EXCHANGE` operation, as
implemented in PR [https://github.com/coreos/bootupd/pull/669 #669]
and discussed in issue [https://github.com/coreos/bootupd/issues/454
#454].
BIOS (MBR) updates are also supported and have been reliable in
practice, but they lack the atomic guarantees and robustness of UEFI.
For this reason, UEFI is recommended for systems that rely on
automatic bootloader updates.
See more discussions in issue
[https://github.com/coreos/fedora-coreos-tracker/issues/1468 #1468]
and [https://github.com/coreos/bootupd#status bootupd's README] for
details about the safety of updates.
== Feedback ==
None so far.
== Benefit to Fedora ==
Bootloader updates generally bring security and other fixes. Applying
them automatically will make sure that all systems are running the
latest versions without any special intervention from users/admins.
== Scope ==
* Proposal owners: Enable automatic bootloader updates for Bootable
Container systems
* Other developers: N/A
* Release engineering: N/A
* 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
== Upgrade/compatibility impact ==
Existing installations will have their bootloader updated as part of
this change. This change should not require any manual action.
Users that do not want to have their bootloaders updated automatically
for any reason can mask the systemd unit before the Fedora 43 release
to disable this functionality.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
* Download an older Fedora CoreOS version, and start it.
* Enable `bootloader-update.service`.
* Let the system update to the lastest version automatically via Zincati.
* Once rebooted, verify that the bootloader components have been
updated automatically using bootupd:
<pre>
$ sudo systemctl status bootloader-update.service
$ journalctl -u bootloader-update.service
$ sudo bootupctl status
</pre>
== User Experience ==
Bootloader updates will be automatically applied in the background on
boot. There are no user actions required. User can check the status of
their bootloader with the `bootupctl status` command.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Revert the change
* Contingency deadline: Beta/Final freeze
* Blocks release? No
== Documentation ==
Mostly already written on the bootc and CoreOS side, will need some
small updates:
* https://docs.fedoraproject.org/en-US/bootc/bootloader-updates/
* https://docs.fedoraproject.org/en-US/fedora-coreos/bootloader-updates/
== Release Notes ==
To be written
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/NodejsNodeModulesPath
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-nodejs-node-modu…
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 ==
Nodejs needs a new shared stream agnostic installation folder for modules.
== Owner ==
* Name: [[User:tjuhasz| Tomas Juhasz]]
* Email: tjuhasz(a)redhat.com
* Name: [[User:jstanek| Jan Stanek]]
* Email: jstanek(a)redhat.com
* Name: [[User:aradchen| Andrei Radchenko]]
* Email: aradchen(a)redhat.com
== Detailed Description ==
This proposal is a part of a larger effort to improve the way we
package Nodejs for Fedora and RHEL. The other parts are
[[Changes/NodejsAlternativesSystem]] and
[[Changes/NodeJSMetapackages]].
This effort is specifically focused on allowing users to install
'''any supported''' version of Nodejs, without specifying a major
version.
=== Current Nodejs Situation ===
Currently, Fedora's Node.js setup uses a symlink:
`%{_libdir}/node_modules` points to a version-specific folder like
`%{_libdir}/node_modulesXX` (e.g., `%{_libdir}/node_modules20` or
`%{_libdir}/node_modules22`).
Primary motivation for change is an ongoing effort to de-bundle
certain parts of Node.js, particularly NPM packages that include
pre-built WebAssembly (WASM) binary blobs.
With multiple Nodejs versions present in Fedora, and upstream
recommendations against globally shared NPM packages in consideration,
we need a better way to store these de-bundled packages which could be
shared between multiple streams.
=== Suggested Change ===
Proposed way of doing this is to change `%{_libdir}/node_modules` from
a symlink to a static shared folder.
This static `%{_libdir}/node_modules` path will be used for
version-agnostic modules that can be shared across multiple Nodejs
versions.
For version-specific dependencies, the existing
`%{_libdir}/node_modulesXX` folders (e.g.,
`%{_libdir}/node_modules20`, `%{_libdir}/node_modules22`) will
continue to be used.
=== Alternative path options ===
If the change of `%{_libdir}/node_modules` from a symlink to a shared
folder is not agreeable a alternative path could also be used for the
same purpose e.g.:
* <code>%{_libdir}/nodejs/packages/shared</code> for NPM packages that
can be shared between multiple NodeJS major versions. This should be
the default path for the unbundled packages unless a stream is
identified to need a specific version.
* <code>%{_libdir}/nodejs/packages/<major_version></code> for NPM
packages that are specifically used by a single NodeJS major version.
Reserved for compat-style packages.
Packages installed in these paths are assumed to be used by a
non-npm-related loading mechanism; for NodeJS specifically, via the
"Shared builtins" mechanism
([https://github.com/nodejs/node/blob/main/BUILDING.md#building-to-use-shared…
upstream docs]).
== Feedback ==
== Benefit to Fedora ==
By having downstream-standartized path for "Shared builtins" modules,
we can start removing potentially unsafe pre-build WASM (binary) blobs
from the NodeJS sources, rebuilding them on our infrastructure from
trusted sources.
Accommodating single default shared directory will reduce work
necessary for unbundling the packages from several NodeJS major
versions at once, while the preservation of version-specific paths
will allow for compatibility packages where necessary.
== Scope ==
* Proposal owners: Adding a small `%pretrans` scriptlet for turning
`/usr/lib/node_modules` into a separate directory in all active nodejs
streams
* Other developers: Any developers who package npm packages will need
to verify, that their RPM will be functional after the
`%{_libdir}/node_modules` will change from a symlink to a folder and
if necessary rebuild their packages so that the files are present in
`%{_libdir}/node_modules` and rather then in e.g.
`%{_libdir}/node_modules_22`.
* Release engineering: N/A
* Policies and guidelines: N/A.
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
There should be no need for manual intervention.
== Early Testing (Optional) ==
== How To Test ==
Allow to install nodejs dependencies like `nodejs-cjs-module-lexer`
into a shared static folder.
== User Experience ==
User experience should not be affected in any way.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: Reverting the change back to using
`%{_libdir}/node_modules` as a symlink pointing to version specific
folders.
* Contingency deadline: N/A
* Block release: N/A
== Documentation ==
This Page.
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/StaticLibraryPreserveDebuginfo
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-lets-preserve-de…
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 ==
RPMs supplying static libraries should build with useful & preserved debuginfo.
Let's stop stripping them by default, and rely on new debugedit to process
static library debuginfo in a way that's useful for full debugging.
See also: [[Changes/StaticLibraryDebuginfo|an earlier attempt]] at this idea.
== Owner ==
* Name: [[User:Fche| Frank Ch. Eigler]]
* Adjutants: [[User:Mjw| Mark Wielaard]] [[User:Fweimer | Florian Weimer]]
* Email: fche(a)redhat.com
== Detailed Description ==
The current rpmbuild environment includes a post-build process that includes:
<pre>
%__os_install_post \
...
%{!?__debug_package:\
%{?__brp_strip} \
%{?__brp_strip_comment_note} \
} \
%{?__brp_strip_lto} \
%{?__brp_strip_static_archive} \
...
</pre>
The last part, __brp_strip_static_archive, removes all debuginfo from
any static archive (.a) files that may be packaged into foo-static
subrpms. These are not stripped into a separate -debuginfo file
(there's no tech for that); they are simply removed. This makes those
functions permanently undebuggable.
This was undesirable for several packages, so they experimented with
disabling the stripping step by redefining the
__brp_strip_static_archive macro to nothing. This would allow the
original object file / archive debuginfo to proceed into RPMs.
However, these files were not subject to source-file rewriting
normally performed by find-debuginfo.sh / debugedit, which let random
build-time directory names propagate into those debuginfo files.
(Normally, debugedit rewrites them to standard
/usr/src/debug/PACKGE/... paths and arranges to ship them into
debugsource RPMs.) This made their source files unpackaged and/or
inaccessible. But now debugedit master (coming to release 5.2
shortly) can process .a files, rewriting source path names and
collecting source files.
Fedora is finally in a position to '''preserve all static library
debuginfo''', and also arrange for distribution of their source code.
This Change proposes that this be done '''by default''':
* adopt the forthcoming version of debugedit 5.2
* change the %__os_install_post rpm macro to avoid the
__brp_strip_static_archive step
* offer an opt-in option for packages to retain stripping
We performed test mass-rebuilds of a number of packages, including all
fedora 42 packages that include "static" subrpms. There were no
build-breaking concerns.
We measured file size differences before/after to quantify the size
impact. Some interesting corner cases:
* xz is a typical case: small C library
* fftw is a worst-case scenario: template meta-programming C++ causes
huge debuginfo.
* gcc is good case: includes small C static-library, linked into many
fedora binaries. For this test, we removed the manual strip of libgcc
and other static libraries done in gcc.spec.
* llvm is also C++ and relatively debuginfo intensive
{| class="wikitable"
|-
! package or file !! old size !! new size !! delta !! notes
|-
| xz-static-5.8.1-2.fc42.x86_64.rpm || 119173 || 506301 || 4.2x bigger
|-
| liblzma.a || 392948 || 2172276 || 5.6x bigger
|-
| fftw-static-3.3.10-13.fc42.x86_64.rpm || 2904595 || 34036502 || 11x bigger
|-
| libfftw3f.a || 6976592 || 104539928 || 15x bigger
|-
| gcc-15.1.1-2.fc42.x86_64.rpm || 41440269 || 45581745 || +9% ||
includes libgcc.a
|-
| libgcc.a || 3349468 || 8271084 || 2.5x bigger || 64-bit
|-
| gcc debugsource rpm || 8243 || 10582 || +2339 || number of files
(mostly offload libraries)
|-
| llvm 20.1.7 lib64/libMLIRArithDialect.a || 6441876 || 45053964 || 7x bigger
|}
Note that figures like "10x bigger" should be taken in context. These
static libraries / RPMs form a tiny fraction of the entire Fedora
distro. Binary packages are unaffected, and their debuginfo would be
only trivially affected (e.g., by including snippets of libgcc.a).
Preserving debuginfo in the small number of static libraries should
not dramatically grow the overall distro. However, we don't have a
complete mass-build-based measurement on the overall impact.
== Feedback ==
In previous discussions over the last years, some concerns have come up:
==== Larger .a files and static RPMs ====
Static archive files become 2-12 times bigger after they carry
debuginfo content, and cannot be compressed by DWZ. (Hypothetically,
they could be processed with
objcopy --compress-debug-sections to win back some of this space.)
However, subrpms carrying those larger .a files are '''are compressed
at the rpm level''', so the storage / transport penalty of these
subrpms can be reasonable. Downstream packages that use static
libraries can be fully compressed by DWZ in the usual way. A small
number of very common libraries (e.g., libgcc.a) with newly preserved
debuginfo would enlarge many other Fedora -debuginfo packages, but
only by a trivial relative amount.
We believe the RPM size increases for the ~300ish
static-library-bearing packages are bearable to Fedora infrastructure.
For those who develop against static libraries, we expect the larger
disk footprint of those libraries is acceptable, in exchange for the
value of getting full debuggability of the finished binaries.
==== Alternative idea of moving debuginfo-carrying static .a files
into a -debuginfo subrpm ====
The gcc.spec has an option _enable_debug_packages, which if set, moves
original unstripped libFOO.a files under /usr/lib/debug/..., thus
getting them packaged into a gcc-debuginfo subrpm. This macro is not
enabled in Fedora builds, but the logic is consistent with ideas
expressed [https://bugzilla.redhat.com/show_bug.cgi?id=1395280|in
rhbz1395280].
We believe these measures are unnecessary. Users of -static libraries
should not need to use cumbersome custom -L/usr/lib/debug/.... paths
nor BuildRequire debuginfo RPMs just to make their programs
debuggable. Keeping debuginfo data in the original .a files & subrpms
is simple and effective.
==== Non-RPM developers getting some debuginfo even without gcc -g ====
Since basic runtime libraries like crt, libgcc would now carry
debuginfo, that data would be linked into binaries produced with "gcc
foo.c", even if "-g" was not specified. This is a relatively small
amount: x86_64 libgcc.a without -g is about 3MB, with -g is about 8MB,
and that's for all the individual runtime .o files. A developer
concerned about this could opt to strip his/her binaries after
linking. (Note that the toolchain has never guaranteed that there
would be zero debuginfo in a binary compiled/linked without -g.)
We believe this is not a serious impediment, when developers can work
around the distro change with classic tooling.
==== What about source code ====
In the status quo, a static library that is somehow packaged
unstripped ends up with broken DWARF source references, and thus no
files in the -debugsource. This change actually solves the "what
about the source" problem, because new debugedit (find-debuginfo.sh)
rewrites the source file names in the preserved DWARF, and arranges
for those source files to be included in the FOO-debugsource subrpm.
In the new scheme, debuginfod can automatically fetch the static
library sources!
== Benefit to Fedora ==
Binaries that link Fedora static libraries would become fully
debuggable. Crashed programs that include static libraries would
become fully backtraceable.
== Scope ==
* Proposal owners:
** Update debugedit rpm to bring in static-archive support
** Update redhat-rpm-config to disable __brp_strip_static_archive by
default in /usr/lib/rpm/redhat/macros, details tbd
** Identify packages that perform manual static-library stripping now
(e.g., gcc), file bugs to request discontinuation.
* Other developers:
** foo-static packagers who embrace the change: do nothing
** foo-static packagers who prefer to keep rpmbuild-stripped .a status
quo: activate __brp_strip_static_archive by tbd rpm macro
** foo-static packagers who want to keep manually stripping their own
.a: do nothing
** foo-static packagers who no longer want to manually strip their own
.a: strip that part from the .spec files
** Non-package developers linking against foo-static who embrace the
change: do nothing
** Non-package developers linking against foo-static who want stripped
binaries: strip binaries after linking
* Release engineering: [https://pagure.io/releng/issue/12799 #12799]
to note somewhat larger RPMs, which would be generated during a
mass-rebuild.
* Policies and guidelines: No formal change is necessary, as the
packaging guidelines do not specify whether static libraries do or do
not carry debuginfo.
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: N/A
== Upgrade/compatibility impact ==
The only upgrade/compat impact appears to be larger disk footprint if
updating from previous -static subrpms.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N.
== How To Test ==
* Build RPMs or non-RPM binaries that link against -static libraries.
* Observe they function just like before.
* Run readelf -w on the static .a files. It should print lots of
.debug_info stuff (not just .eh_frame information)
* Run under debugger. Observe that the portions that came from
-static libraries now have full debuginfo and source code.
== User Experience ==
Ordinary Fedora user experience is unaffected, since this is a
developer rather than user change. Users of packages that incorporate
static library elements would, if the program crashed, be able to get
complete traceback information to assist with problem reporting.
Developers of static-library related packages would need to accept
somewhat larger disk footprint for the debuginfo-carrying files, and
would benefit from the thorough debuggability.
== Dependencies ==
This change is not blocked on others, nor on new upstream work. The
precise mechanism by which the __brp_strip_static_archive macro would
be disabled by default is tbd. We'd provide a way of forcing
stripping back on for packages who prefer the status quo.
The changes should land before the mass-rebuild for full effectiveness.
== Contingency Plan ==
* Contingency mechanism: If debugedit changes were to somehow break
builds for this or unrelated reasons, we can roll that back
immediately. If the rpm-side macro changes cannot be committed in
time, then status quo (stripping .a files) will happen. Packages will
be able to force static-library stripping for themselves.
* Contingency deadline: Beta freeze. Even if the rpmbuild-default
reconfiguration were to miss the mass-rebuild, subsequently rebuilt
packages could gradually take advantage.
* Blocks release? No.
== Documentation ==
End-user documentation should not be necessary.
== Release Notes ==
The release notes should mention that developers who do not want
debugging information in statically linked applications should link
with the -s flag or run the strip command after linking; analogous
instructions for RPM builders tbd.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/NodeJSMetapackages
Discussion thread -
https://discussion.fedoraproject.org/t/f43-change-proposal-nodejs-metapacka…
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 NodeJS team no longer wish to design one of the maintained NodeJS
streams as the "default" or "preferred" one explicitly,
but wishes for the users to retain the ability to install "any" NodeJS
stream when the specific major version is not important to them.
To that end, the non-versioned <code>nodejs</code> package will become
an empty "metapackage" pulling one of the versioned nodejsXY packages
as it's dependency.
== Owner ==
* Name: [[User:jstanek|Jan Stanek]]
* Email: jstanek(a)redhat.com
* Name: [[User:aradchen|Andrei Radchenko]]
* Email: aradchen(a)redhat.com
* Name: [[User:tjuhasz|Tomas Juhasz]]
* Email: tjuhasz(a)redhat.com
== Detailed Description ==
This is a part of a larger iteration in a way we package NodeJS for
Fedora and RHEL. The other parts are [[Changes/NodejsNodeModulesPath]]
and [[Changes/NodejsAlternativesSystem]].
This change deals specifically with the ability to install '''any
supported''' version of NodeJS, without specifying a major version.
Previously, this was achieved by selecting one of the streams as a
"default" one.
This stream then would produce ''only'' non-versioned rpms
(<code>nodejs</code> vs. <code>nodejs22</code>),
and thus be selected when doing <code># dnf install nodejs</code>.
<code># dnf install nodejs22</code> also worked thanks to a virtual
<code>Provides: nodejs22</code> specified in the spec file.
This approach works reasonably well, but also have several drawbacks:
<ol>
<li>Producing ''only'' non-versioned rpms has various corner cases,
such as breaking test assertions like <code># dnf install nodejs22;
dnf list installed | grep nodejs22</code>.</li>
<li>
<p>There is no way to tell if a specific version was requested:
results of <code># dnf install nodejs</code> and <code># dnf install
nodejs22</code> are exactly the same.</p>
<p>This means we have no way to infer whether it is "safe" to
update the non-versioned rpms to another stream, and essentially
forces us to have single default stream for the entire lifetime of the
distribution.
For Fedora itself, that is not that big of a problem, since
the lifetime of a branched release roughly matches the span of
upstream support for a LTS stream,
but it becomes much larger problem in a long-living
distribution such as RHEL.</p>
</li>
</ol>
To address these drawbacks, the following changes are proposed:
<ul>
<li>All NodeJS streams will '''always''' produce full set of
versioned rpms (<code>nodejs22 nodejs22-npm …</code>). The
non-versioned rpms (<code>nodejs nodejs-npm …</code>) will be provided
''in addition'' to those above.</li>
<li>
<p>The non-versioned rpms (<code>nodejs</code>) rpms will
explicitly represent the desire to have ''any'' stream installed,
without any guarantees about which version gets installed or
keeping that version the same during the entire lifetime of the
distribution.</p>
<p>(The working internal term for this non-guarantees and behavior
is "rolling stream".)</p>
</li>
</ul>
It is assumed that the non-version rpms (the "metapackages") will
always pull their versioned equivalent from one of the supported
streams and be otherwise empty.
Which specific stream they delegate to will be left to the
maintainer's discretion and the needs of the specific distribution.
=== Implementation options ===
Currently, we are thinking about 2 possible ways to implement this change.
<ol>
<li>Adding an extra set of sub-packages to the current SPEC file(s),
hidden behind a <code>%bcond</code>. Only one of these
<code>%bcond</code>s should ever be active at once. Simplified
example:
<pre>
%bcond metapackages %[%{node_version_major} ==
%{nodejs_default_stream}] # %nodejs_default_stream presumably defined
in nodejs-packaging globally
...
%if %{with metapackages}
%package -n nodejs
Requires: nodejs%{node_version_major} = %{node_version}
...
%endif
</pre>
This would most closely mirror how the non-versioned packages are generated now.
</li>
<li>Shipping separate empty package <code>nodejs</code>.
<pre>
Name: nodejs
Version: 24 # the default stream
Summary: nodejs metapackage
Requires: nodejs%{version}
...
</pre>
</li>
</ol>
We do not have a clear preference between those two, so feedback is welcome.
== Feedback ==
== Benefit to Fedora ==
We'll give users the option to choose between specific NodeJS stream
and "any" NodeJS stream explicitly, and then work with the streams
accordingly.
Those wishing to have "any" NodeJS version available will always get
(and keep) known-good version without worrying too much about which
major version is currently supported, recommended, or chosen for them.
Those wishing to have specific NodeJS stream can install one of the
versioned stream explicitly and know that it will always stay on that
particular major version.
== Scope ==
* Proposal owners: Change the non-versioned packages generation logic
in the existing NodeJS packages to accommodate this change; optionally
re-introduce new `nodejs` rpms.
* Other developers: Review their usage of `nodejs` and adjust them to
comply with the new semantics.
* Release engineering: Should not be necessary.
* Policies and guidelines: Update to the new semantics of installation.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
A decision needs to be made to what kind of stream users with the
current default stream installed will be migrated:
#. Treating current "default" stream as the "rolling" stream and
simply update the installation to using the metapackages.
#. Treating current "default" stream as weirdly named "specific"
stream, and setting Obsoletes so that the installation would move to
using the versioned packages (e.g. `nodejs` → `nodejs22`).
== Early Testing ==
After gathering initial round of feedback, a COPR will be set up, so
that the changes can be tested before implementing them in the
distribution proper.
== How To Test ==
#. Enable the COPR mentioned above.
#. Try updating your NodeJS installation, or install new one from
scratch. Brave testers might even tests rollbacks to previous
versions.
== User Experience ==
* Ability to better select between NodeJS streams and have the
selection honored going forward.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: Not merging the Koji side tag. Keep using the
(perhaps slightly tweaked) current approach, without any semantic
changes.
* Contingency deadline: Beta freeze.
* Blocks release? No, asuming the builds and rebuilds will be done in
separate environment (Koji side tag) and then merged atomically.
Otherwise, YES.
== Documentation ==
This is a downstream initiative; documentation will need to be
created, but that was already mentioned in the Policies and Guidelines
bullet above.
== Release Notes ==
TODO
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/InitrdZstdDefault
Discussion thread
https://discussion.fedoraproject.org/t/f43-change-proposal-compress-the-ini…
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 ==
Use zstd to compress the initrd for all Fedora variants by default
when built with dracut.
== Owner ==
* Name/Email: [[User:Hricky | Hristo Marinov]], hricky(a)mail.bg
* Name/Email: [[User:Siosm | Timothée Ravier]], siosm(a)fedoraproject.org
== Detailed Description ==
Since https://github.com/dracut-ng/dracut-ng/pull/385, dracut is now
using zstd to compress the initrd by default. It does so only when the
zstd binary is available (and not the library as this is a shell
script), so right now on Fedora, most variants are still using xz
compressed initrds by default
(https://src.fedoraproject.org/rpms/dracut/blob/rawhide/f/dracut.spec#_100)
This changes however as soon as users install zstd on their systems.
The current zstd users are:
* Fedora CoreOS which explicitly added zstd and set a compression with
a specific ratio:
** https://github.com/coreos/fedora-coreos-config/blob/testing-devel/overlay.d…
** https://github.com/coreos/fedora-coreos-config/pull/1844
* Some of the bootc images, which include zstd:
** https://gitlab.com/fedora/bootc/base-images/-/blob/main/standard/coreos-use…
Other related issues:
* https://gitlab.com/fedora/bootc/tracker/-/issues/17
* https://gitlab.com/fedora/ostree/sig/-/issues/34
* https://bugzilla.redhat.com/show_bug.cgi?id=1554931
For this change, we will replace the dependency in dracut from xz to
zstd and we might configure a different compression ratio, potentially
pushing that upstream, depending on feedback.
== Feedback ==
None so far.
We welcome testing for various compression ratios and comparing size
of the initrd and speed of decompression (which matters on boot) on
different hardware. See
https://github.com/coreos/fedora-coreos-tracker/issues/1247#issuecomment-11…
for an example.
== Benefit to Fedora ==
Smaller initrd and faster boots. See
https://github.com/coreos/fedora-coreos-tracker/issues/1247#issuecomment-11…
for some measurements. We did the change in Fedora CoreOS to reduce
the size of the initrd to save disk space in the `/boot` partition.
== Scope ==
* Proposal owners: Replace dependency on `xz` by `zstd` in `dracut` to
enable `zstd` by default
* Other developers: Make sure that their tools still work with the new
compression algorithm
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] TBD but nothing should be needed here
* 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, it's a general improvement
== Upgrade/compatibility impact ==
There should be no impact for most users as the decompression of the
initrd is handled by the kernel and it has had support for zstd for a
while now. Users of custom kernels should make sure this is supported
in their configs.
Existing installations will be updated to use zstd by default. No
manual action should be required.
Users that want to keep using xz for compressing the initrd can
configure it in their dracut config.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
On package mode systems:
# Install zstd: `dnf install -y zstd`
# Rebuild the initrd: `dracut <path to initrd>` or `dracut
--regenerate-all` to do it for all kernel versions (make a backup to
compare sizes, etc.)
# Validate that it is zstd compressed: `LANG=C grep -aUPq
"\x28\xb5\x2f\xfd" <path to initrd> && echo "using zstd" || echo "not
using zstd"`
# Reboot
For ostree image systems, you should wait until the change lands in
Rawhide or build your own, including the configuration from Fedora
CoreOS as an example.
For bootable container image mode systems, you can install zstd and
rebuild the initrd in a Containerfile and switch/rebase your system to
it.
== User Experience ==
There should be no change in user experience beyond slightly faster boots.
== Dependencies ==
No other dependencies as far as the authors know right now.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) Revert the change
* Contingency deadline: Final freeze
* Blocks release? No
== Documentation ==
To be written if accepted.
== Release Notes ==
To be written if accepted.
Discussion thread -
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.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/GNUToolchainF43
Discussion thread -
https://discussion.fedoraproject.org/t/f43-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 43 GNU Toolchain to gcc 15.2, binutils 2.45, glibc
2.42 and gdb 17.1.
The set of core GNU Toolchain packages for Fedora 43 are as follows:
* GNU C Compiler 15.2
** Associated runtimes for C++ (libstdc++), Go (gccgo), OpenMP (gomp),
Fortran (gfortran), D (phobos), Objective C/C++.
* GNU Binary Utilities 2.45
* GNU C Library 2.42
* GNU Debugger 17.1 (immediately available in all Fedora releases)
The gcc 15.2 change will be tracked in this top-level GNU Toolchain
system-wide change request.
The binutils 2.45 change will be tracked in this top-level GNU
Toolchain system-wide change request.
The glibc 2.42 change will be tracked in this top-level GNU Toolchain
system-wide change request.
The gdb 17.1 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 latest point release for gcc 15 will be included in Fedora 43,
this will most probably be 15.2.
<!-- Use this text for a BINUTILS update: -->
The GNU Binutils version 2.45 will be released before Fedora 43; and
we have already been using this version of binutils in Fedora Rawhide
to successfully build the distribution. Given the present schedule for
Fedora 43 we will continue to use Binutils 2.45.
<!-- Use this text for a GLIBC update: -->
The GNU C Library version 2.42 is expected to be released before
Fedora 43; we have started closely tracking the glibc 2.42 development
code in Fedora Rawhide and are addressing any issues as they arise.
Given the present schedule Fedora 43 will branch after the release of
glibc 2.42. However, the mass rebuild schedule means Fedora 43 will
mass rebuild before the final release of glibc 2.42, but after the ABI
is frozen.
<!-- Use this text for a GDB update: -->
The GNU Debugger version 17.1 will be 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 43 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://pagure.io/releng/issue/12798 #12798]
* 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.42 will be noted here:
https://sourceware.org/glibc/wiki/Release/2.42#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 43 cycle. The mass rebuild would ensure all packages can be
built with the newer compiler and core runtimes.
== Contingency Plan ==
* 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.45 proves too
disruptive to assembling and linking the distribution we could revert
to 2.44, but given that Rawhide is using 2.45, 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.42 proves too disruptive to
compiling the distribution we could revert to 2.41, but given that
Rawhide has started tracking glibc 2.42, no show-stopper problems are
expected. At this point we can still revert to upstream version 2.41
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.
* Contingency deadline: Fedora mass rebuild on 2025-07-23.
* Blocks release?
** No, upgrading to gcc 15.2 does block the release.
** Yes, upgrading to binutils 2.45 does block the release.
** Yes, upgrading to glibc 2.42 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-15/changes.html for the GNU Compiler
Collection version 15 release notes.
<!-- Use this text for BINUTILS updates: -->
The GNU Binary Utilities version 2.45 will be released August 2025.
The current release notes will be sent to the developer mailing list.
<!-- Use this text for GLIBC updates: -->
The GNU C Library version 2.42 will be released at the beginning of
August 2025. 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.1 will be released July 2025.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney