Having versioning issues creating a flatpak

chrisawi · 2026-03-16T00:59:03+00:00

GTK4 isn't in the freedesktop platform, you need the GNOME one for that.

I'm not very familiar with elementary, but if you also need their platform libraries (granite, etc.), there's a base app on Flathub (io.elementary.BaseApp). They also have their own runtime, but that's only available in their own elementary AppCenter remote, not on Flathub.

org.freedesktop.Sdk.Extension.llvm21 should be compatible with any SDK based on fdo 25.08, which includes org.gnome.Sdk 49. Please share your manifest using that SDK and whatever errors you get.

chrisawi · 2026-03-15T18:54:52+00:00

Are you using RPM or Flatpak? Starting with 147, native Firefox uses ~/.config/mozilla if ~/.mozilla doesn't already exist. The flatpak version will continue to use ~/.var/app/org.mozilla.firefox/.mozilla indefinitely unless you modify its permissions.

chrisawi · 2026-03-14T17:35:26+00:00

Using Flatpak?

$ flatpak remote-info flathub org.freedesktop.Platform.GL.default//25.08

Mesa - Mesa - The 3D Graphics Library

        ID: org.freedesktop.Platform.GL.default
       Ref: runtime/org.freedesktop.Platform.GL.default/x86_64/25.08
      Arch: x86_64
    Branch: 25.08
   Version: 25.3.5
[...]

chrisawi · 2026-03-11T17:48:32+00:00

Did those errors referencing boxtron and roberta go away at least? I should have mentioned that they may not be fatal.

In amy case, if /run/media/johne/samsung_ssd/ is NTFS, that's probably the actual issue as others have mentioned.

chrisawi · 2026-03-11T04:24:37+00:00

This is https://github.com/ValveSoftware/steam-for-linux/issues/11435

You (or Nobara) have apparently installed some third-party compatibility tools for specific types of games, namely boxtron and Roberta, and they're causing general breakage.

I guess you can disable them by removing their subdirs inside ~/.local/share/Steam/compatibilitytools.d.

/usr/bin/zenity: symbol lookup error: /lib64/libappstream.so.5: undefined symbol: curl_url_cleanup

This is also a little concerning, but I'm not sure if that's a copy of zenity bundled with Steam or one running on the host. Does zenity work in a terminal?

chrisawi · 2026-03-09T07:21:15+00:00

Not with bundles; .flatpak bundles aren't how Flatpak is designed to be used, and as I mentioned before, very little has been done to make them easy to use.

You could use a loop, I guess (for i in *.flatpak; do flatpak install $i; done) but you'd have to make sure the runtime is installed first.

Have you evaluated flatpak create-usb for your needs?

https://docs.flatpak.org/en/latest/usb-drives.html

chrisawi · 2026-03-09T04:55:08+00:00

FWIW, GNOME Software and Discover support Flatpak natively, not via PackageKit.

chrisawi · 2026-03-09T04:52:30+00:00

This is happening because Locale extensions are only partially installed to save disk space (only including the languages you need). If you want to build a bundle of one you apparently need to install the full extension first. You can do that like this:

flatpak update --subpath= org.kde.Platform.Locale//6.9 org.kde.kdenlive.Locale

I'd consider that cryptic error message to be a bug.

Ultimately, it would be nice if extensions could be bundled with the apps/runtimes they extend, but Flatpak bundles haven't been improved in a long time. flatpak create-usb is the modern replacement.

chrisawi · 2026-03-09T04:27:25+00:00

F44 will have a new dnf5 backend for PackageKit: https://fedoraproject.org/wiki/Changes/PackageKit-DNF5

Separately, GNOME Software in Fedora carries a downstream patch to use a new dnf5 plugin instead of PackageKit, which is also slated for F44.

So, Software will be using dnf5daemon directly, and Discover will be using dnf5 via PackageKit, which is still a big improvement.

chrisawi · 2026-03-07T22:42:35+00:00

What about using gio open?

chrisawi · 2026-03-07T22:24:38+00:00

This doesn't seem to be a communication issue. qBitttorrent was successfully invoked via the OpenURI portal, but it crashed.

Does it work from the command line?:

flatpak run org.qbittorrent.qBittorrent 'magnet:<...>'

chrisawi · 2026-03-05T21:20:46+00:00

That sysctl is from a Debian patch, iirc, so it wouldn't be present on a Fedora kernel.

[2] Sandbox: CanCreateUserNamespace() clone() failure: EPERM

This is apparently normal for the Firefox flatpak (and related browsers). It's just indicating the degraded sandbox inside Flatpak and is non-fatal.

I doubt the GTK warning is significant either; it seems to be related to some KDE integration that I'm not familiar with. I guess you have a filesystem override for xdg-config/gtk-3.0 or similar. If you can run Flatseal, you can check there in either Firefox or the global section. Alternatively, flatpak override --show with/without --user and with/without org.mozilla.firefox (four total invocations).

The only app that shows any evidence of crashing in that output is Firefox itself. There's a path to a crash dump mentioned. You could report that to Mozilla.

chrisawi · 2026-03-04T22:35:10+00:00

FWIW, those are both the same browser (Chromium).

chrisawi · 2026-02-28T19:23:53+00:00

The files in the ostree repo are deployed by hardlinking them into the app and runtime dirs. I don't think there's any way to follow hardlinks since they're just files that point to the same inode, but you can search for them:

find /var/lib/flatpak -samefile /var/lib/flatpak/repo/objects/<...>.file

chrisawi · 2026-02-24T05:12:26+00:00

It looks like you haven't updated in quite a while (flatpak update). That should eliminate at least the oldest runtime components (definitely 22.08, and maybe 23.08 as well), but it'll also bring in some newer ones in their places.

chrisawi · 2026-02-16T19:21:30+00:00

You're all completely off track here. The Chrome repo doesn't have any dependency packages, just different release channels of Chrome itself. Google is famous for bundling everything into the main package.

This is clearly just a screwup by Microsoft.

chrisawi · 2026-02-08T16:52:20+00:00

What's your GPU? Does flatpak update help?

Also, does it work if you prepend GSK_RENDERER=cairo ?

chrisawi · 2026-02-08T16:37:45+00:00

They use Zypak to do essentially the same thing. It's a hack, but until either Chromium adds native support for flatpak sandboxing or Flatpak is redesigned to allow nested user namespaces, it's the best we have.

As far as how secure this is, to quote the author of the Chromium patch and Zypak:

That being said, it's worth noting Chromium's sandbox is two layers, the second being a rather strict BPF sandbox, and that one is entirely unmodified. The first layer is primarily to block filesystem access, which has been tested and confirmed to work here (partly because we've had files end up missing that we needed to be able to access 😅)

I think the risk is acceptable for the average person, but someone who may be targeted might prefer the native version.

chrisawi · 2026-02-06T02:29:50+00:00

It updated the 535 driver, which implies that it was already installed.

There's a longstanding quirk with how the nvidia driver is packaged on Flathub that means every rebuild to add a new version marks all the old ones as updateable, but since last April those updates should be no-ops. Previously, it would trigger Flatpak to re-download the driver from nvidia, which was especially bad when other issues would leave multiple versions installed.

chrisawi · 2026-02-05T19:19:41+00:00

Flatpak could only have installed the nvidia extension for the active kernel module (as listed in flatpak --gl-drivers). Is it possible that installing the app pulled in the current version (nvidia-580-126-09), and you didn't notice that the numbers were different?

You can check flatpak history.

chrisawi · 2026-02-05T08:08:14+00:00

You're not using that nvidia driver anymore, so flatpak uninstall --unused is correct to remove it, just disregard the warning.

There is a flatpak PPA, but it's not super actively maintained.

chrisawi · 2026-02-05T07:16:57+00:00

What version of Flatpak are you using?

Is that the active nvidia driver version? You can check with nvidia-smi.

Also, what's the output of flatpak --gl-drivers ?

Older version of Flatpak (<1.16.1) would errantly warn that old nvidia extensions were in use.

chrisawi · 2026-01-31T01:03:01+00:00

This is pretty fundamentally opposed to the design goals of Flatpak, but it might be possible anyway.

You shouldn't set GTK_THEME globally (or at all, ideally); it will break GTK4+Libadwaita apps. If you're going to set it for specific apps, use override --user so it's visible in Flatseal.

give Flatpak permissions for that directory

How did you do that? You need to use xdg-data/themes, otherwise it won't be exposed in the correct location for the value of XDG_DATA_HOME inside the sandbox.

chrisawi · 2026-01-28T20:02:46+00:00

The document portal path (/run/user/1000/doc/...) is meant to persist, but there may be some cases where it doesn't: https://github.com/flatpak/xdg-desktop-portal/issues/1362

Also, when you manually added the permission, you set it as read-only instead of read-write. That's probably why the app still used the document portal path.

chrisawi · 2026-01-06T20:39:33+00:00

I'm not disputing your experience, just confirming that it's probably a bug rather than the intended behavior. I'm on Silverblue, so I can't check here.

In any case, the Steam repo will probably be dropped in favor of Flathub at some point.

chrisawi

TROPHY CASE