The idea of packaging Mailspring with Flatpak has been floated before. As the Flatpak ecosystem becomes more mature and widespread, I believe this is worth taking a second look at.
Flatpak is preferred over Snap by many distros, and is presently more widely adopted than Snapcraft across the Linux ecosystem.
Flatpak has a smaller “payload” due to its ability to share dependencies, instead of bringing everything itself.
Flatpak has better integration with system theming and icons.
The related GitHub discussion is here:
One of the major Snapcraft issues that underscore the need to move to Flatpak:
Very happy to see this revisited. Flatpak is quickly becoming the package of choice for most Linux distros and has a good update model for pushing new features etc without tracking down an RPM or DEB.
Has there been any movement on this? I’m happy to contribute if it’s warranted. I have atmoic OSes and would love to pay for mail spring and use the app.
btw… having to create an account on mailspring’s forum to update a bug is a bit annoying.
Sorry for the inconvenience. GitHub Issues simply was not maintainable for this project, and we’ve been in need of a proper community space for some time besides.
I would also like to mention that Flatpak is more universal, but the primary reason I want to avoid snap is its inability to update software nicely.
Once an update for a snap container is released and its installed, the container loses its filesystem and usually starts misbehaving massively, this has already caused me data loss with multiple snap containers and snap developers do not prioritize fixing that issue by-default. Some ugly half-workarounds exist, but I don’t do those. That is an unacceptable risk for me and I want to use Flatpak that doesn’t have caveats like this.
I can only upvote the effort of releasing Mailspring as flatpak. I’m looking for some modern mail client on Linux and having Mailspring as flatpak would be pretty amazing (I’ve tested snaps before but from end user perspective they seem inferior for the reasons outlined above and I don’t see a point in having both on my system).
I was able to unpack the .deb file for the 1.9.1 release and create a flatpak YAML file which installs it using Flatpak. It may not be the prettiest thing, but it works. I’m not a Mailspring user (yet), but I really like the Mailspring UI and wanted to try it out by installing it in a sandbox, so I took a few hours to try getting it to work with Flatpak. I actually have no idea what I’m doing with Flatpak, I started using it less than a week ago and this is my first attempt to package something with it.
These are the steps I took:
mkdir flatpak; cd flatpak
Copy the Flatpak YAML file contents below into a file called com.getmailspring.Mailspring.yml.
mkdir deb; mv mailspring-1.9.1-amd64.deb deb; cd deb
ar x mailspring-1.9.1-amd64.deb to unpack the deb.
tar xvf data.tar.xz . to unpack the data.
cd ..
git init - This is needed for the next step to get libraries to be packaged alongside the app.
git submodule add https://github.com/flathub/shared-modules.git - This gives us a way to package libsecret which Mailspring depends on.
Install the base the flatpak will run on: flatpak install flathub org.electronjs.Electron2.BaseApp//20.08
Install NodeJS for Electron to run (not sure this is necessary): flatpak install flathub org.freedesktop.Sdk.Extension.node14//20.08
flatpak-builder --user --force-clean --install dist com.getmailspring.Mailspring.yml to build and install Mailspring locally with Flatpak.
Voila! Mailspring is installed with Flatpak. Use flatpak run com.getmailspring.Mailspring to run it.
Known Issues
After quitting Mailspring, the sync process sticks around for just a minute while syncing. You can see it with ps aux | grep mailspring. It quits after a bit, so maybe this is the normal behavior for syncing.
I’m not sure if I stripped down the flatpak yml file enough, or if other libraries need to be added. For me, I can see the system tray icon and sync my email account just fine, I just don’t know if anything is missing feature-wise.
I haven’t taken much time to see how to get or generate a .desktop file so I can launch the app outside of the terminal. I may get it working at some point, but I hope others can fill the gap here.
Following the Slack Flatpak manifest as an example, I think I’ve gotten to a pretty good place with this. I copied the Mailspring .desktop, appdata.xml, and icon png files to the root flatpak directory I made, then changed the Flatpak yml file to look like this:
I’m actually working on a source build of mailspring for flatpaks, this would in theory allow us to support arches like armv8. There was actually already an attempt to submit a flatpak using the deb to flathub that was turned down due to the fact there is nothing preventing a source build. Could the team bump the cld version to 2.7? 2.6 can’t be built since its missing some #include <exception> in certain files.
could someone help me with building mailspring offline? I’ve gotten to past installing deps. Attempting to build the Mailspring it makes network requests which doesn’t work
Not working on Fedora 35
❯ flatpak run com.getmailspring.Mailspring
[2 preload-host-spawn-strategy] Running: /app/bin/zypak-helper child - /app/share/mailspring/mailspring --type=zygote
The futex facility returned an unexpected error code.
Failed to generate minidump.%
I’m not a Mailspring user (yet), but I really like the Mailspring UI and wanted to try it out by installing it in a sandbox, so I took a few hours to try getting it to work with Flatpak. I actually have no idea what I’m doing with Flatpak, I started using it less than a week ago and this is my first attempt to package something with it.