Signal-desktop: Please provide a distribution-neutral AppImage for Linux

[probonopd]

• [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.

[probonopd]

An example AppImage built on Travis CI is available on https://github.com/probonopd/Signal-Desktop/releases.

[dmhowcroft]

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.

[probonopd]

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.

[philipzae]

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

[stratacast]

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)

[probonopd]

electron-builder can build AppImages.

[willwh]

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.

[adnion]

Does anyone have a working script to build the appimage locally?

[dmhowcroft]

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.

[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.

[probonopd]

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?

[thenktor]

As Slackware user I'd like to vote for an official Appimage, too. Even Wire has one.

[stratacast]

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.

[kemsar]

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?

[vphantom]

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.

[adnion]

Great work @kevinsarsen https://github.com/signalapp/Signal-Desktop/pull/3055
I really hope @scottnonnenberg-signal has some time to decide about this.

[probonopd]

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/.

[skeet70]

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.

[codewing]

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!

[ghost]

so since the fedora snap version is not working for over a month. I would like to see a appimage version also.

[shoogle]

+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).

[ctrlcctrlv]

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.

[probonopd]

https://www.andreafortuna.org/2019/03/27/how-to-build-signal-desktop-on-linux/

[ctrlcctrlv]

Is that for me? I'm no longer interested in Signal due to what I wrote above.

[dmhowcroft]

@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?

[ctrlcctrlv]

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.

[maverick74]

I believe an AppImage should be THE official Linux package for distributing Signal!!!
It would allow me to have it anywhere.

[dmhowcroft]

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!

[almereyda]

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?

[zenny]

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.

[kargaroc]

This is super important now.

[hasufell]

I'm sorry to say this, but this ticket is deeply troubling.

It's also a bit embarrassing, because there has been a lot of praise about the quality of the Signal codebase and the cryptographic primitives in the past, suggesting Signal developers are aware of software security issues inside out.

Unfortunately, they don't seem to be aware of the intricacies of software distribution and that it's one of the major problems of security:

1. ensuring the user gets a trusted binary
2. ensuring that binary is up to date
3. ensuring that dependencies of that binary are up to date (this is non-trivial and flatpak etc don't solve it)

If you put any relevance to your desktop users, you should make sure that linux users on all major distros can install and update Signal through their package manager.

If you don't, then I'm afraid you really haven't understood the relevance of software distribution in software security and users are better off using alternatives, even if they have worse code quality or design.

[aspiers]

As someone who previously worked for SUSE for many years, I entirely agree with the previous comment.

Having said that, AFAIK there shouldn't be anything stopping each distro from packaging Signal itself. It's actually more normal for downstream distros to do the packaging themselves rather than to rely on the upstream project to do it.

In fact SUSE's Open Build Service (OBS) already provides experimental packages for openSUSE and Fedora, although in my experience they have some annoying bugs, at least when run on openSUSE Tumbleweed. It probably wouldn't be hard to extend this package to build on other Linux distributions too, since OBS supports many distros.

[probonopd]

ensuring the user gets a trusted binary

The only way to ensure this imho is to have the user download the Signal binary from the upstream Signal website, or else you can never know what the distribution has changed or whether the exact version of libraries the distribution has compiled it against has been tested by the upstream authors.

Even very reputable distributions (like Debian) have changed software in the past to an extent the application authors did not agree with.

[hasufell]

If you're weighing the competence of distro developers against the competence of upstream developers wrt software distribution, dynamic linking, shipping updates and communicating CVEs to users... I'd pick my distro any day.

They do it every day since decades, have developed tools, processes and policies to enforce quality, correctness and swift communication in case of vulnerabilities.

However, an upstream maintained ppa/rpm repo can be a solution too. Better than an unknown 3rd party repo for sure.

Ideally, upstream developers, who care about linux desktop experience should ultimately work with distro developers, trying to push them for including their software and offering help to mitigate problems. Some do that. It works. It's the correct way.

[probonopd]

I prefer a single binary file coming from, tested and supported by, upstream. Because I can wait like, forever, for Debian Stable to ever get the lastest and greatest Signal.

[hasufell]

If you're talking about a static binary, then that's probably one of the worst ideas wrt security. I haven't seen a single developer, who recorded the entire build plan (including transitive deps) of the binary and then did periodic CVE checks to identify whether one of the deps are vulnerable and then rebuilt the entire binary and shipped it in time every time that happened.

With dynamic system-wide linking, this is much easier and distros have the appropriate tools and manpower to identify and update this in a timely manner.

Of course, if you don't personally care about that, then that's fine, but it isn't a strong argument for security.

[pepa65]

I have started advocating for wide Signal uptake, but this issue is seriously undermining trust. ARE ANY PEOPLE IN CHARGE EVEN PAYING ATTENTION TO THIS?? This is the golden opportunity for all the refugees from Whatsapp, but they have to be able to install a desktop client! A webclient would be sufficient as well, but you can't just supply something for the smartphone only, that is a losing proposition!

[shoogle]

If you're weighing the competence of distro developers against the competence of upstream developers wrt software distribution, dynamic linking, shipping updates and communicating CVEs to users... I'd pick my distro any day.

That might be true for major distro packages (e.g. Firefox), but the smaller and medium-sized projects are packaged by volunteer maintainers, not by anybody "official" at the distribution. So it's not really the distribution that you are trusting so much as a random person.

If you're talking about a static binary, then that's probably one of the worst ideas wrt security. I haven't seen a single developer, who recorded the entire build plan (including transitive deps) of the binary and then did periodic CVE checks to identify whether one of the deps are vulnerable and then rebuilt the entire binary and shipped it in time every time that happened.

Applications on Windows and macOS (including Signal) bundle their own private copies of libraries and the world has not ended. Besides, this is not really relevant for Signal because it releases core updates so often. As long as Signal core is built against the latest libraries then users only need to wait a few days for the next core update to get the latest library as part of the AppImage.

BTW, where do you think libraries inside AppImages come from? (Spoiler: it's from the distros.)

[aspiers]

ensuring the user gets a trusted binary

The only way to ensure this imho is to have the user download the Signal binary from the upstream Signal website, or else you can never know what the distribution has changed

This is not true. Every reputable distro makes it easy to find out exactly what the distro has changed. For example, a simple search and a few clicks gets me to this page, which shows the exact three patches which are applied to create the openSUSE Tumbleweed build of Signal, and a myriad of other details about how the package was built.

Additionally, openSUSE and other prominent distros have made significant progress in recent years on providing Reproducible Builds, which is especially relevant to apps like Signal.

or whether the exact version of libraries the distribution has compiled it against has been tested by the upstream authors.

Even very reputable distributions (like Debian) have changed software in the past to an extent the application authors did not agree with.

Yes, there is always a tension between upstream and downstream testing. There are usually pros and cons to both. But I strongly agree with @hasufell here who clearly knows what he's talking about. Static binaries with huge amounts of dependencies introduce plenty of problems which can be mitigated to some extent if upstream are really good at tracking security updates and the quality of their CI. Many upstreams are not but one would hope that Signal are, given the importance of security to their code.

[aspiers]

Applications on Windows and macOS (including Signal) bundle their own private copies of libraries and the world has not ended.

Hah, that has been a common cause of bloat and security issues in Windows for many years.

Besides, this is not really relevant for Signal because it releases core updates so often. As long as Signal core is built against the latest libraries then users only need to wait a few days for the next core update to get the latest library as part of the AppImage.

Don't get me wrong, an AppImage would be a lot better than nothing. If the build process is transparent, verifiable, reproducible, and published regularly, then great. IMHO it still wouldn't be as good as distro-native packages, but I'd happily take it.

Anyway, we probably shouldn't turn this issue into an AppImage vs. native packages debate, and I apologise for already contributing to that tangent. But the Signal team should think carefully about how to provide Linux support properly.

BTW, where do you think libraries inside AppImages come from? (Spoiler: it's from the distros.)

1. Not necessarily, they could be building from source.
2. Even if it's from the distros, that's irrelevant because AppImages subvert the distro build/test/release lifecycle, so e.g. if you perform a normal update of all packages on your system, you could still have a vulnerability in your AppImages.

[shoogle]

@aspiers, what you say is true, but I was just pointing out that the problems with AppImages are not as serious as they have been made out to be, and distros do not provide the perfect solution as has been claimed (because it is not the official distribution that does the packaging but a random volunteer). In my view it would be better to get Signal from the Signal developers, using libraries tried and tested by the Signal developers, rather than from a random contibutor to some distribution.

[pepa65]

The nice thing about an AppImage is that it works on all distros/installs as long as it's the same architecture.
I just followed the earlier mentioned page, combined with Signal-Desktop's Contributing page and managed to build an AppImage that works (on amd64/x86_64)!

I replaced Andrea Fortuna's page's yarn icon-gen by the Contributing page's yarn build:webpack and before doing yarn build-release I edited the package.json file to add the AppImage target as described on Andrea's page. It would be great if this project could build this, because we have to trust them already anyway.

But the result of my Signal-1.39.4-beta.1.AppImage build can be downloaded here for those that would like to test it (it's147 MB).

To test it on your system, download it in the browser, make the file executable and click on it.

[aspiers]

@shoogle commented on January 10, 2021 1:38 PM:

@aspiers, what you say is true, but I was just pointing out that the problems with AppImages are not as serious as they have been made out to be, and distros do not provide the perfect solution as has been claimed (because it is not the official distribution that does the packaging but a random volunteer).

Neither is perfect, it is true. Like I said there are pros and cons to both, and I'd be very happy if Signal provided an Appimage.

In my view it would be better to get Signal from the Signal developers, using libraries tried and tested by the Signal developers, rather than from a random contibutor to some distribution.

Well, having worked with many of those random contributors for 25 years, and being one myself, I have a slightly different opinion, but of course everyone's free to have their own preferences ;-)

[mdedonno1337]

But the result of my Signal-1.39.4-beta.1.AppImage build can be downloaded here for those that would like to test it (it's147 MB).

To test it on your system, download it in the browser, make the file executable and click on it.

Nothing against you, but I'm sorry, I will not download a binary from the web and run it locally, in particular if it's hosted on this type of site.

The best (better?) way would be to add a CI job here on github, producing all the files (.deb, appimages, ...).

I have a gitlab CICD job to do that on my side (done yesterday), and will be more than happy to contribute back in this repo (and maintaining it) iif the maintainers of Signal are OK with it (from a philosophical point of view).

[pepa65]

This is exactly what I am driving at. We need an AppImage file as an asset on THIS project. Thank you for having done the work already to make this happen. They only need to add "AppImage" as a target besides "deb" and we're good.

[mdedonno1337]

At the moment, if I dont mistake, there is only the sources that are present in the Release page; and this was exactly why I had to compile it my self.

I think that all targets shall be present in the release page, including the .deb, .appimage, .exe and the sources files (I dont know about mac, I dont have one).

[mdedonno1337]

@aspiers

1. Even if it's from the distros, that's irrelevant because AppImages subvert the distro build/test/release lifecycle, so e.g. if you perform a normal update of all packages on your system, you could still have a vulnerability in your AppImages.

Correct if you consider only your machine.

I think that the build shall be redone continuously, let say every day, even if no commit is done on the signal-desktop app. This will re-pull the update from upstream for the dependencies (from source, distro, whatever), hence having the same update as the "hard installed" versions (via any type of package manager).

I agree that this will not ensure that your old version on your computer is up-to-date, obviously, but will at least ensure that the downloadable version on the release page is up-to-date.
There is, as far as I know, no good solution to manage the update of appimages at the moment.

[mdedonno1337]

because of the high traffic on the issues page, should we ping someone in particular ?

[andrewmackrodt]

The best (better?) way would be to add a CI job here on github, producing all the files (.deb, appimages, ...).

This would be my preferred solution as well.

In the meantime, for anyone who wishes to compile their own AppImage but don't have the correct node version installed, here's a copy/paste docker snippet to create an AppImage from the latest master HEAD in your ~/Applications directory:

docker run --rm -it -v $HOME/Applications:/app -w /app node:12.13.0 bash -c "$(cat << 'EOF'
    set -euo pipefail
    git clone --branch=master --depth=1 https://github.com/signalapp/Signal-Desktop.git /tmp/Signal-Desktop
    cd /tmp/Signal-Desktop
    sed -i -E 's/ {8}"deb"/        "appimage"/' package.json
    yarn install
    yarn build-release
    cp /tmp/Signal-Desktop/release/Signal-*.AppImage /app/
    uid=$(ls -nd /app | awk '{ print $3 }')
    gid=$(ls -nd /app | awk '{ print $4 }')
    chown $uid:$gid /app/Signal-*.AppImage
EOF
)"

[hamid-elaosta]

@andrewmackrodt Here's a slightly modified version using npm's "json" package to edit package.json, which might be a little safer;

docker run --rm -it -v $HOME/Applications:/app -w /app node:12.13.0 bash -c "$(cat << 'EOF'
    set -euo pipefail
    git clone --branch=master --depth=1 https://github.com/signalapp/Signal-Desktop.git /tmp/Signal-Desktop
    cd /tmp/Signal-Desktop
    npm install -g json && json -I -f package.json -e "this.build.linux.target[0] = 'appimage'"
    yarn install
    yarn build-release
    cp /tmp/Signal-Desktop/release/Signal-*.AppImage /app/
    uid=$(ls -nd /app | awk '{ print $3 }')
    gid=$(ls -nd /app | awk '{ print $4 }')
    chown $uid:$gid /app/Signal-*.AppImage
EOF
)"

Tested on Arch Linux.

Bonus info for those interested; You can have it start in tray and/or minimise to tray. Edit your shortcut to add the following flags as desired;

./Signal-1.39.6_2f84c9ccf1c1fcc46f407f28918396a1.AppImage --use-tray-icon --start-in-tray

• --use-tray-icon lets it minimise to your tray when you hit the close button.
• --start-in-tray tells it to start minimised to the tray.

EDIT 2: Build deb, snap, rpm, AppImage (If for some reason you don't want to use the AppImage)

NOTE: I have not tested the Snap, Deb or RPM

docker run --name signal-desktop-builder -it -v $HOME/Signal-Desktop-Builds:/app -w /app node:12.13.0 bash -c "$(cat << 'EOF'
    set -euo pipefail
    git clone --branch=master --depth=1 https://github.com/signalapp/Signal-Desktop.git /tmp/Signal-Desktop
    cd /tmp/Signal-Desktop
    apt-get update && apt-get install -y rpm
    npm install -g json && json -I -f package.json -e "this.build.linux.target = ['appimage','rpm','snap','deb']"
    yarn install
    yarn build-release
    cp /tmp/Signal-Desktop/release/Signal-*.* /app/
    cp /tmp/Signal-Desktop/release/signal-desktop*.{deb,rpm,snap} /app/
    uid=$(ls -nd /app | awk '{ print $3 }')
    gid=$(ls -nd /app | awk '{ print $4 }')
    chown $uid:$gid /app/Signal-*.AppImage
    chown $uid:$gid /app/signal-desktop*.{deb,rpm,snap}
EOF
)"

[pepa65]

Unfortunately, it gives errors now, even when changing the node to 12.13.0...

Cloning into '/tmp/Signal-Desktop'...
remote: Enumerating objects: 1404, done.
remote: Counting objects: 100% (1404/1404), done.
remote: Compressing objects: 100% (1180/1180), done.
remote: Total 1404 (delta 180), reused 656 (delta 125), pack-reused 0
Receiving objects: 100% (1404/1404), 23.62 MiB | 7.35 MiB/s, done.
Resolving deltas: 100% (180/180), done.
yarn install v1.22.4
[1/6] Validating package.json...
[2/6] Resolving packages...
[3/6] Fetching packages...
warning [email protected]: Invalid bin field for "url-loader".
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.
[4/6] Linking dependencies...
warning " > [email protected]" has unmet peer dependency "prop-types@^15.0.0".
warning " > [email protected]" has unmet peer dependency "prop-types@^15.5.7".
warning " > [email protected]" has incorrect peer dependency "typescript@>=3.3.1 <3.10.0".
warning " > [email protected]" has incorrect peer dependency "grunt@~0.4.5".
[5/6] Building fresh packages...
[1/35] ⠂ @journeyapps/sqlcipher
[8/35] ⠂ ref-napi
[7/35] ⠂ ref-napi
[6/35] ⠂ websocket
error /tmp/Signal-Desktop/node_modules/@journeyapps/sqlcipher: Command failed.
Exit code: 1
Command: node-pre-gyp install --build-from-source
Arguments: 
Directory: /tmp/Signal-Desktop/node_modules/@journeyapps/sqlcipher
Output:
node-pre-gyp info it worked if it ends with ok
node-pre-gyp info using [email protected]
node-pre-gyp info using [email protected] | linux | x64
node-pre-gyp WARN Using request for node-pre-gyp https download 
node-pre-gyp info build requesting source compile
gyp info it worked if it ends with ok
gyp info using [email protected]
gyp info using [email protected] | linux | x64
gyp info ok 
gyp info it worked if it ends with ok
gyp info using [email protected]
gyp info using [email protected] | linux | x64
gyp info find Python using Python version 2.7.13 found at "/usr/bin/python"
gyp http GET https://nodejs.org/download/release/v12.18.3/node-v12.18.3-headers.tar.gz
gyp http 200 https://nodejs.org/download/release/v12.18.3/node-v12.18.3-headers.tar.gz
gyp http GET https://nodejs.org/download/release/v12.18.3/SHASUMS256.txt
gyp http 200 https://nodejs.org/download/release/v12.18.3/SHASUMS256.txt
gyp info spawn /usr/bin/python
gyp info spawn args [
gyp info spawn args   '/tmp/Signal-Desktop/node_modules/node-gyp/gyp/gyp_main.py',
gyp info spawn args   'binding.gyp',
gyp info spawn args   '-f',
gyp info spawn args   'make',
gyp info spawn args   '-I',
gyp info spawn args   '/tmp/Signal-Desktop/node_modules/@journeyapps/sqlcipher/build/config.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/tmp/Signal-Desktop/node_modules/node-gyp/addon.gypi',
gyp info spawn args   '-I',
gyp info spawn args   '/root/.cache/node-gyp/12.18.3/include/node/common.gypi',
gyp info spawn args   '-Dlibrary=shared_library',
gyp info spawn args   '-Dvisibility=default',
gyp info spawn args   '-Dnode_root_dir=/root/.cache/node-gyp/12.18.3',
gyp info spawn args   '-Dnode_gyp_dir=/tmp/Signal-Desktop/node_modules/node-gyp',
gyp info spawn args   '-Dnode_lib_file=/root/.cache/node-gyp/12.18.3/<(target_arch)/node.lib',
gyp info spawn args   '-Dmodule_root_dir=/tmp/Signal-Desktop/node_modules/@journeyapps/sqlcipher',
gyp info spawn args   '-Dnode_engine=v8',
gyp info spawn args   '--depth=.',
gyp info spawn args   '--no-parallel',
gyp info spawn args   '--generator-output',
gyp info spawn args   'build',
gyp info spawn args   '-Goutput_dir=.'
gyp info spawn args ]
gyp info ok 
gyp info it worked if it ends with ok
gyp info using [email protected]
gyp info using [email protected] | linux | x64
gyp info spawn make
gyp info spawn args [ 'BUILDTYPE=Release', '-C', 'build' ]
make: Entering directory '/tmp/Signal-Desktop/node_modules/@journeyapps/sqlcipher/build'
  CC(target) Release/obj.target/nothing/../../node-addon-api/nothing.o
  AR(target) Release/obj.target/../../node-addon-api/nothing.a
  COPY Release/nothing.a
  ACTION deps_sqlite3_gyp_action_before_build_target_unpack_sqlite_dep Release/obj/gen/sqlcipher-amalgamation-3033000/sqlite3.c
Traceback (most recent call last):
  File "./extract.py", line 7, in <module>
    tfile = tarfile.open(tarball,'r:gz');
  File "/usr/lib/python2.7/tarfile.py", line 1695, in open
    return func(name, filemode, fileobj, **kwargs)
  File "/usr/lib/python2.7/tarfile.py", line 1753, in gzopen
    raise ReadError("not a gzip file")
tarfile.ReadError: not a gzip file
deps/action_before_build.target.mk:13: recipe for target 'Release/obj/gen/sqlcipher-amalgamation-3033000/sqlite3.c' failed
make: Leaving directory '/tmp/Signal-Desktop/node_modules/@journeyapps/sqlcipher/build'
make: *** [Release/obj/gen/sqlcipher-amalgamation-3033000/sqlite3.c] Error 1
gyp ERR! build error 
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/tmp/Signal-Desktop/node_modules/node-gyp/lib/build.js:196:23)
gyp ERR! stack     at ChildProcess.emit (events.js:315:20)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:275:12)
gyp ERR! System Linux 5.4.0-65-generic
gyp ERR! command "/usr/local/bin/node" "/tmp/Signal-Desktop/node_modules/node-gyp/bin/node-gyp.js" "build" "--build-from-source" "--module=/tmp/Signal-Desktop/node_modules/@journeyapps/sqlcipher/lib/binding/napi-v6-linux-x64/node_sqlite3.node" "--module_name=node_sqlite3" "--module_path=/tmp/Signal-Desktop/node_modules/@journeyapps/sqlcipher/lib/binding/napi-v6-linux-x64" "--napi_version=6" "--node_abi_napi=napi" "--napi_build_version=6" "--node_napi_label=napi-v6"
gyp ERR! cwd /tmp/Signal-Desktop/node_modules/@journeyapps/sqlcipher
gyp ERR! node -v v12.18.3
gyp ERR! node-gyp -v v5.0.3
gyp ERR! not ok 
node-pre-gyp ERR! build error 
node-pre-gyp ERR! stack Error: Failed to execute '/usr/local/bin/node /tmp/Signal-Desktop/node_modules/node-gyp/bin/node-gyp.js build --build-from-source --module=/tmp/Signal-Desktop/node_modules/@journeyapps/sqlcipher/lib/binding/napi-v6-linux-x64/node_sqlite3.node --module_name=node_sqlite3 --module_path=/tmp/Signal-Desktop/node_modules/@journeyapps/sqlcipher/lib/binding/napi-v6-linux-x64 --napi_version=6 --node_abi_napi=napi --napi_build_version=6 --node_napi_label=napi-v6' (1)
node-pre-gyp ERR! stack     at ChildProcess.<anonymous> (/tmp/Signal-Desktop/node_modules/node-pre-gyp/lib/util/compile.js:83:29)
node-pre-gyp ERR! stack     at ChildProcess.emit (events.js:315:20)
node-pre-gyp ERR! stack     at maybeClose (internal/child_process.js:1021:16)
node-pre-gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:286:5)
node-pre-gyp ERR! System Linux 5.4.0-65-generic
node-pre-gyp ERR! command "/usr/local/bin/node" "/tmp/Signal-Desktop/node_modules/@journeyapps/sqlcipher/node_modules/.bin/node-pre-gyp" "install" "--build-from-source"
node-pre-gyp ERR! cwd /tmp/Signal-Desktop/node_modules/@journeyapps/sqlcipher
node-pre-gyp ERR! node -v v12.18.3
node-pre-gyp ERR! node-pre-gyp -v v0.15.0
node-pre-gyp ERR! not ok 
Failed to execute '/usr/local/bin/node /tmp/Signal-Desktop/node_modules/node-gyp/bin/node-gyp.js build --build-from-source --module=/tmp/Signal-Desktop/node_modules/@journeyapps/sqlcipher/lib/binding/napi-v6-linux-x64/node_sqlite3.node --module_name=node_sqlite3 --module_path=/tmp/Signal-Desktop/node_modules/@journeyap[...]

[mdedonno1337]

Exactly the same here (for version 13.9.0).
This let me say that the integration of the compilation in CI here is important se we can check that the app (or the doc) is compiling (and correct).

It went wrong, I think, between the 14 and 18 of Ferbruary. I will check which commit later one.

Once again, I can maintain this for the appimage (if we can make the app to recompile).

[andrewmackrodt]

This appears to be because of the dependency @journeyapps/sqlcipher requiring a .tar.gz file stored using git lfs. This package has an extract stage and is expecting the .tar.gz file but sees a git-lfs metadata file, i.e.

version https://git-lfs.github.com/spec/v1
oid sha256:4ea4ac71c2103999070a6bb899e3cef3ec0d59356f13cdaf5f5d8857a1895d12
size 19212286

I'm not sure how to make yarn install "checkout" the real file. The GitHub CI Action doesn't seem to fail at this stage so it should be possible.

Edit: it seems the behaviour of journeyapps/sqlcipher install changed from node-pre-gyp install --fallback-to-build to node-pre-gyp install --build-from-source which is why it worked previously without git-lfs.

I've just built an image against master (v1.40.1) having changed the base image to Ubuntu Bionic and installing git-lfs:

docker run --rm -it -v $HOME/Applications:/app -w /app ubuntu:bionic bash -c "$(cat << 'EOF'
    set -euo pipefail
    export DEBIAN_FRONTEND=noninteractive
    apt update -qq
    apt install -qqy build-essential libssl-dev git-lfs python2.7 wget
    git lfs install
    update-alternatives --install /usr/bin/python2 python2 $(which python2.7) 10
    update-alternatives --install /usr/bin/python python /usr/bin/python2 10
    wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.37.2/install.sh | bash
    . ~/.nvm/nvm.sh
    git clone --branch=master --depth=1 https://github.com/signalapp/Signal-Desktop.git /tmp/Signal-Desktop
    cd /tmp/Signal-Desktop
    nvm use || nvm install
    npm install -g [email protected]
    echo 'y' | npx json -I -f package.json -e "this.build.linux.target[0] = 'appimage'"
    yarn install --frozen-lockfile
    yarn build-release
    cp /tmp/Signal-Desktop/release/Signal-*.AppImage /app/
    uid=$(ls -nd /app | awk '{ print $3 }')
    gid=$(ls -nd /app | awk '{ print $4 }')
    chown $uid:$gid /app/Signal-*.AppImage
EOF
)"

[pepa65]

I managed to end up with an AppImage, but it takes forever to start, so it doesn't work... This is my docker command (I tried both the master and the development branch):

sudo docker run --rm -it -v $PWD:/A -w /A node:12.18.3 bash -c '
  set -euo pipefail
  curl -s https://packagecloud.io/install/repositories/github/git-lfs/script.deb.sh |bash
  apt install git-lfs
  repo="https://github.com/signalapp/Signal-Desktop.git"
  git clone --branch=development --depth=1 $repo /tmp/Signal-Desktop
  cd /tmp/Signal-Desktop
  sed -i "s@deb\"\$@appimage\"@" package.json
  yarn install --frozen-lockfile
  yarn upgrade electron-rebuild
  yarn build-release
  cp /tmp/Signal-Desktop/release/Signal-*.AppImage /A/
  chown $(stat -c %u:%g /A) /A/Signal-*.AppImage
'

Don't try this at home! It screwed up my database (SQL from 21 to 23...) and now I can't use either unless I wipe it clean... I'm holding out for a working new version of Signal desktop. :-(

[mdedonno1337]

Don't try this at home! It screwed up my database (SQL from 21 to 23...) and now I can't use either unless I wipe it clean... I'm holding out for a working new version of Signal desktop. :-(

Is already an issue opened for that ?
Edit the emoji for the related comment, would help to see that there is an issue I think.

[andrewmackrodt]

That's something I've not encountered but has an open issue https://github.com/signalapp/Signal-Desktop/issues/4513. I see you have the command yarn upgrade electron-rebuild which I imagine would install some dependencies which differ from yarn.lock but I don't think that would affect database compatibility.

This likely isn't related to your issue but https://github.com/signalapp/Signal-Desktop/issues/1758#issuecomment-787915291 loads normally for me and is working. Ubuntu Bionic is used for the GitHub Actions CI pipeline so is a better choice of base image versus the rather outdated Debian Stretch image. Additionally it uses .nvmrc from the repository so will always use the correct node version without having to change docker images.

[pepa65]

I think they must have moved on in database versions to 23... If the new one had worked, the migration would have been no problem, but now I could no longer use version 21 of 1.39.6. It's not #1758. I hope I can keep my data... I maybe should have not interrupted a migration in progress (it that was why it was taking so long, I let it go for over 10 minutes -- but if it was that, a warning & message would have been gooed.)
Thanks for the tip on using Bionic. Unfortunately your build method is leading to a similar result, I let it "start up" for almost 7 hours, and still only 'white bubbles on a blue background'... 👎🏻

[pepa65]

For those that don't want 1.40 yet (although I can't find anything in the Changelog about a database version change...):

sudo docker run --rm -it -v $PWD:/A -w /A node:12.13.0 bash -c '
  set -euo pipefail
  repo="https://github.com/signalapp/Signal-Desktop.git"
  git clone --branch=v1.39.6 --depth=1 $repo /tmp/Signal-Desktop
  cd /tmp/Signal-Desktop
  sed -i "s@deb\"\$@appimage\"@" package.json
  yarn install
  yarn build-release
  cp /tmp/Signal-Desktop/release/Signal-*.AppImage /A/
  chown $(stat -c %u:%g /A) /A/Signal-*.AppImage
'

[pepa65]

Warning: upgrading to 1.40 and beyond changes the database format. It should automatically upgrade an older profile (in ~/.config/Signal) to the new, but not backwards, so once you migrate to 1.40, you can only go back to 1.39 and keep your conversations & attachments if you have copied that 1.39 directory as a backup! I have found 1.40.1 to be glitchy in the interface (might be non-optimal way of building, but the prescribed way of building doesn't seem to work), for instance, "Help > About Signal desktop" doesn't properly show.