devel November 2024

devel@lists.fedoraproject.org

153 participants
200 discussions

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

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

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

replace memtest86+ with pcmemtest, needs maintainer
by Chris Murphy 01 Sep '25

01 Sep '25

[Bug 1988142] memtest boot entry on Fedora install media does not work since Fedora-Rawhide-20210728.n.3 https://bugzilla.redhat.com/show_bug.cgi?id=1988142 This bug might be gcc, but also includes a note about the upstream being kinda weak, possibly non-existent these days. Neal Gompa mentioned pcmemtest earlier this year https://github.com/martinwhitaker/pcmemtest It would need a maintainer. Any takers? Fedora doesn't have a release criterion covering the memory tester, or really any option appearing in the install media's boot menu other than the one that launches the installer. But I think it's better to not ship a memory tester at all, than to ship a broken one (given the options). Memtest86+ is bios only, where pcmemtest can be compiled to run on either firmware type. If we want it to work with UEFI Secure Boot enabled, it'd need to be signed with Fedora's key (I think the same as the one used for GRUB and/or the kernel?). This would be in scope for Fedora 36, assuming the above bug can be easily fixed. But if that bug is hard to fix, and pcmemtest could be a drop-in replacement (i.e. bios only, just like now) maybe that's doable for Fedora 35, and better than having no memory tester. Chris Murphy -- Chris Murphy

15 33

Remove old GPG keys?
by Miroslav Suchý 13 Aug '25

13 Aug '25

I just stumbled upon https://unix.stackexchange.com/questions/400634/does-anyone-bother-to-remov… with the nice link to: https://blog.laimbock.com/2014/05/02/how-to-remove-an-imported-gpg-key-from… And I wonder: is it a good idea to keep old gpg keys in RPM db? Or should we automate the removal of old keys? Mirek

17 31

Upstream tip wanted: CI service for Big Endian acrhes
by Miro Hrončok 06 Aug '25

06 Aug '25

Recently I've reported some Big Endian related test failures to an upstream project [0]. I was asked by an upstream project maintainer, whether I know some free Continuous Integration services where they can easily run their testsuite on Big Endian. Any tips? * Upstream uses Travis CI to test on x86_64 Linux (Ubuntu) * Upstream uses AppVeyor to test on Microsoft Windows * It's a pure Python project, noarch, but some changes need to be done when loading/saving binary data (LE) with NumPy on BE system. What I've considered: * COPR (but there is no big endian arch) * (Ab)using Koji (I guess that would be considered a bad practice?) * using QUEMU on Travis CI [1] Any better tips? Thanks [0] https://github.com/mikedh/trimesh/issues/249 [1] https://developer.ibm.com/linuxonpower/2017/07/28/travis-multi-architecture… -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

8 10

pdftk retired?
by Michael J Gruber 06 Aug '25

06 Aug '25

I just git a "broken dependencies" notice for a package that I maintain. The reason is that "pdftk" got retired just the other day. I may have missed a corresponding post on fedora-devel, but I think a heads up notice to maintainers of depending packages may be in order before you retire a package, as a general idea. You see, unretiring a package is so much more work than changing maintainership. As for pdftk: I see 2 failed builds for version 1.45 and none for the current version 2.02 (which probably breaks the api anyways). What are the plans? Retire pdftk completely? Start fresh with pdftk2? pdflabs, the maker of pdftk, provide binary as well as source rpms for pdftk 2.02, by the way. I might even look into packaging it but don't want to duplicate any existing efforts. Michael

17 26

upgrading RH 9 system->Fedora with iso files and apt only
by Didier Casse 06 Aug '25

06 Aug '25

I have the yarrow's iso files on my HD in a RH9 system. Let's say I want to upgrade selected packages using an "apt-get install" pointing to my iso-mounted files, how do I do it? i.e I mount the iso into some /mnt/yarrow1, /mnt/yarrow 2 etc.. Then what is the complete procedure to make my apt look into my own HD to upgrade packages. Can anybody redirect me to the correct resource or some literature hanging on the web? Thanks. Assume also that I do not wish to burn CDs! I do not want to use apt-cdrom. Thanks. With kind regards, Didier. --- PhD student Singapore Synchrotron Light Source (SSLS) 5 Research Link, Singapore 117603 Email: slsbdfc at nus dot edu dot sg \or\ didierbe at sps dot nus dot edu dot sg Website: http://ssls.nus.edu.sg

6 9

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 November 2024