| Summary: | Flatpak branch end of life, Discover won't let me upgrade | ||
|---|---|---|---|
| Product: | [Applications] Discover | Reporter: | Philipp Kiemle <l10n.daphipz> |
| Component: | Flatpak Backend | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | 4wy78uwh, aleixpol, jakobdev, jgrulich, nate, prettyvanilla, sitter, travier |
| Priority: | NOR | ||
| Version First Reported In: | 5.27.8 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/discover/-/commit/370a22daaded23f4a754fb5168cb582ed34a9d14 | Version Fixed/Implemented In: | 6.1 |
| Sentry Crash Report: | |||
|
Description
Philipp Kiemle
2024-04-21 10:36:43 UTC
We don't implement https://docs.flatpak.org/en/latest/libflatpak-api-reference.html#FlatpakInstalledRef--end-of-life-rebase incoming arguments are flathub runtime/com.github.Eloston.UngoogledChromium.Codecs/x86_64/stable The application has been renamed to io.github.ungoogled_software.ungoogled_chromium runtime/io.github.ungoogled_software.ungoogled_chromium.Codecs/x86_64/stable 0x73a71c122c00 supposedly we need to manipulate the transaction to install the rebased_to_ref instead. Though probably also have to tell the user about this. I have a prototype of sorts locally. I'll try to get some related enhancements landed first though. *** Bug 467981 has been marked as a duplicate of this bug. *** A possibly relevant merge request was started @ https://invent.kde.org/plasma/discover/-/merge_requests/839 Git commit 370a22daaded23f4a754fb5168cb582ed34a9d14 by Harald Sitter. Committed on 17/05/2024 at 14:22. Pushed by sitter into branch 'master'. flatpak: handle end_of_lifed_with_rebase when end_of_lifed_with_rebase is called we need to render a decision on whether to move to the replacement for the EOL flatpak or not. we do this in two ways 1) runtime/ is always auto-transitioned because we consider this implementation details that dont need surfacing to the user 2) everything else (i.e. app/) surfaces a proceed request via the existing job interface since we are dealing with a transaction thread the implementation uses a bog standard waitcondition to implement the blocking aspect of this (i.e. the callback doesn't return until the user made a proceed decision causing the wait condition to get awoken) M +8 -0 libdiscover/backends/FlatpakBackend/FlatpakJobTransaction.cpp M +1 -0 libdiscover/backends/FlatpakBackend/FlatpakJobTransaction.h M +61 -7 libdiscover/backends/FlatpakBackend/FlatpakTransactionThread.cpp M +9 -0 libdiscover/backends/FlatpakBackend/FlatpakTransactionThread.h https://invent.kde.org/plasma/discover/-/commit/370a22daaded23f4a754fb5168cb582ed34a9d14 |