Discover showing flatpaks to be updated, but cannot update flatpaks

Just before the 24.04 release, I had a problem out of the blue updating Flatpaks via Discover. Previously Flatpaks updated just fine, now whenever I try to update Flatpaks I get the error:

While trying to apply extra data: apply_extra script failed, exit status 256

Oddly enough, when I try to update via terminal using:

sudo flatpak update

It’s stated “Nothing to do”.

What gives? I’ve tried sudo flatpak repair, it goes through the verification process and then states:

Pruning objects
Erasing .removed

But upon opening Discover the problematic flatpak’s are still present and will not update citing the exact same error?

Anyone able to assist? I don’t understand how Discover thinks there’s updates present, but terminal states there’s nothing to do?

Screenshot below:

root has no flatpaks I would guess (no sudo needed here).

3 Likes

This was the fix, so obvious!

Thanks for the assistance, problem resolved.

1 Like

Why do you ‘sudo’ flatpak?

This is actually a huge issue with Linux, especially with GUI applications - people think they must sudo to get root permission.

It’s not always wrong - gedit is one of the issues here, unlike kate which will only ask for a password when saving fails to ‘save as sudo’.

flatpak update

Your package manager requires the use of sudo, one would simply assume that flatpak also requires the use of sudo.

The real question is: Why was Discover all of a sudden completely unable to update Flatpaks when it’s done so many times in the past without issue?

do you have a package called plasma-discover-backend-flatpak

perhaps reinstall it.

Package managers also behave differently…

❯ pamac update
Preparing...
==== AUTHENTICATING FOR org.manjaro.pamac.commit ====
Authentication is required to install, update, or remove packages
Authenticating as: ben
Password: 

As you can see, I do not need to run pamac with sudo for it to work - this is a better way of working…

The same is true with many KDE Plasma applications, for example:

kate /etc/fstab

This will open the file for reading and editing, only asking for escalation when required.

Different commands operate differently, and it pays not to make unfounded assumptions…

To assume is to make an ASS out of U and ME.

It is better to NOT use sudo unless your command fails, or you absolutely are familiar and sure that it is required.

This is also true with most systemctl commands (I’m sick of seeing ‘sudo systemctl…’ when simply ‘systemctl’ is required and escalation is only requested when required).

Just run the command without sudo and if you get a error message that looks like sudo would be required simply follow up with a sudo !! The two Exclamation marks, to append the last command, should at least work in Bash and Bash-a-like terminals.

That is what I always do. Not because I follow that as a rule, but because I almost always forget to add sudo to begin with :smiley: (in the very few cases that I need it).

As a side note systemctl with its popping up a password dialog I find annoying why can’t it ask at the Terminal (Konsole) itself when for every (other) output the Terminal is used as well.

2 Likes

I’ve already got plasma-discover-backend-flatpak installed, my package manager reports it’s the latest version.

For some reason Discover no longer seems to be able to install Flatpaks, but flatpak update works perfectly.

that does seem odd… this is what i have installed on kubuntu 24.10

this is what i get when i run plasma-discover in a console window

libs QList("/usr/lib/x86_64-linux-gnu/qt6/plugins", "/usr/bin")
org.kde.plasma.libdiscover: OdrsReviewsBackend: Fetch ratings: false
adding empty sources model QStandardItemModel(0x64dc30ba1ab0)
qt.qml.typeresolution.cycle: Cyclic dependency detected between "qrc:/qt/qml/org/kde/desktop/private/TextFieldContextMenu.qml" and "qrc:/qt/qml/org/kde/desktop/MenuItem.qml"
qrc:/qt/qml/org/kde/discover/qml/DiscoverWindow.qml:330:5: QML OverlaySheet: Binding loop detected for property "implicitHeight"
qrc:/qt/qml/org/kde/discover/qml/BrowsingPage.qml:17:1: QML BrowsingPage: Created graphical object was not placed in the graphics scene.
PackageKitBackend: No distro component found for "com.ubuntu.ubuntu"
AppStreamIntegration: No distro component found for "com.ubuntu.ubuntu"
looking for cache entry
looking for cache entry 0
cache entry KNSCore::Entry(uniqueId: "998469", name:"Root Actions Servicemenu", status: Installed, installedFiles: QList("/home/goo/.local/share/servicemenu-download/rootactions_servicemenu_2.9.1.tar.gz")) "2.9.1" "2.9.1"
UPDATABLE QList()
looking for cache entry
looking for cache entry 0
cache entry KNSCore::Entry(uniqueId: "1609265", name:"Kubuntu Plymouth", status: Installed, installedFiles: QList("/home/goo/.local/share/kplymouththemeinstaller/kubuntu-kde-logo.zip")) "1.0" "1.0"
UPDATABLE QList()


if yours says something different, then maybe try deleting your ~/.cache folder and reinstalling most of those packages

I don’t think that’s the problem, I think we need to focus on the actual error:

While trying to apply extra data: apply_extra script failed, exit status 256

From what I can gather, the error is highlighting that an apply_extra script from within the Flatpak is trying to pull extra data, but for some reason the script is failing.

I’d say it’s a problem with a particular Flatpak application, however that doesn’t explain why the process fails under Discover, but doesn’t fail when flatpak update is run via terminal.

Anyone got any ideas?

Today finally a Flatpak update arrived (GNOME Application Platform …) and I could try Discover for that. No Issue here. Totally strange.

But I have removed the Discover “packagekits” for the NON Flatpak stuff and use Discover solely for Flatpak. (For off-topic reasons) And when I handle other updates from command line I throw in the Flatpak update as well most of the time.
Maybe there is really some other, not directly Flatpak related, thing in your installation that pulls the plug on Discover.

I have a funny feeling something’s been going on with Flathub’s servers, because I just updated a ton of Flatpak’s via Discover and they applied without a hitch.

Very odd.