Bug 2311964 - Discover does not discover upgrades to Fedora 41.
Summary: Discover does not discover upgrades to Fedora 41.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: plasma-discover
Version: 41
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker https://discussion.fe...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-09-12 16:08 UTC by Lukas Ruzicka
Modified: 2024-10-22 15:46 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2024-09-19 00:17:50 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Logs from the machine (305.38 KB, text/plain)
2024-09-12 16:08 UTC, Lukas Ruzicka
no flags Details

Description Lukas Ruzicka 2024-09-12 16:08:27 UTC
I was trying to pass the following Discover test, see https://fedoraproject.org/wiki/QA:Testcase_upgrade_plasma-discover_current_kde, but Discover does not show the possibility to upgrade to Fedora 41, even if I restarted the system several times and performed the settings required by the test case. 

I am adding the journalctl logs for your information, but I did not notice any problems in them, or in pkmon.

Reproducible: Always

Steps to Reproduce:
1.Follow the steps in the above test case

Actual Results:  
Discover does not see the version upgrade.

Expected Results:  
Discover should be able to see the version upgrade when it has been allowed for a prerelease version.

Comment 1 Lukas Ruzicka 2024-09-12 16:08:58 UTC
Created attachment 2046589 [details]
Logs from the machine

Comment 2 Fedora Blocker Bugs Application 2024-09-12 16:11:09 UTC
Proposed as a Blocker for 41-beta by Fedora user lruzicka using the blocker tracking app because:

 It might violate the System Upgrade criterion, however it could be argued that one could upgrade with DNF and hence workaround this. Proposing for discussion.

Comment 3 Adam Williamson 2024-09-12 17:30:21 UTC
Could this possibly be just because the config should now be done with kwriteconfig6, not kwriteconfig5 as the test case says?

Comment 4 Adam Williamson 2024-09-12 17:44:24 UTC
Filed https://pagure.io/fedora-docs/quick-docs/issue/759 to discuss whether Plasma should be the recommended upgrade method for KDE.

Comment 5 František Zatloukal 2024-09-12 21:59:08 UTC
Discussed during the 2024-09-12 Go/No-Go meeting: [1]

The decision to classify this bug as a RejectedBlocker (Beta) was made:

"This doesn't violate the beta criterion as Discover isn't listed as recommended on https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-new-release/ ."

[1] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-09-12/f41-beta-go-no-go.2024-09-12-17.03.log.html

Comment 6 Kamil Páral 2024-09-16 08:31:29 UTC
If this turns out to be a genuine bug and it's not fixed until F41 Final, then proposing as a Common Issue.

Comment 8 Fedora Update System 2024-09-16 11:03:08 UTC
FEDORA-2024-35e748776d (fedora-appstream-metadata-20240915-1.fc41) has been submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-35e748776d

Comment 9 Timothée Ravier 2024-09-16 11:06:08 UTC
This is a tricky thing. If we want this to be ready, we theoretically have to update / rebuild / push the metadata every week until we're go for the beta.

It would probably make sense for releng to own updating that package.

it also needs updated metadata from the release schedule, which is frequently not updated and not correct right now: https://fedorapeople.org/groups/schedule/f-41/f-41-key-tasks.html

Comment 10 Kamil Páral 2024-09-16 11:41:05 UTC
Note that gnome-software seems to be using this source of releases status instead:
https://admin.fedoraproject.org/pkgdb/api/collections

Comment 11 Adam Williamson 2024-09-16 15:12:34 UTC
Kamil: per https://src.fedoraproject.org/rpms/fedora-appstream-metadata , this appstream-metadata is actually *seeded from* that file! This does seem like a needlessly complicated design. This is similar to backgrounds; every other desktop can pick up a new background when we update fXX-backgrounds and desktop-backgrounds, KDE is the only one which *also* needs a bump to its own package (kde-settings). It sure would be nice if KDE could just work like other desktops and not need all this special handling.

Why does KDE need a copy of this data in a package in the operating system? We have internet connections, and JSON parsers...

Comment 12 Fedora Update System 2024-09-19 00:17:50 UTC
FEDORA-2024-35e748776d (fedora-appstream-metadata-20240915-1.fc41) has been pushed to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 13 Geraldo Simião 2024-09-20 15:39:32 UTC
Yeah, just tested today on a VM and F40 was successfully upgraded to F41 using discover.

Comment 14 Timothée Ravier 2024-10-11 17:24:28 UTC
(In reply to Adam Williamson from comment #11)
> Why does KDE need a copy of this data in a package in the operating system?
> We have internet connections, and JSON parsers...

We need this because there are no reliable source for this information in Fedora right now. We need both release status, release date and EOL date.
We build the metadata in https://src.fedoraproject.org/rpms/fedora-appstream-metadata/blob/rawhide/f/update-appstream-metadata.go from several sources.
In the past, the sources have not been consistently updated, thus requiring workarounds that would have been painful to carry in application code.

Comment 15 Adam Williamson 2024-10-11 19:50:56 UTC
I don't mind if you want to maintain your own source of truth, but why does it have to be *in the package*? Can't you just stick it on a web server somewhere? For instance, I keep mine at https://fedorapeople.org/groups/qa/metadata/release.json ...

Comment 16 Timothée Ravier 2024-10-22 15:35:38 UTC
I'm definitely in favor of having it be available in the Fedora infra somewhere and I can adapt Discover to fetch the ressource remotely first and then look at the local config second.

The main advantage of the local config is that it does not require internet access to tell you that your system is out of date or out of support, but I guess we can live with that.

Comment 17 Timothée Ravier 2024-10-22 15:37:27 UTC
Related: https://pagure.io/fedora-pgm/schedule/issue/118

Comment 18 Timothée Ravier 2024-10-22 15:46:32 UTC
I've created https://pagure.io/fedora-kde/SIG/issue/578 to track that work.


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