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): plasma-discover-5.22.5-1.fc35.x86_64 PackageKit-1.2.4-2.fc35.x86_64 Fedora-KDE-Live-x86_64-35-20211005.n.0.iso How reproducible: always 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
Created attachment 1829819 [details] empty search results
Created attachment 1829820 [details] no installed apps
Created attachment 1829821 [details] all offered apps are flatpaks
Created attachment 1829822 [details] journal
Created attachment 1829823 [details] rpm -qa
Proposing for a blocker discussion under https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Default_application_functionality
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
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.
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
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.
Created attachment 1830333 [details] Unable to load applications
(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.
+3 in https://pagure.io/fedora-qa/blocker-review/issue/515 , marking accepted. Do we know if this persists with 5.23?
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.
I think plasma-discover-5.23.0-1.fc35.x86_64 fixes this bug too.
bug fixed here: plasma-discover-libs-5.23.0-1.fc35.x86_64 plasma-discover-flatpak-5.23.0-1.fc35.x86_64 plasma-discover-offline-updates-5.23.0-1.fc35.x86_64 plasma-discover-5.23.0-1.fc35.x86_64 plasma-discover-packagekit-5.23.0-1.fc35.x86_64 plasma-discover-notifier-5.23.0-1.fc35.x86_64 selinux-policy-35.1-1.fc35.noarch selinux-policy-targeted-35.1-1.fc35.noarch flatpak-selinux-1.12.0-1.fc35.noarch libselinux-3.2-4.fc35.x86_64 libselinux-utils-3.2-4.fc35.x86_64
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).
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
(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 ;)
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.
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.
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.
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.
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.
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?
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.
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.
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
this all seem so random...
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.
tested again today, with Fedora-KDE-Live-x86_64-35-20211014.n.0.iso results: at live-session discover didn't worked, bug present. after installation (using pt_BR.UTF-8) discover worked just fine, no bugs.
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.
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!
(In reply to Kamil Páral from comment #32) > Geraldo, bingo! This is locale-dependent! Great, not so random anymore. :D
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.
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: https://koji.fedoraproject.org/koji/taskinfo?taskID=77467469 and see if it solves the problem? Thanks!
FEDORA-2021-ba9eb4f7b1 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-ba9eb4f7b1
FEDORA-2021-ba9eb4f7b1 fixes the issue.
Yes,appstream-0.14.6-1.fc35 fixed the bug!!!!!
Created attachment 1834430 [details] appstream-0.14.6-1.fc35 fixed the issue Fedora-KDE-Live-x86_64-35-20211014.n.0.iso with appstream-0.14.6-1.fc35 locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8"... Bug fixed
(In reply to František Zatloukal from comment #38) > FEDORA-2021-ba9eb4f7b1 fixes the issue. Confirmed by me as well.
👍 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!
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.
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). So...conclusions: 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?
FEDORA-2021-1949dabf93 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-1949dabf93
So for the record, the update does this: https://src.fedoraproject.org/rpms/plasma-discover/blob/rawhide/f/0001-PackageKit-do-not-use-system-appstream-cache.patch 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.
(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).
(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.
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...
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.
We still need a few confirmations from systems which were running for a few days and not cleanly installed...
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?
(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.
Thanks.
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.