Signal-desktop: Please provide a distribution-neutral snap package for GNU/Linux

[tcarrondo]

It would be nice to have the app distributed as a snap.
It would make ##installation/update so much easier (and more secure) for lots of distros.

[scottnonnenberg]

If you could provide links to snap documentation about updates, that would be useful. Also, it would be helpful to contrast Snap with AppImage and FlatPak. Thanks!

[Dyras]

@scottnonnenberg I think the biggest question here is: Are you willing to support both Snap and Flatpak? If you're only willing to support just one, I'd say Flatpak is the obvious choice for one simple reason: It has a larger adoption rate with the distributions.
https://kamikazow.wordpress.com/2017/02/09/adoption-of-flatpak-vs-snap/
https://www.phoronix.com/scan.php?page=news_item&px=Snaps-v-Flatpaks-Linux-Distros
"He found that generally the latest Flatpak version was available on all of the latest distribution releases. However, he found that Snap was only using the latest version in Ubuntu 17.04 Zesty and Debian Stretch. Snap support in Ubuntu was out-of-date, Fedora doesn't have the support in the main repository on F25, the Gentoo Snaps were outdated, the openSUSE support was outdated, and on Mageia the support wasn't even available. "

An easy to read summary of the differences between them can be found here:
https://www.maketecheasier.com/snap-packages-vs-flatpacks/

Key differences:
Flatpaks aren't as centralized as Snaps. Flatpak is available for most distros while Snaps are as of today, really only available on Ubuntu.
Flatpak is more focused on desktops, Snaps is "server technology" - I doubt it makes a difference though
Flatpak uses SELinux for security, Snap uses AppArmor - I'm going to be honest with you, I can't tell which one is better.

Interestingly, Signal is already on Flatpak
https://flathub.org/apps.html
If you contact Flatpak you can claim ownership of it and update it whenever you want. Since Flatpak is supported on the major distros I think you would be crazy to create PPA's and shit instead of just using Flatpak.

Using Flatpak is really simple:
https://flathub.org/index.html#using
"If you are on Arch, Debian Stretch (or later), Endless OS, Fedora 25 (or later), Mageia 6 (or later), or OpenSUSE Tumbleweed, you can download the repository file and use GNOME Software to install it."

AppImages are available for lots of distros too, but they aren't sandboxed so I think choosing AppImages for a security focused Messenger would be a weird choice.

[ghost]

+1 for Snap.

Snaps are simpler for developer and end users.

This video sums up the differences between both formats, debunks a few myths about snaps, and shows the process of creating a "Hello world" script in snap and flatpak packages.

https://www.youtube.com/watch?v=ixWuE1hhZfw

[philipzae]

You can find a comparison chart of snap, flatpak and appimage here.

https://github.com/AppImage/AppImageKit/wiki/Similar-projects#general

[diazbastian]

@philipzae That comparison seems somewhat biased 🙃

Snaps are simpler for developer and end users

@drakofrost I am an end user and it is not easy to use Snaps outside Ubuntu and derivatives. You have to resort to unofficial repos and perform additional configurations (for many distros there is only devmode support or even no support for classic snap, etc.)

[philipzae]

@diazbastian what comparison is 100% unbias :smirk:, but it definitely has alot of facts in it with references

[cornfeedhobo]

It's a bunch of JS, do we really need Snap/Flatpak/AppImage at all? These tools are not the panacea they claim to be. I work with plenty of linux users and only 2 of us have a distro that even supports Snap!

Looking at package.json shows the build invocation process is already an abstracted mess; why not focus on simplifying that?

Going with this argument, Signal's requirements appear to be static: desktop menus, icons, etc, but nothing complicated. I would suggest a generalized builder like pacur before chasing a nascent technology. Please give this some consideration. If anyone from the project would like me to take this on, please reach out and I'd be happy to.

[om26er]

I am willing to contribute the snap support for the Signal Desktop, I'll also commit to help for at least a few months as a surety. I have already snapped Android Studio, Crossbar and Sublime Text so I do have some experience there.

Its a little disappointing that there is misinformation being spread here regarding that technology. First I want to clear that I have verified snaps to work without a problem on openSUSE and Ubuntu (and its derrivates) and KDE Neon and I am told other distros are supported as well https://docs.snapcraft.io/core/install.

The snapcraft guys provide a great tool for automatic builds (http://build.snapcraft.io), which will really make things simpler for us.

[cornfeedhobo]

@om26er There is no misinformation that I have read. Just going with your example of OpenSuse, while I'm sure you have gotten it to work, it's not an official package manager yet.

Please, let's just use the package managers that exist and are wide spread.

[Kedstar99]

If there is a decent CI mechanism in place, it should already be simple to support all of these distribution mechanisms. They already use electron-builder which supports snaps, apk, appimages, debs, rpms etc.. All it requires is to test the system and then have a CI to deploy the releases to various locations.

[popey]

It's great to see some interest in having a snap of signal-desktop.

I've built and published the latest stable build of signal-desktop to the store. It's build from a checkout of 1.7.0 in a clean Ubuntu 16.04 container.

It can be installed on systems which support snaps with snap install signal-desktop.

https://snapcraft.io/signal-desktop

As I understand it upstream developers don't have resources to manage this right now. I'm happy to keep publishing it regularly to the snap store under the snapcrafters name, but equally happy to hand it over to upstream so it can be more officially published.

<3

[ghost]

Thanks a lot @popey

[Natanji]

@popey I am having some trouble with this snap package. On my system, I have to use the --classic switch because otherwise the app will fail to start. So I have ~/snap/signal-desktop and within that, there's a folder "83" and a folder "90". Back when I installed it, it was only "83" there and within that folder, the app created a .config/Signal directory to store the settings and messages.
But after the app got updated and the "90" folder appeared, the .config/Signal directory was not copied over to the "90" folder. I had to manually do this in order for the updated version to access the saved conversations. I assume I will need to do this again once Signal gets updated the next time.

I don't know where else to post such a bug report so that's why I do it here.

[popey]

@Natanji hi! I'd recommend filing issues against the snap at the snapcrafters repo. My apologies, the store didn't have that link, but does now.

Sorry to hear you're having problems. Let's move the conversation over there.

[andrejpodzimek]

Currently the snap package doesn't work on Debian at all. It has seccomp permissions issues, most likely because the accept syscall is not allowed. This leads to an infinite loop with multiple CPU-hogging processes (Signal itself, a ChromeIOThread another one and systemd-journald flooded by the audit log entries yet another one). It looks like Signal is trying the accept syscall over and over again, but it's banned. I tried to allow accept somehow somewhere (/var/lib/snapd/apparmor/profiles), but it had no effect and the error message was still the same. I think it may be related to this issue.