Bug 2463519

Filed a PR with a fix:

https://src.fedoraproject.org/rpms/gnome-software/pull-request/14

Probably a duplicate of bug 2458182 .

Thanks for a bug report and the patch, I commented on the patch.

Kamil, the article [1], it's a bit misleading. The problem is not `repo_gpgcheck=1`, but that some repos do not have imported their keys. A valid fix (or workaround, if you wish) is to import that key, which can be done by `sudo dnf update`, because dnf asks for the key import on the command line. The repository and its apps uninstallation is inconvenient and unneeded.

[1] https://discussion.fedoraproject.org/t/gnome-software-is-unresponsive-when-a-repository-with-repo-gpgcheck-1-exists/189222

(In reply to Milan Crha from comment #3)
> Kamil, the article [1], it's a bit misleading. The problem is not
> `repo_gpgcheck=1`, but that some repos do not have imported their keys.

That's great feedback, but it doesn't seem to be the case at least on my system. The key seems imported here and the problem persists.

$ cat /etc/yum.repos.d/cursor.repo 
[cursor]
name=Cursor
baseurl=https://downloads.cursor.com/yumrepo
enabled=1
gpgcheck=1
gpgkey=https://downloads.cursor.com/keys/anysphere.asc
repo_gpgcheck=1

$ rpm -q gpg-pubkey --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{SUMMARY}\n' | grep -iE "cursor|anysphere"
gpg-pubkey-380ff4bcdc34a4bd92a3565342a1772e62e492d6-686ffed8	Anysphere Inc <security> public key

$ curl -sL https://downloads.cursor.com/keys/anysphere.asc | gpg --show-keys
pub   rsa4096 2025-07-10 [SC]
      380FF4BCDC34A4BD92A3565342A1772E62E492D6
uid                      Anysphere Inc <security>


I even ran
$ sudo rpm --import 'https://downloads.cursor.com/keys/anysphere.asc'
manually, but no change.

I update through `dnf distro-sync --offline` regularly, didn't see a prompt.

As mentioned in bug 2458182 comment 9 , this is also broken just by running `dnf5daemon-client repoinfo`, so it doesn't seem to be specific to gnome-software.

> I update through `dnf distro-sync --offline` regularly, didn't see a prompt.

Hmm, I do not know how much it's the same as running plain `dnf update`. It probably is the same in this regard. being it so, you probably face a different problem then?

> this is also broken just by running `dnf5daemon-client repoinfo`, so it doesn't seem to be specific to gnome-software.

Right, right, either it's some problem in the dnf5daemon-server, or it's caused by the way the clients use the D-Bus API, like in case of the gnome-software, when it does not respond to the key import questions.

> $ cat /etc/yum.repos.d/cursor.repo 

Nice, I can reproduce it with your repo too. I also verified both distro-sync and update commands ask for the key when it's not imported.

The dnf5damon server is waiting in:

Thread 3 (Thread 0x7f876f7fe6c0 (LWP 4245) "dnf5daemon-serv"):
#0  0x00007f8777c80e92 in __syscall_cancel_arch () at /lib64/libc.so.6
#1  0x00007f8777c750cc in __internal_syscall_cancel () at /lib64/libc.so.6
#2  0x00007f8777c75417 in __futex_abstimed_wait_cancelable64 () at /lib64/libc.so.6
#3  0x00007f8777c780ec in pthread_cond_clockwait () at /lib64/libc.so.6
#4  0x000055c573a842f1 in dnf5daemon::KeyImportRepoCB::repokey_import(libdnf5::rpm::KeyInfo const&) ()
#5  0x00007f877836b00d in libdnf5::repo::RepoPgp::import_key(int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () at /lib64/libdnf5.so.2
#6  0x00007f8778370bfe in libdnf5::repo::RepoSack::Impl::update_and_load_repos(libdnf5::repo::RepoQuery&, bool) [clone .constprop.0] () at /lib64/libdnf5.so.2
#7  0x00007f8778371f36 in libdnf5::repo::RepoSack::load_repos() () at /lib64/libdnf5.so.2
#8  0x000055c573ac479e in Session::read_all_repos() ()
#9  0x000055c573a8f28d in Base::read_all_repos(sdbus::MethodCall&) ()
#10 0x000055c573a92acb in std::thread::_State_impl<std::thread::_Invoker<std::tuple<ThreadsManager::handle_method<Base, true>(Base&, sdbus::MethodReply (Base::*)(sdbus::MethodCall&), sdbus::MethodCall&, std::optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >)::{lambda(Base&, sdbus::MethodReply (Base::*)(sdbus::MethodCall&), sdbus::MethodCall, std::optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >)#1}, std::reference_wrapper<Base>, sdbus::MethodReply (Base::*)(sdbus::MethodCall&), sdbus::MethodCall, std::optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > >::_M_run() ()
#11 0x00007f8777e51eb6 in execute_native_thread_routine () at /lib64/libstdc++.so.6
#12 0x00007f8777c787b9 in start_thread () at /lib64/libc.so.6
#13 0x00007f8777cfcacc in __clone3 () at /lib64/libc.so.6

Thread 2 (Thread 0x7f876effd6c0 (LWP 4246) "dnf5daemon-serv"):
#0  0x00007f8777c80e92 in __syscall_cancel_arch () at /lib64/libc.so.6
#1  0x00007f8777c750cc in __internal_syscall_cancel () at /lib64/libc.so.6
#2  0x00007f8777c75417 in __futex_abstimed_wait_cancelable64 () at /lib64/libc.so.6
#3  0x00007f8777c77c6c in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libc.so.6
#4  0x00007f8777e480e0 in std::condition_variable::wait(std::unique_lock<std::mutex>&) () at /lib64/libstdc++.so.6
#5  0x00007f87783788d0 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<libdnf5::repo::RepoSack::Impl::update_and_load_repos(libdnf5::repo::RepoQuery&, bool)::{lambda()#1}> > >::_M_run() [clone .lto_priv.0] () at /lib64/libdnf5.so.2
#6  0x00007f8777e51eb6 in execute_native_thread_routine () at /lib64/libstdc++.so.6
#7  0x00007f8777c787b9 in start_thread () at /lib64/libc.so.6
#8  0x00007f8777cfcacc in __clone3 () at /lib64/libc.so.6

Can you reproduce the problem even when the key is correctly imported?

On my system,

/var/cache/libdnf5/redacted-redacted/pubring

exists, but

/var/cache/dnf5daemon-server/redacted-redacted/pubring

does not.

So this may not be related to `rpm --import`; the daemon appears to use a separate cache/keyring location. I am not completely sure yet, but that difference seems relevant.

> Can you reproduce the problem even when the key is correctly imported?

Yeah, the backtrace is from the time when it was imported for the dnf command line.

> So this may not be related to `rpm --import`

I've been told, and the last time I tried it, the keys are in `rpmkeys -l` and when I've been testing the key import prompt in the dnf5 gnome-software plugin I used the rpmkeys to trigger it (I simply removed the keys). It's some time ago though, it can be the dnf5 changed something meanwhile, which splits the rpm keys or anything else.

Fix from Byoungchan [1] on the gnome-software side helps:

10:06:39:412 GsDnf5 gs_dnf5_repo_key_import_request_cb: key_id:'62E492D6' user_ids:["Anysphere Inc <security>"] key_fingerprint:'380FF4BCDC34A4BD92A3565342A1772E62E492D6' key_url:'https://downloads.cursor.com/keys/anysphere.asc' timestamp:1752170200
10:06:39:412 GsDnf5 gs_dnf5_repo_key_import_request_cb: rejecting non-interactive repository key import request for key '62E492D6'

With it gnome-software starts flawlessly.

[1] https://gitlab.gnome.org/mcrha/gnome-software/-/merge_requests/1

(In reply to Byoungchan Lee from comment #8)
Not sure if it's expected or not, but I can confirm the same on my system:

$ ls /var/cache/libdnf5/cursor-57cee92e3e966e02/pubring/
42A1772E62E492D6.pub
$ ls /var/cache/dnf5daemon-server/cursor-57cee92e3e966e02/pubring
ls: cannot access '/var/cache/dnf5daemon-server/cursor-57cee92e3e966e02/pubring': No such file or directory
$ ls /var/cache/dnf5daemon-server/cursor-57cee92e3e966e02/
repodata  solv

Like I mentioned in previous comments, I think the best fix is to make both sides defensive: the server (`dnf5daemon`) and clients (`dnf5daemon-client`, GNOME Software, and so on).

I also reproduced the `dnf5daemon-client repoinfo` hang, captured a stack trace, and found two related issues:

- On the client side, `dnf5daemon-client repoinfo` makes a synchronous D-Bus call. This is similar to the GNOME Software refresh case: the call can trigger a repository key-import request, but the client is blocked waiting for the original method reply and cannot handle the prompt path, so it cannot make progress.

- On the server side, the daemon can ask for interactive confirmation even when the client may not be able to handle it.

I made two commits and uploaded a draft PR here:
https://github.com/rpm-software-management/dnf5/pull/2716

Since this changes `dnf5daemon` behavior, I am not fully sure whether the changes are valid in terms of D-Bus API contract or compatibility, so I opened it as a draft.
From my testing, either side of the fix is enough to avoid the `dnf5daemon-client repoinfo` hang, but they address different parts of the same failures.

FEDORA-2026-64904d9210 (gnome-software-50.1-3.fc44) has been submitted as an update to Fedora 44.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-64904d9210

FEDORA-2026-64904d9210 has been pushed to the Fedora 44 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-64904d9210`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-64904d9210

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Unfortunately this doesn't help in my case. GS still takes 5 minutes to load the app icons on the welcome screen.

From the verbose log:

07:10:58:723 GsPluginFlatpak org.winehq.Wine.mono needs update
07:10:58:723 OSTree using fuse: 0
07:10:58:723 flatpak Checking installation ‘user’ for EOL unused refs and autoprunes
07:10:58:723 flatpak Checking installation ‘user’ for EOL unused refs and autoprunes
07:10:58:723 OSTree using fuse: 0
07:15:01:287 Gs  Setting I/O priority of thread 0x55bc79fc8ec0 to IDLE, 7
07:15:01:287 GsDnf5 Using existing session
07:15:01:287 Gs  Setting I/O priority of thread 0x55bc79fa2c10 to IDLE, 7
07:15:01:287 Gs  Downloading 2 icons for app org.gnome.Polari
07:15:01:287 GsPluginMalcontent No OARS ratings provided for ‘*/*/*/app.drey.Dialect/*’: assuming most extreme
07:15:01:287 GsPluginMalcontent No OARS ratings provided for ‘*/*/*/de.haeckerfelix.Fragments/*’: assuming most extreme

Created attachment 2138845 [details]
GS verbose log

Icons have nothing to do with pgp keys, the less with the dnf5 (or PackageKit) plugin. You rather mean:
https://gitlab.gnome.org/GNOME/gnome-software/-/work_items/2966

The log shows the Software does download the icons, one by one, but it may want a lot of icons, thus those you look at can be "at the end of the queue". Some failed, but most had been downloaded.

Sorry, that was confusing. I said icons, but I meant "nothing changed, gnome-software is still completely blank and none of the pages work". I meant this:
https://gitlab.gnome.org/GNOME/gnome-software/-/work_items/2975
And similarly, every other page has just white rectangles with three dots, or infinite spinners, until 5 minutes pass, and then it starts working. As seen from the log.

Unfortunately the log does not show what it is trying to do between those 5 minutes:

   07:10:58:723 flatpak Checking installation ‘user’ for EOL unused refs and autoprunes
   07:10:58:723 OSTree using fuse: 0
   07:15:01:287 Gs  Setting I/O priority of thread 0x55bc79fc8ec0 to IDLE, 7
   07:15:01:287 GsDnf5 Using existing session

The dnf5 plugin is not much verbose in logging.

I understood you are a bit more further in the process, as before it has got stuck within "Refreshing metadata", while this time you see the Explore page and the others, just the icons are an indication that the app is waiting for something. Is that correct?

Could you get a backtrace of the gnome-software process, please?

   DEBUGINFOD_URLS='' gdb --batch --ex "t a a bt" --pid=`pidof gnome-software` &>bt.txt

It will show what it's doing. The log shows only three related GsDnf5 lines in the log for the first five minutes, where the pasted line above is the third.

I just re-tried with gnome-software-50.1-3.fc44.x86_64 and I cannot reproduce it, while with 50.1-2 I can. I have your repo set, but I do not have anything installed from it.

Created attachment 2138867 [details]
bug demonstration video

I have recorded a video so that you can understand exactly how GS behaves while being stuck. In my previous log file, I wasn't doing anything, I kept it waiting on the home screen, and exactly 5 minutes later, it comes to live and suddenly everything works. In this video, I explore all the tabs, which does print new lines into the log. I can collect that log if you want and upload it here.

I'll try to collect the backtrace as well.

Backtrace of gnome-software and dnf5daemon-server processes will be the best. The log is useless in this case.

I've tested a clean F44 VM with default F44 Workstation install, updated to latest stable updates. Installed cursor-3.2.16.el8.x86_64.rpm there from vendor website (which adds the repo during installation). Ran a "dnf update", which asked to add the cursor gpg key, I did. With gnome-software-0:50.1-2, the GS interface was unusable. After updating to gnome-software-0:50.1-3, it works perfectly. Interesting, there must be something else on my production setup.

Furthermore, I'm baffled that in the VM, I don't see the cursor gpg key listed, even though I confirmed adding it:

$ rpmkeys -l
36f612dcf27f7d1a48a835e4dbfcf71c6d9f90a6 Fedora (44) <fedora-44-primary> public key
$ rpm -q gpg-pubkey --qf '%{SUMMARY}: %{VERSION}-%{RELEASE}\n'
Fedora (44) <fedora-44-primary> public key: 36f612dcf27f7d1a48a835e4dbfcf71c6d9f90a6-6786af3b

But on my production system, it's there (comment 4).

Created attachment 2138870 [details]
backtrace while GS UI is non-functional

Here's the requested backtrace from GS while it's non-functional on my production system.

Created attachment 2138871 [details]
backtrace from dnf5daemon-server

This is from dnf5daemon-server, taken half a minute later. (I can do better next time, if needed).

Thanks for the backtraces. I see it's the same problem, the dnf5daemon-server is waiting for a response from the client(s) on the key import, but gnome-software is in "list" call, checking for packages, which I'd not expect to also need to import the key. I'm investigating further.

There seem to be two incompatible storage areas for GPG keys:

Machine 1 - a key added through rpm --import is not seen by DNF:

$ rpmkeys -l
36f612dcf27f7d1a48a835e4dbfcf71c6d9f90a6 Fedora (44) <fedora-44-primary> public key

$ sudo rpm --import 'https://downloads.cursor.com/keys/anysphere.asc'

$ rpmkeys -l
380ff4bcdc34a4bd92a3565342a1772e62e492d6 Anysphere Inc <security> public key
36f612dcf27f7d1a48a835e4dbfcf71c6d9f90a6 Fedora (44) <fedora-44-primary> public key
$ sudo dnf update
Updating and loading repositories:
 Cursor                                                                                             100% |   6.7 KiB/s |   4.3 KiB |  00m01s
>>> repomd.xml GPG signature verification error: Signing key not found
 https://downloads.cursor.com/keys/anysphere.asc                                                    100% |   4.0 KiB/s |   1.6 KiB |  00m00s
Importing OpenPGP key 0x62E492D6:
 UserID     : "Anysphere Inc <security>"
 Fingerprint: 380FF4BCDC34A4BD92A3565342A1772E62E492D6
 From       : https://downloads.cursor.com/keys/anysphere.asc
Is this ok [y/N]:


Machine 2 - a key added through DNF is not seen by rpmkeys:

$ rpmkeys -l
36f612dcf27f7d1a48a835e4dbfcf71c6d9f90a6 Fedora (44) <fedora-44-primary> public key

$ sudo dnf update
Updating and loading repositories:
 Cursor                                                                                             100% |   4.8 KiB/s |   4.3 KiB |  00m01s
>>> repomd.xml GPG signature verification error: Signing key not found
 https://downloads.cursor.com/keys/anysphere.asc                                                    100% |   8.7 KiB/s |   1.6 KiB |  00m00s
Importing OpenPGP key 0x62E492D6:
 UserID     : "Anysphere Inc <security>"
 Fingerprint: 380FF4BCDC34A4BD92A3565342A1772E62E492D6
 From       : https://downloads.cursor.com/keys/anysphere.asc
Is this ok [y/N]: y
The key was successfully imported.
 Cursor                                                                                             100% | 164.6 KiB/s | 174.5 KiB |  00m01s
Repositories loaded.
Nothing to do.

$ rpmkeys -l
36f612dcf27f7d1a48a835e4dbfcf71c6d9f90a6 Fedora (44) <fedora-44-primary> public key



I don't know whether it can explain why some machines are still affected by this bug, and some are not, but I suppose it could.

(In reply to Kamil Páral from comment #27)
> There seem to be two incompatible storage areas for GPG keys:

Reported as bug 2464087

With this PR, GS works great for me:
https://github.com/rpm-software-management/dnf5/pull/2717

*** Bug 2464668 has been marked as a duplicate of this bug. ***

FEDORA-2026-64904d9210 has been pushed to the Fedora 44 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-64904d9210`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-64904d9210

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2026-64904d9210 (gnome-software-50.1-4.fc44) has been pushed to the Fedora 44 stable repository.
If problem still persists, please make note of it in this bug report.