devel September 2025

devel@lists.fedoraproject.org

136 participants
237 discussions

guile30 maintainer is non responsive
by Paul Bolle 10 Feb '26

10 Feb '26

Hi, GNU Guile 3.0.10 was released over a year ago, but Fedora's guile30 package is still based on 3.0.9: https://bugzilla.redhat.com/show_bug.cgi?id=2294649 Half a year ago a build of 3.0.10 was tried. Apparently there was a build failure on i686. (I have not been able to find the logs of that build.) I'm not aware of an attempt to fix this failure. Nor was it decided to exclude i686 from future builds of GNU Guile. As far as I can see Tomáš is pretty active in Fedora (https://src.fedoraproject.org/user/tkorbar lists 75 packages!). So there was no reason to check whether Tomáš is non responsive regarding those other packages. It's unfortunate that, in order to get this package unstuck, I have to follow the (public) non-responsive maintainer procedure. Kind regards, Paul Bolle

6 14

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

High CPU usage of fedpkg new-sources
by Julian Sikorski 30 Jan '26

30 Jan '26

Hi list, after upgrading to fiber I have noticed that fedpkg new-sources did not get much faster despite my upload bandwith going up 12 times. I have then noticed that my laptop equipped with semi-recent 4500U APU is at 100% CPU usage when uploading new mame [1] sources. Is this normal, and can anything be done about it? For tiny sources it is not a real issue, but for mame uploading the new sources to lookaside cache is by far the slowest part of the update process. Thanks! Best regards, Julian [1] https://github.com/mamedev/mame/archive/refs/tags/mame0281.tar.gz

6 7

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

07 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 19 Dec '25

19 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

fedora:rawhide --arch s390x container: bash missing prompt
by Marián Konček 03 Dec '25

03 Dec '25

When I run `podman run --arch s390x --rm -it fedora:rawhide` as well as `mock -r fedora-rawhide-s390x --shell`, the shell prompt is missing but the shell is still working. On F41 shell looks correct. This seems like a bug somewhere in the container. -- Marián Konček

5 12

increasing the size of boot partition
by Chris Murphy 22 Nov '25

22 Nov '25

This thread is distinct from initramfs size increase, initial suspect is dracut 105 to 107 https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… I'm noticing quite large rescue initramfs lately but haven't dug into when it started. -rw-------. 1 root root 268553810 Sep 12 23:10 initramfs-0-rescue-2a837d3749fd4397a3107adde82b7518.img What I have noticed is by removing nvidia-gpu-firmware-0:20250808-1.fc43.noarch and rebuilding the [-N, --no-hostonly, Disable host-only mode.] initramfs... -rw-------. 1 root root 137294342 Sep 21 20:34 initramfs-0-rescue-2a837d3749fd4397a3107adde82b7518.img It's quite a bit smaller. There's also amd firmware in the initial rescue firmware. Both are expected for no-hostonly initramfs. The question is, since firmware is getting bigger at a faster rate than most other things, and because no-hostonly and sloppy mode initramfs contain more firmware files - I'm wondering... Should we bump boot volume size for Fedora 43? The last time it was bumped, from 500M to 1G, was 2016. There wasn't a change proposal, it was just suggested we do it on this list, and then changed. While a 1G boot will accommodate 3 kernels and initramfs today, it may not in the near future. And some folks use kdump which adds more initramfs to boot. We could just double it to 2G, but that seems like overkill for systems that are resource constrained. Another idea is to bump boot to 1.2G for Fedora 43. And then commit to revisiting the size more frequently, even as soon as Fedora 44/45. -- Chris Murphy

32 129

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 September 2025