Description of problem: $ flatpak remote-info OCI org.mozilla.Firefox error: Unsupported URI scheme “oci+https” Version-Release number of selected component (if applicable): flatpak-1.0.6-4.el8.x86_64 How reproducible: always Steps to Reproduce: 1.Add OCI remote $ flatpak remote-add --user OCI oci+https://registry.fedoraproject.org 2.Send query for info: $ flatpak remote-info OCI org.mozilla.Firefox Actual results: error: Unsupported URI scheme “oci+https” Expected results: Command should fetch the info, I am not sure why there is "oci+https" when enabling remote but it has to be there otherwise the remote is not added $ flatpak remote-add --user fedora https://registry.fedoraproject.org error: GPG verification enabled, but no summary found (check that the configured URL in remote config is correct) Additional info:
Alex points out that this is fixed in https://github.com/flatpak/flatpak/commit/cf49bd4ac80404e23ba1d4198706dc3993766c49
(In reply to Matthias Clasen from comment #1) > Alex points out that this is fixed in > https://github.com/flatpak/flatpak/commit/ > cf49bd4ac80404e23ba1d4198706dc3993766c49 Having a quick look at the merge request that this came from (as it seems like the whole series of commits would be required): https://github.com/flatpak/flatpak/pull/3597 it seems to depend on parts of the sideload feature, which in turn seems to depend on variant-schema-compiler, neither of which are on the 1.6 branch. Before I go and rebase/backport a load of stuff for just that patch, is that thinking way off? The variant-schema-compiler changes seem OK to workaround, but the sideload changes look a little complicated to me. Any idea, Alex?
I think you need essentially: 2028a5323fcf39a40c833f0311f768885d972b21 56f530ca1f18f0b10f31870251d6419be9a98e87 cf49bd4ac80404e23ba1d4198706dc3993766c49 However, these will require quite some changes to backport due to other changes in the codebase. Nothing that is fundamentally hard though, just e.g. doing the same thing with gvariant apis instead of the new apis.
I looked at this again, and there is a lot that changed in how transactions work in flatpak 1.8 that make this change work. To work in 1.6 we have to re-implement the feature, which is not impossible, but quite some work. I don't think its worth it at this point and we should rather rebase to 1.8 (out soon) with the fix instead of doing major changes to the old codebase.
Thank you Alex for the update. We agreed on the SST meeting that we will move this to 8.4 and deal with it as part of the possible flatpak update.
Closing as a duplicate of bug 1851958 that was created for the Flatpak 1.8 rebase. The fix for this bug will be part of the rebase. *** This bug has been marked as a duplicate of bug 1851958 ***