devel-announce March 2025

devel-announce@lists.fedoraproject.org

2 participants
9 discussions

Fedora Linux 42 Beta is a GO
by Aoife Moloney 13 Mar '25

13 Mar '25

The Fedora Linux 42 Beta RC1.4 compose is GO and will be shipped live on Tuesday, March 18 2025. Final Freeze will start on Tuesday, April 1 (no joke!) for Fedora Linux 42 Final. For more information on today's release go/no-go meeting please check the meeting minutes[2] or log[3]. [1] https://fedorapeople.org/groups/schedule/f-42/f-42-key-tasks.html [2] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2025-03-… [3] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2025-03-… -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

%pyproject_buildrequires -t/-e and %tox without a suitable tox configuration will error
by Miro Hrončok 12 Mar '25

12 Mar '25

Hello packagers. As a followup to this email sent a month ago to the python-devel list, I now plan to make the incorrect (and unsafe) usage of %pyproject_buildrequires -t/-e and %tox without a suitable tox configuration fail the build. This is a breaking change, but I believe it's the only way to prevent packages with always passing %checks. If your package has no tox configuration, do not use the -t/-e option for %pyproject_buildrequires, do not use %tox. This change will land to rawhide first and later to all stable releases as well. For reference: https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/512 On 05. 02. 25 10:47, Miro Hrončok wrote: > Hello Pythonistas. > > When we updated tox from version 3 to 4, it no longer fails when here is no > suitable tox configuration found. This was a deliberate upstream choice. > > Unfortunately, it means that packages that use %pyproject_buildrequires with -t > or -e now silently succeed if there is no tox configuration found. > > I identified 95 packages that are affected by this, see below. > > Unfortunately, it is tricky to detect a missing tox configuration directly from > %pyproject_buildrequires. For now, I did this by looking for a specific > information in tox output, but that might not be stable. > > I built all Rawhide packages matching %\{?pyproject_buildrequires\s+(.+\s)?- > \S*[te] in a copr with a modified version of %pyproject_buildrequires which > fails when this happens. > > https://copr.fedorainfracloud.org/coprs/churchyard/pyproject-buildrequires-… > tox-error/builds/ > > For all the failures, I looked into the logs and identified the 95 failures are > caused by that (see below). > > > If this affects your package, please consider if your usage of -t/-e for > %pyproject_buildrequires is a mistake (and remove it), or see if some explicit > build dependencies are missing (and the package only builds by chance). > > Sometimes, upstreams which use tox don't put their tox configuration into sdist > (%pypi_source) and only keep it in git. > > Sometimes, upstreams don't use tox at all and the usage of -t/-e is wrong. > > If you have questions, I am happy to help. > > Maintainers by package: > hddfancontrol filiperosset > lazygal rathann > mat2 atim > mkdocs dcavalca smani > mogui xdelaruelle > onnx aalvarez dherrera > past-time fab > patool eclipseo > pmbootstrap defolos > pykka girst > python-ailment fab mikep > python-aioftp fab > python-aiomultiprocess fab > python-archinfo fab mikep > python-archspec orion > python-asn1tools peter > python-asysocks fab > python-base58 peter > python-blowfish limb > python-ckzg peter > python-claripy fab mikep > python-cmd2 fab jcapitao ktdreyer > python-dataclassy peter > python-diff-match-patch amigadave > python-dropbox limb > python-einops trix > python-envisage orion > python-eth-abi peter > python-eth-account peter > python-eth-event peter > python-eth-hash peter > python-eth-keyfile peter > python-eth-keys peter > python-eth-rlp peter > python-eth-stdlib peter > python-eth-typing peter > python-eth-utils peter > python-flask-httpauth jpena > python-flask-session frantisekz > python-haversion fab > python-hexbytes peter > python-hvac ignatenkobrain ngompa rcallicotte > python-influxdb-client fedepell stevetraylen > python-jaconv kevin > python-jsonpath-ng fab > python-lazy_load peter > python-libusb1 jonny peter > python-logutils limb > python-lru-dict peter > python-mailman-web salimma > python-migen somlo > python-morphys peter > python-multiaddr peter > python-multibase peter > python-multicodec peter > python-multihash peter > python-music21 zbyszek > python-nine ondrejj > python-optking jussilehtola > python-optuna limb > python-paginate dcavalca > python-pandas-datareader sergiopr > python-pyaes thebeanogamer > python-pybeam peter > python-pyiqvia fab > python-pymongo apevec cstratak hhorak jonathanspw orion > python-pyrad antorres cicku peter > python-pytest-dependency mikelo2 > python-pytest-fixture-config kevin > python-qcelemental jussilehtola > python-requests-unixsocket jcaratzas radez > python-rlp peter > python-rpyc fab > python-simple-pid ttorcz > python-smi fab > python-ssdp fab > python-telnetlib3 dcavalca > python-textile thm > python-textparser fab > python-timeout-decorator jcapitao > python-tinydb petersen suanand > python-towncrier eclipseo > python-trie peter > python-uhashring amoralej > python-unix-ar ppfeister > python-warlock apevec jcapitao mrunge > python-xlrd ondrejj pingou > python-zstandard ignatenkobrain rathann > python3-exiv2 asn > quearcode limb > reuse jstanek > rpm-spec-language-server frostyx > scancode-toolkit eclipseo > syncstar t0xic0der > vapoursynth slaanesh > > Packages by maintainer: > aalvarez onnx > amigadave python-diff-match-patch > amoralej python-uhashring > antorres python-pyrad > apevec python-pymongo python-warlock > asn python3-exiv2 > atim mat2 > cicku python-pyrad > cstratak python-pymongo > dcavalca mkdocs python-paginate python-telnetlib3 > defolos pmbootstrap > dherrera onnx > eclipseo patool python-towncrier scancode-toolkit > fab past-time python-ailment python-aioftp python-aiomultiprocess > python-archinfo python-asysocks python-claripy python-cmd2 python-haversion > python-jsonpath-ng python-pyiqvia python-rpyc python-smi python-ssdp python- > textparser > fedepell python-influxdb-client > filiperosset hddfancontrol > frantisekz python-flask-session > frostyx rpm-spec-language-server > girst pykka > hhorak python-pymongo > ignatenkobrain python-hvac python-zstandard > jcapitao python-cmd2 python-timeout-decorator python-warlock > jcaratzas python-requests-unixsocket > jonathanspw python-pymongo > jonny python-libusb1 > jpena python-flask-httpauth > jstanek reuse > jussilehtola python-optking python-qcelemental > kevin python-jaconv python-pytest-fixture-config > ktdreyer python-cmd2 > limb python-blowfish python-dropbox python-logutils python-optuna quearcode > mikelo2 python-pytest-dependency > mikep python-ailment python-archinfo python-claripy > mrunge python-warlock > ngompa python-hvac > ondrejj python-nine python-xlrd > orion python-archspec python-envisage python-pymongo > peter python-asn1tools python-base58 python-ckzg python-dataclassy python- > eth-abi python-eth-account python-eth-event python-eth-hash python-eth-keyfile > python-eth-keys python-eth-rlp python-eth-stdlib python-eth-typing python-eth- > utils python-hexbytes python-lazy_load python-libusb1 python-lru-dict python- > morphys python-multiaddr python-multibase python-multicodec python-multihash > python-pybeam python-pyrad python-rlp python-trie > petersen python-tinydb > pingou python-xlrd > ppfeister python-unix-ar > radez python-requests-unixsocket > rathann lazygal python-zstandard > rcallicotte python-hvac > salimma python-mailman-web > sergiopr python-pandas-datareader > slaanesh vapoursynth > smani mkdocs > somlo python-migen > stevetraylen python-influxdb-client > suanand python-tinydb > t0xic0der syncstar > thebeanogamer python-pyaes > thm python-textile > trix python-einops > ttorcz python-simple-pid > xdelaruelle mogui > zbyszek python-music21 > -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

REMINDER: Fedora Linux 42 Beta Go/No-Go Meeting, Thursday March 13
by Aoife Moloney 10 Mar '25

10 Mar '25

The Fedora Linux 42 Beta Go/No-Go meeting[1] will take place on Thursday March 13 @ 1700 UTC in #meeting:fedoraproject.org[2]. At this time, we will determine the status of the F42 Beta release date [3] that is currently targeting Tuesday 18th March. [1] https://fedoraproject.org/wiki/Go_No_Go_Meeting [2] https://calendar.fedoraproject.org/Fedora%20release/2025/3/13/#m11000 [3] https://fedorapeople.org/groups/schedule/f-42/f-42-key-tasks.html -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F43 Change Proposal RPM 6.0 (system-wide)
by Aoife Moloney 10 Mar '25

10 Mar '25

Wiki - https://fedoraproject.org/wiki/Changes/RPM-6.0 Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-rpm-6-0-system-w… 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 RPM to the upcoming 6.0 major release. == Owner == * Name: [[User:Pmatilai| Panu Matilainen]] * Email: pmatilai(a)redhat.com == Detailed Description == Update RPM to the upcoming 6.0 release for several security improvements. Note: adopting Fedora to the new v6 package package format is explicitly NOT IN SCOPE for this change. RPM 6.0 in Fedora 43 will ship with v4 package generation as default, regardless of the upstream default. == Feedback == == Benefit to Fedora == The major theme in 6.0 is increased security and related improvements: * enforcing signature checking on by default * OpenPGP keys are referred to by their fingerprint or full key id where fingerprint not available (compared to the short keyid in previous versions) * OpenPGP keys can be updated with `rpmkeys --import <key>` and corresponding API(s) * support for multiple signatures per package (also an enabler for Post-Quantum signatures later on) * support for automatic signing on package build (mainly for local use) * support for signing with Sequoia-sq as an alternative to GnuPG A less direct benefit is enabling the testing of the new v6 package format in the wider ecosystem. Last but not least: with the release of 6.0, the RPM 4.x branch will go into a strict maintenance-only mode, there will be no further development on that branch. == Scope == This is the first RPM version to support the new v6 package format, but adopting Fedora to the new package format is explicitly not in scope for this change. * Proposal owners: ** Rebase RPM ** Assist dealing with incompatibilities * Other developers: ** Test and report issues ** Adjust 3rd party software/tools to work with the new formats and defaults where needed ** Test v6 package behavior with 3rd party software/tools (optional) * Release engineering: [https://pagure.io/releng/issue/12616 #12616] * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with the Fedora Strategy: N/A == Upgrade/compatibility impact == * Existing package build+install workflows may need to be adjusted due to enforced signature checking being the default. * 3rd party scripts and tools may need adjusting to the new key addressing format and other signature related output changes. == Early Testing (Optional) == Do you require 'QA Blueprint' support? N == How To Test == Rpm receives a thorough and constant testing via every single package build, system installs and updates, but of particular interest in this release are * updating previously imported keys * manipulating the rpm keyring via rpmkeys * testing the new v6 package format compatibility with 3rd party software (requires building packages with %_rpmformat set to 6) == User Experience == * The most noticeable change is that RPM now refuses to install packages whose signature hasn't been positively verified, whether due to being unsigned, missing key or otherwise. This can be worked around by supplying `--nosignature` on the command line, or more permanently, changing the `%_pkgverify_level` macro to the former default of `digest`, but these should be only temporary measures, users are encouraged to import necessary keys and/or setup automatic signing for their (local) builds instead. * Signature and key related output has changed: upper/lower case is followed consistently in related output, and OpenPGP keys are always addressed either by their fingerpring hash or the full keyid, whereas previously a collision prone, short key id was used. * `rpmkeys` is now the official tool for manipulating the rpm keyring. Other methods such as manipulating `gpg-pubkey` pseudo-packages manually are deprecated and should be updated to either the rpmkeys tool or the newly provided keyring APIs. == Dependencies == * The soname does not change so no rebuilds are required for dependencies or otherwise * There are no dependencies to other Fedora changes. * This is the first version of rpm built as C++, so rpm gains a runtime dependency on libstdc++. * Signing with Sequoia additionally requires sequoia-sq >= 1.0, but this is an optional dependency and even then, only for signing packages. == Contingency Plan == * Contingency mechanism: Revert back to RPM 4.20 * Contingency deadline: Beta freeze * Blocks release? No == Documentation == * [https://github.com/rpm-software-management/rpm/discussions/3602 The road to RPM 6.0 blog] * [https://rpm.org/wiki/Releases/6.0.0 Draft release notes] (subject to change) * [https://rpm-software-management.github.io/rpm/manual/ Upstream reference manual] == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F43 Change Proposal: Migrate to lastlog2 (system-wide)
by Aoife Moloney 10 Mar '25

10 Mar '25

Wiki - https://fedoraproject.org/wiki/Changes/Migrate_to_lastlog2 Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-migrate-to-lastl… 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 == Migrate lastlog and all functionality associated with it (e.g. pam_lastlog, the PAM service files) to lastlog2. == Owner == * Name: [[User:ipedrosa| Iker Pedrosa]] * Email: <ipedrosa(a)redhat.com> == Detailed Description == The Year 2038 problem (Y2038) poses a significant threat to systems relying on 32-bit time representations. It's crucial to address this before it impacts Fedora. This proposal suggests replacing the current lastlog utility with lastlog2, a robust and widely adopted solution already integrated into distributions like Debian and openSUSE. lastlog reports the last login of a given user or of all users who did ever login on a system. The standard `/var/log/lastlog` implementation using `lastlog.h` from glibc uses a 32bit time_t in struct lastlog on bi-arch systems like x86-64 (so which can execute 64bit and 32bit binaries). So even if you have a pure 64bit system, on many architectures using glibc this leads to the [https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit/ Y2038 problem]. lastlog2 is a Y2038 safe implementation of lastlog and it is considered as the natural replacement. lastlog2 offers a comprehensive solution, including not just the lastlog2 binary for interacting with user login information, but also a dedicated library and a PAM module for seamless integration and accurate user tracking. Critically, lastlog2 provides a migration path for existing lastlog data. == Feedback == This Fedora System-Wide Change is open to feedback and other proposals from the community. == Benefit to Fedora == * Y2038 safe: it addresses the core issue by using a time representation that avoids the Y2038 overflow. * SQLite3 backend: it leverages a modern and efficient database for storing login information. * PAM module integration: data collection is handled exclusively through a PAM module, allowing any tool to utilize the information without requiring modifications to existing packages. This ensures broad compatibility and avoids cascading changes. * Backward compatibility: output is designed to be as compatible as possible with the traditional lastlog format, minimizing disruption to existing workflows. * Data migration: it provides a mechanism to import existing data from the legacy `/var/log/lastlog` file, preserving valuable login history. * Scalability: the database size scales with the number of users, not the largest UID, offering improved performance and resource utilization, especially in environments with sparse UID allocation. This change offers a proactive and well-supported solution to the Y2038 problem within Fedora, ensuring the continued reliability and security of the system. In short, lastlog2 is part of the util-linux project, which Fedora has been using for years, and which has been accepted by different communities such as Debian or OpenSuse as the ideal replacement for lastlog. == Scope == * Proposal owners: shadow-utils, PAM and util-linux projects need to change their configuration to stop providing lastlog functionality and start providing lastlog2. authselect project needs to replace pam_lastlog by pam_lastlog2 in the PAM stack and update fedora content accordingly. Finally, util-linux needs to migrate the existing database from lastlog to lastlog2 format during the upgrade process. * Other developers: N/A * Release engineering: [https://pagure.io/releng/issue/12608 #12608] * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with the Fedora Strategy: N/A == Upgrade/compatibility impact == Nothing will be affected, since the old database format from lastlog will be automatically migrated to the new lastlog2 format. == How To Test == Two different scenarios come to my mind: # New system: once the system is correctly installed authenticate as a user and run `lastlog2` for this user. The timestamp of the last login should match the one that recently happened. # Old system: once the system is correctly updated authenticate as root and run `lastlog2` for another user. The timestamp of the last login should have happened before the update happened. == User Experience == `lastlog` and `pam_lastlog` don't exist anymore and are replaced by `lastlog2` and `pam_lastlog2`. They should behave in a similar manner to the aforementioned artifacts, thus no other change will be experienced by the user. == Dependencies == There are no other dependencies. == Contingency Plan == * Contingency mechanism: If any change was committed revert it. * Contingency deadline: Just before beta freeze. * Blocks release? No == Documentation == * https://en.wikipedia.org/wiki/Year_2038_problem * https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit/ * https://ikerexxe.github.io/idm/2023/06/14/Y2038-problem-in-shadow/ == Release Notes == Users should be informed that `lastlog` and `pam_lastlog` are replaced by `lastlog2` and `pam_lastlog2` in Fedora 43. In addition, the reasons for this change should be clearly explained. This FSWC proposal should be enough to understand the context, but if you have any doubts while writing the RN don't hesitate to contact the owner. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F43 Change Proposal: Retire gtk3-rs, gtk-rs-core v0.18, and gtk4-rs v0.7 (self-contained)
by Aoife Moloney 10 Mar '25

10 Mar '25

Wiki - https://fedoraproject.org/wiki/Changes/Retire_gtk3-rs,_gtk-rs-core_v0.18,_a… Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-retire-gtk3-rs-g… 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 Rust bindings for GTK3 (and related libraries) are unmaintained upstream, and are no longer updated in lockstep with bindings for GLib and other related libraries. The packages for gtk3-rs were previously [https://fedoraproject.org/wiki/Changes/Deprecate_gtk3-rs deprecated]. This is the next step - the removal of the packages for gtk3-rs, and the compat packages for old versions of gtk-rs-core (v0.18) and gtk4-rs (v0.7) that are associated with them. == Owner == * Name: [[User:Decathorpe| Fabio Valentini]] * Email: decathorpe (at) gmail (dot) com == Detailed Description == The Rust bindings for GTK3 have been officially on basic maintenance only since the release of [https://gtk-rs.org/blog/2023/02/10/new-release.html gtk-rs 0.17], and the last release that included updated GTK3 bindings was [https://gtk-rs.org/blog/2023/08/28/new-release.html gtk-rs 0.18]. As a result, the most recent version continues to pull in compat packages for version 0.18 of gtk-rs-core (Rust bindings for GLib, pango, cairo, etc.), which has not been maintained either, since it was obsoleted by versions 0.19 and 0.20 upstream. These Rust bindings receive regular fixes for safety and correctness issues - continuing to depend on old versions is not ideal, since only critical fixes are backported to the Fedora packages for these obsolete versions (if that is even possible). The upstream project does not backport fixes or release new versions of older release branches at all. This also affects packages that continue to depend on version 0.7 of the bindings for GTK4. However, packages that only depend on crates from gtk-rs-core or gtk4-rs do have a migration path to newer versions of these crates, whereas packages that depend on crates from gtk3-rs need to port from GTK3 to GTK4 first. == Feedback == N/Y == Benefit to Fedora == The Rust bindings for GTK3 - and gtk-rs 0.18 in general - are obsolete. This Change ensures that Fedora ships less obsolete software and / or fewer obsolete versions of packages. == Scope == * Proposal owners: Retire the following packages: gtk3-rs / libhandy-rs packages (unmaintained upstream): rust-atk rust-atk-sys rust-gdk rust-gdk-sys rust-gtk rust-gtk-sys rust-libhandy rust-libhandy-sys gtk-rs-core v0.18 compat packages: rust-cairo-rs0.18 rust-cairo-sys-rs0.18 rust-gdk-pixbuf0.18 rust-gdk-pixbuf-sys0.18 rust-gio0.18 rust-gio-sys0.18 rust-glib0.18 rust-glib-sys0.18 rust-glib-build-tools rust-gobject-sys0.18 rust-graphene-rs0.18 rust-graphene-sys0.18 rust-pango0.18 rust-pango-sys0.18 rust-pangocairo0.18 rust-pangocairo-sys0.18 gtk4-rs v0.7 / libadwaita-rs v0.5 compat packages: rust-gdk4_0.7 rust-gdk4-sys0.7 rust-gsk4_0.7 rust-gsk4-sys0.7 rust-gtk4_0.7 rust-gtk4-sys0.7 rust-libadwaita0.5 rust-libadwaita-sys0.5 The Change Owner(s) will file Pull Requests for dependent packages to move to newer versions of those libraries, where possible. === Other developers === There are some applications in Fedora that depend on these old bindings: * helvum → libadwaita-rs v0.5 and gtk-rs-core v0.18 compat packages * squeekboard → obsolete GTK3 bindings and gtk-rs-core v0.18 compat packages * system76-keyboard-configurator → obsolete GTK3 bindings and gtk-rs-core v0.18 compat packages * wildcard → libadwaita-rs v0.5 and gtk4-rs v0.7 compat packages All of these packages are either co-maintained by the Rust SIG or are maintained by a member of the Rust SIG. Most of these projects already have begun work on porting to a newer version of gtk-rs, or have been aware that continuing to depend on the obsolete GTK3 bindings is a problem for years: * helvum: https://gitlab.freedesktop.org/pipewire/helvum/-/commit/f325595 * squeekboard: https://gitlab.gnome.org/World/Phosh/squeekboard/-/issues/64 * system76-keyboard-configurator: https://github.com/pop-os/keyboard-configurator/issues/133 * wildcard: https://gitlab.gnome.org/World/Wildcard/-/issues/42 Packages that will not or cannot be ported to a newer version of gtk-rs in time - for example because it would also involve a port from GTK3 to GTK4 - will be broken, and should likely also be retired from Fedora. === Release engineering === N/A (not needed for this Change) === 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 == The packages for Rust libraries like the gtk-rs crates are only installed at build-time, and are not pulled in as dependencies on user systems. There should be no impact on upgrades other than the possible removal of applications that cannot be ported to gtk-rs 0.19+ or from gtk3-rs to gtk4-rs in time. == Early Testing (Optional) == N/A == How To Test == The listed packages should no longer be available from Fedora repositories. == User Experience == Packages for projects that cannot be ported to gtk-rs 0.19+ or from gtk3-rs to gtk4-rs will no longer be available from the Fedora repositories. == Dependencies == * helvum * squeekboard * system76-keyboard-configurator * wildcard == 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) == Documentation == * https://gtk-rs.org/blog/2023/02/10/new-release.html * https://gtk-rs.org/blog/2023/08/28/new-release.html * https://gtk-rs.org/blog/2024/06/01/new-release.html == Release Notes == The Rust bindings for GTK3 are obsolete and officially unmaintained. They had been marked as deprecated in Fedora 42, and were removed in Fedora 43, alongside the obsolete packages for version 0.18 of the gtk-rs-core crates and version 0.7 of the gtk4-rs crates. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F43 Change Proposal: Deprecate the Gold Linker (system-wide)
by Aoife Moloney 10 Mar '25

10 Mar '25

Wiki - https://fedoraproject.org/wiki/Changes/DeprecateGoldLinker Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-deprecate-the-go… 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 goal of this change is to deprecate the binutils-gold subpackage of the binutils package. This will allow its eventual removal from Fedora. == Owner == * Name: Nick Clifton * Email: nickc(a)redhat.com == Detailed Description == The GOLD linker is no longer being developed in the upstream GNU Binutils project. Given that there are now four linkers available to Fedora users (ld.bfd, ld.gold, lld, mold) deprecating one of them should not cause a lot of disruption and should reduce the maintenance burden for the binutils maintainers. == Feedback == I reached out to the maintainers of the packages that currently use gold. Almost all of them were willing to switch to another linker immediately: * ghc No longer uses gold. * llvm Uses gold for tests. Willing to change. * meson Only used for testing. Willing to drop as the test is not gold specific. * perfetto Uses gold. Might be a hard req. Maintainers checking with upstream developers. * pypy3.10 Willing to drop. Test build in a PR to make this change succeeded. https://src.fedoraproject.org/rpms/pypy3.10/pull-request/33 * python-torch No longer uses gold. * qt5-qtwebengine Willing to switch to another linker if it works * rust Gone as of rust-1.85.0-2.fc43 * swift-lang Uses gold. Package might become deprecated. == Benefit to Fedora == * Reduces the complexity of Fedora by removing a linker that is no longer needed. * Reduces the maintenance burden of the binutils package by removing a component that is no longer being developed upstream. * Simplifies a developer's experience by reducing the number of choices for a linker from 4 to 3. == Scope == * Proposal owners: Add the deprecated() tag to the binutils-gold subpackage of the binutils package in rawhide. Add a comment explaining why the gold linker is being deprecated. Bump the NVR and build. Wait for responses, if any, from other package maintainers. Make an announcement on the devel mailing list, informing developers that gold is now deprecated. Optional (I am not sure if this counts as part of the deprecation, or will require a separate change request): After the next Fedora release is out, change the binutils package so that it does not build gold by default. Instead it would need the builder to add the ''--with gold'' option. A release after that, remove the option to build gold entirely. * Other developers: For developers who are currently using the gold linker in their project(s), a decision will have to be made as to whether they should switch to a different linker or stay with gold. Since deprecation does not actually remove the linker from the distribution, not making any change will still work. For package maintainers who package(s) use gold a similar choice should be made although again not changing anything will still work. * Release engineering: [https://pagure.io/releng/issue/12622] There should be no need to change the installer or update package delivery because of this change. * Policies and guidelines: N/A (not needed for this Change) The packaging guidelines are linker agnostic, so there is no need to alter them because of this change. * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: The change aligns with the strategy of increasing the number of active contributors in the sense that it simplifies the binutils package, making it easier to maintain, and it removes one of the linker choices available to developers, making their choice simpler. == Upgrade/compatibility impact == There should be no affect on users or developers upgrading from earlier versions of Fedora. Since the binutils-gold rpms will still be available (albeit marked as deprecated) no-one should notice any change. The only possible exception to this is for developers who are creating new packages for Fedora and who want to use gold. They will need to switch to a different linker. == Early Testing (Optional) == Do you require 'QA Blueprint' support? N == How To Test == No special hardware, data or the like is needed to test this change. In fact in theory no testing is necessary at all. Since the change is to add a ''deprecated()'' tag to the binutils-gold sub-package the only people who will be affected are packagers who want to add a dependency upon gold. So all existing packages should be unaffected. As for actual testing I guess a dummy package could be created that has a ''BuildRequires: binutils-gold'' dependency and then see if it is rejected by the packaging systems. == User Experience == Users who are also developers and who choose the use the gold linker for their project(s) will not be affected by the deprecation. But if/when the gold linker is actually removed they will notice the change. Switching to a different linker should be relatively easy however. == Dependencies == Currently the following rpms have a ''BuildRequires'' on ''binutils-gold'': * ghc8.10-0:8.10.7-15.fc41.src * ghc8.10-compiler-0:8.10.7-15.fc41.x86_64 * ghc9.0-0:9.0.2-18.fc41.src * ghc9.0-compiler-0:9.0.2-18.fc41.x86_64 * ghc9.2-0:9.2.8-28.fc42.src * ghc9.2-compiler-0:9.2.8-28.fc42.x86_64 * ghc9.4-0:9.4.8-33.fc42.src * ghc9.4-compiler-0:9.4.8-33.fc42.x86_64 * llvm-0:19.1.7-11.fc43.src * meson-0:1.7.0-3.fc43.src * perfetto-0:49.0-1.fc42.src * pypy3.10-0:7.3.19-2.3.10.fc43.src * pypy3.11-0:7.3.19-2.3.11.fc43.src * pypy3.9-0:7.3.16-4.3.9.fc42.src * swift-lang-0:6.0.3-2.fc42.x86_64 Most of these packages are in the process of being updated however. There should be no packages that have a runtime requirement on the gold linker. == Contingency Plan == * Contingency mechanism: Remove the deprecated() tag from the binutils-gold sub-package and rebuild the binutils rpms. * Contingency deadline: Before the Fedora 44 branch ie: 2026-02-03 * Blocks release? No == Documentation == The [https://lists.gnu.org/archive/html/info-gnu/2025-02/msg00001.html| Release Announcement] for version 2.44 of the upstream GNU Binutils project included a notice that the gold linker was being moved out of the default release tarballs in preparation for its eventual discontinuation. == Release Notes == The Gold linker has been deprecated and will eventually be removed from Fedora entirely. Upstream development of the gold linker has stopped which is why it is being deprecated in Fedora. Three other linkers are available to developers however (ld.bfd, lld and mold) so there is still plenty of choice. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F42 Change Proposal: Copilot Runtime Verification Framework (self-contained)
by Aoife Moloney 10 Mar '25

10 Mar '25

Wiki - https://fedoraproject.org/wiki/Changes/Copilot_Runtime_Verification_Framewo… Discussion thread - https://discussion.fedoraproject.org/t/f42-change-proposal-copilot-runtime-… 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. In this instance, this proposal has been previewed by the Fedora Engineering Steering Committee and members of Fedora QA as it is a late change, https://pagure.io/fesco/issue/3367, and has been provisionally approved as acceptable for F42 release, pending community feedback. If any feedback is received that alters the change proposal in a significant way, it will be resubmitted to FESCo for a further review and vote. == Summary == [https://copilot-language.github.io/ Copilot Language and Runtime Verification System] is a stream-based runtime-verification framework for generating hard real-time C code. == Owner == * Name: [[User:fdedden|Frank Dedden]] * Email: <frank(a)systemf.dev> * Name: [[User:Petersen|Jens Petersen]] * Email: <petersen(a)redhat.com> == Detailed Description == Copilot is a realtime programming language and Runtime Verification framework, developed for NASA. It allows users to write concise programs in a simple but powerful way using a stream-based approach. Programs can be interpreted for testing, or translated C99 code to be incorporated in a project, or as a standalone application. The C99 backend ensures us that the output is constant in memory and time, making it suitable for systems with hard realtime requirements. == Feedback == == Benefit to Fedora == This is a new feature in Fedora which will of interest to those developing specific critical embedded systems requiring a high level of software assurance. == Scope == * Proposal owners: ** build the copilot stack for Rawhide/F42: version 3.19 is packaged [done] * 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 the Fedora Strategy: == Upgrade/compatibility impact == == Early Testing (Optional) == == How To Test == * `sudo dnf install ghc-copilot-devel` * follow the documentation below for tutorial examples == User Experience == Users will be able to easily install the Copilot verification framework and test it. == Dependencies == == 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) == Documentation == * https://copilot-language.github.io/documentation.html * https://github.com/Copilot-Language/copilot * https://ntrs.nasa.gov/citations/20240010993 == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

CANCELLED - F42 Beta Go/No-Go Meeting, March 6
by Aoife Moloney 05 Mar '25

05 Mar '25

Hi all, Please be advised that due to a number of outstanding unresolved blockers[1] for F42 beta, we are cancelling this week's go/no-go meeting tomorrow, March 6. We will instead meet next Thursday, March 13 @ 1700 UTC in #fedora-meeting[2] to determine the status of Fedora Linux 42 Beta. The new target release date is Tuesday March 18 for F42 Beta. The release schedule[3] has been updated accordingly and an email reminder will be sent on Monday 10 March ahead of the Go/No-Go meeting. Kindest regards, Aoife [1] https://qa.fedoraproject.org/blockerbugs/milestone/42/beta/buglist [2] https://calendar.fedoraproject.org/Fedora%20release/2025/3/10/#m11003 [3] https://fedorapeople.org/groups/schedule/f-42/f-42-key-tasks.html -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce March 2025