devel February 2026

devel@lists.fedoraproject.org

121 participants
227 discussions

Non-responsive maintainer: crosa
by Henryk Paluch 14 Jul '26

14 Jul '26

Hello! I have issue with non-responsive maintainer crosa (Cleber Rosa) that maintains Avocado-VT related packages (but some of these packages are included in Fedora base). There are several important fixes required for Python3.14 (Fedora43) to work at all. Oldest bug in New state is from February 2025 (so 9 months idle). Bugzilla search url: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&columnlist=product%2… Results in CSV: "ID","Product","Component","Assignee","Status","Summary","Changed","Severity","Priority" "2026200","Fedora","python-aexpect","Cleber Rosa","NEW","python-aexpect-1.8.0 is available","2025-07-30T22:01:23Z","unspecified","unspecified" "2341130","Fedora","python-avocado","Cleber Rosa","NEW","python-avocado: FTBFS in Fedora rawhide/f42","2025-02-26T13:42:51Z","unspecified","unspecified" "2377418","Fedora","python-aexpect","Cleber Rosa","NEW","python-aexpect: Stop using deprecated %py3_build/%py3_install macros","2025-07-08T14:16:03Z","unspecified","unspecified" "2414808","Fedora","python-aexpect","Cleber Rosa","NEW","import aexpect crashes with: No module named 'pipes' (pipes removed from python3.13+)","2025-11-13T13:24:35Z","high","unspecified" "2292883","Fedora","python-avocado","Cleber Rosa","NEW","Please update to latest release 105.0","2025-02-26T13:04:06Z","medium","unspecified" I already tried to ping maintainer via python-aexpect-maintainers(a)fedoraproject.org on Nov 14 but received no response so far. Please let me know what we can do to move things forward. Regards --Henryk Paluch

3 4

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

Fedora Workstation probably removing gnome-abrt (also: don't forget the crash telemetry!)
by Michael Catanzaro 06 May '26

06 May '26

Hi, Fedora Workstation Working Group is tentatively planning to remove the ABRT user interface (gnome-abrt) in Fedora 44. For more information, see: https://pagure.io/fedora-workstation/issue/130#comment-992075 ABRT is currently in maintenance mode, receiving primarily bugfixes rather than feature development. The Working Group would prefer to keep gnome-abrt, but only if it were to receive considerable new feature development. If anybody is interested in working on ABRT, help would be welcome. Removing the user interface will not affect the automatic crash report functionality. Crashes will still be reported to https://retrace.fedoraproject.org/faf/summary/ which contains a treasure trove of crash telemetry. It's a shame that Fedora developers rarely look at it! This data could be quite useful for improving software quality. If anybody is interested in this topic, it might be a good opportunity to integrate AI, which could identify crash patterns or perhaps even suggest fixes. So that's two possible projects, in case anybody is looking for an itch to scratch. Michael

20 36

I'm considering orphaning mopidy &c due to missing dependencies
by Tobias Girstmair 03 Apr '26

03 Apr '26

Hi all, I've been quietly maintaining mopidy, a music streaming server written in Python, and its MPD compatibility layer mopidy-mpd for some years. Recent upstream changes make me consider orphaning them. Most notably, the latest version introduced dependencies on the PyPI packages polyfactory and cyclopts, neither of which are packaged by Fedora. I don't have the time to package them myself, as especially cyclopts has a rather fast-paced release schedule. Unless someone steps up to package these (which I do not expect anyone to do), I will sooner than later click the 'orphan' button on dist-git for the three related packages: * mopidy * mopidy-mpd * pykka (an otherwise unneeded dependency of both) tobi

2 3

Glycin support for XBM and XPM images
by Michael Catanzaro 27 Mar '26

27 Mar '26

Hi, Since [1], Glycin now supports XBM and XPM images. In our previous discussion [2] we suggested that gdk-pixbuf2-modules-extra is probably no longer needed if Glycin adds support for XPM, so we can probably retire this package now! Michael [1] https://gitlab.gnome.org/GNOME/glycin/-/commit/e2eb88b7dacf468e8f386718f9b0… [2] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…

7 15

F45 Change Proposal: Lua5.5 [SystemWide]
by Allison King via devel-announce 25 Mar '26

25 Mar '26

Wiki: https://fedoraproject.org/wiki/Changes/Lua5.5 Discussion Thread: https://discussion.fedoraproject.org/t/f45-change-proposal-lua5-5-systemwid… **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 == Update Fedora's Lua interpreter to 5.5. == Owner == * Name: [[User:spot| Tom Callaway]] * Email: spotrh(a)gmail.com == Detailed Description == Lua is one of the critical languages supported in Fedora, notably, because of RPM, but for a variety of other reasons as well. It is lightweight and well maintained. Upstream released 5.5 on December 22, 2025, and we have always kept Fedora on the current revision whenever possible. Its main new features are declarations for global variables, named vararg tables, more compact arrays, and major garbage collections done incrementally. == Feedback == N/A == Benefit to Fedora == Fedora has always been considered an excellent platform for lua users, because of our quick adoption of the current lua interpreter, as well as our willingness to aggressively patch for minor releases and known lua bugs fixed in their upstream source. This change would continue that behavior. Additionally, because lua is used in the internals of RPM, we inherit performance improvements through newer lua that benefit RPM, which has a broad impact on Fedora. Changing to lua 5.5 has low impact to end users, the language itself remains mostly compatible with previous revisions. Most of the gains here are in bug and performance fixes. == Scope == * Proposal owners: The following dependent packages need to be rebuilt (in a side-tag): ClanLib06 apk-tools aqualung asc asterisk awesome brltty ceph cgit clingo collectd conky corsix-th darktable domoticz dovecot eiskaltdcpp fcitx fennel fillets-ng fityk funguloids geeqie gnuplot golly gpick gplugin grafx2 graphviz grilo-plugins haproxy hexchat highlight httpd ibus-libpinyin ibus-pinyin imapfilter ipe janus libguestfs libinput libloc librime librs232 lighttpd lite-xl lsyncd lua-alt-getopt lua-argparse lua-bit32 lua-cassowary lua-cldr lua-cliargs lua-cosmo lua-coxpcall lua-cqueues lua-cyrussasl lua-dbi lua-epnf lua-ev lua-event lua-expat lua-filesystem lua-fluent lua-inotify lua-json lua-ldap lua-lgi lua-linenoise lua-loadkit lua-lpeg lua-luaossl lua-luarepl lua-luautf8 lua-lunitx lua-luv lua-lxc lua-md5 lua-moonscript lua-mosquitto lua-mpack lua-posix lua-psl lua-readline lua-sec lua-socket lua-sql lua-term lua-timerwheel lua-unbound lua-vstruct lua-zlib luabind luarocks lujavrite lumail lutok lxi-tools mathgl megaglest mle mm3d mod_security monotone nbdkit neomutt opendkim osm2pgsql plplot prosody rpc2 rpm rrdtool scorched3d sile slurm suricata texworks tio tolua++ ucviewer uwsgi vis vlc weechat wireplumber wireshark worker xmake xmoto xournalpp I expect these packages should rebuild with minimal changes. * Other developers: Barring any significant issues in the above packages, no other developers should be impacted. * Release engineering: This feature should not require coordination with rel-eng, though, we probably want to merge this _before_ the mass rebuild to make sure RPM is intact. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: Yes, because it keeps Fedora on current lua. == Upgrade/compatibility impact == Should be none. == Early Testing (Optional) == Do you require 'QA Blueprint' support? N == How To Test == All existing lua scripts/scripting should continue to work as is. If not, this is a bug we will address in conjunction with upstream. == User Experience == The user experience should not be affected. == Dependencies == Known dependencies are listed above. We have updated lua in the past and feel confident there are not hidden dependencies. == Contingency Plan == We can keep a lua54 compatibility package (I'm 99% sure we will need one in order to update RPM, but we usually get rid of it before everything lands). We can also rollback to lua 5.4 if we have issues rebuilding the dependencies. * Contingency mechanism: (What to do? Who will do it?) I will make a lua54 compatibility package that is generated from the lua package and contains liblua-5.4. Packages unable to migrate can depend on it as long as necessary. * Contingency deadline: Beta freeze? * Blocks release? Yes, because of RPM. If we get RPM going quickly, this becomes a no. == Documentation == https://www.lua.org/manual/5.5/readme.html#changes == Release Notes == Fedora has updated to Lua 5.5. -- *Allison King* Senior Technical Project Manager, In-Vehicle OS Red Hat <https://www.redhat.com/> alking(a)redhat.com <https://red.ht/sig> -- _______________________________________________ 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

5 6

What happened to this texlive subpackage? (No match for argument: tex(ecrm1000.tfm))
by Richard W.M. Jones 21 Mar '26

21 Mar '26

When building ocaml-mlgmpidl in Rawhide: No match for argument: tex(ecrm1000.tfm) https://koji.fedoraproject.org/koji/taskinfo?taskID=142550461 I looked at the texlive spec file, and ... yup. However it does appear to still contain ecrm1000.tfm, so why couldn't it be installed in the Rawhide buildroot? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html

9 16

Is it possible to drop jdk21 already in f44?
by Jiri Vanek 11 Mar '26

11 Mar '26

Hello! When I'm observing java stack, its usage, and adaptation of eclipse temurin JDKs, I'm happily surprised by what I see. It seems that temurin JDKs are used extensively, even more than our in-distro JDKs. Originally - in https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks - I wrote that jdk21 will be removed in f45, but it seems it can be removed already in f44. From total java-stack(546 packages), only 26 requires jdk21 for build[1]. Dropping jdk21 already for f44 would help our quite constrained resources and also have a net benefit on the infrastructure, since keeping it in Fedora 44 means keeping 21 alive until May 2027 which is too long of a time for a duplicate legacy JDK, especially when such a great and working alternative exist. WDYT? Best regards, J. [1] apache-commons-modeler-0:2.0.1-43.fc42.src apache-commons-text-0:1.10.0-8.fc42.src apache-sshd-1:2.11.0-2.fc41.src decentxml-0:1.4-36.fc41.src fop-0:2.9-9.fc41.src Java-WebSocket-0:1.6.0-4.fc43.src l10n-maven-plugin-0:1.1.0-2.fc43.src maven-archetype-0:3.2.1.0.8b3bdb6-14.fc41.src resteasy-0:3.0.26-32.fc42.src xmlgraphics-commons-0:2.11-1.fc43.src javapoet-0:1.7.0-27.fc43.src java-runtime-decompiler-0:10.0-6.fc43.src jol-0:0.17-10.fc43.src juniversalchardet-0:2.4.0-16.fc43.src plexus-velocity-0:2.2.1-2.fc43.src stringtemplate4-0:4.3.4-9.fc43.src xbean-0:4.24-8.fc43.src xbean-0:4.24-9.fc43.src icedtea-web-0:1.8.8-10.fc43.src java-21-openjdk-portable-1:21.0.8.0.9-1.fc43.2.src ldapjdk-0:5.6.0-0.1.alpha1.fc43.3.src ldapjdk-0:5.6.0-1.fc43.src mecab-java-0:0.996-14.fc43.src openjdk-asmtools-0:9.0.0.b12.ea.eb1979669-0.fc43.src mecab-java-0:0.996-14.fc43.src fop-0:2.9-9.fc41.src nekohtml-0:1.9.22-29.fc42.src jedit-0:5.6.0-8.fc43.src Seem like I'm maintaining quite a few of them anyway.... -- Jiri Vanek <j.vanek(a)ibm.com> Principal JDK QA engineer IBM Middleware Czechia s.r.o. +420 775 39 01 09

7 11

Handing over lmdb package
by Jan Stanek 09 Mar '26

09 Mar '26

Hello! I'm the current main maintainer for lmdb in Fedora, mainly for historical reasons. It did not receive many updates, so it was not really a problem. However, the recent CVE report [1] made me think I should probably hand the package over to someone with more time and interest in maintaining it than I currently have. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2427791 CC'ing tdawson, who is listed as the collaborator on Pagure; however, other takers are also welcome to voice their interest in taking over. Have a nice day! -- Jan Stanek Software Engineer Red Hat IM: @jstanek

4 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 February 2026