Bug 2011322 - Discover doesn't seem to find any RPM packages, neither locally installed nor in RPM repos (but just under en_US locale)
Summary: Discover doesn't seem to find any RPM packages, neither locally installed nor...
Alias: None
Product: Fedora
Classification: Fedora
Component: plasma-discover
Version: 35
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F35FinalBlocker
TreeView+ depends on / blocked
Reported: 2021-10-06 12:12 UTC by Kamil Páral
Modified: 2021-10-26 22:11 UTC (History)
10 users (show)

Fixed In Version: plasma-discover-5.23.0-3.fc35
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-10-26 07:37:01 UTC
Type: Bug

Attachments (Terms of Use)
empty search results (37.40 KB, image/png)
2021-10-06 12:13 UTC, Kamil Páral
no flags Details
no installed apps (36.81 KB, image/png)
2021-10-06 12:13 UTC, Kamil Páral
no flags Details
all offered apps are flatpaks (145.17 KB, image/png)
2021-10-06 12:13 UTC, Kamil Páral
no flags Details
journal (268.49 KB, text/plain)
2021-10-06 12:13 UTC, Kamil Páral
no flags Details
rpm -qa (60.40 KB, text/plain)
2021-10-06 12:13 UTC, Kamil Páral
no flags Details
Unable to load applications (238.47 KB, image/png)
2021-10-07 11:41 UTC, Lukas Ruzicka
no flags Details
video from discover finding rpms at F35 kde (7.84 MB, application/x-matroska)
2021-10-11 11:42 UTC, Geraldo Simião
no flags Details
appstream-0.14.6-1.fc35 fixed the issue (421.00 KB, image/png)
2021-10-18 23:15 UTC, Geraldo Simião
no flags Details

Description Kamil Páral 2021-10-06 12:12:28 UTC
Description of problem:
When I open Discover, I can't find any RPM package in it. If I look into Installed, it says "Nothing found". If I try to search for a package, e.g. "homebank" or "soundconverter" or "frozen bubble", etc, it says "Nothing found". Sometimes (e.g. when searching for "nautilus") it shows some icons and themes from KDE addons website. But no RPM package. If I go to "Applications" category, I can see some apps that I can install, but all of those are flatpaks. Again, no RPM packages.

It seems Discover forgot how to discover 95% of content of the Fedora distribution...

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. install a clean F35 KDE
2. open Discover
3. search for some apps like "homebank", nothing found (compare to dnf or gnome-software)
4. look into Installed, empty
5. look into Applications, only flatpaks

Comment 1 Kamil Páral 2021-10-06 12:13:00 UTC
Created attachment 1829819 [details]
empty search results

Comment 2 Kamil Páral 2021-10-06 12:13:16 UTC
Created attachment 1829820 [details]
no installed apps

Comment 3 Kamil Páral 2021-10-06 12:13:30 UTC
Created attachment 1829821 [details]
all offered apps are flatpaks

Comment 4 Kamil Páral 2021-10-06 12:13:34 UTC
Created attachment 1829822 [details]

Comment 5 Kamil Páral 2021-10-06 12:13:39 UTC
Created attachment 1829823 [details]
rpm -qa

Comment 6 Kamil Páral 2021-10-06 12:14:12 UTC
Proposing for a blocker discussion under https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Default_application_functionality

Comment 7 Adam Williamson 2021-10-06 17:31:58 UTC
well, if confirmed, isn't this an obvious blocker per Beta "The installed system must be able appropriately to install, remove, and update software with the default tool for the relevant software type in all release-blocking desktops (e.g. default graphical package manager). This includes downloading of packages to be installed/updated." ? https://fedoraproject.org/wiki/Fedora_35_Beta_Release_Criteria#Installing.2C_removing_and_updating_software

Comment 8 Lukas Ruzicka 2021-10-07 10:38:46 UTC
I can confirm this behaviour, but it only happened when I fully updated the KDE system.
I have downloaded the 20211006 iso and installed it. After the installation, Discover was showing applications. I used it to update the system, and after it got updated and restarted, I am getting the behaviour described in this bug.

Comment 9 Kamil Páral 2021-10-07 11:30:11 UTC
I tried again, to verify what Lukas said. And it's a bit different and even more broken :-D Right after a clean install, you can't search for an RPM, that doesn't work. But Installed tab indeed shows applications. Funnily enough, it doesn't show *installed* applications, it shows available updates ;-D And so once you fully update (or disable updates-testing - my case), you see empty Installed, because there are no available updates... :-D

Comment 10 Lukas Ruzicka 2021-10-07 11:40:53 UTC
Yes, when I tried for second time, I could spot what Kamil describes. I would also point out, that even after a clean installation, only Flatpaks are available for installation.

There is one more glitch -> when Discover is started, it claims that "Unable to load applications. Please verify Internet connectivity". Internet connection works normally though. It seems that it even works for Discover as updates can be downloaded and applied.

See screenshot.

Comment 11 Lukas Ruzicka 2021-10-07 11:41:26 UTC
Created attachment 1830333 [details]
Unable to load applications

Comment 12 Kamil Páral 2021-10-07 12:21:48 UTC
(In reply to Lukas Ruzicka from comment #10)
> There is one more glitch -> when Discover is started, it claims that "Unable
> to load applications. Please verify Internet connectivity".

That is bug 1976661.

Comment 13 Adam Williamson 2021-10-07 19:37:29 UTC
+3 in https://pagure.io/fedora-qa/blocker-review/issue/515 , marking accepted. Do we know if this persists with 5.23?

Comment 14 Adam Williamson 2021-10-08 00:13:34 UTC
I did try to test this, but I couldn't exactly reproduce it with 5.22.0, so I'm not really sure if it's fixed. I did not observe the described behaviour in 5.23.0, though.

Comment 15 Geraldo Simião 2021-10-10 02:34:15 UTC
I think plasma-discover-5.23.0-1.fc35.x86_64 fixes this bug too.

Comment 16 Geraldo Simião 2021-10-10 11:54:55 UTC
bug fixed here:



Comment 17 Kamil Páral 2021-10-11 10:07:37 UTC
I'm interested how exactly you can't reproduce this or how you see it fixed. With plasma-discover-5.23.0-1.fc35.x86_64, in my VM, the Installed tab still shows available updates instead of installed apps (see comment 9), all items in Applications tab are Flatpaks, and it can't search for any RPM (only shows Flatpaks, if there are some).

Comment 18 Geraldo Simião 2021-10-11 11:42:25 UTC
Created attachment 1831849 [details]
video from discover finding rpms at F35 kde

Version-Release number of components same as comment #16
Fedora-Workstation-Live-x86_64-35_Beta-1.2.iso wtih latest updates

Comment 19 Geraldo Simião 2021-10-11 11:50:14 UTC
(In reply to Geraldo Simião from comment #18)
> Created attachment 1831849 [details]
> video from discover finding rpms at F35 kde
> Version-Release number of components same as comment #16
> Fedora-Workstation-Live-x86_64-35_Beta-1.2.iso wtih latest updates

Sorry ==> Fedora-KDE-Live-x86_64-35_Beta-1.2.iso with latest updates, not workstation ;)

Comment 20 Adam Williamson 2021-10-11 17:45:41 UTC
I just tested again, and none of the things Kamil described are true in the VM I'm testing on (mostly updated F35, with plasma-discover 5.23.0). The 'Installed' tab shows installed packages for me (e.g. it starts with abrt and abrt-addon-ccpp), the Applications tab shows packaged things with "Install" buttons (e.g. Transmission, GParted) along with Flatpaks with "Install from Flatpak" buttons, and searching for 'gedit' finds it as an RPM package.

Comment 21 Mattia Verga 2021-10-12 06:59:39 UTC
I had the same problem on a fresh install of F34 from a netinst ISO. See #1976661

In my case the problem was solved after the update of PackageKit to 1.2.4-2 which it seems to not be in F35Beta.

Comment 22 Kamil Páral 2021-10-12 07:38:15 UTC
I believe I found the difference. I performed the following today:

VM #1:
1. Install a clean system from Fedora-KDE-Live-x86_64-35-20211011.n.0.iso [1].
2. Boot the system and run "dnf distrosync --refresh" [2].
3. Reboot, run plasma-discover and test it.
-> BROKEN plasma-discover (as summarized in comment 17).

VM #2:
1. Install a clean system from Fedora-KDE-Live-x86_64-35_Beta-1.2.iso [3].
2. Boot the system and run "dnf distrosync --refresh" [2].
3. Reboot, run plasma-discover and test it.
-> WORKING plasma-discover (Installed tab, Applications browsing and searching, even the Featured tab!)

[1] https://kojipkgs.fedoraproject.org/compose/branched/Fedora-35-20211011.n.0/compose/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-35-20211011.n.0.iso
[2] I didn't want to introduce additional possible functionality changes by updating the system using the older plasma-discover.
[3] https://dl.fedoraproject.org/pub/alt/stage/35_Beta-1.2/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-35_Beta-1.2.iso

So, Adam, Geraldo, I believe your system is functional because it is updated. Please install a fresh one from the latest ISO (follow the steps above) and I believe you'll also reproduce this bug.

Comment 23 Lukas Ruzicka 2021-10-12 11:26:09 UTC
Not happy about it, but I have to agree with Kamil here. When following the VM#1 Setup steps, I can see exactly the same behaviour as he is describing in comment #17.

Comment 24 Adam Williamson 2021-10-12 17:09:47 UTC
I did use a fairly recent nightly to deploy my test VM, I didn't use the Beta. I believe it would have been Fedora-KDE-Live-x86_64-35-20211005.n.0.iso . I'll try it again, though.

Comment 25 Geraldo Simião 2021-10-13 14:45:10 UTC
ok, I will try two approaches today (with Fedora-KDE-Live-x86_64-35-20211011.n.0.iso and with Fedora-KDE-Live-x86_64-35-20211012.n.0.iso) without any changes, to see if the two new builds work the same here at my VMs.
but, before I do that, just one observation: doesn't "system is functional because it is updated" assume that with the right package updates, the bug is fixed?

Comment 26 Adam Williamson 2021-10-13 16:14:42 UTC
Nope, still can't reproduce. I did this:

1. Install a clean system from Fedora-KDE-Live-x86_64-35-20211012.n.0.iso (creating user 'test' as an admin, no root password)
2. Boot, log in as 'test', run 'sudo su' then 'dnf --refresh distro-sync'
3. Reboot, log in as 'test' again, run plasma-discover
-> WORKING plasma-discover.

Comment 27 Geraldo Simião 2021-10-13 19:00:32 UTC
sooo, I tested both ISOs (Fedora-KDE-Live-x86_64-35-20211011.n.0.iso and Fedora-KDE-Live-x86_64-35-20211012.n.0.iso) and installed them both ways on VM (without root user, and with root and adm users) and in all cases the bug shows itself. 
I tried distro-sync, tried to enable root user after install on the VMs I choose anaconda not to use root, then reboot, tried to upgrade all packages, but allways discover showed the bahavior described by Kamil.

It's really strange that on the ISO 35-20211012.n.0 live session discover worked correctly, but after installation and reboot, it doesn't.

Comment 28 Geraldo Simião 2021-10-13 20:19:40 UTC
sooo (nº 2), another piece for the mistery:
I tried again another installation of the same Fedora-KDE-Live-x86_64-35-20211012.n.0.iso on a VM here, this time doing exactly as I usaly do on my VMs (selecting portuguese Brazil as language and only keyboar layout, because the last two installations  I chosed English US as language and English and PT_BR as keyboards) and this time DISCOVER WORKED FINE after install, without any upgrades or changes.

SUMMARY: with the same Fedora-KDE-Live-x86_64-35-20211012.n.0.iso, at KVM/quemu/virt-manager UEFI - with 4cpus, 4GB ram, virtio video, system locale: LANG=pt_BR.UTF-8 VC keymap: br X11 layout: br, at plasma-wayland session of a admin user (and with root user created at installation by anaconda) PLASMA-DISCOVER WORKS

Comment 29 Geraldo Simião 2021-10-13 20:21:20 UTC
this all seem so random...

Comment 30 Geraldo Simião 2021-10-13 21:36:48 UTC
sooo (nº3)
Now I installed in portuguese brazil, and with no root user, not even clicked on the option at anaconda, only the admin user as habitual.
Used the same ISO and same VM settings: Fedora-KDE-Live-x86_64-35-20211012.n.0.iso

DISCOVER WORKED NORMALY after installation, right out of the box, no updates.

My timezone here is Brazil São Paulo.

Comment 31 Geraldo Simião 2021-10-14 19:54:03 UTC
tested again today, with  Fedora-KDE-Live-x86_64-35-20211014.n.0.iso 
at live-session discover didn't worked, bug present.
after installation (using pt_BR.UTF-8) discover worked just fine, no bugs.

Comment 32 Kamil Páral 2021-10-18 10:05:22 UTC
Geraldo, bingo! This is locale-dependent! I installed Fedora-KDE-Live-x86_64-35-20211017.n.0.iso with a default en_US locale (as always) and plasma-discover was broken. But when I close the app, and run it again under a different locale, it works!

$ LC_ALL="en_US.UTF-8" plasma-discover
-> broken
$ LC_ALL="en_GB.UTF-8" plasma-discover
-> works
$ LC_ALL="en_CA.UTF-8" plasma-discover
-> works
$ LC_ALL="cs_CZ.UTF-8" plasma-discover
-> works
$ LC_ALL="pt_BR.UTF-8" plasma-discover
-> works

Adam, do you perhaps use some other locale than en_US as well? That would explain why it is working for you.

Comment 33 Adam Williamson 2021-10-18 15:14:51 UTC
aha, yeah, I'll be using en_CA because of geolocation.

Aleix, since you've been kind enough to look at the other Discover blockers for us, do you have any ideas on this one, now we've sorted out the cause? The bug is as described in the original description and comment #17, with the additional information that it *only* seems to happen in the US locale (see comment #32). Thanks!

Comment 34 Geraldo Simião 2021-10-18 17:47:23 UTC
(In reply to Kamil Páral from comment #32)
> Geraldo, bingo! This is locale-dependent! 

Great, not so random anymore. 

Comment 35 Adam Williamson 2021-10-18 21:03:13 UTC
So yep, I can reproduce this on F35 using LC_ALL="en_US.UTF-8".

I also just tested Rawhide, and I do *not* see the bug there. So, something between current stable F35 and current Rawhide fixes it, it seems.

Comment 36 Adam Williamson 2021-10-18 21:09:53 UTC
I believe the bug may be fixed by appstream 0.14.6. At least, after updating it on my VM the bug seemed to go away.

Can folks please try updating all installed appstream packages to 0.14.6 from this scratch build:


and see if it solves the problem? Thanks!

Comment 37 Fedora Update System 2021-10-18 21:43:22 UTC
FEDORA-2021-ba9eb4f7b1 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-ba9eb4f7b1

Comment 38 František Zatloukal 2021-10-18 22:14:10 UTC
FEDORA-2021-ba9eb4f7b1 fixes the issue.

Comment 39 Geraldo Simião 2021-10-18 23:11:07 UTC
Yes,appstream-0.14.6-1.fc35 fixed the bug!!!!!

Comment 40 Geraldo Simião 2021-10-18 23:15:58 UTC
Created attachment 1834430 [details]
appstream-0.14.6-1.fc35 fixed the issue

Fedora-KDE-Live-x86_64-35-20211014.n.0.iso with 
locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8"...
Bug fixed

Comment 41 Kamil Páral 2021-10-19 07:17:47 UTC
(In reply to František Zatloukal from comment #38)
> FEDORA-2021-ba9eb4f7b1 fixes the issue.

Confirmed by me as well.

Comment 42 Aleix Pol 2021-10-19 13:49:05 UTC
👍 like I told you yesterday somewhere, libappstream seemed to be the one at fault, so the fact that a newer version fixes it makes sense. Thanks!

Comment 43 Adam Williamson 2021-10-19 16:19:31 UTC
Oh dear. Bad news.

I just saw this bug on my Rawhide VM. Which has appstream 0.14.6-1.

So, apol and I wonder if it's not exactly that appstream 0.14.6 fixes it. Rather, appstream runs `/usr/bin/appstreamcli refresh --force` in its %posttrans script, and we think doing that 'solves' the problem (at least for a while, apparently). Then I guess, somehow, some metadata goes 'out of sync' again and the problem comes back?

I ran `appstreamcli refresh --force` manually and the problem was 'solved' again. I guess until tomorrow. Grr.

Comment 44 Adam Williamson 2021-10-19 19:14:45 UTC
So I looked into the actual cache file situation a bit here. It's sort of interesting.

After a fresh install from a current KDE live (including appstream 0.14.6-1) *using the English (Canada) locale*, a /var/cache/app-info/cache/en_US.cache exists. It's quite tiny: 167936 bytes. There is no /var/cache/app-info/cache/en_CA.cache , and ~/.cache/appstream does not exist yet.

When I first run plasma-discover in en_CA locale, ~/.cache/appstream/system/en_CA.cache (and all parent dirs, obviously) is created. The bug does not happen. After exit, that cache file persists.

If I then run `LC_ALL=en_US.UTF-8 plasma-discover`, *that file is removed*. No ~/.cache/appstream/system/en_US.cache is created. The bug happens.

If I run plasma-discover in default (en_CA) locale again, ~/.cache/appstream/system/en_CA.cache is re-created and the bug does not happen.

The /var/cache/app-info/cache/en_US.cache file is odd; its timestamp is Oct 18 15:03, while the current system time is Oct 19 11:56 and I only installed the system within the last hour or two. But it's not listed as owned by a package. So I'm not sure how it comes to exist with such a timestamp.

If I move that file out of the way and run `LC_ALL=en_US.UTF-8 plasma-discover` again, a ~/.cache/appstream/system/en_US.cache is created, and the bug doesn't happen.

If I then move `/var/cache/app-info/cache/en_US.cache` back into place and run `LC_ALL=en_US.UTF-8 plasma-discover` again, the bug happens again, and ~/.cache/appstream/system/en_US.cache is *deleted*.

If I run `appstreamcli refresh --force` as root, a /var/cache/app-info/cache/en_CA.cache is created. It's much larger than /var/cache/app-info/cache/en_US.cache - 19660800 bytes. After this, the bug still happens in en_US locale, and doesn't happen in en_CA locale, but ~/.cache/appstream/system/en_CA.cache is no longer created when I run the app.

If I force a reinstall of the appstream package, a /var/cache/app-info/cache/en_CA.cache just as if I'd run `appstreamcli refresh --force` manually (note: it does *not* create a US locale cache, though that seemed a possibility).


1. If there's a cache file for the relevant locale in /var/cache/app-info/cache/ , we seem to wind up just using it, even if it's broken or incomplete(?)
2. When the system is first installed in a non-US locale, there won't be such a cache file, but one will likely be created sometime after system install, either by an update of the appstream package or by a package being installed which contains a file in %{_datadir}/app-info/xmls (which will cause a trigger in appstream to run `appstreamcli refresh --force`)
3. We're seeing the bug for the US locale immediately after installation because, somehow, during install we deploy a /var/cache/app-info/cache/en_US.cache which seems pretty clearly to be broken and/or incomplete.
4. The bug may possibly happen for other locales some time after installation if a /var/cache/app-info/cache/(locale).cache is created which is *initially* correct but then goes stale?

Comment 45 Fedora Update System 2021-10-19 23:09:20 UTC
FEDORA-2021-1949dabf93 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-1949dabf93

Comment 46 Adam Williamson 2021-10-19 23:16:58 UTC
So for the record, the update does this:


the idea is to set flags that tell appstream not to use the system cache when we're (re)loading appstream data. This is kind of a blunt instrument, but my suspicion is that whatever cases there are where this bug can happen, they involve things going wrong with the system cache. Just using the user cache should reduce the number of potential paths and hopefully avoid the problems. I can see some potentially questionable paths in the upstream appstream code that deals with the various levels of cache, but I don't want to start fiddling with those at this point.

I am a *bit* worried that this isn't the whole story, given that I think I saw the issue fleetingly on my Rawhide VM this morning in a scenario where a system cache shouldn't have been involved. It'd be good if, after initially testing the fix on a fresh install, folks could keep the VM around and re-test periodically over the next couple of days...

I did build a live image with the new update included and run the standard test on that - install, boot installed system, run `LC_ALL=en_US.UTF-8 plasma-discover` - and it worked. So I think it does at least help.

Comment 47 Kamil Páral 2021-10-20 06:47:46 UTC
(In reply to Fedora Update System from comment #45)
> FEDORA-2021-1949dabf93 has been submitted as an update to Fedora 35.
> https://bodhi.fedoraproject.org/updates/FEDORA-2021-1949dabf93

This seems to work right now, let's see if it still works tomorrow (I'm keeping the VM).

Comment 48 Geraldo Simião 2021-10-20 10:33:09 UTC
(In reply to Fedora Update System from comment #45)
> FEDORA-2021-1949dabf93 has been submitted as an update to Fedora 35.
> https://bodhi.fedoraproject.org/updates/FEDORA-2021-1949dabf93

Confirmed, working here too.

Comment 49 Adam Williamson 2021-10-20 16:47:03 UTC
CCing rhughes in case he happens to have any thoughts about the appstream angle here. From that perspective, the code I'm kinda looking questioningly at is the interaction between `as_pool_load_collection_data()` and `as_pool_refresh_system_cache()` in https://github.com/ximion/appstream/blob/master/src/as-pool.c , especially how things work around https://github.com/ximion/appstream/blob/master/src/as-pool.c#L796-L814 . It seems to me there are at least potentially some scenarios where `as_pool_refresh_system_cache()` can go quite badly wrong but still return TRUE, and in these cases `as_pool_load_collection_data()` can wind up doing `system_cache_used = TRUE;` even if it really shouldn't be using the system cache...

Comment 50 Fedora Update System 2021-10-21 23:17:45 UTC
FEDORA-2021-1949dabf93 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 51 Kamil Páral 2021-10-25 09:16:56 UTC
We still need a few confirmations from systems which were running for a few days and not cleanly installed...

Comment 52 Kamil Páral 2021-10-25 11:57:22 UTC
My long-term VM with plasma-discover seems to work OK, all the Featured/Installed/etc pages show RPM packages correctly.

Can anyone else confirm it has been working fine?

Comment 53 Geraldo Simião 2021-10-25 22:00:52 UTC
(In reply to Kamil Páral from comment #52)

> Can anyone else confirm it has been working fine?

Yeah, here too on the same VM I last confirmed the bug occured only on en_US, doesn't see the problem anymore for a while.

Comment 54 Kamil Páral 2021-10-26 07:37:01 UTC

Comment 55 Adam Williamson 2021-10-26 22:11:40 UTC
So the fix here was kinda a workaround, we shouldn't forget to try and look into appstream's caching in more detail and figure out what the problem is.

I filed https://bugzilla.redhat.com/show_bug.cgi?id=2017587 for the "tiny system cache file on the live image" problem at least, maybe we can start there.

Note You need to log in before you can comment on or make changes to this bug.