gitbutlerapp
Provide an official flatpak on flathub
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 https://github.com/gitbutlerapp/gitbutler/pull/5609 helps here
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.
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.
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
@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
@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.
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 🙏
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 🤝
@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
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.
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.
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.
@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 :thinking:
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
The copying is especially weird, since copying works just fine during the github authentication process.
@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.
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?
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 :thinking:
@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.
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 :sweat_smile:) 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-keyringinstalled 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? :thinking:
Any other thoughts?
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.
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.
Hey folks, a quick update - we're getting ready to release a first-party flatpak. I've been working on the build at https://github.com/ndom91/gitbutler-flathub. There you can find the latest build artifact (a .flatpak file you can install with flatpak install ..) under the github actions (i.e. https://github.com/ndom91/gitbutler-flathub/actions/runs/12789271694).
I've been in touch with the author of the community com.gitbutler.gitbutler flathub package that's already out there and I will just commit our changes into that repository once we're ready and then going forward we'll maintain that together.
So long story short, if you're already using the flathub package - it should work better and require no changes from you other than updating it.
We'd love any and all feedback you may have on it already, if you're up for trying out an experimental release, you can download it from the GHA linked above :pray:
EDIT: Updating the keyring feature from linux-native to the dbus one (sync-secret-service) fixed that secret store issue btw :partying_face:
Unfortunately that secret store feature didnt work in a "vanilla" GitButler build on linux for me. Same is true for the "mixed" feature (linux-native-sync-persistent). So I've kept the upstream one untouched at linux-native and added a little patch to the flatpak build to swap the feature to sync-secret-service there.
Hey. Just following up on this – what's the latest status? The Flatpak version (0.13.8) appears to be outdated
We aren't maintaining the flatpack distribution, so for now one would have to reach out to its maintainers for an update.
We aren't maintaining the flatpack distribution, so for now one would have to reach out to its maintainers for an update.
@ndom91 announced a few comments before that you are working on a first-party flatpak. I assume that's what @andre0xFF was referring to 🙂
Right, and thanks :D! This isn't actively worked on right now, but I imagine it increasing in priority once GitButler reaches version 1.0 .
Hi everyone, I'm also experiencing the same issues. it appears GitButler hasn't been updated on Flathub for over a year.
While @ndom91's PR (https://github.com/flathub/com.gitbutler.gitbutler/pull/104) is excellent, we haven't yet been able to resolve the issue with pnpm. I believe we should at least continue updating the package using the repackaging approach in the meantime. I've opened a PR here: https://github.com/flathub/com.gitbutler.gitbutler/pull/126, could someone please review it?
Thanks for taking the lead in this!
I did review and "approve" the linked PR, and maybe we can get this update out even before all problems that it may have are resolved. Also pinging @slarse as he probably uses Linux and is much closer to the tech-stack.
I don't think I've ever installed a flatpak, it's not really used much in my neck of the woods and wasn't around back when I was in the neck of the woods where it seems to be more popular. I'll definitely look into it now that I'm setting up a Debian machine to start working out compatibility kinks.
I've taken over the maintainership of the package on Flathub and have merged https://github.com/flathub/com.gitbutler.gitbutler/pull/126. If anyone from the GitButler team is interested in maintaining this package in the future, please fell free to reach out for access.
Some of the issues mentioned by @Hofer-Julian here remain unresolved, as they require changes to the default permissions. I've opened https://github.com/flathub-infra/flatpak-builder-lint/pull/772 to address this. In the meantime, you can manually grant the necessary permissions using a tool like Flatseal.
With the merge of https://github.com/flathub/com.gitbutler.gitbutler/pull/127, all reported issues should now be resolved. Please give it a test and let me know if you find any other problems.