Signal-Desktop
Signal-Desktop copied to clipboard
Please provide a distribution-neutral AppImage for Linux
- [x] I have searched open and closed issues for duplicates
Bug description
Currently the application is provided only in .deb
format, which makes it hard to use on anything but Debian/dpkg-based systems.
Steps to reproduce
- Run Fedora
- Try to install Signal Desktop
Actual result: Many (undocumented) manual steps need to be executed on the command line Expected result: As the user, I can download a single file (like an .exe for Windows or a .dmg for macOS) for Linux, and run the application with minimal fuss
Platform info
Operating System: Linux desktop OSes like Fedora, CentOS, or lesser-known ones not based on deb
Recommendation
Providing an AppImage (as has been requested, e.g., here) would have, among others, these advantages:
- Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
- One app = one file = super simple for users: just download one AppImage file, make it executable, and run
- No unpacking or installation necessary
- No root needed
- No system libraries changed
- Works out of the box, no installation of runtimes needed
- Optional desktop integration with
appimaged
- Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
- Can optionally GPG2-sign your AppImages (inside the file)
- Works on Live ISOs
- Can use the same AppImages when dual-booting multiple distributions
- Can be listed in the AppImageHub central directory of available AppImages
Here is an overview of projects that are already distributing upstream-provided, official AppImages.
electron-builder, which this project is using, has built-in support for generating AppImages. It is literally as easy as changing
https://github.com/WhisperSystems/Signal-Desktop/blob/475e9020eddc8b224920e45d2ed193be8bce305d/.travis.yml#L12
to
- ./node_modules/.bin/build --em.environment=$SIGNAL_ENV --config.mac.bundleVersion='$TRAVIS_BUILD_NUMBER' --publish=never --linux=AppImage
i.e., adding --linux=AppImage
.
If you have questions, AppImage developers are on #AppImage on irc.freenode.net.
An example AppImage built on Travis CI is available on https://github.com/probonopd/Signal-Desktop/releases.
I could settle for an RPM for Fedora/RHEL/CentOS. As for AppImage, there's the question of whether one should use a Snap, a FlatPak, or AppImage for multidistro distribution.
As for AppImage, there's the question of whether one should use a Snap, a FlatPak, or AppImage for multidistro distribution.
They have different objectives and different principles. As for AppImages, it's ease of use, "one app = one file", needs no special runtimes to be installed before you can run it. And thanks to --appimage-extract
, it can double as a self-extracting compressed archive, too.
I could settle for an RPM for Fedora/RHEL/CentOS. As for AppImage, there's the question of whether one should use a Snap, a FlatPak, or AppImage for multidistro distribution.
You can find a comparison chart of appimage, snap and flatpak here https://github.com/AppImage/AppImageKit/wiki/Similar-projects#general
I want to rant about this each time I see I don't have signal for desktop anymore, but then I remember you're a small team and ISO a desktop dev. So, best of luck :) many many many many many of us would love something independent of Ubuntu/Debian. I also know a lot of BSD people would like this too, so perhaps even having something that is just easy to build from source would be great. I wouldn't mind building my desktop app for *Linux and *BSD (I think)
electron-builder
can build AppImages.
I'd also like to see something other than a .deb
, we mostly run Fedora desktops, an rpm
or an AppImage
as suggested, would be great.
Does anyone have a working script to build the appimage locally?
Note that you can install it on Fedora through dl.flathub.com. I'm not sure what settings you need to change, if any, to get it to appear in the GUI software installer (Software), but it shows up there for me when I search.
Sorry I don't have an AppImage build recipe for you, adnion.
Thank you for your reply. I found it: https://flathub.org/apps/details/org.signal.Signal But sadly it's flatpak package format only.
Looking at the many thumbs-ups in this ticket, it seems that there is considerable demand for an AppImage. @liliakai, @scottnonnenberg what do you think? Would you entertain a PR?
As Slackware user I'd like to vote for an official Appimage, too. Even Wire has one.
I just think they need to get off the "cross platform" base known as Electron. They tout security, yet they use the most bloated method possible to provide "cross platform" support. Really what they did was limit their userbase to Windows/Linux/some Linux and knocked out the rest who had access to a chromium-based browser. If this was an intermediary solution I think it would be reasonable and fair as they built something in, say, C++ or whatever so it could be easily cross-compiled even on BSD operating systems.
My PR for AppImage support was declined, so I'd like to bump this conversation to find out what @scottnonnenberg-signal feedback is and what needs to happen to get this approved. I've been using my AppImage build for months on Fedora but just switched to Ubuntu so don't really need it anymore. But when I ran across this issue, I figured it might help out others.
So, back to the question: what needs to happen to get AppImage approved?
AppImage is the only format where users can simply download the file and run it, regardless of Linux distribution. No daemons or other special requirements for users, unlike Snap and FlatPak. If it's already supported by the build system Signal Desktop is using, then it can only benefit the community to enable it. A single-file executable is the simplest way by far for a user to test the software; no fussing with Apt.
I find it odd that the PR was rejected outright for being a "new platform to support" given that an AppImage is literally just a fancy archive format. Because Signal Desktop is not compiled, there can't be a "static build" so this would be the next best thing.
I hope Signal will reconsider, given that it seemingly would involve no additional work.
Great work @kevinsarsen https://github.com/signalapp/Signal-Desktop/pull/3055 I really hope @scottnonnenberg-signal has some time to decide about this.
https://www.andreafortuna.org/2019/03/27/how-to-build-signal-desktop-on-linux/ describes how to build a Signal AppImage.
A test one is available from https://cdn.andreafortuna.org/Signal-Desktop-Beta/.
Has their been any communication somewhere on why this isn't being accepted/done? I'm setting up an Arch laptop for work and while there exists an AUR package for signal, it would've been much nicer to find a .AppImage
from Signal officially a la Bitwarden.
Since there is no web client signal becomes impossible to use on devices where you're not able to install the software as well (e.g, my home university). Running an AppImage is allowed there and thus I support this ticket!
so since the fedora snap version is not working for over a month. I would like to see a appimage version also.
+1. AppImage is basically the Linux equivalent of .app bundles on macOS:
- Totally portable with no external depenencies
- Built and distributed in-house (i.e. from https://signal.org/download/)
- can offer regular updates without waiting for distributions or maintainers
AppImage enables you to offer a single Linux download that will work on all distros out-of-the-box (unlike Flatpaks or Snaps which rely on users having access to a particular appstore or package manager).
I downloaded and ran ./Signal 1.25.0-beta.4.AppImage
It's not even that old, but it refuses to work. Lovely. :roll_eyes:
To build according to the AUR the LTS nodejs
is needed, but I need the latest nodejs
for something else, and they conflict. So, yeah, guess I'm not using Signal for now.
https://www.andreafortuna.org/2019/03/27/how-to-build-signal-desktop-on-linux/
Is that for me? I'm no longer interested in Signal due to what I wrote above.
@ctrlcctrlv, where did you download that from? From andreafortuna.org? If so, that's not an official distribution channel and I don't know why you're posting about it in this thread as though it is the developers' fault.
@scottnonnenberg-signal: as others have asked over the past two years, what needs to happen to have an AppImage build process accepted? And if it's not being actively considered, can you please clearly articulate why and close this issue so we stop holding our breath?
It is the developers' fault for so quickly deprecating releases, regardless of the distribution channel. As stated, I have no good way to build it myself, and scarce little time to do so.
@probonopd donated their time to the project and made an AppImage available even though none existed officially. This was a selfless, noble act.
1.25.0 was released on May 31. I tried it on October 29, around five months later.
@probonopd's work was squandered because apparently releases that are five months old are so old that they must be bricked remotely by the server. :roll_eyes:
But yes, please continue to tell me about how it's not the developers' fault that they squandered the community's efforts to fix a problem they have no interest in even addressing.
Meanwhile I'll not bother using this app.
I believe an AppImage should be THE official Linux package for distributing Signal!!! It would allow me to have it anywhere.
Just got the upgrade warning directing me to the Signal download page which only has instructions for DEB-based systems. Still no AppImage, still no RPM.
@scottnonnenberg-signal, please let us know what needs to happen to get this support--maybe we can help!
Asides from technical considerations between AppImage, Flatpak, Snap, RPM and DEB, I am wondering about the political perspective of the Signal developers on this subject.
As far as I know, Signal wants to be a trustable and recommended platform for private and public, end-to-end encrypted messaging. Since a plethora of alternatives exists, and the double ratchet has meanwhile also found its way to What's App, people rely on the network effect to choose which platform to use.
Often it is the recommendation of a privacy-aware person (jargon computer nerd), that helps create new Signal installs worldwide, following Edward Snowden's example. In turn these people are often running Linux themselves, and would also promote it to their peers where feasible. Not supporting this user base on the Linux desktop, and reducing the diversity and variety of Linux to mere Ubuntu, is a drawback against Element and other encrypted messengers.
This issue is open for almost three years, and messaging skyrockets. Linux grew well-tested and hardened, because it combines the efforts of many on multiple platforms. Since distribution formats for supporting all of them exist, it remains to ask what is blocking the decision here to do so?
A real case scenario why an AppImage is essential to build for applications like this as in OT, not because of political reasons, but due to the userbase.
A friend in Germany who is aggressively concerned about the security, but has no knowledge of Linux wanted to install Signal to quench his insatiable thirst for "privacy". He went amok with the installation instructions and wrote back to me . Methought if there would have been an AppImage, I could just point him to the download link and ask to make it executable and run. That was not the case. Thus, I landed to this issue by @probonopd.
If Signal is something that should be handy with everyone who uses linux, an AppImage would be more than useful. However, I build my own Signal from the source, but not everyone is able to do so.
I have a support for what https://github.com/signalapp/Signal-Desktop/issues/1758#issuecomment-712407448 stated above.
Cheers and stay safe.