ive installed 6.10 and 6.11 please help me.

Is this a problem on wivrns end or is my stuff kis?

When I try to update the bottles, it fails and I get this message Warning: While pulling runtime/org.freedesktop.Platform.GL32.default/x86_64/26.08 from remote flathub: While fetching https://dl.flathub.org/repo
/objects/94/6c2b5c57340e5c6b6a8e13f881976167d28161e42c45d5d6876cbeba64fb66.filez: [92] Stream error in the HTTP/2 framing layer
Warning: While pulling runtime/org.freedesktop.Platform.GL32.default/x86_64/26.08-extra from remote flathub: While fetching https://dl.flathub.or
g/repo/objects/94/6c2b5c57340e5c6b6a8e13f881976167d28161e42c45d5d6876cbeba64fb66.filez: [92] Stream error in the HTTP/2 framing layer
Installation complete.

I've tried all the solutions. I checked that I can update other FlatHub apps and download them without problems. I checked my network and tried this command "flatpak repair", but unfortunately, it's the same thing.

I'm working on a small screenshot/OCR app called FrameXShot (Tauri + Rust), and I'm running into some weird Linux packaging issues specifically on CachyOS/Hyprland.

The app itself works fine when built/run natively, but the packaged versions are where things get messy. AppImage issue

I tried building the AppImage locally on CachyOS with:

cargo tauri build --bundles appimage

The build doesn't even get as far as producing an AppImage. It fails inside linuxdeploy while stripping bundled libraries.

The interesting part is that CachyOS is currently using binutils 2.47, while the linuxdeploy bundled by Tauri appears to contain an old GNU strip 2.35.

The newer CachyOS libraries contain .relr.dyn ELF sections, which the old strip doesn't understand.

The error looks roughly like:

unknown type \[0x13\] section '.relr.dyn'

and it happens with multiple libraries, including things like:

libwayland-client
libwebkit2gtk
libudev
libxml2
libzstd

So this seems less like a FrameXShot problem and more like an old linuxdeploy toolchain being used against a rolling-release distro.

I'm trying to figure out the cleanest solution here. Ideally I'd like the AppImage to be buildable on Arch/CachyOS without hacking the linuxdeploy binary. Flatpak issue

The other problem is the Flatpak version.

FrameXShot has several screenshot fallbacks. On my Hyprland setup I have:

grim
slurp
xdg-desktop-portal-hyprland
xdg-desktop-portal-gtk
xdg-desktop-portal-kde

The Flatpak can see/use the portal, but the direct portal screenshot call is returning NotAllowed.

The code is currently calling:

org.freedesktop.portal.Screenshot.Screenshot

with something along the lines of:

interactive=false
modal=false
filename=file:///tmp/...

I'm not convinced adding more Flatpak permissions is actually the answer. The manifest already has access to the relevant portal interfaces, and the app is clearly reaching the portal.

I'm currently testing the portal independently with gdbus to determine whether:

the portal supports interactive screenshots but not non-interactive ones,
the options we're passing are wrong,
Hyprland's portal backend has a limitation/bug,
or there's some other issue with the session.

For example, I'm comparing an interactive call against a non-interactive call using target=1 (screen). Where I'm at

So at the moment I have two separate Linux problems:

AppImage: Tauri's bundled linuxdeploy appears to have an ancient strip which can't handle modern CachyOS ELF sections.

Flatpak: Screenshot portal calls return NotAllowed on Hyprland, and I don't want to blindly throw more finish-args at it without understanding why.

The .deb package from the latest release is another path I'm testing since it avoids both the AppImage and Flatpak layers.

Has anyone here dealt with either of these?

Especially interested in:

Building Tauri AppImages on Arch/CachyOS with modern binutils
Replacing/updating the linuxdeploy binary Tauri uses
Getting xdg-desktop-portal Screenshot working correctly on Hyprland
Whether interactive=false + target=1 is actually supported by xdg-desktop-portal-hyprland
Whether there's a recommended packaging approach for Tauri apps on rolling-release distros

I'm mainly looking for the "proper" fix rather than a workaround that happens to make one machine work.

Repo is here:

[https://github.com/sahilcodexx/framexshot\](https://github.com/sahilcodexx/framexshot)

Thanks!

Hello! My FDM (Free Download Manager) which I install via Flatpak, doesn't seem to recognize my browsers.

I am on Fedora 44 Gnome version.

There is no native .rpm package available, only a .deb on, and a link to it's Flathub page, which I followed to install it.

And yes, I do have the browser extension, I also did search before asking here, didn't find any easy and straight forward solution. Only a way to apparently install the .deb package on Fedora which has a small chance of working, and uninstalling it is a pain. I don't really wanna go that route.

What to do?

I've created an app for automatic sync between local machine to (or from) a home NAS - after not seeing anything similar online.

The project was built almost entirely using Claude Code, aside from the high-level architecture, design, and the development tools I selected beforehand. right now its mainly finished, besides bugs I find and fix here and there.

I want to publish it in order to contribute to the community :), but I understood here that there is a strict approach towards heavy leaning on AI use - which in my case, it is massive. I'd like to know what my next moves should be in order to publish it.

For context I'll say that I work with code a lot as an engineer at a large american HW corporate, so programming fundamentals are nothing new to me. At work the leaning on AI is huge, and even forced at most cases - so using it for private projects sounds trivial to me.

I ship a GTK4 Markdown editor (Marco) and its standalone preview companion (Polo) as one Flatpak, io.github.ranrar.Marco — two binaries, two exported .desktop files, one app ID. They're launched from each other, which is why they share a sandbox.

Everything works except one thing: GNOME Resources labels the running editor "Polo" — and sometimes it doesn't, depending on the install.

Why it happens

resources keys apps by the X-Flatpak= field, and Flatpak stamps the same app ID onto both exported entries automatically. From src/utils/app.rs:

rust let id = desktop_entry .string("X-Flatpak") // first priority .or_else(|| desktop_entry.string("X-AppImage-Identifier")) .or_else(|| Some(file_path.file_stem()?…)) // filename is only a fallback

Both of my entries produce the same ID, so they collide in the app map and one silently overwrites the other. Then lookup is by cgroup:

rust self.apps.get(&Some(process.data.cgroup.clone()…))

Both binaries run under one Flatpak app ID, so they share a cgroup and both resolve to whichever entry survived the collision.

What I tried

• Renaming the desktop files to control sort order. I had a scheme where both were named after their binary (…Marco.markdowncomposer.desktop / …Marco.markdownviewer.desktop) so the editor would come first alphabetically. Then I read the code: enumeration is applications_path.read_dir(), which is unsorted. It's filesystem order, not alphabetical — arbitrary, and liable to flip between reinstalls. The rename also broke my taskbar icons, so it got reverted.
• **NoDisplay=true on the viewer's entry.** No effect — nothing in the enumeration path filters on should_show().
• Suppressing X-Flatpak on one entry. Not possible; Flatpak adds it during export, I don't control it.

So it isn't even a stable wrong label I could shrug at and move on. It's a coin toss per install.

The question

Is there anything left on the packaging side, or is this just an upstream limitation? As far as I can tell the only real fix is in Resources: when several desktop files share an X-Flatpak ID, prefer the one whose basename equals that ID. That seems small and well-defined, and I have a clean reproducer.

Happy to file it (and the reproducer) at https://github.com/nokyan/resources/issues — but I'd rather first hear from anyone who's hit this with a multi-binary Flatpak and found something I've missed. Also curious whether other monitoring tools (mission-center, btop's app view, GNOME's own System Monitor) handle the multiple-desktop-files-per-app-ID case any better, since I've only tested Resources.

I tried to update my Flatpak packages, but it's taking a very, very long time.
Could it be that Flathub is down, or am I the only one?

flatpak update -vv  
F: No installations directory in /etc/flatpak/installations.d. Skipping
F: Opening system flatpak installation at path /var/lib/flatpak
F: Opening user flatpak installation at path /home/sven/.local/share/flatpak
Looking for updates…
F: Fetching summary index file for remote ‘flathub’
F: Loading https://dl.flathub.org/repo/summary.idx using curl
F: Received 10001 bytes
F: Fetching indexed summary file 34abf2ee91b7a0b429589ec611bf1bd6fe9836088b12fb7717ce149b143494bd.gz for remote ‘flathub’
F: Loading https://dl.flathub.org/repo/summaries/34abf2ee91b7a0b429589ec611bf1bd6fe9836088b12fb7717ce149b143494bd.gz using curl
F: Should retry request (remaining: 5 retries), due to transient error: While fetching https://dl.flathub.org/repo/summaries/34abf2ee91b7a0b429589ec611bf1bd6fe9836088b12fb7717ce149b143494bd
.gz: [28] Timeout was reached
F: Loading https://dl.flathub.org/repo/summaries/34abf2ee91b7a0b429589ec611bf1bd6fe9836088b12fb7717ce149b143494bd.gz using curl

Hello everyone,

I am Hima the developer behind BetterStickies app, it is a unique productivity desktop app with features that don't exist in any other app, so it isn't a low effort app by any mean.

Currently I distribute it on windows as .exe and in MS store, Linux as app image and .snap in snap store, I recently found increasing number of Linux users which makes me happy as a Linux user and I am planning to publish it to Flathub for broader reach.

The issue is the app is freemium so the free version includes all features by limited by 4 concurrent notes max, while the premium is one time payment with no limits, but the app is offline so there is no way a user on snap store or flathub can have the premium version without downloading and using the app image for the premium version from the official website.

My concerns are two, will my app be approved to be published to begin with? Will users be pissed about not being able to upgrade to premium via flathub, should I make a premium version as a flatpak and provide it in premium downloads binaries on the website?

Finally, is it worth the hassle and development or the discoverability of the app won't improve much by being listed on Flathub?

Thank you and please feel free to ask or suggest anything you may have in your minds.

I use Arch Linux and have Steam (flatpak) and Heroic Games Launcher (flatpak) so basically I have two sandboxes.

I am able to add Heroic game to Steam library but it will not launch.

I have added permissions:

$ flatpak override --user --show com.valvesoftware.Steam  
[Context]
filesystems=/home/vi***/Games/Heroic;
$ flatpak override --user --show com.heroicgameslauncher.hgl
[Context]
filesystems=/home/vi***/.var/app/com.valvesoftware.Steam/data/Steam;

Game settings in Steam:

Target: "flatpak"
Start In: "/home/vi***"
Launch Options: "run com.heroicgameslauncher.hgl --no-gui --no-sandbox "heroic://launch?appName=1207658718&runner=gog""

Game is visible in Steam Library but will not launch.

I've been struggling for days to get the thumb wheel on my Logitech mouse (e.g., MX Master) working for volume control under Bazzite. Since Bazzite relies on an immutable system and Solaar runs as a Flatpak by default, most standard guides found online fail completely.

The problem: The Flatpak runs isolated inside a sandbox. It can neither see the normal rules.yaml in the global system path, nor is it allowed to simulate keystrokes or execute standard system tools directly.

Here is the clean workaround that finally solved it for me:

1. Granting Sandbox Permissions

To allow Solaar to escape its sandbox and send execution commands to the host system, you need to give it this permission via the terminal: flatpak override --user --talk-name=org.freedesktop.Flatpak io.github.pwr_solaar.solaar

Afterwards, completely close Solaar by running: flatpak kill io.github.pwr_solaar.solaar

1. Editing the RIGHT YAML File

Do NOT modify the file located under ~/.config/solaar/! The Flatpak uses its own isolated sandbox storage instead. Delete the old bugged file and open the correct configuration file in your terminal by entering these two commands:
rm -f ~/.var/app/io.github.pwr_solaar.solaar/config/solaar/rules.yaml
and then:
nano ~/.var/app/io.github.pwr_solaar.solaar/config/solaar/rules.yaml

Now, paste exactly the following text structure into the empty file. We are using flatpak-spawn to directly control Bazzite's modern audio architecture (wpctl) on the host system:

%YAML 1.3

• Rule:
  • Rule:
    • Test: [thumb_wheel_up, 10]
    • Execute: [flatpak-spawn, --host, wpctl, set-volume, "@DEFAULT_AUDIO_SINK@", 5%+]
  • Rule:
    • Test: [thumb_wheel_down, 10]
    • Execute: [flatpak-spawn, --host, wpctl, set-volume, "@DEFAULT_AUDIO_SINK@", 5%-] ...

(Save the file in nano with Ctrl + O, press Enter, and exit the text editor with Ctrl + X)

1. Start Solaar & Activate Key Diversion

Relaunch Solaar via terminal: flatpak run io.github.pwr_solaar.solaar

Open the Solaar window, select your mouse, click on the lock icon next to Key/Button Diversion, and change the Thumb Wheel setting to Diverted. Make sure to click Save Changes at the top of the Solaar window.

1. Optional: Set Up Autostart in the Background

To make Solaar run invisibly in the background on every single reboot, just drop this long one-liner command into your terminal:
mkdir -p ~/.config/autostart && echo -e '[Desktop Entry]\nType=Application\nExec=flatpak run io.github.pwr_solaar.solaar --window=hide\nHidden=false\nNoDisplay=false\nX-GNOME-Autostart-enabled=true\nName=Solaar Autostart\nComment=Starts Solaar minimized in the background' > ~/.config/autostart/io.github.pwr_solaar.solaar.desktop

That's it! The thumb wheel now perfectly controls the system volume via Pipewire without spamming your terminal with Python crash errors.

Hope this saves some fellow Bazzite users from pulling their hair out!

Janus is a text editor written in 100% C. It's meant to be the successor to leafpad (same shortcuts), and it's coded with an emphasis on small memory and cpu, trading features for efficiency. It's best at opening small files or binaries through it's fallback binary editor, and also contains an optional sytnax highlighting engine. This update shrinks the install size by around 1 MB. You can download it on flathub: https://flathub.org/apps/dev.pantheum.janus

I was looking for a ChatGPT Flatpak so I could run Codex safely alongside my local dev environment, couldn't find anyone maintaining one, so I built my own.

No OpenAI binaries are redistributed: the payload is an extra-data source, so installs fetch their .deb straight from OpenAI against a pinned sha256, for x86_64 and aarch64. Electron renderers run under zypak instead of --no-sandbox. The remote is GPG signed, and the release gate in CI does a real flatpak install from the published URL with verification on.

Updates are hands-off: a nightly job reads upstream's APT index and re-pins the manifest when a new version appears, so you get the latest even when it lands at 3am my time (I'm an Aussie, timezones are rough).

The sandbox starts sealed and you grant directories with overrides. Main known issue: the app's transparent overlay window (the desktop pet) doesn't composite on Wayland, which upstream has acknowledged as part of their Wayland support still maturing.

flatpak remote-add --user chatgpt https://rulin132.github.io/chatgpt-flatpak/chatgpt.flatpakrepo
flatpak install --user chatgpt io.github.rulin132.ChatGPT

Source: https://github.com/rulin132/chatgpt-flatpak

I'm maintaining it for my own use either way, and if OpenAI ever ships an official Flatpak I'll point people at theirs and wind this down. Bug reports and PRs welcome.

I have about 70 apps all flatpak, inkscape is the only one I have issues with. It is slow to save a 780 mb file, switching tabs in the sidebar takes several seconds - the gui seems to freeze, and when saving this file several times a popup appears saying that inkscape is not responding.

What can I do to get better response times? Should I just use the .deb version? None of the other flatpaks have issues like this including gimp.

In case it matters:

• Ubuntu 24.04.4 LTS
• Wayland.
• Intel® Core™ i7-14700 × 28
• 32GB RAM (2 x DDR5 DIMM 5600MHz Corsair)
• 1TB hard disc with over 400GB free (Samsung 990 PRO (NVMe PCIe 4.0))
• AMD Radeon RX 7600 | 8GB GDDR6

I have flat seal installed but have never really used it as I don't know what all the settings do really and didn't want to make things worse.

I can use several apps at the same time, like OBS, handbrake, Kdenlive, Browser with videos playing and play games on steam all at once without any issues, but inkscape - even when the only app running - is slow to do everything. Small files don't exhibit these issues. 780MB doesn't seem that large to me.