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.
Created attachment 2046589 [details] Logs from the machine
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.
Could this possibly be just because the config should now be done with kwriteconfig6, not kwriteconfig5 as the test case says?
Filed https://pagure.io/fedora-docs/quick-docs/issue/759 to discuss whether Plasma should be the recommended upgrade method for KDE.
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
If this turns out to be a genuine bug and it's not fixed until F41 Final, then proposing as a Common Issue.
This is because the appstream metadata has not been updated yet: https://src.fedoraproject.org/rpms/fedora-appstream-metadata I've made https://src.fedoraproject.org/rpms/fedora-appstream-metadata/pull-request/9. And update: https://bodhi.fedoraproject.org/updates/FEDORA-2024-35e748776d
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
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
Note that gnome-software seems to be using this source of releases status instead: https://admin.fedoraproject.org/pkgdb/api/collections
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...
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.
Yeah, just tested today on a VM and F40 was successfully upgraded to F41 using discover.
(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.
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 ...
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.
Related: https://pagure.io/fedora-pgm/schedule/issue/118
I've created https://pagure.io/fedora-kde/SIG/issue/578 to track that work.