devel July 2025

devel@lists.fedoraproject.org

142 participants
218 discussions

Switch gnome-software to use a dnf5 plugin in rawhide
by Milan Crha 06 Feb '26

06 Feb '26

Hi, I'd like to switch gnome-software in rawhide to use a dnf5 plugin, to move away from its dependency on the PackageKit. This had been announced together with the dnf5 change proposal some time ago [1], but due to some missing work on the gnome-software side it had been postponed. As the work is ready, I'd like to finally finish this part [2] of that Change as well. I'll wait for two weeks and unless some strong objection is arose here I'll do the switch to the dnf5 plugin in rawhide, for the Fedora 43. Bye, Milan [1] https://fedoraproject.org/wiki/Changes/SwitchToDnf5 [2] https://fedoraproject.org/wiki/Changes/SwitchToDnf5#GNOME_Software_support

8 17

Release rpkg-1.68 and fedpkg-1.46
by Ondrej Nosek 06 Jan '26

06 Jan '26

Hi all, a new version rpkg-1.68 together with fedpkg-1.46 are released containing both features and bugfixes. Currently, all supported versions (Fedora 40, Fedora 41, Fedora 42, Fedora Rawhide, EPEL 8, EPEL 9, EPEL 10) are present in stable repositories. Changelog (web documentation): https://docs.pagure.org/rpkg/releases/1.68.html https://docs.pagure.org/fedpkg/releases/1.46.html Both released (rpkg & fedpkg) versions need to be installed together, they contain some changes incompatible with older packages. All changes listed above are not new - most of them were released earlier as patches. Updates: https://bodhi.fedoraproject.org/updates/?builds=rpkg-1.68-1.el8&builds=rpkg… Alternative link: https://bodhi.fedoraproject.org/updates/?packages=rpkg&page=1 https://bodhi.fedoraproject.org/updates/?packages=fedpkg&page=1 rpkg is also available from PyPI. Because setuptools is not working on the latest Fedora versions, PyPI package was prepared in Hatchling instead. Fedpkg is not supported in Python 2 anymore. Thanks to all contributors; Special thanks to Adam Williamson and Diego Herrera for their notable contributions. Regards

1 1

yajl - call for new maintainer and/or to stop using it
by Daniel P. Berrangé 05 Jan '26

05 Jan '26

I've been maintainer of the yajl package in Fedora forever, as it was a dep of libvirt. yajl upstream has been dead since 2015, so the current release tarball has multiple CVEs, which I've patched downstream by grabbing patches from github issue comments from third parties or other distros [1]. In the libvirt 10.8.0 release that just hit rawhide, we've switched to using json-c instead. Aside from libvirt in stable Fedora release branches, there are a few other packages in Fedora still using yajl that I see: Io-language collectd crun grive2 i3 i3-gaps i3status libmodsecurity mod_security raptor2 xen If anyone is cares about the above packages enough to want to take over ownership of 'yajl', either now or in future, please let me know. I'm willing to keep ownership of yajl until the Fedora 41 branch goes end of life, at which point no version of libvirt will still use it If no new volunteer has stepped forward by then I'll be orphaning yajl. If you are the Fedora maintainer of any of the above packages, I'd strongly recommend talking to their respective upstream about switching JSON library to json-c instead of yajl, to avoid being stuck using a dead project forever. With regards, Daniel [1] I collect patches in src-git at https://github.com/berrange/yajl/tree/fedora-dist-git -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

4 6

Windows Secure Boot certificate expiration (June 2026)
by Mateus Rodrigues Costa 31 Dec '25

31 Dec '25

Hello all, As you guys know Secure Boot is supported by Fedora Linux and it relies on the Microsoft signing keys. Well, recently I was looking at this month's Windows 11 cumulative update and noticed this warning: Important: Secure Boot certificates used by most Windows devices are set to expire starting in June 2026. This might affect the ability of certain personal and business devices to boot securely if not updated in time. To avoid disruption, we recommend reviewing the guidance and taking action to update certificates in advance. For details and preparation steps, see Windows Secure Boot certificate expiration and CA updates. Which links to https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-e… My question is if we as Fedora users should worry.... I guess that users with devices that actively receive BIOS updates should receive a update with the new certificates included, but it's unknown what will happen for devices that are basically out of support. I believe that fwupd should be able to update that certificate, but at least on my system the Microsoft certificate isn't shown on it (I believe on a UEFI Secure Boot VM it's shown) Should we worry about this? For instance, my device, a Dell laptop, for which fwupd recognizes: the firmware (which I update via a built in Bios flash utility), the dbx (updated via fwupd) and a mysterious "Dell Platform Key", which might be Microsoft's certificate along with some other Dell stuff. Is Linux ready for the Microsoft certificate expiring next year? Thanks for your time, Mateus Rodrigues Costa

20 47

Looking for provenpackager to update rapid-photo-downloader package
by Damon Lynch 18 Dec '25

18 Dec '25

Greetings Fedora community, I am the developer of Rapid Photo Downloader. The package for it in Fedora is about two years old, and crashes during start-up under Python 3.10. As the subject says, I'm looking for a provenpackager to update the package. I'm posting this message here at the suggestion of a fellow PyQt developer who unlike myself is a Fedora expert. I filed a bug report last year but the maintainer has been unable to work on it: https://bugzilla.redhat.com/show_bug.cgi?id=2031866 Meanwhile, two months ago Neal Gompa made this pull request to update it: https://src.fedoraproject.org/rpms/rapid-photo-downloader/pull-request/3 The current release is 0.9.33. Compared to the Fedora version, it requires a new package in Fedora: https://github.com/damonlynch/showinfilemanager Unfortunately I'm unable to volunteer my time because I managed to injure my hands while working on the code earlier this year. Serious typing injuries are not fun. :-( (I'm dictating this using a voice recognition program under Windows.) Fun fact: Fedora was the first distro to package Rapid Photo Downloader.

8 7

Replacing regular file with directory on RPM upgrade ?
by Daniel P. Berrangé 10 Dec '25

10 Dec '25

In the packaging guidelines we call out the problematic upgrades for replacing a directory with a non-directory, or replacing a symlink with a directory. We don't mention replacing a regular file with a directory though. Empirically that appears to be a broken scenario too. # ls -al /usr/lib64/gimp/3.0/plug-ins/gmic_gimp_qt -rwxr-xr-x. 1 root root 10443848 Aug 29 2024 /usr/lib64/gimp/3.0/plug-ins/gmic_gimp_qt # dnf update --enablerepo=updates-testing gmic-gimp ...snip... [5/8] Upgrading gmic-gimp-0:3.5.2-4.fc41.x86_64 >>> [RPM] failed to open dir gmic_gimp_qt of /usr/lib64/gimp/3.0/plug-ins/gmic_gimp_qt/: cpio: mkdir failed - File exists >>> [RPM] unpacking of archive failed on file /usr/lib64/gimp/3.0/plug-ins/gmic_gimp_qt/gmic_gimp_qt;67ceae1e: cpio: mkdir failed - Directory not empty >>> Unpack error: gmic-gimp-0:3.5.2-4.fc41.x86_64 Did something change in cpio, or has it always been broken for regular file to directory replacement too, and our docs were thus always incomplete ? With regards, Daniel [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Replace… -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

6 8

F36 Change: Remove Wire Extensions Support (Self-Contained Change proposal)
by Ben Cotton 11 Nov '25

11 Nov '25

https://fedoraproject.org/wiki/Changes/RemoveWirelessExtensions == Summary == The legacy wireless extensions interface was replaced by the new mac80211/cfg80211 interface in 2007. The legacy Wireless Extensions support has been long deprecated and only supports long EOL WiFi encryption like WEP so it's time to disable it and remove it. == Owner == * Name: [[User:pbrobinson| Peter Robinson]] * Email: [mailto:pbrobinson@fedoraproject.org| pbrobinson(a)fedoraproject.org] == Detailed Description == The Wireless Extensions support in the kernel has been long replaced by the mac80211/cfg80211 support. Disable the kernel options and retire the wireless-tools userspace utilities. Wireless Extensions only supports a minor subset of the wireless interfaces, predominently the WEP interface and userspace has been replaced by iw/libnl/ip interfaces which offer a lot more advanced features as well as modern 802.11 functionality like WPA. == Benefit to Fedora == More secure and advanced features in wireless. In most cases most users won't notice a difference. The vast majority of users use NetworkManager to use 802.11 based wireless interfaces which has long ceased to support wireless extensions/wireless-tools, if it evere did. == Scope == * Proposal owners: ** Disable the wireless extensions interface in the kernel and any drivers that depend on it. The only driver that is currently enabled that requires wireless extension support is the Intel Pro Wireless 2100/2200 drivers, this hardware was released in 2003-2005 as part of the original Centrino laptop platforms and all officially supported devices were 32 bit so it's unlikely there's any current users but as they were mPCI cards it's possible there's a few users that put them into 64 bit machines. ** Retire the wireless-tools package, retirn any packages that depend on it, or migrate them to use libnl3. * Other developers: ** No impact * Release engineering: [https://pagure.io/releng/issue/10386 #10386] * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == A handful of packages still use the libiw interface and hence depend on the wireless-tools package. Some projects look dead upstream, a number have already been migrated in the last year or so. Where the project is alive upstream tickets have been filed requesting migration. The current remaining package list is: * conky * lxpanel * reaver == How To Test == * Check that the wireless extensions kernel options are disabled: (CONFIG_WEXT_CORE CONFIG_WEXT_PROC CONFIG_WEXT_SPY CONFIG_WEXT_PRIV CONFIG_CFG80211_WEXT CONFIG_CFG80211_WEXT_EXPORT) * Check the wireless-tools package is no longer available == User Experience == Generally users should notice little to no difference. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: Leave WEXT enabled in the kernel, leave wireless-tools package in Fedora package repository. * Contingency deadline: GA * Blocks release? No. * Blocks product? No. == Documentation == N/A (not a System Wide Change) == Release Notes == N/A -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

8 12

Is the chromium debuginfo package exists?
by Mikhail Gavrilov 08 Oct '25

08 Oct '25

Hi folks! Is the chromium debuginfo package exists? Quick searching in repos didn't find any debuginfo packages for chromium. # dnf search chromium | grep debuginfo Last metadata expiration check: 0:08:12 ago on Mon 26 Jul 2021 02:25:19 AM +05. chromium-bsu-debuginfo.x86_64 : Debug information for package chromium-bsu lightspark-chromium-plugin-debuginfo.x86_64 : Debug information for package lightspark-chromium-plugin And of course I enabled "rawhide-debuginfo" repo.

5 4

fedup upload failure
by Martin Gansser 29 Sep '25

29 Sep '25

Hello, I'm getting the following error when I'm uploading a new tarball: $ kinit martinkg(a)FEDORAPROJECT.ORG $ fedpkg new-sources vdr-plugin-epg2vdr-1.1.86.tar.bz2 Could not execute new_sources: Request is unauthorized. Any ideas as to why I can not do an fedpkg upload? I'm able to do a fedpkg clone so my rsa keys are good...

2 3

F43 Change Proposal: Use update-alternatives for managing NodeJS symlinks (self contained)
by Aoife Moloney via devel-announce 22 Sep '25

22 Sep '25

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 -- _______________________________________________ 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://pagure.io/fedora-infrastructure/new_issue

6 5

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 2025