dnfdragora has not been working on Fedora Workstation since F41 and up through and including fully updated F43.
The following was found at:
Stable
Fedora 43 2.99.0^git20250421.1.2f707ee-5.fc43
Testing
Fedora 43 2.99.0^git20250421.1.2f707ee-5.fc43
I have the listed version installed:
$ dnf info dnfdragora
Updating and loading repositories:
Repositories loaded.
Installed packages
Name : dnfdragora
Epoch : 0
Version : 2.99.0^git20250421.1.2f707ee
Release : 1.fc42
Architecture : noarch
Installed size : 2.2 MiB
Source : dnfdragora-2.99.0^git20250421.1.2f707ee-1.fc42.src.rpm
From repository : updates
Summary : DNF package-manager based on libYui abstraction
URL : GitHub - manatools/dnfdragora: dnfdragora is a dnf frontend based on libyui abstraction
License : GPL-3.0-or-later
Description : dnfdragora is a DNF frontend, based on rpmdragora from Mageia
: (originally rpmdrake) Perl code.
:
: dnfdragora is written in Python 3 and uses libYui, the widget
: abstraction library written by SUSE, so that it can be run
: using Qt 5, GTK+ 3, or ncurses interfaces.
Vendor : Fedora Project
Reference bug:
I have seen no activity on this bug.
One new thing since this bug is that dnfdragora when started from the command line with “sudo dnfdragora” though there are black popups that say “dnfdragora not responding”, but with patience they clear and dnfdragora will work in a limited way. For instance it returns no results for searches that should produce a long list of results like “lib” or “gnome-shell-extension-”.
I will appreciate any help you can provide on this.
Note that the available version is newer than the one you currently showed.
$ sudo dnf info dnfdragora
Updating and loading repositories:
Repositories loaded.
Available packages
Name : dnfdragora
Epoch : 0
Version : 2.99.0^git20250421.1.2f707ee
Release : 5.fc43
Architecture : noarch
Download size : 577.4 KiB
Installed size : 2.2 MiB
Source : dnfdragora-2.99.0^git20250421.1.2f707ee-5.fc43.src.rpm
Repository : fedora
Summary : DNF package-manager based on libYui abstraction
URL : https://github.com/manatools/dnfdragora
License : GPL-3.0-or-later
Description : dnfdragora is a DNF frontend, based on rpmdragora from Mageia
: (originally rpmdrake) Perl code.
:
: dnfdragora is written in Python 3 and uses libYui, the widget
: abstraction library written by SUSE, so that it can be run
: using Qt 5, GTK+ 3, or ncurses interfaces.
Vendor : Fedora Project
The dnfdragora package for f42 requires python 3.13 while f43 uses python 3.14
Solution:
upgrade dnfdragora to the version for f43
I just checked and all the required packages are loaded and at the required versions. I am running F43 and dnfdragora was installed on F43 and the versions match as shown at the top of this post..
This is the version for F43 installed on F43. I Have checked that all the software is installed twice now. Also, I have run dnfdragora from the command line with “dnfdragora” and get the same results as when run from the icon, but when I run it with “sudo dnfdragora” it starts and run much of it’s functionality. I’m guessing this problem has more to do with dnfdragora’s interaction with packages that have been mentioned or interaction with system software. I’m guessing that when dnfdragora is tested for inclusion in a new version fedora workstation the test is run on a test server that and has root privileges and whatever is tested is part of the dnfdragora functionality that works when run with root privileges. I am wondering can someone running F43 Workstation on hardware (not a VM) can install dnfdragora (sudo dnf install dnfdragora) and it runs properly?
For me it doesn’t work either on Fedora 42. It does talk to dnf5daemon-server via dbus so it should not need to be run with sudo. Also, in the end it crashed with coredump.
What I quoted that you had posted with that command clearly shows you have the f42 version of dnfdragora installed. That version requires python 3.13.
F43 uses python 3.14 and requires dnfdragora-2.99.0^git20250421.1.2f707ee-5.fc43
Please show the result of dnf list --installed dnfdragora as i asked earlier.
If you insist that the correct version is already installed in spite of having your own post show otherwise then I can assist no further.
I’ve never used “sudo” with dnfdragora. I’m on KDE Plasma/Wayland and run plain old “dnfdragora” as the command (or from the App Launcher, which itself would do “dnfdragora” as the normal user as well). In my case due to being KDE I suspect the problem is when you run in GTK mode (gnome), I’m running in QT mode since that’s the KDE toolkit. So what I get is:
“dnfdragora” → works, defaults to QT due to KDE plasma desktop
“dnfdragora --qt” → works, uses QT
“dnfdragora --gtk” → fails, window becomes grey, title bar says “(Not Responding)” and window is frozen saying “Creating packages cache” and “Caching updates” but never changes.
When in frozen state for GTK, it has to be core dumped to get out of it and I get a dump for python3.14.
Though I run Gnome I have some KDE application installed so qt is on my machine. So I tried “dnfdragora –qt” and the results are exactly the same and when I I run “sudo dnfdragora” it’s partially functional. For instance when dnfdragora first starts it is set for Groups searching When I set it for All searching there is a long pause with the black wait or force quit popup, but with patience the popup clears and it comes up in All mode. Also when I search for “gnome-shell-extension-freon” it finds it fine. but when I search for “gnome-shell-extension-” instead of returning a list of all the extensions, it returns nothing.
I have this bug for many years. Before this summer, I was always running Fedora in a virtual machine and I thought it was related to it. But I have now installed Fedora 42 (GNOME) on several real machines and I still have the same problem most of the time. dnfdragora is often unusable.
My understanding is that dnfdragora should not be run as root
It does not require the extra privileges since it asks for confirmation when it needs the extra access.
I’m an engineer and I do electronics and software. I help out on Fedora QA though I don’t attend the meetings much anymore, but I do file bugs. So yes, I understand that dnfdragora or most anything else for that matter should not be normally run as root. I sometimes do though when I’m troubleshooting something on my dedicated bare metal test machine which never has any of my data on it. I posted here to see if I could get a little more attention to this problem since I never see anything on the bugs I filed and I even sent a note to the team that maintains dnfdragora. Now I think the the reason is that all the people on the dnfdragora development team run KDE so it always works for them and they figure the bugs were written by someone who doesn’t know what they are talking about. or it’s possible they don’t have time or care enough about is to look into it.
It is not appropriate to throw mud at the developers. Negative comments are discouraged.
While it may be true that the developers are mostly using KDE, I am sure that they do truly care about the quality of their product for everyone.
It is certain that running dnfdragora with qt is much better than with gtk. That would be appropriate to address in a bug report with logs and facts to support the claim. Dnfdragora can be run in debugging mode and with logs to reflect the performance on your system.
Use man dnfdragora and man dnfdragora.yaml to see the options, as well as info about debugging and logs.
When I launch dnfdragora from the cli I see quite a bit of info provided on-screen, and that info is different when using --qt or --gtk
I’ve met and talked to Neal Gompa and I know better of him and his team. I’m sorry Neal and team. please accept my heart felt apology. I know you are all very busy with other more important things since a lot of QA team folks and development people too left to help with fedora’s AI effort.
I’ve just gotten dependent on dnfdragora as a help for loading debug versions, the file list, and link to the source code,
Actually I posted all the info from running dnfdragora at the CLI in my bug report back in June:
I’ve been getting by without it, though, doing less trouble shooting, since Fedora Workstation 40 as I recall. I will be patient.
Why not use command line dnf5? There’s nothing dnfdragora does better than dnf5 with the exception of showing package information in a more handy way.
I do use DNF5. That’s how I’ve been getting by for package information.
I also used dnfdragora for package searching. For instance From time to time I’m hoping there is a library for some need I have for new a program I’m writing. With dnfdragora I could structure queries to find out.
From what I can tell applications like Software or Discover can’t find libraries or any other package that doesn’t have a GUI.
I just tried “dnfdragora --gtk” from KDE Plasma 6.5.4 and it’s working correctly for me. So it’s been 5 days since my other post where “dnfdragora --gtk” failed.
One thing, dnfdragora will sometimes seem “zoned out” and show “not responding” in the title if you give it something really big like showing “All” packages but after a while it will recover and show the new view. So the trick is “how long do I wait” to tell between hung for good or hung for 1 or 2 minutes.