Hide Forgot
Created attachment 1862999 [details] Log file from the affected machine. Description of problem: When Discover is started, a cog wheel is spinning for a while (Loading) and finally it does not display any application. Instead it reports "Unable to load applications. Please verify Internet connectivity". At the same time, the ping command is successfully running in the background. When I click on Applications, Discover displays applications that can be installed, but all of them are Flatpak applications only. No RPM applications are available. The list of installed applications only shows three flatpak items, although I have installed several applications using DNF. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Start Discover. 2. Try to list through applications. 3. Try to see the list of installed applications. Actual results: Applications are not shown, or only Flatpaks are shown. Expected results: All applications should be visible from the start. Additional info: See the log file.
Proposed as a Blocker for 36-beta by Fedora user lruzicka using the blocker tracking app because: Since Discover does not display any RPM based applications, I believe that it violates the following criterion and therefore I am proposing this bug as a Beta Blocker. # Installing, removing and updating software. https://fedoraproject.org/wiki/Fedora_36_Beta_Release_Criteria#Installing.2C_removing_and_updating_software
Created attachment 1863005 [details] No applications visible. This image shows the application claiming not to have an internet connection available, but at the same time a successfully running PING that proves the Internet connection was available.
Created attachment 1863006 [details] Available applications This image shows that only Flatpak applications are listed in the list of available applications.
Created attachment 1863007 [details] Installed applications This image shows that only Flatpak applications are listed among the installed applications.
Does running this (as root) help? appstreamcli refresh --force
It looks similar to this old ticket here at f35 https://bugzilla.redhat.com/show_bug.cgi?id=2011322
(In reply to Rex Dieter from comment #5) > Does running this (as root) help? > > appstreamcli refresh --force Yes, running the command solves the situation partly. 1. Newly, repositories are available to install (Fedora RPM Fusion, etc) in Applications menu, but their status is still "Loading" so they cannot be installed after all. 2. All packages seem now to be listed in Installed. 3. The application still starts with "Check the internet connection." 4. No RPM applications are available in Applications menu.
Rex disabled the patch we added to address #2011322 in December: https://src.fedoraproject.org/rpms/plasma-discover/c/7a36373b3445e2ef34db464abf35ac10b70f3b10?branch=rawhide because it doesn't work with current appstream, apparently. So that would tie in. I think we might want to just re-open #2011322 as this is likely the same thing.
For now, though, there's +4 in https://pagure.io/fedora-qa/blocker-review/issue/626 , so accepting as a Beta blocker.
A quick fix we could try here is to try wiping the apparently-bad appstream cache from the KDE live image in kickstart %post - see https://bugzilla.redhat.com/show_bug.cgi?id=2017587 . But I'm going to see first if I can figure out why we get the bad cache on KDE images.
Huh. So I just tested this myself with Fedora-KDE-Live-x86_64-36-20220224.n.0.iso . Interestingly the appstream cache on that image seems to be full size, not broken. And I can't reproduce the bug. I installed in en_US locale, booted, logged in, ran plasma-discover, and it shows apps fine, RPM as well as flatpak. Can you reproduce with a clean install from that ISO, Lukas?
I cannot reproduce it when a clean install from the suggested ISO is performed.
Also, I cannot reproduce this when I let the VM update to the latest versions.
OK, that's good news, but let's keep testing with new builds. I don't know if the 'fix' is permanent or if it's just random, maybe another day's compose will have the bad cache and show the bug again...
I'm setting this to ON_QA to reflect the fact that it's (at least temporarily) fixed. We'll move it back to NEW if the behavior reappears.
Still working, Lukas?
Still working for me.
OK, let's call this fixed for now then. If the bug comes back we can re-open it. Thanks!