Bug 1903294 - plasma-discover doesnt refresh metadata
Summary: plasma-discover doesnt refresh metadata
Alias: None
Product: Fedora
Classification: Fedora
Component: plasma-discover
Version: 34
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedFreezeException
Depends On: 1950041
Blocks: F34FinalBlocker F34FinalFreezeException
TreeView+ depends on / blocked
Reported: 2020-12-01 19:12 UTC by Martin
Modified: 2021-04-20 01:34 UTC (History)
11 users (show)

Fixed In Version: plasma-discover-5.21.4-2.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-04-20 01:34:47 UTC
Type: Bug

Attachments (Terms of Use)
discover (187.44 KB, image/png)
2020-12-01 19:12 UTC, Martin
no flags Details

Description Martin 2020-12-01 19:12:03 UTC
Created attachment 1735371 [details]

Description of problem:
plasma-discover doent show any updates

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

How reproducible:

Steps to Reproduce:
1.click to update button in menu
2.open discover window doesnt show any updates
3.try refresh not help

Actual results:
plasma-discover cant show any updates(rpm flatpak works)

Expected results:
plasma-discover show updates(in window)
or allow older updates-applet(now discover replace update-applet)

Additional info:

Comment 1 Persona non grata 2020-12-05 10:11:53 UTC
I too have this problem when updating RPMs

Additional info:
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

Comment 2 Ben Cotton 2021-02-09 15:29:26 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

Comment 3 Adam Williamson 2021-03-28 16:45:51 UTC
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

Comment 4 Carlos 2021-04-13 18:22:06 UTC
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.

Comment 5 Adam Williamson 2021-04-13 19:05:44 UTC
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?


Comment 6 Rex Dieter 2021-04-14 14:13:44 UTC
I've some evidence this may actually be a PackageKit bug, the effect is
pkcon refresh
(sometimes?) doesn't refresh metadata as expected.

I'll do more testing and report back.

Comment 7 Rex Dieter 2021-04-14 16:57:10 UTC
OK, ruled that out, created a local repo with short metadata_expire, and 'pkcon refresh' worked as expected here.

Comment 8 Ben Cotton 2021-04-14 19:08:24 UTC
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)

Comment 9 Raphael Groner 2021-04-15 05:45:35 UTC
TBH really never needed discover for anything useful, so my vote tends as -1 for a real blocker.

Comment 10 Ben Cotton 2021-04-15 16:12:08 UTC
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.

Comment 11 Ben Cotton 2021-04-15 16:57:50 UTC
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.

Comment 12 Fedora Update System 2021-04-16 15:11:43 UTC
FEDORA-2021-4cb56488da has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-4cb56488da

Comment 13 Ben Cotton 2021-04-16 15:42:31 UTC
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)

Comment 14 Fedora Update System 2021-04-16 16:25:24 UTC
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.

Comment 15 Carlos 2021-04-16 18:39:18 UTC
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.

Comment 16 Rex Dieter 2021-04-17 13:59:38 UTC
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)

Comment 17 Jaroslav Rohel 2021-04-19 07:08:57 UTC
@comment 11
> 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).

Comment 18 Rex Dieter 2021-04-19 14:50:08 UTC
Yes, if you look at the linked bug about PK, that's the case.  The default cache age is way (way!) too big

Comment 19 Adam Williamson 2021-04-19 15:48:40 UTC
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.

Comment 20 Geoffrey Marr 2021-04-19 18:59:36 UTC
Discussed during the 2021-04-19 blocker review meeting: [0]

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.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-04-19/f34-blocker-review.2021-04-19-16.00.txt

Comment 21 Fedora Update System 2021-04-20 01:34:47 UTC
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.

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