devel July 2026

devel@lists.fedoraproject.org

112 participants
134 discussions

F45 Change Proposal: Sequoia opengpgverify (self-contained)
by Aoife Moloney via devel-announce 20 Jul '26

20 Jul '26

Wiki - https://fedoraproject.org/wiki/Changes/Sequoia_opengpgverify Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-sequoia-opengpgv… 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 == Introduce a rpm macro <code>%openpgpverify</code> and update packages to use it instead of existing gnupg specific <code>%gpgverify</code>. The new macro will use standard OpenPGP implementation from Sequoia instead of GnuPG by default to provide support for Post Quantum Cryptography defined in the OpenPGP WG. This is part of gradual switching from GnuPG dependency. == Owner == * Name: [[User:jjelen| Jakub Jelen]] [[User:decathorpe | Fabio Valentini ]] * Email: jjelen(a)redhat.com, decathorpe AT gmail DOT com == Detailed Description == The GnuPG decided to fork the OpenPGP specification as LibrePGP to develop incompatible standard in 2023. Since then, the GnuPG 2.5.* versions (not present in Fedora) can create artifacts incompatible with current OpenPGP standard. We are observing the situation and the we believe Fedora project should embrace the OpenPGP standard developed within the IETF, which involves gradually switching from the GnuPG to other implementations where possible. We identified Sequoia-PGP as a good candidate as it implements the standard OpenPGP (including the RFC 9980 standardizing PQC). The Sequoia-PGP is already used as part of RPM to verify [https://sequoia-pgp.org/blog/2023/04/27/rpm-sequoia/ RPM signatures] since 2023, as well as in [https://src.fedoraproject.org/rpms/rust-podman-sequoia podman]. RPM also supports [https://github.com/rpm-software-management/rpm/blob/master/docs/man/rpmsign… signing RPMs using Sequoia tools] since version 6.0 so adjusting the rpm macros is natural next step. == Feedback == == Benefit to Fedora == * Prevent vendor-lock-in in GnuPG ecosystem. * Follow IETF standardization * Improve security by providing developers with ability to use Post Quantum Cryptography to sign their artifacts. * Integrate better with the rest of the operating system by following system wide crypto policies. == Scope == * Proposal owners: * Create a new <code>%openpgpverify</code> macro using sqv CLI * Verify it works with existing artifacts in Fedora, fix/workaround/report possible issues. * Change <code>%gpgverify</code> rpm macro in existing spec files to use <code>%openpgpverify</code> where possible with proven packager or PRs * Other developers: Respond to possible issues/PRs in cases where this will not work out of the box. * Release engineering: [https://forge.fedoraproject.org/releng/tickets/issues #Releng issue number] * Policies and guidelines: The Packaging Guidelines should be updated to make use %openpgpverify macro by default. * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: N/A == Upgrade/compatibility impact == No upgrade impact -- this involves just build system and development. Compatibility needs to be evaluated. There should not be any existing librePGP artifacts, but there might be some old GnuPG keys that will not pass stricter Sequoia checks. Identifying them will help increase security of the supply chain as insecure keys might allow getting forged artifacts to Fedora. == Early Testing (Optional) == Verify all packages that use <code>%gpgverify</code> macro work with <code>%openpgpverify</code>. == How To Test == * Have a dist git of a package with upstream tarball signed with GPG key * Update gpgverify BuildRequires to openpgpverify * Update %gpgverify macro to %openpgpverify * Verify the local package build works for you with `fedpkg local` or `fedpkg mockbuild` If not, review the log, key(ring) and report potential issues to the upstream developer or Sequoia developers. Do they use SHA1 in their certificate? Do they use small RSA key that could be broken by Quantum Computer in close future? == User Experience == This change should not affect user experience. == Dependencies == * rust-sequoia-sqv * gpgverify * other packages using gpgverify == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) 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 == Fedora packaging guidelines need to be updated to reflect this change. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_verifying_signa… N/A (not a System Wide Change) == Release Notes == Fedora is using Sequoia to by default to verify upstream tarball signatures during the build time. This allows upstreams to sign their artifacts using Quantum Resistant algorithms defined in the latest OpenPGP RFC 9980. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr… Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

6 10

Announcement: on-demand openQA testing of dist-git pull requests
by Adam Williamson 20 Jul '26

20 Jul '26

Hi folks! I'm hoping this new feature I've been working on since Flock is now ready for prime time. It's pretty simple, really. Comment '/openqa test' on a dist-git PR and openQA will test it. It should report the state back to the pull request - you'll get an entry called something like "Fedora openQA tests - scratch build 147755141" that will start in 'pending' state then go to 'success', 'failure' or 'error' once all tests complete. The entry is a link to the openQA summary page where you can see the state of each test (so if you get a 'failure' result you can see specifically which test(s) failed; I don't want to report the state of each test separately to the PR because there can be dozens or hundreds). Here's a PR where you can see it "in action": https://src.fedoraproject.org/rpms/sqlite/pull-request/64 It looks for the Packit scratch build for the target branch of the PR, so if that build fails, the tests won't run. If the scratch build is not done at the time you post the comment, the tests *should* run once the scratch build succeeds (and any subsequent time a scratch build of the PR for the correct branch succeeds). If the package is in the critical path, it will run only "appropriate" tests (using the same mapping used for update tests). If the package is not in the critical path, it will just run all the update tests. There is no multi-package / multi-PR capability at this time; the tests will always run on *only* the scratch build of the PR you commented on. (with the relevant buildroot repo enabled in the system-under-test). If the change in the PR depends on a pending change to another package that has not already appeared in the buildroot, the tests will fail. Sorry. I don't want to invent some kind of system for marking PRs as related myself; we might want to do it as a project, though, and if we do go that way, I'll try and enhance this system to work with it so related PRs are tested together. This is the primary reason this system is "on- demand" - I don't want to trigger tests automatically for all critpath package PRs, or anything like that, because we know they would sometimes fail because of interdependency issues. Right now there's no authorization check - if *anyone* comments '/openqa test' on a PR it is "enabled" for testing and tests will run every time a scratch build of the PR completes. Please don't abuse this by spamming it on PRs you're not involved in, or anything; if anyone does that I'll just have to turn the feature off unless/until I can implement some kind of "only accept comments from people with commit access to the package" mechanic, and I'd rather believe I can just trust people. Please only use this mechanism if you're actually going to find the results directly useful. The tests will trigger on both staging and production openQA instances, but only the production instance should report status back to the PR. The implementation of this is Pagure-specific, but it's not really that complicated and should hopefully be fairly easy to port to Forgejo when we move dist-git. If anyone's interested, this is the code: https://forge.fedoraproject.org/quality/fedora_openqa/commit/ac5a56f41b2a7f… Of course, please let me know if you try it out and it doesn't work, or you notice some kind of bug. Thanks! -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

3 5

F45 Change Proposal: RelocateRpmRepoConfigsToUsr [SelfContained]
by Allison King via devel-announce 20 Jul '26

20 Jul '26

Wiki: https://fedoraproject.org/wiki/Changes/RelocateRpmRepoConfigsToUsr Discussion Thread: https://discussion.fedoraproject.org/t/188916 **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 == Relocate all packaged RPM repository configuration data from <code>/etc</code> to <code>/usr</code>. == Owner == * Name: [[User:Ngompa| Neal Gompa]] * Email: ngompa13(a)gmail.com == Detailed Description == This Change aims relocate all packaged RPM repository configuration data from <code>/etc/yum.repos.d</code> to <code>/usr/share/dnf5/repos.d</code>. All Fedora packaging PGP/GPG keys in <code>fedora-gpg-keys</code> will also be relocated to <code>/usr/share/pki/rpm-gpg</code>. This is now possible because all major read+write frontends for DNF configuration now go through DNF5. Fedora has now switched to DNF version 5 in the build system ([[Changes/BuildWithDNF5|Fedora Linux 40]]), the user-facing CLI tools ([[Changes/SwitchToDnf5|Fedora Linux 41]]), the installer ([[Changes/Switch_Anaconda_installer_to_DNF5|Fedora Linux 43]]), and PackageKit ([[Changes/PackageKit-DNF5|Fedora Linux 44]]). This means all the major supported entry points implicitly support DNF5's layered configuration system. The <code>fedora-third-party</code> tool used by Fedora KDE Plasma variants and Fedora Workstation will also be adjusted for this new world. == Feedback == == Benefit to Fedora == The key benefit for Fedora is it establishes a clean separation of packaged repository definitions and allows for users to trivially identify local changes and undo them if desired. This is also necessary to simplify how derivatives handle repository definitions, since moving it to <code>/usr</code> allows the middle layer for packaged repository configuration overrides to function properly. == Scope == * Proposal owners: ** {{package|fedora-repos}}: Relocate yum.repos.d and rpm-gpg data to new locations in <code>/usr</code> ** {{package|fedora-workstation-repositories}}: Relocate yum.repos.d and rpm-gpg data to new locations in <code>/usr</code> ** {{package|fedora-third-party}}: Update configuration editor code to generate drop-in files in <code>/etc/dnf/repos.override.d</code> * Other developers: N/A (not needed for this Change) * Release engineering: [ https://forge.fedoraproject.org/releng/tickets/issues/13321 #13321] * 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 == Distribution provided RPM repository configuration files, if unmodified, will cleanly move from <code>/etc</code> to <code>/usr</code>. If modified, they will stay in place and override the configuration files shipped in <code>/usr</code> entirely. Going forward, packaged repository configuration will no longer be present in <code>/etc</code>. == Early Testing (Optional) == N/A == How To Test == Once the changes are made in Rawhide, simply upgrade into them and interact with the package manager normally. == User Experience == There should be no substantially visible changes to the user experience. == Dependencies == * {{package|fedora-repos}} * {{package|fedora-workstation-repositories}} * {{package|fedora-third-party}} == Contingency Plan == * Contingency mechanism: Rollback and defer to the next release * Contingency deadline: Final Freeze * Blocks release? Yes == Documentation == DNF5 documentation on the configuration system: https://dnf5.readthedocs.io/en/latest/dnf5.conf.5.html == Release Notes == Fedora Linux 45 now ships all distribution-provided configuration for the DNF package manager in <code>/usr</code>, which makes it easier to identify user-local changes in <code>/etc</code> separately from distribution-provided configuration. -- _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr… Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

2 1

slow s390x builds
by Julian Sikorski 20 Jul '26

20 Jul '26

Hello, it appears that s390x builds are getting considerably slower than others. I was updating AusweisApp today [1] and got the following results: - i686: 3 minutes - x86_64: 5 minutes - aarch64: 9 minutes - ppc64le: 13 minutes - s390x: still running after 41 minutes This makes s390x build at least three times slower than the next slowest build and more than ten times slower than the fastest one. Together with not working koji notifications and limited time, this makes it quite frustrating wait before I can create updates in bodhi and complete the task. Can I just call it a day and ExcludeArch: s390x? I doubt anyone is using German IDs to authenticate online on a mainframe anyway. Best regards, Julian [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=3059518

5 6

Fedora 45 Mass Rebuild Completed
by Patrik Polakovic via devel-announce 20 Jul '26

20 Jul '26

Hello all, As per the Fedora 45 release schedule [1], we started a mass rebuild for Fedora 45 on 2026-07-15. This is now completed. The mass rebuild was run for the changes listed here: https://fedoraproject.org/wiki/Fedora_45_Mass_Rebuild#Driving_Changes The rebuild was done in a side tag (`f45-rebuild`) that was merged into the release tag (`f45`). Failures from the mass rebuild can be found here: https://kojipkgs.fedoraproject.org/mass-rebuild/f45-failures.html Packages that still need to be rebuilt can be found here: https://kojipkgs.fedoraproject.org/mass-rebuild/f45-need-rebuild.html FTBFS bugs will be filed shortly for the remaining failures. Discussions related to the Fedora 45 mass rebuild took place in the tracker ticket [2]. Please let Release Engineering know if you notice any issues with the reporting. You can contact us through the Release Engineering Matrix room [3] or by opening a ticket on our issue tracker [4]. The following builds had to be manually untagged or canceled during the rebuild for various reasons, which are detailed in the tracker ticket: python-geopmpy-3.2.1-4.fc45 sbcl-2.6.6-2.fc45 rust-async-std-1.13.2-3.fc45 simdutf-9.0.0-2.fc45 file-5.48-2.fc45 tomcat-10.1.57-2.fc45 gnutls-3.8.13-2.fc45 nettle-4.0-3.fc45 nettle3.10-3.10.1-4.fc45 Regards, Patrik Polakovic Fedora Release Engineering [1] https://fedorapeople.org/groups/schedule/f-45/f-45-all-tasks.html [2] https://forge.fedoraproject.org/releng/tickets/issues/13406 [3] https://matrix.to/#/#releng:fedoraproject.org [4] https://forge.fedoraproject.org/releng/tickets/issues -- _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr… Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

4 3

Unretire sugar packages.
by Chihurumnaya Ibiam 20 Jul '26

20 Jul '26

I'd like to unretire the following sugar packages; sugar sugar-browse They've been orphaned for <8 weeks so they don't need a review. I'd also like a review for sugar-paint <https://bugzilla.redhat.com/show_bug.cgi?id=2228190>, it has been open for quite a while now. Thank you! -- Ibiam Chihurumnaya ibiam(a)sugarlabs.org

2 3

Orphaning yosys/nextpnr & related packages
by Gabriel L. Somlo 20 Jul '26

20 Jul '26

I'm no longer able to properly look after these packages, and having not heard back from any of my co-maintainers over the last week or so, I'm formally orphaning them in hope that they get picked up by someone who can do them justice. The list includes: - yosys: HDL compilation, synthesis, and logic optimization - recent upstream support for SystemVerilog frontend may need to be packaged as standalone RPM, to be used by yosys as a buildrequires dependency - yosyshq-abc (fork of Berkeley ABC logic optimizer and tech-mapping tool, used by yosys as a dependency, but also able to be used as a stand-alone tool) - nextpnr: place-and-route tool for Lattice FPGAs - upstream has done extensive work on supporting other FPGA models, with various degrees of RPM packageability, and it would be nice to incorporate some of that in the Fedora version - **NOTE**: I can't *formally* orphan this package as my co-maintainer is the official owner, but walking away from it nonetheless !!! - trellis: Lattice ECP5 FPGA dependency for nextpnr - icestorm: Lattice iCE40 FPGA dependency for nextpnr - python-migen: a "pythonic" HDL meta-language that elaborates to Verilog before being compiled (e.g., with Yosys) Best, --Gabriel

1 0

List of long term FTBFS packages to be retired in August
by Miro Hrončok 20 Jul '26

20 Jul '26

Dear maintainers. Based on the current fail to build from source policy, the following packages should be retired from Fedora 45 approximately one week before branching, i.e. 2026-08-05. 5 weekly reminders are required, this is the third one. Policy: https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails… The packages in rawhide were not successfully built at least since Fedora 42. This report is based on dist tags. Packages collected via: https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbf… If you see a package that was built, please let me know. If you see a package that should be exempted from the process, please let me know and we can work together to get a FESCo approval for that. If you see a package that can be rebuilt, please do so. Package (co)maintainers ============================================================================ axel orphan cvise mpolacek drumstick0 kkofler, yanqiyu golang-github-facebookincubator-go2chef @go-sig, dcavalca, salimma golang-github-jedib0t-pretty-6 @go-sig, eclipseo golang-github-kit @go-sig, alexsaezm google-osconfig-agent @cloud-sig, @go-sig, ngompa, siosm gotun @go-sig, kushal hfsutils dwmw2 json-fortran jussilehtola kf5-akonadi-calendar @kde-sig, farchord knotes @kde-sig, farchord, than mingw-gsm valtri php-mtdowling-jmespath-php siwinski plotnetcfg jbenc psi4 jussilehtola python-pamela orion rubygem-sinatra-cross_origin valtri slim aarem tcl-pgtcl @db-sig, fjanus, praiskup tcl-tcludp spot tcl-tileqt spot tcl-tkpng spot tcl-tktreectrl spot ularn wart The following packages require above mentioned packages: Depending on: drumstick0 (1) kmid2 (maintained by: cheeselee, kkofler) kmid2-2.4.0-34.fc44.src requires drumstick0-devel kmid2-2.4.0-34.fc44.x86_64 requires drumstick0, libdrumstick-alsa.so.0()(64bit), libdrumstick-file.so.0()(64bit) Depending on: json-fortran (7) mctc-lib (maintained by: jussilehtola) mctc-lib-0.3.2-4.fc44.i686 requires libjsonfortran.so.8.3 mctc-lib-0.3.2-4.fc44.src requires json-fortran-devel mctc-lib-0.3.2-4.fc44.x86_64 requires libjsonfortran.so.8.3()(64bit) mctc-lib-devel-0.3.2-4.fc44.i686 requires pkgconfig(json-fortran) mctc-lib-devel-0.3.2-4.fc44.x86_64 requires pkgconfig(json-fortran) dftd4 (maintained by: jussilehtola) dftd4-3.7.0-12.fc45.i686 requires libmctc-lib.so.0, libmulticharge.so.0 dftd4-3.7.0-12.fc45.src requires mctc-lib-devel, mstore-devel, multicharge-devel dftd4-3.7.0-12.fc45.x86_64 requires libmctc-lib.so.0()(64bit), libmulticharge.so.0()(64bit) dftd4-devel-3.7.0-12.fc45.i686 requires pkgconfig(mctc-lib), pkgconfig(multicharge) dftd4-devel-3.7.0-12.fc45.x86_64 requires pkgconfig(mctc-lib), pkgconfig(multicharge) mstore (maintained by: jussilehtola) mstore-0.3.0-5.fc44.i686 requires libmctc-lib.so.0 mstore-0.3.0-5.fc44.src requires mctc-lib-devel mstore-0.3.0-5.fc44.x86_64 requires libmctc-lib.so.0()(64bit) mstore-devel-0.3.0-5.fc44.i686 requires pkgconfig(mctc-lib) mstore-devel-0.3.0-5.fc44.x86_64 requires pkgconfig(mctc-lib) multicharge (maintained by: jussilehtola) multicharge-0.3.0-6.fc44.i686 requires libmctc-lib.so.0 multicharge-0.3.0-6.fc44.src requires mctc-lib-devel, mstore-devel multicharge-0.3.0-6.fc44.x86_64 requires libmctc-lib.so.0()(64bit) multicharge-devel-0.3.0-6.fc44.i686 requires pkgconfig(mctc-lib) multicharge-devel-0.3.0-6.fc44.x86_64 requires pkgconfig(mctc-lib) xtb (maintained by: jussilehtola) xtb-6.7.1-6.fc44.src requires dftd4-devel, mctc-lib-devel, multicharge-devel xtb-6.7.1-6.fc44.x86_64 requires libmctc-lib.so.0()(64bit) xtb-libs-6.7.1-6.fc44.i686 requires libmctc-lib.so.0 xtb-libs-6.7.1-6.fc44.x86_64 requires libmctc-lib.so.0()(64bit) avogadro2 (maintained by: sagitter) avogadro2-2.0.0-1.fc45.x86_64 requires xtb(x86-64) crest (maintained by: jussilehtola) crest-2.12-10.fc43.src requires xtb crest-2.12-10.fc43.x86_64 requires xtb Depending on: kf5-akonadi-calendar (3) kf5-calendarsupport (maintained by: @kde-sig, farchord) kf5-calendarsupport-23.08.5-5.fc44.i686 requires libKPim5AkonadiCalendar.so.5 kf5-calendarsupport-23.08.5-5.fc44.src requires cmake(KF5AkonadiCalendar), kf5-akonadi-calendar-devel kf5-calendarsupport-23.08.5-5.fc44.x86_64 requires libKPim5AkonadiCalendar.so.5()(64bit) kf5-calendarsupport-devel-23.08.5-5.fc44.i686 requires cmake(KF5AkonadiCalendar), kf5-akonadi-calendar-devel kf5-calendarsupport-devel-23.08.5-5.fc44.x86_64 requires cmake(KF5AkonadiCalendar), kf5-akonadi-calendar-devel kf5-eventviews (maintained by: @kde-sig, farchord) kf5-eventviews-23.08.5-5.fc44.i686 requires libKPim5AkonadiCalendar.so.5, libKPim5CalendarSupport.so.5 kf5-eventviews-23.08.5-5.fc44.src requires cmake(KF5AkonadiCalendar), cmake(KF5CalendarSupport), kf5-akonadi-calendar-devel, kf5-calendarsupport-devel kf5-eventviews-23.08.5-5.fc44.x86_64 requires libKPim5AkonadiCalendar.so.5()(64bit), libKPim5CalendarSupport.so.5()(64bit) kf5-eventviews-devel-23.08.5-5.fc44.i686 requires cmake(KF5AkonadiCalendar), cmake(KF5CalendarSupport) kf5-eventviews-devel-23.08.5-5.fc44.x86_64 requires cmake(KF5AkonadiCalendar), cmake(KF5CalendarSupport) kf5-incidenceeditor (maintained by: @kde-sig, farchord) kf5-incidenceeditor-23.08.5-6.fc44.x86_64 requires libKPim5AkonadiCalendar.so.5()(64bit), libKPim5CalendarSupport.so.5()(64bit), libKPim5EventViews.so.5()(64bit) kf5-incidenceeditor-23.08.5-6.fc44.src requires cmake(KPim5CalendarSupport), cmake(KPim5EventViews), kf5-eventviews-devel kf5-incidenceeditor-devel-23.08.5-6.fc44.x86_64 requires cmake(KPim5CalendarSupport), cmake(KPim5EventViews) Depending on: knotes (1) kdepim (maintained by: @kde-sig, than) kdepim-7:17.12.3-19.fc44.x86_64 requires knotes Depending on: mingw-gsm (2) mingw-gstreamer1-plugins-bad-free (maintained by: elmarco, etrunko, mooninite) mingw-gstreamer1-plugins-bad-free-1.28.5-1.fc45.src requires mingw32-gsm, mingw64-gsm mingw32-gstreamer1-plugins-bad-free-1.28.5-1.fc45.noarch requires mingw32(libgsm-1.dll) mingw64-gstreamer1-plugins-bad-free-1.28.5-1.fc45.noarch requires mingw64(libgsm-1.dll) mingw-gtk4 (maintained by: elmarco) mingw-gtk4-4.22.2-2.fc45.src requires mingw32-gstreamer1-plugins-bad-free, mingw64-gstreamer1-plugins-bad-free mingw32-gtk4-4.22.2-2.fc45.noarch requires mingw32(libgstd3d12-1.0-0.dll), mingw32(libgstplay-1.0-0.dll) mingw64-gtk4-4.22.2-2.fc45.noarch requires mingw64(libgstd3d12-1.0-0.dll), mingw64(libgstplay-1.0-0.dll) Affected (co)maintainers @cloud-sig: google-osconfig-agent @db-sig: tcl-pgtcl @go-sig: google-osconfig-agent, gotun, golang-github-jedib0t-pretty-6, golang-github-facebookincubator-go2chef, golang-github-kit @kde-sig: knotes, kf5-akonadi-calendar aarem: slim alexsaezm: golang-github-kit cheeselee: drumstick0 dcavalca: golang-github-facebookincubator-go2chef dwmw2: hfsutils eclipseo: golang-github-jedib0t-pretty-6 elmarco: mingw-gsm etrunko: mingw-gsm farchord: knotes, kf5-akonadi-calendar fjanus: tcl-pgtcl jbenc: plotnetcfg jussilehtola: json-fortran, psi4 kkofler: drumstick0 kushal: gotun mooninite: mingw-gsm mpolacek: cvise ngompa: google-osconfig-agent orion: python-pamela praiskup: tcl-pgtcl sagitter: json-fortran salimma: golang-github-facebookincubator-go2chef siosm: google-osconfig-agent siwinski: php-mtdowling-jmespath-php spot: tcl-tileqt, tcl-tkpng, tcl-tcludp, tcl-tktreectrl than: knotes valtri: rubygem-sinatra-cross_origin, mingw-gsm wart: ularn yanqiyu: drumstick0

4 3

i686 removal - easy win set
by Michal Schorm 20 Jul '26

20 Jul '26

For those interested in this topic, I compiled a set of packages that exactly: builds i686 && all binary RPMs are buildroot-only && leaf && NOT on FESCo "protected" list https://mschorm.fedorapeople.org/ARCHIVE/i686-removal/koji-only-leaf-i686_2… If my method and understanding are both correct, we could add 'ExcludeArch: %{ix86}' to each of these 3,400 packages with zero impact on the rest of the packages and save some resources. What do you think? Michal -- Michal Schorm Senior Software Engineer Databases Team Red Hat --

7 12

F45 Change Proposal: Authselect: Hardcode nss-altfiles in profiles (self-contained)
by Aoife Moloney via devel-announce 20 Jul '26

20 Jul '26

Wiki - https://fedoraproject.org/wiki/Changes/Authselect_Hardcode_Altfiles Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-authselect-hardc… 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 == Currently, authselect users can enable nss-altfiles in nsswitch.conf using "with-altfiles" feature. This proposal is to remove the feature and hardcode nss-altfiles support in nsswitch.conf in all shipped profiles, making it required. == Owner == * Name: [[User:pbrezina| Pavel Březina]] * Email: pbrezina(a)redhat.com == Detailed Description == Currently, non-ostree systems (e.g. Fedora Workstation) have nss-altfiles nsswitch.conf module optional in authselect profiles. Users can enable this module by calling "authselect enable-feature with-altfiles" or directly when selecting the profile "authselect select $profile with-altfiles". However, the nss-altfiles nsswitch.conf module is required to be enabled on ostree systems (e.g. Fedora Silverblue) and must not be disabled there to make system users available to the system. This is currently handled by authselect in %post scriptlet that modifies the shipped profiles and hardcodes nss-altfiles in them. This solution, however, makes authselect different on ostree and non-ostree systems. The history also showed that it is quite fragile and easy to break with modifications to the profiles. The intention is to hardcode nss-altfiles on both ostree and non-ostree, making authselect install exactly the same files on both distribution types. == Feedback == None. == Benefit to Fedora == Both ostree and non-ostree Fedora releases will ship exactly the same authselect content. == Scope == * Proposal owners: Do the work in upstream and release it in Fedora. * Other developers: None. * Release engineering: None. [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 == None. Upgrade path will be handled by authselect. == Early Testing (Optional) == == How To Test == 1. Check that with-altfiles is no longer available in the profiles 2. Check that "altfiles" is present in generated /etc/nsswitch.conf == User Experience == User's should not notice the change. == Dependencies == None. == 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 == N/A (not a System Wide Change) == Release Notes == The "with-altfiles" feature has been removed from all authselect profiles. The nss-altfiles support is now enabled and can not be disabled. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr… Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel July 2026