manatools / dnfdaemon Goto Github PK

View Code? Open in Web Editor NEW

12.0 6.0 16.0 500 KB

DBus daemon for doing package action with the dnf package manager

License: GNU General Public License v2.0

Python 91.84% Makefile 4.09% Shell 0.35% Perl 3.72%

dnf dbus dnf-daemon daemon fedora mageia

dnfdaemon's Introduction

dnf-daemon

dnf-daemon is a 2 DBus services there make part for dnf's API available for application via DBus calls.

There is a DBus session bus service running as current user for performing readonly actions.

There is a DBus system bus service running as root for performing actions there is making changes to the system

This makes it easy to do packaging action from your application no matter what language it is written in, as long as there is DBus binding for it.

dnf-daemon uses PolicyKit for authentication for the system service, so when you call one of the commands (as normal users) you will get a
PolicyKit dialog to ask for password of a privileged user like root.

dnf-daemon is still under heavy development and the API is not stable or complete yet

Source overview

dnfdaemon/      Contains the daemon python source
client/         Contains the client API bindings for python 2.x & 3.x
test/           Unit test for the daemon and python bindings
dbus/           DBus system service setup files
policykit1/     PolicyKit authentication setup files

How to install services and python bindings:

Run the following

	git clone ...
	cd dnf-daemon
	make test-inst

How to test:

just run:

make test-verbose

to run the unit test with output to console

or this to just run the unit tests.

make test

To make the daemons shutdown

Session:

make exit-session

System

make exit-system

Both

make exit-both

to run the daemons in debug mode from checkout:

session (readonly as current user)

make run-session

system (as root)

make run-system

API Definitions:

The dnfdaemon api is documented here

The API is under development, so it might change, when we hit version 1.0, API methods will be frozen and API method names, parameters and return types will not change in future releases, new API can be added, but the old ones stays as is

API Addition Checklist:

Add the new API methods to dnfdaemon-system.py and optional dnfdaemon-session.py
Add client api method in DnfDaemonBase if it is available in both daemon or in DnfDaemonClient is it is a system only api.
Add unit tests for the api in test/test-system-api.py and optional to test/test-system-api.py if it exists in the session api
Update docs/server.rst and docs/client-python.api ( add new api method to members )
All unit tests must pass (make test) before pushing to github

dnfdaemon's People

Stargazers

Watchers

Forkers

j-mracek besser82 edcuba dmach adamwill maxamillion timlau anaselli lauriereeves mikhailnov papoteur-mga carlwgeorge sporadicthought ruyaos dragonzx syslogic

dnfdaemon's Issues

Hawkey is deprecated, use libhif instead

See these announcements [2] for details.

Plugins not loaded after first daemon access

Well, this is embarrassing.

There is a small issue with the recent pull-request that I submitted (ec3cbde) (which was merged, thank you!).

The first time the daemon is accessed everything works. Plugins are loaded, variables in repo urls are populated, everything's good. If the daemon is accessed a second time, plugins are not loaded, variables are not substituted. When I enable debug logging, I can see that the plugins fail to load: "Failed to init plugins: load_plugins() called twice".

In dnfdaemon, the dnf.Base object is "reset" after a transaction and it looks like that is not compatible with plugins. However, I do see that the reset is necessary to get updated state. e.g. if you install a package the current dnf.Base thinks the package is not installed.

As per the dnf documentation, it is assumed that the dnf.Base object lives for the length of the program's life and there is further implication that plugins get a reference to this Base object:

https://dnf.readthedocs.io/en/latest/api_base.html

For now, I can force the daemon to exit before every transaction, but this is not ideal. I fear a more formal solution would require a bit of a refactoring, but hopefully there's a simple fix.

Locking doesn't work as expected, Exception handling too

While experimenting with yumex-dnf/src/yumex/updater.py, in Updater.get_updates(), I changed these lines:

        try:
            self.backend.Lock()
            pkgs = self.backend.GetPackages('updates')
            rc = len(pkgs)
            logger.debug('# of updates : %d' % rc)
            self.backend.Unlock()
        except:  # Get locking errors
            logger.debug('Error getting the dnfdaemon lock')
            rc = -1

I wanted to make the except: statement less general and only capture dnfdaemon.client.LockedError, but this failed for two reasons:

Running self.backend.Lock() is executed without exceptions although yumex-dnf is still running and keeping the lock.
Running self.backend.GetPackages('updates') triggers an Exception, but due to dnfdaemon.client.DnfDaemonBase._handle_dbus_error() directly parsing strings, the string g-io-error-quark: GDBus.Error:org.baseurl.DnfSystem.LockedError: dnf is locked by another application (36) is incorrectly handed and not recognized as dnfdaemon.client.LockedError.

It seems like dnfdaemon.client.DnfDaemonBase._handle_dbus_error() is supposed to handle both client and server side errors, but I think they should be handled separately.

Use system dnf cache?

Every laucnh of dnfdragora takes quite a lot of time to at least make cache and maybe update metadata, why can't it use system dnf cache without updating it, provided that dnf-makecache.timer is enabled by default? Just to speedup things a lot. Or maybe update metadata in the background.

handle network offline more gracefully

Currently when starting yumex-dnf on an offline PC which has not been online since last boot, I get a huge error message dialog in yumex-dnf:

g-io-error-quark: GDBus.Error:org.freedesktop.DBus.Python.dnf.exceptions.RepoError: Traceback (most recent call last):
  File "/usr/lib/python3.4/site-packages/dnf/repo.py", line 206, in perform
    return super(_Handle, self).perform(result)
  File "/usr/lib64/python3.4/site-packages/librepo/__init__.py", line 1425, in perform
    _librepo.Handle.perform(self, result)
librepo.LibrepoException: (8, "Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f23&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org]", 'An Curl handle error')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.4/site-packages/dnf/repo.py", line 796, in load
    if self._try_revive():
  File "/usr/lib/python3.4/site-packages/dnf/repo.py", line 710, in _try_revive
    handle.perform()
  File "/usr/lib/python3.4/site-packages/dnf/repo.py", line 210, in perform
    raise _DetailedLibrepoError(exc, source)
dnf.repo._DetailedLibrepoError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib64/python3.4/site-packages/dbus/service.py", line 826, in _message_cb
    retval = candidate_method(self, *args, **keywords)
  File "/usr/lib/python3.4/site-packages/dnfdaemon/server/__init__.py", line 83, in newFunc
    rc = func(*args, **kwargs)
  File "/usr/share/dnfdaemon/dnfdaemon-system", line 207, in SetConfig
    rc = self.set_option(setting, value)
  File "/usr/lib/python3.4/site-packages/dnfdaemon/server/__init__.py", line 692, in set_option
    if hasattr(self.base.conf, option):
  File "/usr/lib/python3.4/site-packages/dnfdaemon/server/__init__.py", line 218, in base
    self._get_base()
  File "/usr/lib/python3.4/site-packages/dnfdaemon/server/__init__.py", line 1065, in _get_base
    self._base.setup_base()
  File "/usr/lib/python3.4/site-packages/dnfdaemon/server/backend.py", line 66, in setup_base
    self.fill_sack()
  File "/usr/lib/python3.4/site-packages/dnf/base.py", line 249, in fill_sack
    self._add_repo_to_sack(r.id)
  File "/usr/lib/python3.4/site-packages/dnf/base.py", line 104, in _add_repo_to_sack
    repo.load()
  File "/usr/lib/python3.4/site-packages/dnf/repo.py", line 817, in load
    raise dnf.exceptions.RepoError(msg)
dnf.exceptions.RepoError: Failed to synchronize cache for repo 'updates' from 'https://mirrors.fedoraproject.org/metalink?repo=updates-released-f23&arch=x86_64': Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f23&arch=x86_64 [Could not resolve host: mirrors.fedoraproject.org]
 (36)

Please make this error message simpler and easier to understand for users.

_history_undo_operations does not work with dnf 4.6

Private API (https://bugzilla.redhat.com/show_bug.cgi?id=1079526) has broken in dnf 4.6.1 in rosa2019.1, because undoing transaction in dnfdragora does not work:

Event received HistoryUndo, g-io-error-quark: GDBus.Error:org.freedesktop.DBus.Python.AttributeError: Traceback (most recent call last):
  File "/usr/lib64/python3.8/site-packages/dbus/service.py", line 711, in _message_cb
    retval = candidate_method(self, *args, **keywords)
  File "/usr/lib/python3.8/site-packages/dnfdaemon/server/__init__.py", line 68, in newFunc
    rc = func(*args, **kwargs)
  File "/usr/share/dnfdaemon/dnfdaemon-system", line 305, in HistoryUndo
    value = self.history_undo(tid)
  File "/usr/lib/python3.8/site-packages/dnfdaemon/server/__init__.py", line 705, in history_undo
    self.base._history_undo_operations(mobj, old.tid)
AttributeError: 'DnfBase' object has no attribute '_history_undo_operations'
 (36) - status DNFDragoraStatus.RUNNING
BuildTransaction failure

It was removed in dnf 4.6:
Remove Base._history_undo_operations() as it was replaced with transaction_sr code
rpm-software-management/dnf@c826d7db4

ExpireCache seems not to do anything

I would expect the cache to be set as expired and the metadata reloaded, but nothing happens calling ExpireCache

problems using GetConfig with DNF 2.0

As in issue #11 seems that GetConfig has similar problem:

(Pdb) p self.backend.GetConfig("*")
*** dnfdaemon.client.DaemonError: g-io-error-quark: GDBus.Error:org.freedesktop.DBus.Python.AttributeError: Traceback (most recent call last):
  File "/usr/lib64/python3.5/site-packages/dbus/service.py", line 707, in _message_cb
    retval = candidate_method(self, *args, **keywords)
  File "/usr/lib/python3.5/site-packages/dnfdaemon/server/__init__.py", line 83, in newFunc
    rc = func(*args, **kwargs)
  File "/usr/share/dnfdaemon/dnfdaemon-system", line 191, in GetConfig
    value = self.get_config(setting)
  File "/usr/lib/python3.5/site-packages/dnfdaemon/server/__init__.py", line 289, in get_config
    data = [(c, getattr(cfg, c)) for c in cfg.iterkeys()]
AttributeError: 'MainConf' object has no attribute 'iterkeys'
 (36)

while in Fedora without dnf 2.0:

(Pdb) p self.backend.GetConfig("*")
{'proxy': None, 'plugins': True, 'persistdir': '/var/lib/dnf', 'exclude': [], 'rpmverbosity': 'info', 'history_record': True, 'enabled': True, 'password': None, 'pluginconfpath': ['/etc/dnf/plugins'], 'color_list_available_downgrade': 'dim,cyan', 'sslverify': True, 'proxy_password': None, 'color_update_installed': 'normal', 'color_list_available_upgrade': 'bold,blue', 'proxy_username': None, 'minrate': 1000, 'username': None, 'obsoletes': True, 'reset_nice': True, 'sslcacert': None, 'sslclientkey': None, 'bugtracker_url': 'https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=dnf', 'logdir': '/var/log', 'throttle': 0, 'disable_excludes': [], 'color_update_local': 'bold', 'color_list_installed_older': 'bold', 'cachedir': '/var/cache/dnf', 'diskspacecheck': True, 'metadata_timer_sync': 10800, 'strict': True, 'color_update_remote': 'normal', 'metadata_expire': 172800, 'max_parallel_downloads': None, 'assumeno': False, 'debug_solver': False, 'color_list_available_install': 'normal', 'color_list_installed_reinstall': 'normal', 'pluginpath': ['/usr/lib/python3.5/site-packages/dnf-plugins'], 'assumeyes': False, 'installonlypkgs': ['kernel', 'installonlypkg(kernel)', 'installonlypkg(kernel-module)', 'installonlypkg(vm)'], 'recent': 7, 'ip_resolve': None, 'fastestmirror': False, 'defaultyes': False, 'installroot': '/', 'alwaysprompt': True, 'color_list_installed_extra': 'bold,red', 'color_list_available_reinstall': 'bold,underline,green', 'keepcache': False, 'bandwidth': 0, 'color_list_installed_newer': 'bold,yellow', 'tsflags': [], 'include': [], 'repo_gpgcheck': False, 'installonly_limit': 3, 'history_record_packages': ['dnf', 'rpm'], 'color_search_match': 'bold', 'clean_requirements_on_remove': True, 'multilib_policy': 'best', 'enablegroups': True, 'timeout': 120, 'install_weak_deps': True, 'deltarpm': True, 'localpkg_gpgcheck': False, 'debuglevel': 2, 'sslclientcert': None, 'best': False, 'config_file_path': '/etc/dnf/dnf.conf', 'gpgcheck': True, 'reposdir': ['/etc/yum.repos.d', '/etc/yum/repos.d', '/etc/distro.repos.d'], 'color': 'auto', 'errorlevel': 2, 'showdupesfromrepos': False, 'history_list_view': 'commands'}

dnfdaemon fails since updating hawkey

With dnfdaemon 0.3.14-1.fc24 from timlau/yumex-dnf copr, yumex-dnf fails to work. I always get this error message in a dialog:

DNF Dbus backend is not responding

Yum Extender will exit
[Ok]

At the same time, this error message is printed to journal (syslog):

dnfdaemon-system[32010]: python3: /builddir/build/BUILD/hawkey-0.6.3/src/sack.c:568: load_yum_repo: Assertion `hrepo->state_main == _HY_NEW' failed.

A downgrade of hawkey from 0.6.3-2 to 0.6.2-4 makes this problem go away.

support dnf system upgrades and notify users when a new release is available

Based on discussions at

https://lwn.net/Articles/773577/

ConfirmGPGImport seems not to work as expected

I added google-chrome repository (/etc/yum.repos.d/google-chrome.repo) then i used either dnfdragora or yume-dnf to install google-chrome-stable. They correctly ask to get the gpg key from the configured site and provide the related info, but after the transaction is run again the question to get the gpg key is asked again and again.
dnfdragora code is in https://github.com/manatools/dnfdragora/blob/master/dnfdragora/ui.py#L938

Warnings from dnf for using deprecated APIs

When running yumex-dnf, I'm getting this warning a lot:

The 'group_persistor' function is not a part of DNF API and will be removed in the upcoming DNF release. Please use only officially supported API functions. DNF API documentation is available at https://dnf.readthedocs.org/en/latest/api.html.

GetGroups does not return the id = icon name for categories

For categories, the GetGroups D-Bus API (implemented in DnfDaemonBase.get_groups in python/dnfdaemon/server/__init__.py) returns the name instead of the id, the id is lost. This is a problem because the id is needed to look up the correct icon in GUIs, both for the category itself, and for groups within the category that do not have their own icons (where, according to https://fedorahosted.org/comps/ , we are supposed to fall back to the category's icon).

memory leak

I'm using fedora 32

Featurerequest: support changelog feature of dnf

https://bugzilla.redhat.com/show_bug.cgi?id=1066867 has been fixed 3 years ago.
So https://github.com/manatools/dnfdaemon/blob/master/python/dnfdaemon/server/__init__.py#L933-L936 could now be implemented, to make dnfdragora support changelogs on Fedora: manatools/dnfdragora#196

Dnfdeamon ignores Dnf variables!

See:

timlau/yumex-dnf-old#174
manatools/dnfdragora#208

Use system dnf cache?

Every launch of dnfdragora takes quite a lot of time to at least make cache and maybe update metadata, why can't it use system dnf cache without updating it, provided that dnf-makecache.timer is enabled by default? Just to speedup things a lot. Or maybe update metadata in the background.

DNF daemon not recognize any 3rd party repository other than official Fedora repositories !

Hi. Since Fedora received DNF till now Dnfdragora does not recognize any 3rd party repositories. It recognizing only Fedora repositories !

RPMFusion repositories not recognized. Other 3rd party repositories like that of Jami or Retroshare also not recognized !

When I say "not recognized" I mean when new update reach for Fedora package, then dnfdragora notify about this new update. But if package(s) in RPMFusion repositories receive update then dnfdragora not recognize this ! Also when user search about 3rd party repository package by "Alt+S" within dnfdragora search result will either not show package(s) or show it(they) at last line ......

I opened bug about this in dnfdragora GitHub since long time & developer said that this is dnf daemon issue not dnfdragora issue. But since that too long time till now no fix done ! For that I open this issue here.

Kindly your attention.

HistoryUndo crashes

running dnfdragora history undo i got the following error:

File "/usr/lib64/python3.8/site-packages/dbus/service.py", line 711, in _message_cb
    retval = candidate_method(self, *args, **keywords)
  File "/usr/lib/python3.8/site-packages/dnfdaemon/server/__init__.py", line 68, in newFunc
    rc = func(*args, **kwargs)
  File "/usr/share/dnfdaemon/dnfdaemon-system", line 305, in HistoryUndo
    value = self.history_undo(tid)
  File "/usr/lib/python3.8/site-packages/dnfdaemon/server/__init__.py", line 656, in history_undo
    history = dnf.history.open_history(self.base.history)
AttributeError: module 'dnf.history' has no attribute 'open_history'

[RFE] Add support for retrieving Group property from Package

As of hawkey 0.6.3-1, it has been possible to access the "Group" tag information of a package through the Package class. This became available in Fedora with hawkey-0.6.3-2.

In Mageia, we are working on developing applications around dnfdaemon, though unlike Fedora, we actually use RPM Groups. Like SUSE, we use them for visually categorizing packages when being presented through our installer (DrakInstall) or our GUI package management frontend (currently rpmdrake).

We're working on a new tool, dnfdragora, which we're planning on rebasing from the raw DNF API to dnfdaemon. In order for us to fully move over from the raw DNF API to dnfdaemon, we need the ability to retrieve that property so that we can sort packages into their component sections.

While it is not currently mentioned in the DNF API documentation, it is accessible the same way the rest of the properties are (through the Package class), as evidenced by the commit that added it to hawkey.

I'd greatly appreciate it if it was possible to retrieve that information along with the rest of the package properties for populating the GUI via the dnfdaemon API.

problems using GetRepo in dnf 2.0

developing dnfdragora, I found a problem in using GetRepo in Mageia caludron which is currently using DNF 2.0. The same code does not have any problems in my Fedora VM in which DNF is not 2.0.

Mageia output:

(Pdb) p self.backend.GetRepositories("*")      
['backports_testing-i586-debuginfo', 'mageia-x86_64-tainted-source', 'updates_testing-i586-tainted-debuginfo', 'cauldron-x86_64', 'backports-x86_64-tainted-debuginfo', 'cauldron-updates_testing-x86_64-tainted', 'updates-x86_64-tainted-source', 'cauldron-backports_testing-i586-nonfree-debuginfo', 'backports-i586-tainted', 'cauldron-updates-x86_64-debuginfo', 'cauldron-backports-x86_64-source', 'mageia-x86_64-tainted', 'cauldron-x86_64-source', 'cauldron-backports-i586-nonfree', 'updates_testing-i586', 'cauldron-updates_testing-x86_64-source', 'cauldron-updates_testing-i586-debuginfo', 'updates_testing-x86_64-tainted-debuginfo', 'backports-i586', 'cauldron-backports-x86_64-tainted-debuginfo', 'cauldron-backports-x86_64-nonfree', 'cauldron-i586-tainted-debuginfo', 'cauldron-updates-i586', 'cauldron-updates-i586-tainted-debuginfo', 'backports_testing-i586', 'cauldron-updates-x86_64-nonfree-source', 'cauldron-backports-x86_64-nonfree-debuginfo', 'updates_testing-i586-debuginfo', 'cauldron-updates_testing-x86_64-tainted-debuginfo', 'backports-x86_64-tainted-source', 'updates-x86_64-tainted', 'backports-i586-nonfree-debuginfo', 'cauldron-x86_64-nonfree-source', 'cauldron-updates_testing-x86_64', 'mageia-i586-nonfree', 'cauldron-backports-x86_64-tainted-source', 'cauldron-x86_64-debuginfo', 'updates-i586-tainted-debuginfo', 'cauldron-backports_testing-x86_64-debuginfo', 'cauldron-updates_testing-x86_64-nonfree-source', 'backports-x86_64-nonfree', 'mageia-i586-nonfree-debuginfo', 'cauldron-backports_testing-x86_64-nonfree-debuginfo', 'cauldron-i586-nonfree-debuginfo', 'backports-x86_64-tainted', 'backports_testing-x86_64-source', 'cauldron-backports_testing-x86_64-tainted', 'backports_testing-x86_64-nonfree', 'cauldron-backports_testing-i586-nonfree', 'mageia-x86_64-nonfree-debuginfo', 'updates-x86_64-nonfree-source', 'cauldron-updates_testing-i586-tainted-debuginfo', 'cauldron-backports_testing-x86_64-tainted-source', 'cauldron-backports-i586', 'backports-x86_64-nonfree-source', 'backports-i586-tainted-debuginfo', 'backports_testing-x86_64-tainted', 'backports-x86_64', 'updates-i586-tainted', 'cauldron-updates_testing-i586-nonfree-debuginfo', 'cauldron-updates_testing-x86_64-nonfree', 'cauldron-backports_testing-i586-debuginfo', 'cauldron-backports_testing-x86_64-nonfree-source', 'updates_testing-x86_64-debuginfo', 'updates-i586-debuginfo', 'cauldron-updates-i586-nonfree-debuginfo', 'updates-x86_64-source', 'cauldron-x86_64-nonfree-debuginfo', 'updates-i586-nonfree', 'cauldron-updates-x86_64-tainted-debuginfo', 'updates_testing-i586-nonfree-debuginfo', 'updates_testing-x86_64-tainted', 'cauldron-backports_testing-x86_64-source', 'updates_testing-x86_64-nonfree-source', 'cauldron-backports-x86_64-nonfree-source', 'cauldron-backports_testing-i586-tainted', 'cauldron-i586-debuginfo', 'cauldron-backports_testing-x86_64-nonfree', 'updates_testing-x86_64-source', 'mageia-x86_64-nonfree-source', 'cauldron-updates-x86_64', 'cauldron-updates_testing-x86_64-nonfree-debuginfo', 'cauldron-x86_64-nonfree', 'backports_testing-x86_64-nonfree-source', 'ngompa-livecd-creator-mga', 'backports_testing-x86_64-nonfree-debuginfo', 'cauldron-backports_testing-x86_64-tainted-debuginfo', 'cauldron-backports-x86_64-tainted', 'backports_testing-i586-nonfree-debuginfo', 'cauldron-updates_testing-i586-nonfree', 'cauldron-backports-x86_64-debuginfo', 'cauldron-backports_testing-i586-tainted-debuginfo', 'updates-x86_64-tainted-debuginfo', 'backports_testing-x86_64-debuginfo', 'mageia-i586-debuginfo', 'cauldron-updates-x86_64-source', 'updates-x86_64-nonfree-debuginfo', 'mageia-x86_64-nonfree', 'backports-i586-nonfree', 'updates-x86_64-nonfree', 'cauldron-backports-i586-tainted', 'mageia-cauldron-core', 'cauldron-backports-i586-nonfree-debuginfo', 'mageia-x86_64-debuginfo', 'backports_testing-i586-tainted', 'mageia-i586', 'backports-i586-debuginfo', 'cauldron-x86_64-tainted', 'cauldron-updates-i586-tainted', 'updates_testing-i586-tainted', 'cauldron-x86_64-tainted-debuginfo', 'cauldron-x86_64-tainted-source', 'cauldron-updates-i586-nonfree', 'mageia-cauldron-core-debug', 'updates_testing-i586-nonfree', 'cauldron-backports-i586-debuginfo', 'updates-x86_64', 'cauldron-i586-nonfree', 'cauldron-updates_testing-i586', 'cauldron-backports_testing-x86_64', 'cauldron-updates-x86_64-nonfree-debuginfo', 'mageia-x86_64-tainted-debuginfo', 'updates_testing-x86_64-nonfree-debuginfo', 'mageia-x86_64', 'cauldron-updates-i586-debuginfo', 'updates-i586-nonfree-debuginfo', 'backports-x86_64-debuginfo', 'backports_testing-i586-nonfree', 'backports_testing-x86_64', 'updates_testing-x86_64-nonfree', 'updates-x86_64-debuginfo', 'cauldron-updates-x86_64-tainted', 'updates-i586', 'cauldron-updates_testing-x86_64-tainted-source', 'cauldron-backports-x86_64', 'cauldron-backports_testing-i586', 'backports-x86_64-source', 'cauldron-updates_testing-i586-tainted', 'cauldron-updates_testing-x86_64-debuginfo', 'cauldron-updates-x86_64-tainted-source', 'updates_testing-x86_64', 'updates_testing-x86_64-tainted-source', 'backports-x86_64-nonfree-debuginfo', 'mageia-i586-tainted-debuginfo', 'cauldron-backports-i586-tainted-debuginfo', 'mageia-cauldron-core-32', 'mageia-x86_64-source', 'backports_testing-i586-tainted-debuginfo', 'backports_testing-x86_64-tainted-debuginfo', 'mageia-i586-tainted', 'cauldron-i586-tainted', 'backports_testing-x86_64-tainted-source', 'cauldron-updates-x86_64-nonfree', 'cauldron-i586']
(Pdb) p self.backend.GetRepo("cauldron-x86_64")
*** dnfdaemon.client.DaemonError: g-io-error-quark: GDBus.Error:org.freedesktop.DBus.Python.AttributeError: Traceback (most recent call last):
  File "/usr/lib64/python3.5/site-packages/dbus/service.py", line 707, in _message_cb
    retval = candidate_method(self, *args, **keywords)
  File "/usr/lib/python3.5/site-packages/dnfdaemon/server/__init__.py", line 83, in newFunc
    rc = func(*args, **kwargs)
  File "/usr/share/dnfdaemon/dnfdaemon-system", line 223, in GetRepo
    value = self.get_repo(repo_id)
  File "/usr/lib/python3.5/site-packages/dnfdaemon/server/__init__.py", line 306, in get_repo
    repo_conf = dict([(c, getattr(repo, c)) for c in repo.iterkeys()])
AttributeError: 'Repo' object has no attribute 'iterkeys'
 (36)

Fedora output:

(Pdb) p self.backend.GetRepositories("*")
['ngompa-dnfdragora', 'kkofler-dnfdragora', 'updates-source', 'fedora-cisco-openh264-debuginfo', 'fedora', 'fedora-source', 'fedora-cisco-openh264', 'updates-debuginfo', 'ngompa-libyui-qt-test', 'updates-testing-debuginfo', 'updates', 'fedora-debuginfo', 'updates-testing', 'updates-testing-source']
(Pdb) p self.backend.GetRepo("fedora")
{'proxy': None, 'sslcacert': None, 'sslclientcert': None, 'bandwidth': 0, 'exclude': [], 'repo_gpgcheck': False, 'skip_if_unavailable': False, 'enabled': True, 'sslverify': True, 'proxy_password': None, 'timeout': 120, 'proxy_username': None, 'metalink': 'https://mirrors.fedoraproject.org/metalink?repo=fedora-25&arch=x86_64', 'minrate': 1000, 'username': None, 'enablegroups': True, 'sslclientkey': None, 'cost': 1000, 'throttle': 0, 'baseurl': [], 'deltarpm': True, 'priority': 99, 'password': None, 'max_parallel_downloads': None, 'metadata_expire': 604800, 'gpgcheck': True, 'mediaid': None, 'gpgkey': ['file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-x86_64'], 'include': [], 'name': 'Fedora 25 - x86_64', 'ip_resolve': None, 'fastestmirror': False, 'mirrorlist': None}

System service always returns untranslated group names.

The user-visible name (DNF's ui_name) we get from the dnfdaemon system service (in the [1] list entry of any comps group or category) is always returned in English rather than translated. This is strange because DNF itself translates these names, and the DNF API documentation says that these names are translated. But dnfdaemon is not setting the locale appropriately, probably because it is a system service, and I cannot find an API to set it manually.

Should the applications ask the session daemon rather than the system daemon for the groups? Should they set the locale somewhere? (Where?) Yumex-DNF (unmodified Fedora package) and dnfdragora (even after my fix to use the [1] (ui_name) entry in the UI instead of the [0] (id or name) entry) both show me the groups in English whereas the DNF command line shows me German names.

dnfdaemon does not respect vendor pinning and repo priorities

Fedora Asahi Remix sets allow_vendor_change=False in dnf.conf and defines a number of repos with higher priority than the stock Fedora ones. I've noticed that dnfdragora doesn't seem to respect this, for example offering to update uboot-images-armv8 from 2023.07-6 (from https://copr.fedorainfracloud.org/coprs/g/asahi/u-boot) to 1:2023.07-3 (the upstream one from the fedora repo).

Memory leak

On Fedora 27, all up to date, tested on multiple systems. The dnfdaemon-system process just keep growing. It's at almost 800mb right now after about a day or 2.