Provide an official flatpak on flathub

[Hofer-Julian]

First, thanks a lot for your work. GitButler is fascinating, and I'd love to use it on a regular basis.

Since .deb packages are specific to Debian-based distributions and AppImage doesn't work on Wayland, I'd love to see if you'd take over the flatpak on flathub and fix the remaining paper cuts.

The (seemingly) flatpak specific ones that I noticed are:

• git binary cannot be found (probably best to package it within the flatpak)
• it cannot access git repositories after restart (I would just give it access to the whole home folder)
• it attempts to acccess some D-Bus service (need to figure out which one and poke a whole for it)

I also hope that #5609 helps here

[Byron]

Thanks a lot for the suggestion, and the helpful tips as well!

• git binary cannot be found (probably best to package it within the flatpak)

Most Git clients I tried ended up doing this, even though a FlatPak release seems to be a special case of this as to GitButler, git would just natively appear in the PATH if it's bundled? This is more of a rhetorical question, as I know nothing about FlatPak really.

• it attempts to acccess some D-Bus service (need to figure out which one and poke a whole for it)

This is probably keyring crate trying to read previously stored secrets from the system keychain. #5753 updates it to the latest version, which may also affect how this works on Linux.

CC @ndom91 who knows all about our FlatPak setup.

[ndom91]

Interesting timing haha. I've been working on a replacement flathub repo here for the past few days.

Building the app from scratch and bundling git seems to fix most issues. I also have pretty lenient flatoak sandbox rules atm, so maybe that's avoiding the dbus issue you're referring to.

Everything seems to work building the debug build locally. However I can't get the release build to build locally yet, I think that's a more general rust / tauri issue with my build system though. The tauri build process just segfaults toward the end.

The build/bundle GHA is also not quite working yet, but that one seems more easily fixable. It can't find the appstream-compose binary, even though its installed. Some bubblewrap issue probbaly

I've tried reaching out to the existing flathub gitbutler maintainer on our discord, they're a member, but haven't heard back.

[ndom91]

Also side note, the appimage doesn't work on wayland for you? I use it on Hyprland and another Ubuntu 24.04 gnome box regularly, what issues are you running into?

Alternarively, you can force gitbutler to run as an xwayland window by prepending the following env var to launching the appimage, i.e.

GDK_BACKEND="x11" ./GitButler.AppImage 

[Hofer-Julian]

@Byron

Most Git clients I tried ended up doing this, even though a FlatPak release seems to be a special case of this as to GitButler, git would just natively appear in the PATH if it's bundled? This is more of a rhetorical question, as I know nothing about FlatPak really.

Maybe you are more familiar with Docker? Flatpak behaves very similarly. Inside the container there's a filestructure resembling a classical unix file structure. If you put an executable into /usr/bin it will be in your PATH

[Hofer-Julian]

@ndom91

Interesting timing haha. I've been working on a replacement flathub repo here for the past few days.

That's awesome. Let me know when you can need a second pair of eyes for something

I've tried reaching out to the existing flathub gitbutler maintainer on our discord, they're a member, but haven't heard back.

Are you part of the GitButler team? If the current maintainer is unresponsive, don't hesitate to reach out to flathub maintainers. They will help to transfer ownership of the repository.

Also side note, the appimage doesn't work on wayland for you? I use it on Hyprland and another Ubuntu 24.04 gnome box regularly, what issues are you running into?

The AppImage started on my Fedora machine. I don't know if it used Wayland or XWayland behind the scenes. I was actually under the impression that AppImage is completely incompatible with Wayland because of this gist by the AppImage creator. When trying it out, I've hit the mentioned clipboard problem, which is why I couldn't log into GitButler and therefore also not GitHub. And of course it doesn't install a desktop file and doesn't have an icon.

[ndom91]

Oh interesting, I'd never seen that gist. No so generally our appimage should "just work"😅. Of course not installing a desktop file, etc. is definitely annoying, but we've worked around the open external links and clipboard problems afaik

I am on the gitbutler team, and yeah if it comes time to release it and I still haven't heard back then I'll reach out to the flathub team.

Once I can get the release build building either locally or in CI I'd be happy about some more testing and feedback! I can ping you back in this issue with a download link if that's cool 🙏

[Hofer-Julian]

Once I can get the release build building either locally or in CI I'd be happy about some more testing and feedback! I can ping you back in this issue with a download link if that's cool 🙏

Yes, please do that 🤝

[ndom91]

@Hofer-Julian alright so I've got it building the release build in CI finally. Unfortunately this still doesn't seem to communicate with the keyring correctly. I can login and everything works fine, however, as soon as I hard reload the application, or close / reopen it, the auth token is gone.

Looking into the keyring, it doesn't look like anything is ever written into there.

Anyway, besides for that I haven't found any big issues yet: https://github.com/ndom91/gitbutler-flathub/actions/runs/12223161843

[Hofer-Julian]

Awesome!

Actually, I cannot reproduce your problems.
It stores both GitButler and GitHub credentials just fine for me.
If I restart the application, I am still logged in.

[Hofer-Julian]

Copying link when logging into GitButler still doesn't work. Seems like I wrongly blamed AppImage for that. If I press on the whole field in order to trigger opening the browser instead, logging in works just fine.

[Byron]

Looking into the keyring, it doesn't look like anything is ever written into there.

Maybe you could try again with #5753 applied? It updates the keyring crate and maybe that changes something to the better.

[ndom91]

@Hofer-Julian oh great news then haha. I'm testing this on a pretty vanilla Ubuntu 24.04 VM though so I can't be the only one having this issue 🤔

However, on my local nixos system I can't reproduce the keyring issue either. I can, however, reproduce the clipboard issue

@Byron I'll give your keyring crate PR a test tomorrow

[Hofer-Julian]

The copying is especially weird, since copying works just fine during the github authentication process.

[ndom91]

@Byron #5753 didn't seem to help in this case unfortunately :(

That Ubuntu box still doesn't seem to write the info the password keyring. Also maybe notable, but its not working on both Ubuntu 24.04 VMs I have - one on my desktop at home and one on my laptop at work. They're both super vanilla gnome installations of 24.04.

[Hofer-Julian]

That Ubuntu box still doesn't seem to write the info the password keyring. Also maybe notable, but its not working on both Ubuntu 24.04 VMs I have - one on my desktop at home and one on my laptop at work. They're both super vanilla gnome installations of 24.04.

Mmmh, but the AppImage or deb package adds the keyring entry correctly?

[ndom91]

That Ubuntu box still doesn't seem to write the info the password keyring. Also maybe notable, but its not working on both Ubuntu 24.04 VMs I have - one on my desktop at home and one on my laptop at work. They're both super vanilla gnome installations of 24.04.

Mmmh, but the AppImage or deb package adds the keyring entry correctly?

Correct and the same flatpak works well in my normal desktop nixos environment haha

Maybe something that Ubuntu is missing out of the box 🤔

[Byron]

@Byron #5753 didn't seem to help in this case unfortunately :(

Too bad, thanks for giving it a shot. But maybe there is still hope - there are plenty of linux-features that one can enable to use different credential stores. If any of that makes sense to you, maybe that is something you could additionally try - it should be as easy as picking different cargo-features in the Cargo manifest that declares the keyring dependency.

[ndom91]

Yeah tbh I don't think its an issue on the side of our code / the keyring crate though at this point. Everywhere we've tried so far has worked (granted a small sample size 😅) except the two vanilla Ubuntu 24.04 VMs I have.

So I'm thinking more that Ubuntu just doesn't come with somethign critical pre-installed. Pulling on that thread some more:

• It does have gnome-keyring installed as well as the gnome seahorse GUI for viewing your keyring.
• The AppImage / deb installations can interact with the keyring successfully on those same systems
• Maybe its some desktop portal / dbus communication issue? 🤔

Any other thoughts?

[Hofer-Julian]

One other thing one could try is this crate: https://crates.io/crates/oo7

On Linux it is actually preferred, since it stores the secret in a way that only GitButler can see it but not other apps.

[Byron]

Thanks for the suggestion, this is one of the coolest names for a crate for sure!

It seems Linux only and using it here would mean some effort as keyring is probably the best place to make it available in. And then we'd still not know if it makes a difference.

Trying different cargo features for keyring would be the first thing to try… but trying the cli of 007 might be even easier.

And speaking off, keyring also has a CLI - this should make trying different features trivial to find something that works consistently.