Created attachment 1735371 [details]
Description of problem:
plasma-discover doent show any updates
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.click to update button in menu
2.open discover window doesnt show any updates
3.try refresh not help
plasma-discover cant show any updates(rpm flatpak works)
plasma-discover show updates(in window)
or allow older updates-applet(now discover replace update-applet)
I too have this problem when updating RPMs
Operating System: Fedora 33
KDE Plasma Version: 5.20.3
KDE Frameworks Version: 5.75.0
Qt Version: 5.15.2
Kernel Version: 5.9.11-200.fc33.x86_64
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.
Similar discussion on IRC today:
(eiglow_): At the moment in my pretty clean fedora 34 kde vm, discover "check for updates" says there's no updates, but dnf upgrade tells me there's a bunch of updates
(marcdeop): I've been facing the same problem
(marcdeop): but on regular F33
(marcdeop): try pkcon refresh force on a terminal and then discover will find the updates
I'd say this pretty much matches the criteria to be considered blocker right?
My personal opinion is that the new update method is not ready for production.
Marking as a proposed blocker, since it seems that's what Carlos wanted. However, I think there's some subtlety here. There's a 'plasma-discover-notifier' package that provides update notification. That wasn't in comps until quite recently, but it is now, so it will be installed on fresh installs and should be installed on upgrades as long as the 'kde-desktop' package group is installed. I would think that would cause a refresh to happen regularly, or else it could not notify of new updates.
So, are folks still seeing this? If so, do you have plasma-discover-notifier installed? If not, does installing it help?
I've some evidence this may actually be a PackageKit bug, the effect is
(sometimes?) doesn't refresh metadata as expected.
I'll do more testing and report back.
OK, ruled that out, created a local repo with short metadata_expire, and 'pkcon refresh' worked as expected here.
I saw this behavior on my F34 Beta KDE VM with plasma-discover-notifier installed. `dnf update` showed 13 updates available, while Discover showed none. Clicking "Check for updates" produced no updates until I ran `pkcon refresh force`. I'd used the VM for testing the user switching bug today so I would think it had been up long enough over the course of the day to have a chance to refresh (although I don't know how frequently it is expected to check)
TBH really never needed discover for anything useful, so my vote tends as -1 for a real blocker.
I retested again today. `dnf update` showed packages available, but plasma-discover did not. Notably, `pkcon update` did not either. Once I ran `pkcon refresh force`, both `pkcon update` and Discover showed the available updates.
As far as I can tell, Discover is doing the right thing and pkcon is just slow to refresh.
After a little more poking around, it seems that `pkcon refresh` just never works and hasn't in a while. My F33 box which hasn't had updates applied in about 3 weeks shows no updates available with `pkcon update`, even after a refresh. Only a `pkcon refresh force` causes updates to appear.
According to Neal Gompa, plamsa-pk-updates always did a force, which is why we haven't noticed this previously:
So I think the long-term solution is for `pkcon refresh` to actually refresh. But in the short term, we could address the issue by modifying plasma-discover to do a force or switch back to plasma-pk-updates
Rex opened https://bugzilla.redhat.com/show_bug.cgi?id=1950037 for the refresh issue.
FEDORA-2021-4cb56488da has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-4cb56488da
I tested with FEDORA-2021-4cb56488da. I can confirm that it "fixes" the issue (in that we get the desired behavior, but it's really a papering over a PackageKit bug)
FEDORA-2021-4cb56488da has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-4cb56488da`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-4cb56488da
See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Could we bring back plasma-pk-updates to the repo, as an option, regardless of what happens with this bug? It's not like I'm super happy with the new update method even if it works.
Re: comment #15
An enterprising user/maintainer is welcome to provide it via copr or other non-official repo, no objection to that. plasma-pk-updates is just not something kde-sig wants to support at this point, too many downsides/missing-features:
* no offline updates
* supports only PackageKit (no flatpak, firmware updates)
> After a little more poking around, it seems that `pkcon refresh` just never works and hasn't in a while. My F33 box which hasn't had updates applied in about 3 weeks shows no updates available with `pkcon update`, even after a refresh.
I also did some tests with `pkcon refresh`.
The question is, what exactly does `pkcon refresh` mean? According to the documentation, `pkcon` has the option:
-c, --cache-age Maximum age of the metadata cache. Use -1 for "never".
What is the default value? It seems that dafault is "-1". If I test this with a value >0, metadata with an age greater than this value (seconds) or the value in the configuration ("metadata_expire" in *.repo) have been restored. So, the "metadata_expire" value in the configuration was respected, and the "-c" option behaved as the maximum allowed repository age. With a value of "-1", the age of the repositories was ignored and only damaged repositories were refreshed.
Therefore, the problem may be the default "cache age" value used in pkcon (and the PackageKit daemon).
Yes, if you look at the linked bug about PK, that's the case. The default cache age is way (way!) too big
Blocker vote for this is still up in the air, but we at least have +3 FE, so marking accepted FE for now. That will be enough to push the fix.
Discussed during the 2021-04-19 blocker review meeting: 
The decision to delay the classification of this as a blocker bug was made as there isn't a clear consensus on blocker status here. It is already accepted as a freeze exception issue and a fix is prepared, so we expect that will resolve it shortly.
FEDORA-2021-4cb56488da has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.