I have a Acer Chromebook r13 and I'm trying to use signal desktop on it under crostini on ChromeOS.
Currently the Android app doesn't work on tablets, and it seems that ChromeOS falls under this category.
Also, armv7 compatibility with raspberry pi brings in complications with older board versions that don't support HF, so I'm not asking for that. armv7hf may be an ok compromise. It won't work on old RPI boards, but anything armv7hf compatible and up will.
Any chance the .deb can be built for armv7hf and/or arm64?
Actual Result:
No .deb package for arm.
Expected Result:
.deb package for arm in signal apt repo.
Signal Version:
Operating System:
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
Linked Device Version:
I have an identical issue. Anybody know if support is coming?
@mikefedyk I'm going to try to build it from source on my chromebook, I'll post my results (if I don't forget.)
I ended up cross-compiling it because my chromebook was too slow :P
It works great, though. Here are the steps I followed:
git clone https://github.com/signalapp/Signal-Desktop.git # I used ssh, not https, but ymmv
git checkout v1.28.0 # or whatever version
# curl -sL https://deb.nodesource.com/setup_10.x | sudo -E bash - # install nodejs & npm if you do it on a chromebook
# sudo apt-get install -y nodejs
wget -qO- https://raw.githubusercontent.com/creationix/nvm/v0.32.1/install.sh | bash # install nvm
# (restart shell)
sudo npm i -g npm yarn # install nvm, update npm
npm config delete prefix # make it stop complaining
# cd into cloned repo
nvm use # switch node version to be compatible
yarn install --frozen-lockfile # Install and build dependencies (this will take a while)
yarn grunt # Generate final JS and CSS assets
yarn icon-gen # Generate full set of icons for Electron
SIGNAL_ENV=production yarn build --linux --arm64 # cross-compile a .deb file
To install it, I used sshfs to remote mount the server I built it on, then copied the file from the server's dist directory to the Linux share on the chromebook (file came to be about 80mb)
sudo apt install -f libnotify4 libappindicator1 libnss3
sudo dpkg -i signal-desktop_1.28.0_arm64.deb
Hope it helps!
I ended up cross-compiling it because my chromebook was too slow :P
It works great, though. Here are the steps I followed:
git clone https://github.com/signalapp.git # I used ssh, not https, but ymmv git checkout v1.28.0 # or whatever version # curl -sL https://deb.nodesource.com/setup_10.x | sudo -E bash - # install nodejs & npm if you do it on a chromebook # sudo apt-get install -y nodejs wget -qO- https://raw.githubusercontent.com/creationix/nvm/v0.32.1/install.sh | bash # install nvm # (restart shell) sudo npm i -g npm nvm yarn # install nvm, update npm npm config delete prefix # make it stop complaining # cd into cloned repo nvm use # switch node version to be compatible yarn install --frozen-lockfile # Install and build dependencies (this will take a while) yarn grunt # Generate final JS and CSS assets yarn icon-gen # Generate full set of icons for Electron SIGNAL_ENV=production yarn build --linux --arm64 # cross-compile a .deb fileTo install it, I used sshfs to remote mount the server I built it on, then copied the file from the server's dist directory to the Linux share on the chromebook (file came to be about 80mb)
sudo apt install -f libnotify4 libappindicator1 libnss3 sudo dpkg -i signal-desktop_1.28.0_arm64.debHope it helps!
Thanks for the info on how to build for a Chromebook.
I am getting an error.
warning " > [email protected]" has unmet peer dependency "prop-types@^15.0.0".
warning " > [email protected]" has incorrect peer dependency "grunt@~0.4.5".
warning "react-styleguidist > [email protected]" has incorrect peer dependency "webpack@^2.2.0 || ^3.0.0".
warning "react-styleguidist > webpack-dev-server > [email protected]" has incorrect peer dependency "webpack@^1.0.0 || ^2.0.0 || ^3.0.0".
error An unexpected error occurred: "EPERM: operation not permitted, symlink '../../../../node-pre-gyp/bin/node-pre-gyp' -> '/var/host/media/removable/usbstick/Signal-Desktop/node_modules/@journeyapps/sqlcipher/node_modules/.bin/node-pre-gyp'".
Any insight?
PS: You were joking about taking a while to build, yikes.
I ended up cross-compiling it because my chromebook was too slow :P
It works great, though. Here are the steps I followed:
git clone https://github.com/signalapp.git # I used ssh, not https, but ymmv git checkout v1.28.0 # or whatever version # curl -sL https://deb.nodesource.com/setup_10.x | sudo -E bash - # install nodejs & npm if you do it on a chromebook # sudo apt-get install -y nodejs wget -qO- https://raw.githubusercontent.com/creationix/nvm/v0.32.1/install.sh | bash # install nvm # (restart shell) sudo npm i -g npm nvm yarn # install nvm, update npm npm config delete prefix # make it stop complaining # cd into cloned repo nvm use # switch node version to be compatible yarn install --frozen-lockfile # Install and build dependencies (this will take a while) yarn grunt # Generate final JS and CSS assets yarn icon-gen # Generate full set of icons for Electron SIGNAL_ENV=production yarn build --linux --arm64 # cross-compile a .deb fileTo install it, I used sshfs to remote mount the server I built it on, then copied the file from the server's dist directory to the Linux share on the chromebook (file came to be about 80mb)
sudo apt install -f libnotify4 libappindicator1 libnss3 sudo dpkg -i signal-desktop_1.28.0_arm64.debHope it helps!
Thanks for the great tutorial. Was able to cross compile to arm64 & install on my Chromebook in the Crostini VM.
Ran into an issue though, even though the package & its contents were compiled to arm64. When running "signal-desktop", I'm guessing it drops a temporary Chromium binary in /tmp as /tmp/.org.chromium.Chromium.xxxxx. The xxxx represents random string, each time it runs, it generates a new string.
The issue is that "signal-desktop" itself doesn't run as it turns out the Chromium it drops in /tmp is still compiled as x64 and not arm64 which I find odd as the whole package should have been cross compiled into arm64 code yet the Chromium code for some reason is x64 code when dropped into the /tmp folder.
Has anyone run into this issue? It feels like I'm so close yet so far with this.
I also tried to natively compile signal-desktop on my ARM based Chromebook with no avail, the dependencies fail to compile, especially the journeyapps/sqlcipher module where it consistently fails, works fine on my desktop which runs an AMD64 processor.
Any help would be much appreciated.
Thanks!
@rj45jack I didn't run into that issue at the time I built it, but I'll need to build it again soon here so I'm not completely out of date.
@deltatux that's interesting. I don't remember having to do anything weird to get an arm64 chromium but a lot has changed for such a short amount of time to go by. I'll hopefully look into it again soon and amend my tut.
@taigrr in attempting to cross-build last night, it seems like the project.json has been changed since when you wrote this up and the flags you included are no longer working. Haven't yet figured out how to tweak it to build cross-platform, will update if I figure out the change!
edit: tried doing 1.29.3 and it builds properly but I run into the same issue as @deltatux
I was able to build an installable armv7l architecture .deb file today using the instructions given above (some minor tweaks) but I also get the same problem as @deltatux
I will repeat my build, take notes and provide updated instructions on the build though (when I get some time for another go at this), and then we just need to fix the arch for the chromium dependencies and I can then run Signal desktop on my Pinebook Pro! :)
I was able to build an installable armv7l architecture .deb file today using the instructions given above (some minor tweaks) but I also get the same problem as @deltatux
I will repeat my build, take notes and provide updated instructions on the build though (when I get some time for another go at this), and then we just need to fix the arch for the chromium dependencies and I can then run Signal desktop on my Pinebook Pro! :)
Mind sharing your tweaks? I can't even get that far, the build command for cross-compiling quoted above, SIGNAL_ENV=production yarn build --linux --arm64, gives me
ERROR: Invalid Option: --linux
and hilariously yarn help build just gives a "full" list of commands I could request help about, none of them being yarn build. It's bad enough that Signal-Desktop doesn't have documentation on how to build it, but even the _commands it uses to build_ aren't documented?
I'm actually also trying to compile for my Pinebook Pro (although after figuring that out I'd like to compile it for other ARM devices too; Open Whisper System's hostility to 3rd-party apps makes using Signal on non-Android portables tricky!), so I'm all ears for any way to make this work . . .
P.S. Compiling on the device would be fine too, if that could be made to work; I haven't had any luck with that myself though.
I sadly lost my transcript for a working build (other than the wrong-arch chromium binaries). However if I got it working once I could do it again. I have had a couple of requests to share how. Hoping to get to that this weekend.
I really would like to get signal on my pi4, anyone got that working?
I really would like to get signal on my pi4, anyone got that working?
I’m in the same camp. I found an older compiled version, but it was outdated and would not let me use it. It ran though. Does anyone have a repo or binary fro armhf?
This would also be quite good to have for the Pinephone.
I've just stumbled upon this while looking for "general developments" with regards to building Signal-Desktop on aarch64. I've been building it for a while now for use on the Pinebook Pro via a PKGBUILD and in a clean chroot for Manjaro ARM systems. Maybe that PKGBUILD might give some pointers to how to build it on other systems as well, for anyone else trying/struggling?
The main hurdles I had encountered were:
patch-package or earlier didn't seem to survive yarn pulling things in afresh for rebuilding, so things get manually pulled, patched and referenced in the package.jsonfpm is required during build, with all its dependencies, using USE_SYSTEM_FPM – otherwise an x86_64 one is usedzkgroup-node uses ffi-napi at a version without aarch64 support, so that gets patched.so is used, so we need to build it ourselves and provide the correct one for the architectureAll the other parts of the build process are what's done by upstream-Arch as well at https://www.archlinux.org/packages/community/x86_64/signal-desktop – I'm following their releases and update things accordingly.
The PKGBUILD is admittedly somewhat messy (comments hanging around etc.), sorry about that, but it works for building Signal-Desktop directly on an aarch64 device :)
I'm open to pointers for handling some of those issues more elegantly – I'm very far from being an expert on node, electron and the whole npm-ecosystem.
--
you cand find my efforts at: https://gitlab.com/ohfp/pinebookpro-things/-/blob/master/signal-desktop/PKGBUILD
An example to build it in a clean chroot from this PKGBUILD, once you've built the dependencies, would be:
export CHROOT=/path/to/your/chroot
makechrootpkg -c -r $CHROOT \
-I ../dependencies/icu60/icu60-60.3-1-aarch64.pkg.tar.xz \
-I ../dependencies/nvm/nvm-0.35.3-1-any.pkg.tar.xz \
-I ../dependencies/phantomjs/phantomjs-2.1.1-9-aarch64.pkg.tar.xz \
-I ../dependencies/ruby-arr-pm/ruby-arr-pm-0.0.10-1-any.pkg.tar.xz \
-I ../dependencies/ruby-backports/ruby-backports-3.15.0-1-any.pkg.tar.xz \
-I ../dependencies/ruby-cabin/ruby-cabin-0.8.1-1-any.pkg.tar.xz \
-I ../dependencies/ruby-childprocess-0.7/ruby-childprocess-0.7-0.7.1-2-any.pkg.tar.xz \
-I ../dependencies/ruby-clamp/ruby-clamp-1.2.1-1-any.pkg.tar.xz \
-I ../dependencies/ruby-dotenv/ruby-dotenv-2.7.5-1-any.pkg.tar.xz \
-I ../dependencies/ruby-insist/ruby-insist-1.0.0-3-any.pkg.tar.xz \
-I ../dependencies/ruby-io-like/ruby-io-like-0.3.0-1-any.pkg.tar.xz \
-I ../dependencies/ruby-json-1/ruby-json-1-1.8.6-5-aarch64.pkg.tar.xz \
-I ../dependencies/ruby-stud/ruby-stud-0.0.22-1-any.pkg.tar.xz \
-I ../dependencies/ruby-xz/ruby-xz-0.2.3-1-any.pkg.tar.xz \
-I ../dependencies/ruby-pleaserun/ruby-pleaserun-0.0.31-2-any.pkg.tar.xz \
-I ../dependencies/fpm/fpm-1.11.0-1-any.pkg.tar.xz
Your pathes and versions could, of course, be different.
I'm trying to cross-compile latest master (1.34.1 as of this writing) and I can build an arm64 .deb, but I have the same problems as everyone else in this thread with the incompatible Chrome object in /tmp. I'll try to pivot from the PKGBUILD instructions above from @lsfxz but I'm not using Arch -- I'm building on WSL2 (Ubuntu) for an arm64 Chrome-OS linux container (Lenovo Duet tablet) .
Not expecting much luck but I'll give it a go...
A bit of progress! The app opens and I see a big wash of Signal Blue. But nothing after that. Some of the menu items work e.g. for opening help URLs, but I cannot link my account or open preferences.
To get this far, I built it (verry slowly) on the chromebook itself, instead of cross-compiling. Used the patches from @lsfxz above. The log output appears to say that the app has started up, the sqlite and sqlcipher libraries have loaded, spellcheck is on.... and then it just sits there. I need to figure out how to get more verbose logging in order to find out what is missing.
I will keep banging on this for a while...
having signal-desktop packaged for arm64 will make my pinephone fly. Hopefully the team will consider such option
It makes me very sad, that Telegram (which is implemented in C++) does work on arm64/aarch64 with ready to install packages from Arch, but for Signal-Desktop (implemented in JavaScript), which runs basically in a browser it is not possible at all.
Don't get me wrong, I dislike Telegram very much from non-technical point of views, but in this regard they are IMHO far ahead.
I'm no pro at Electron apps so I'm wondering if someone can help me debug this. The import of the native 'zkgroup' package is failing, and it is failing when it tries to import the 'ffi-napi' package. But what is strange is that I can add a require("ffi-napi") to main.js, and it imports without crashing.
The zkgroup package itself (and libzkgroup too) seems to be building properly and even passes all tests.
Does someone have an idea why ffi-napi would be importable in the app's main.js, but not in one of its dependencies? This is baffling to me.
i installed signal messenger on a pinebook pro using the privacyshark repo. works great!
I managed to build it on Linux for aarch64: however it crashes in the same way as @deltatux describes above.
To build, I built the steps outlined in build one by one manually, separating the electron builder step as to allow providing the required arch flags.
git clone https://github.com/signalapp/Signal-Desktop.git
git checkout v1.34.5
nvm use
yarn install --frozen-lockfile
yarn build:grunt
yarn build:typed-scss
yarn build:webpack
SIGNAL_ENV=production yarn build:release --linux --arm64
scp signal-desktop_1.34.5_arm64.deb [email protected]:/home/mobian/Downloads/
sudo dpkg -i signal-desktop_1.34.5_arm64.deb
sudo apt-get -f install
When starting, it exits with an unhandled error /tmp/.org.chromium.Chromium.xxxxx cannot open shared object file: this is the same error as described above.
Device info:
Linux mobian 5.7-pinephone
To everyone trying to run it on the PinePhone, remember that the desktop client interface isn't responsive at the moment. So even if we succeed to run the app correctly on the phone, you won't be able to use it at least while https://github.com/signalapp/Signal-Desktop/issues/2454 isn't solved.
Hey Signal team. I run Beekeeper Studio, which is also Electron. I just figured out how to build ARM64 and ARMv7l binaries and have an a1 box on AWS to do it.
Maybe I could host a GitHub worker on that box for you? The box has plenty of spare capacity. That way you can support ARM builds and I can get Signal on my Pi4 :-D.
If you don't want to do that I just wrote a guide for building on ARM. I basically just documented how I set up my a1 box.
Let me know if you're open to it!
Hey Signal team. I run Beekeeper Studio, which is also Electron. I just figured out how to build ARM64 and ARMv7l binaries and have an
a1box on AWS to do it.
@rathboma did you actually try to build Signal targeting ARM? Did the application launch after that? If so, can you post the steps you did here? Having a build provided automatically by OWS would be cool but being able to build it at all is the first step.
I'll chime in again to maybe give some pointers to those trying to achieve or provide Signal-Desktop for ARM: I'm still keeping up providing an arm64/aarch64-build over at https://gitlab.com/ohfp/pinebookpro-things/-/tree/master/signal-desktop. I have to employ several more or less ugly workarounds, mainly:
USE_SYSTEM_FPMnode-sqlcipher (for openssl linking, patch taken from Arch)libzkgroupsignal-zkgroup-node to pull in ffi-napi >=2.4.7, as 2.4.5 does not support arm64libringrtc.node, as only a linux-amd64 binary is provided¹phantomjs as well, as that's a required dependency, tooMost of this should be possible to do for armv7 more or less the same way; the PKGBUILD is more or less a shell script that could be used as a starting point for other environments.
¹ I have forked ringrtc and signal-ringrtc-node for this and modified the ringrtc-electron-build-script to use separate build tools (like clang). I've described the steps needed to get a succesful build on Manjaro (on an aarch64 machine) elsewhere as well, so here they are:
# fork of signalapp/ringrtc with some slight modifications to the build scripts
git clone https://github.com/lsfxz/ringrtc
cd ringrtc
git checkout aarch64
# the arch/Manjaro depot tools do not seem to agree with the build scripts
git clone https://chromium.googlesource.com/chromium/tools/depot_tools ../depot_tools
cd ..
export PATH="$(pwd)/depot_tools:${PATH}"
# we need clang 11. the included clang is not provided for aarch64 by ringrtc
# and the manjaro clang is "too old" with version 10
wget https://github.com/llvm/llvm-project/releases/download/llvmorg-11.0.0-rc2/clang+llvm-11.0.0-rc2-aarch64-linux-gnu.tar.xz -O clang11.tar.xz
mkdir -p clang11
tar --strip-components=1 -C ./clang11 -xf clang11.tar.xz
rm -f clang11.tar.xz
export PATH="$(pwd)/clang11/bin:${PATH}"
# the clang archive seems to be linked against libtinfo.so.5, so we need ncurses5-compat-libs
yay -S --needed rustup ncurses5-compat-libs ninja yarn
rustup toolchain install 1.44.1
rustup default 1.44.1
cd ringrtc
bin/prepare-workspace unix
make distclean
make electron
# if everything went well, the aarch64-binary is now available at ./src/node/build/linux/libringrtc.node
With that build, is the Signal client fully functional?
I didn't have a chance to test the new RTC-features yet (voice/video-calling), though no errors related to this appear during startup, nor have I gotten any feedback indicating issues with it yet.
Everything else seems to work fine ("registering" the desktop client with the app on a phone) as well as all the "regular" features. I've been using my builds for quite some time now myself, and there are quite a few PinebookPro-users also using it regularly – and so far, things seem to be fine for them as well :)
That's a very very good news. Do you plan to open merge requests to integrate your changes to the signal code base?
"Plan" would be too strong a word :D
Seriously, though: That would certainly be my goal; currently I'm just (as with so many things) limited by lack of time; my solutions are focused on a relatively specific situation (building on aarch64 for aarch64) and use some relatively hacky workarounds. To do this cleanly and in a way that would have a chance of being accepted by the affected projects (it's not just signal directly) would (I'd assume) require quite a bit of work: Solutions would need to be sufficiently generalized, so they can work on whatever CI is used for releases of projects (eg. cross-compiling instead of native compilation on the architecture); sometimes build processes would need to be extended quite a bit (let's take ringrtc: currently, ringrtc only "knows" linux, win32 and darwin with no consideration for architecture; libringrtc-node just references .../linux/.., and some of the build tools used by ringrtc are just not directly available for aarch64 in the way they are employed/pulled in); some of the affected projects haven't gotten an update for quite some time, so one might have to provide (and maintain) a fork etc.
Nothing insurmountable, sure, but nothing I'd assume I could just "quickly get done" – which is why I haven't really put much work towards it yet.
Furthermore, it should be made certain that it would be actually welcomed by the devs – I'd assume the current lack of ARM builds is mostly related to lack of resources and a rather small group of interested users, so it would be more work for little gain, so to speak. In that case it would be worth to get this going – while it could also be possible (I'm not implying this!) that there's no interest at all, in which case it would be a wasted effort.
Pinging @scottnonnenberg-signal there then, to know the interest of OWS about ARM builds.
From what I can tell, the signal-zkgroup-node dependency introduces the one of the bigger hurdles as it relies on Node Foreign Function Interface (FFI), provided by node-ffi-napi.
The node-ffi-napi library in its turn wraps the libffi library.
Interesting here is that the latest libffi library version does indeed support Linux aarch64/arm64, however the version of the node wrapper library (node-ffi-napi) used by Signal Desktop (2.4.5) is ca two years old and does not support aarch64.
Using the latest 2.x version of the node wrapper library (2.4.5 -> 2.5) introduces aarch64 support, and additionally includes ca 12 months work to the library.
Just a quick note: I've just built signal-desktop 1.36.3 for aarch64 and finally got around to testing the RTC features as well. I can report, everything seems to work fine on that front as well – voice-only as well video calling to and from my PBP worked without any hickups :)
Just a quick note: I've just built signal-desktop 1.36.3 for aarch64 and finally got around to testing the RTC features as well. I can report, everything seems to work fine on that front as well – voice-only as well video calling to and from my PBP worked without any hickups :)
Thats some good news. Could you describe what and how you did this in an attempt to help others out?
Did you build on the aarch64 device, or cross-compile? What dependency/code changes, if any, did you do to allow building?
Did that already, a few posts above (https://github.com/signalapp/Signal-Desktop/issues/3410#issuecomment-693340268) – you might've just missed it :)
I build it directly on an aarch64 device (either directly on a PineBook Pro or on a Packet ARM instance).
--
To get on with it some more: I'm currently going through possible changes to the upstream repos/dependencies to see if it's feasible to make it easier to get an aarch64 build, hoping that OWS might then pick it up.
One of the changes would be what you've already submitted as a PR at signal-zkgroup-node.
Another would be to also build and publish libzkgroup for aarch64/armv7 by default, which should be relatively easy to do and more about determining which .so to use afterwards and/or triggering a local rebuild of the dependency automatically when yarn --installing on an ARM architecture, if feasible.
Regarding fpm, using USE_SYSTEM_FPM with a separately provided fpm installation should be sufficient, but maybe upstream fpm could also provide prebuilt ARM libraries – didn't look into how complicated that would be for them.
Building ringrtc/libringrtc.node is possible, as I've shown, but I haven't found a simple way to do it without providing many required build tools separately yet (the prepare-workspace-script pulls in tools that just do not seem to provide (appropriate) ARM-binaries at all). Once that's done, it would be mainly about also using the architecture when including the dependency (ie. require('../../build/' + os.platform() + '-' + os.arch() + '/libringrtc.node'); or something like that).
Than one would have to find a good way to run the build as part of the signal-desktop CI. One could either run it directly on ARM instances with an appropriate image, or run it on amd64 instances with aarch64/armv7-images and qemu. In those cases, the hardest thing would probably be to provide a phantomjs binary (which seems to be required under those circumstances) – unless that's already provided by the default ubuntu/debian-arm-images.
It might even be possible to cross-compile things directly on x86_64 machines, but I've never really looked into that much; maybe someone else has more experience with cross-compiling electrony things that way and could chime in.
I see this thread starts back in 2019 and continues... are there any honest plans from the signal folks to provide a proper build process to get this working on aarch64 environments like the pinephone?
Would also like to see support for arm-v8 and aarch64.
I too would like aarch64 binaries to use the Signal-Desktop client on my chromebook. I am currently attempting to follow lsfxz's build steps above, but not with any success so far.
It's ironic ... the whole point of using Electron is that one does not want to worry about platform specifics ... :man_shrugging:
@riggs- not really if the arm binaries are build it should just work, it should be just a matter of compiling it for arm
@riggs- not really if the arm binaries are build it should just work, it should be just a matter of compiling it for arm
Correct. However I have tried 6 different ways to get thus to build successfully on our platform and gotten nowhere. (Im not familiar with Electron development).
I would be satisfied (and maybe even try to maintain the aarch64 build/fork or others as well).
@toaster42 you should at least be bit familiar with electron development to compile it tbh
if you scroll up you'll find someone who has successfully compiled it
a fork is the last thing you'd want to do, maybe help upstream the changes?
@riggs- not really if the arm binaries are build it should just work, it should be just a matter of compiling it for arm
@Fuseteam You're right. This is, however, precisely the issue. It should be as simple as git clone && make, but it's not. Have you read through @lsfxz 's comments? They show how much manual fiddling is required to make this work.
@riggs- that's called dependencies, those dependencies are not a issue crossplatform or cross architecture, if all of 'em support all the platforms and all the architectures.
many projects are not a simple clone and build, you more often than not have to deal with dependencies.
node-sqlcipher, libzkgroup, signal-zkgroup-node. libringrtc.node and phantomjs are all components that the electron app ships with, his "fiddling" was him building each component for arm64 so they can actually run
in the end it's _still_ not about platform specifics but more about all the components supporting or being build for the arm architecture.
@Fuseteam I am very well aware of dependencies, having my fair share of experience in that area. All I am saying is that the whole electron ecosystem is a far cry from making cross platform any easier than every other failed "write once, run anywhere" promise we have seen in the past decades, and I stand by that comment until I see evidence to the contrary.
@riggs- if you're aware of dependencies are you expecting electron application to get all the dependencies in one repository? that's the only way you can get git clone && make
Is there anyone familiar enough to validate https://github.com/signalapp/signal-zkgroup-node/pull/3 and get it into a merge-able state so we can make some progress on this issue?
As mentioned above, one of the complications in getting the current build working is that the current version of ffi-napi used by Signal does not support aarch64. Newer versions off ffi-napi do, so a significant step towards getting this moving is updating ffi-napi in signal-zkgroup-node. That would concretely move Signal towards a viable aarch64 build.
The PR does the naive work (updating package.json), but that seems to have stalled. Does anyone know enough to get that PR moving?
I'm still keeping up providing an arm64/aarch64-build over at https://gitlab.com/ohfp/pinebookpro-things/-/tree/master/signal-desktop.
@lsfxz Perhaps I'm missing it, but do you have a release precompiled anywhere for ARM64/aarch64? Or just the steps? Thanks!
@Fmstrat Yeah, binary packages are provided via https://privacyshark.zero-credibility.net (https://privacyshark.zero-credibility.net/privacyshark/aarch64/ for the aarch64 packages), a repository for Manjaro/Arch. Not sure how well those can be used on other systems, though, as they're built against library versions available on Manjaro ARM available at build time – so quite often, things might not work on, say, Ubuntu or Debian.
I've just realized I've totally missed the upstream update to 1.39.x, though — I'll try to get it updated as soon as possible!
Be aware that there're currently at least two isssues making the build unreproducible (https://github.com/signalapp/Signal-Desktop/issues/4709 and https://github.com/snyk/snyk/issues/1536) so it's currently not possible to verify the binary packages provided by a third party with the usual reproducible Arch Linux tooling. Be careful.
@lsfxz Thank you. Though given that commentary I'm not sure that would work for me since I'm on the same system as @billyc (Lenovo Duet Chromebook).
someone can help me with this error ? (im trying to compile signal on my x86 + ubuntu 20.10 pc)
root@ziomario-z390aoruspro:/home/ziomario/Scrivania/Signal-Desktop# SIGNAL_ENV=production yarn build --linux --arm64
yarn run v1.22.5
$ run-s --print-label build:grunt build:typed-scss build:webpack build:release build:zip --linux --arm64
ERROR: Invalid Option: --linux
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
@Fmstrat @billyc I replaced the Debian container with Arch on my Lenovo Duet and Signal runs great using the precompiled binary via https://privacyshark.zero-credibility.net/ . I prefer Arch anyway, so this is a good solution for me.
I am having trouble receiving notifications in ChromeOS from Signal, though. Anyone with experience in ChromeOS, Crostini, and Electron apps able to chime in?
@Fmstrat @billyc I replaced the Debian container with Arch on my Lenovo Duet and Signal runs great using the precompiled binary via https://privacyshark.zero-credibility.net/.
@enjewneer Thank you for this obvious (in hindsight) revelation. I'm not sure why changing distros never crossed my mind, despite knowing it was possible. I now have an easier project ahead of me than finishing learning electron and familiarizing myself with the Signal codebase and it's
Many thanks, kind internet stranger. :-)
--Toaster42
I can't change os thanks to nvidia. I'm stuck with the old ubuntu 18.04 because nvidia doesn't want to make available their jetpack on ubuntu 20.04
Most helpful comment
This would also be quite good to have for the Pinephone.