Bug 510031

Summary: Discover only shows settings for one user repo and one system repo at a time if they all have same remote
Product: [Applications] Discover Reporter: john.liptrot
Component: Flatpak BackendAssignee: Plasma Bugs List <plasma-bugs-null>
Status: CONFIRMED ---    
Severity: normal CC: akselmo, aleixpol, jgrulich, nate, travier
Priority: NOR    
Version First Reported In: 6.5.80   
Target Milestone: ---   
Platform: KDE Linux   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: flatpak default setup

Description john.liptrot 2025-09-28 18:29:44 UTC
Created attachment 185349 [details]
flatpak default setup

Hi,

I’ve been trying to add several flatpak repos to my system but discover doesn’t seem to recognise them properly. My flatpak setup is in screenshot [1]. This is the flathub repo that comes with the system. This is reflected correctly in discover's settings menu, as expected.

Added another repo with the command;

flatpak remote-add --subset=verified_floss --prio=2 --title=“Flathub-Verified-FLOSS” flathub-verified-floss https://dl.flathub.org/repo/flathub.flatpakrepo

The ‘–prio=2’ argument sets the repositories’ priority, higher the number = higher priority.

The commands "flatpak remotes" and "flatpak remotes -d" show the newly added repo, but discover still only shows the original, pre-installed repo. Closed discover and reopened, nothing. Closed discover and deleted the ‘.cache’ folder in the home directory then reopened discover, and discover now *only* shows the newly created flathub-verified-floss repo. The buttons to increase or decrease priority are greyed out.

Deleted the verified repo;

flatpak remote-delete flathub-verified-floss

and re-added it with the ‘–user’ argument;

flatpak remote-add --subset=verified_floss --prio=2 --title="Flathub-Verified-FLOSS" --user flathub-verified-floss https://dl.flathub.org/repo/flathub.flatpakrepo

This worked! Discover now shows both repos, in the correct order according to repo priority. The commands ‘flatpak remotes’ and ‘flatpak remotes -d’ both verify the existence of the new repo.

The problem now, though, is I can add additional repos, either system (which is the default) or user (using the –user switch), but discover doesn’t acknowledge them.

Added a third repo (a user repo);

flatpak remote-add --subset=floss --prio=3 --title="Flathub-FLOSS" --user flathub-floss https://dl.flathub.org/repo/flathub.flatpakrepo

Added a fourth repo (no –user switch, i.e. default)

flatpak remote-add --subset=verified --prio=4 --title="Flathub-Verified-Only" flathub-verified-only https://dl.flathub.org/repo/flathub.flatpakrepo

Opened discover to find both the third & fourth repo’s missing in discovers settings. Closed and reopened, nothing. Closed, deleted ‘.cache’ folder again, reopened discover only to find the original ‘system’ repo (the one that came preconfigured with the system) has been replaced with the fourth repo, and the ‘flathub-verified’ user repo has now been replaced with the ‘flathub-floss’ user repo.

…So, here’s where I am with this. It appears discover is only capable of showing one 'user' repo and one 'system' repo at a time in the settings menu. The only way to get around this, as far as I can tell, is by changing the repo priority in the command line. For example, if I run the command;

flatpak remote-modify flathub-verified-floss --prio=9

I’ve changed the second 'user' repo to a higher priority. Verified with "flatpak remotes -d”

Opened discover and found the user repo has changed to “flathub-verified-floss (user)”, as expected.

To add a spanner into the works, although discover won’t show all repo’s in settings, it does actually seem like discover can “see” all the configured repos, and it allows you to install software from all of them.

Firefox is both FLOSS and verified, so I get the option of all 4 repos for installation, as expected.

VLC media player is FLOSS but not verified, so I get the options of installing from “flathub” or “flathub-floss”, as expected. Blender is the same.

Spotify is neither FLOSS nor verified, so the only install option is “flathub”, as expected. Chrome is another example of this.

To test this even further, I’ve disabled the flathub repo “flathub” that came preinstalled with the system. The expected outcome here is software that is non-verified and non-floss software should no longer be available for installation via discover. Ran the command;

flatpak remote-modify --disable flathub

verified the repo is disabled with “flatpak remotes --show-disabled”

Open discover and searched for spotify, chrome, etc etc.

All gone, as expected. Closed discover, re-enabled the repo with;

flatpak remote-modify --enable flathub

All apps are back, as expected.

So, I’m kind of baffled really. Discover has no issue “seeing” the repositories configured via the command line, nor does it have any issue recognising configuration changes via the command line, but in the settings menu it only seems to show one user repository and one system repository at a time when added via command line.
Comment 1 Akseli Lahtinen 2025-09-29 08:41:53 UTC
Can confirm, I only see one of the user and system repos for same remote.

Operating System: Fedora Linux 42
KDE Plasma Version: 6.5.80
KDE Frameworks Version: 6.19.0
Qt Version: 6.9.2
Kernel Version: 6.16.8-200.fc42.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 3600 6-Core Processor
Memory: 16 GiB of RAM (15.5 GiB usable)
Graphics Processor: AMD Radeon RX 6600
Comment 2 john.liptrot 2025-09-29 15:09:30 UTC
Oops!

Accidentality Ctrl-V'd over the template when posting this bug, so forgot to add system info. Can't see an edit button so I'll leave my specs here. Sorry about that!

Operating System: KDE Linux 2025-09-20
KDE Plasma Version: 6.5.80
KDE Frameworks Version: 6.19.0
Qt Version: 6.9.2
Kernel Version: 6.16.7-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 2 × Intel® Pentium® 3805U @ 1.90GHz
Memory: 4 GiB of RAM (3.7 GiB usable)
Graphics Processor: Intel® HD Graphics
Manufacturer: LENOVO
Product Name: 80EW
System Version: Lenovo B50-80
Comment 3 Akseli Lahtinen 2025-09-30 08:04:58 UTC Comment hidden (spam)
Comment 4 Akseli Lahtinen 2025-09-30 08:05:13 UTC
(In reply to Akseli Lahtinen from comment #3)
> Been looking into this bug. Somehow the rating field gets an empty rating:
> root.application.rating.packageName is empty.

Sorry, wrong bug report