devel February 2025

devel@lists.fedoraproject.org

130 participants
229 discussions

2FA policy for provenpackagers is now active
by Zbigniew Jędrzejewski-Szmek 25 Jun '26

25 Jun '26

Proven packagers, we changed [2,3] the FESCo policy document [1] for provenpackagers to say: "Provenpackagers SHOULD have two-factor-authentication (2FA) enabled for their FAS accounts." This is not enforced or checked, but please take steps to conform to the policy if you haven't yet. [1] https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/ [2] It's not visible on the web yet, because antora is doing its thing … slowly. [3] https://pagure.io/fesco/issue/3186 Zbyszek

30 75

unannounced soname bump: gnome-desktop3 / libgnome-desktop-3
by Fabio Valentini 09 Jun '26

09 Jun '26

FYI, the .so version of libgnome-desktop-3 was bumped from 12 to 17 with the build of gnome-desktop3-3.27.90-1.fc28 without previous announcement. Packages that will have to be rebuilt - if it hasn't happened already (I didn't check individual changelogs, so no guarantee for correctness or completeness of this list): cheese-2:3.26.0-3.fc28.src control-center-1:3.26.2-4.fc28.src deepin-mutter-0:3.20.26-1.fc28.src deepin-wm-0:1.9.21-2.fc28.src eog-0:3.26.2-2.fc28.src epiphany-1:3.27.1-3.fc28.src evince-0:3.26.0-3.fc28.src evolution-0:3.27.4-1.fc28.src gnome-clocks-0:3.26.1-2.fc28.src gnome-contacts-0:3.26.1-1.fc28.src gnome-directory-thumbnailer-0:0.1.9-3.fc27.src gnome-documents-0:3.26.1-3.fc28.src gnome-font-viewer-0:3.26.0-1.fc28.src gnome-initial-setup-0:3.26.0-2.fc28.src gnome-screensaver-0:3.6.1-18.fc27.src gnome-session-0:3.26.1-3.fc28.src gnome-settings-daemon-0:3.26.2-4.fc28.src gnome-shell-extension-pomodoro-0:0.13.4-1.fc28.src gnome-shell-extensions-0:3.27.1-2.fc28.src gnome-software-0:3.27.4-1.fc28.src mutter-0:3.27.1-1.fc28.src nautilus-0:3.26.2-2.fc28.src switchboard-plug-display-0:0.1.3-4.fc28.src switchboard-plug-pantheon-shell-0:0.2.6-4.fc28.src totem-1:3.26.0-5.fc28.src xviewer-0:1.6.0-4.fc28.src Fabio

1 0

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

F42 Change Proposal: Deprecation of STI Tests (self-contained)
by Aoife Moloney via devel-announce 26 Aug '25

26 Aug '25

Wiki - https://fedoraproject.org/wiki/Changes/DeprecateSTI Discussion Thread - https://discussion.fedoraproject.org/t/f42-change-proposal-deprecation-of-s… 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 == Display a deprecation warning for Fedora 41 for all STI tests. Deprecate execution of STI tests in all CI pipelines for Fedora 42. * CI for bodhi updates * CI for dist-git pull requests All users of STI tests will need to [https://tmt.readthedocs.io/en/stable/questions.html#how-do-i-migrate-sti-te… migrate to the new tmt format]. '''The change will affect 281 components'''. The list of components affected can be found via [https://sourcegraph.com/search?q=context:global+repo:src.fedoraproject.org+… this sourcegraph query]. All references to STI will be removed from the Fedora CI documentation. == Owner == * Name: [[User:mvadkert| Miroslav Vadkerti]], [[User:lecris| Cristian Le]], * Email: mvadkert(a)redhat.com, fedora(a)lecris.me == Detailed Description == For some time CI testing in Fedora can be defined using two different formats: * Standard Test Interface (STI) * Test Management Tool (tmt) As tmt has matured to a state it can fully replace the STI functionality, we are proposing to drop STI as the supported format. STI format is not actively developed and is causing us a maintenance burden. More and more STI test failures are starting to appear as the Fedora packages evolve out of sync with the test scripts. Tmt provides various advantages over STI that would make it easier to manage in the long term: * Better organization of `tests` and test environments (referred to as `plans` in tmt) * Local reproducible environment thanks to testing-farm reproducer script, allowing to thinker locally without pushing to dist-git * Tests can be defined in the local dist-git repo, inside the srpm archive, [https://src.fedoraproject.org/projects/tests/%2A `tests/*`] dist-git namespace, or in the upstream repo, allowing it to be reused more freely between packages and with upstream directly * Tmt tests are integrated with packit allowing it to be executed with upstream and better migrate to the new dist-git environment Hopefully this list can help inspire some better ways of reorganizing the tests during the migration. == Feedback == == Benefit to Fedora == Having two formats for executing the tests is an unnecessary duplication and causes confusion for the Fedora maintainers and community. STI tests have limited functionality and are harder to develop and maintain, when compared to tmt. == Scope == * Proposal owners: [[User:mvadkert| Miroslav Vadkerti]], [[User:lecris| Cristian Le]] * 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 == This is a change to the development experience, no changes to Fedora distribution are made. == How To Migrate == To find out if you package has STI tests, check if `tests/tests*.yml` files are present in your dist-git repository. Follow the [https://tmt.readthedocs.io/en/stable/questions.html#how-do-i-migrate-sti-te… sti to tmt migration guide]. For the majority of tests involve just executing the already provided script you only need to: 1. Initialize `tmt` structure using `tmt init` 2. Create a minimal plan <pre> # /plan.fmf # Boilerplate to indicate tmt to run any tests files it finds in the repo discover: how: fmf execute: how: tmt # Prepare test environment, e.g. install packages # Note: the current packages in the spec file will already be installed by default prepare: how: install packages: - foo - bar </pre> 3. Migrate individual tests <pre> # /tests/foo.fmf test: ./foo.sh </pre> For more complex needs feel free to discuss in the [https://matrix.to/#/#fedora-ci:fedoraproject.org `#fedora-ci`] or [https://matrix.to/#/#tmt:fedoraproject.org `#tmt`] matrix channels. You can also explore [https://sourcegraph.com/search?q=context:global+repo:src.fedoraproject.org/… other project's tmt tests] (identified by having a `.fmf` folder) using `tmt tests show` and `tmt plans show` == User Experience == For Fedora 41 users will be presented with a deprecation warning in the Testing Farm artifacts. For Fedora 42 users who have setup gating on STI tests will be obligated to migrate to be able to push their packages to stable repositories. == Dependencies == N/A == Contingency Plan == * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? No (not a System Wide Change) We will keep the STI support until all references to STI tests are gone in case all users have not migrated to tmt until Fedora 42. See the description for the list of the affected components. == Documentation == * [https://tmt.readthedocs.io/en/stable/questions.html#how-do-i-migrate-sti-te… How to migrate STI tests to tmt] * [https://src.fedoraproject.org/tests/python/tree/main Example test repo implemented in both STI and tmt format] (see for example the `smoke/venv.fmf` file and `smoke_default` test in `tests.yml` file) * [https://tmt.readthedocs.io/en/stable/spec.html Tmt specs] (reference for the available keys defining `plans` or `tests`) * Example project with shared [https://github.com/containers/aardvark-dns upstream]+[https://src.fedoraproject.org/rpms/aardvark-dns downstream] tests == Release Notes == -- 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

2 1

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

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