06-24-2020, 05:36 PM
(This post was last modified: 06-25-2020, 09:42 AM by ninefathom.
Edit Reason: Add download link for Wayland version
)
Evening, Pine64 community.
I've been doing builds of the Signal Desktop client for Manjaro/aarch64 for myself for a while now. They've proven stable enough for my daily use that I've decided to start posting them here in case anybody else can benefit from them.
I'll try to keep this post updated within a couple of weeks of new releases. This is a best-effort project and the packages are distributed as-is, without any warranty, express or implied, including the implied warranties of merchantability and fitness for a particular purpose, etc. etc. etc. ad nauseam. These are NOT official Signal builds, and I am not in any way affiliated with the Signal project or Open Whisper Systems. TL;DR use at your own risk. Distributed under the GPLv3, source code and detailed license are available at https://github.com/signalapp/Signal-Desktop
These are Manjaro/aarch64 packages. Install with pacman -U directly, or create a local repo for use with pacman -S, whichever suits you.
Current stable versions (Google Drive download links)
Notes
- Minor modifications to some of the build scripts may be required, and often vary from one version to the next, usually because of the Node community's love of bundling pre-compiled x86-only binaries into their git repos. I do not under any circumstances alter the source code of Signal Desktop itself, nor of any of its dependencies. If you're curious about the modified build files for a given version, and/or would like instructions to reproduce these builds yourself, send me a message.
- The Ozone build provides native Wayland support, no Xwayland required. Ozone is the name in the Chromium project (and thus in Electron, which Signal Desktop is built on) of a relatively new abstraction layer which modularizes GUI support. This is highly experimental, requires on my end an Electron build with custom build configuration, and is not in any way supported by upstream Signal Desktop. I'd very much like feedback on these builds, but do not be surprised if there are major bugs!
EDIT: grabbed the wrong archive initially. Updated one is now live, and the package rev is bumped in case you'd already installed the previous one.
Thanks for your work!
So far I have only used Signal on my phone, but I'll keep an eye on your work.
UPDATE: The experimental Ozone build is now up. This build can run natively on Wayland, i.e. it does not require Xwayland. These builds take quite a bit of work and should be considered highly experimental. Please provide me feedback on how the Ozone build works for you on Wayland, but do be prepared for bugs!
Thanks for doing this! I was just thinking about how nice it would be to have a working message client on the PBP.
If I recall properly, my last attempts to build Signal on aarch64 ran into some problems with deep Node dependencies refusing to do something or other because they had no idea what aarch64 was.
Did you work around that? I'd like to get it built for Ubuntu, just haven't put too much time into it. I'm developing an allergy to Node, I think...
06-25-2020, 02:14 PM
(This post was last modified: 06-25-2020, 02:15 PM by llsf.)
Would you be willing to host/provide your build scripts / environment somewhere as well? We've been providing a non-ozone build for a while now over at https://forum.pine64.org/showthread.php?tid=9452 (providing the PKGBUILDS at https://gitlab.com/ohfp/pinebookpro-things), and maybe we could profit from each others work on it, instead of doing more or less the same work twice, while keeping things nicely open-source-ish all the while :)
(06-25-2020, 02:14 PM)llsf Wrote: Would you be willing to host/provide your build scripts / environment somewhere as well? We've been providing a non-ozone build for a while now over at https://forum.pine64.org/showthread.php?tid=9452 (providing the PKGBUILDS at https://gitlab.com/ohfp/pinebookpro-things), and maybe we could profit from each others work on it, instead of doing more or less the same work twice, while keeping things nicely open-source-ish all the while 
Somehow I'd managed to miss those in all of my past forum-searching. For the standard package @1.34.2-1, your PKGBUILD is virtually identical to what I'm doing.
For the Ozone package, the process was so arduous that I haven't even bothered trying to express it in a normal, reproduceable PKGBUILD as of yet; there was lots of "manual intervention" required. To get to a point where somebody could simply PKGBUILD it, there would be two main things required:
- The first bit is electron-ozone. There are really two separate things here. The first is that some of the build flags from electron-ozone in upstream AUR aren't quite what we need. Component ffmpeg is a must, for example, but upstream AUR has it disabled in their electron-ozone build. The second is that, since Electron/aarch64 only supports cross-builds from x86_64, not native, we'd have to build on x86_64 but make the final package for aarch64. Both of those things together tell me that we probably need a seperate PKGBUILD for a hypothetical "electron-ozone-aarch64" that A) has the needed build flags changed, and B) builds on x86_64, with added dependencies for cross-compile, but generates the resulting package for installation on aarch64.
- An overhauled PKGBUILD specifically for signal-desktop-ozone, which has a dependency on that electron-ozone-aarch64, and does the necessary patching and shoehorning to use the local electron-ozone-aarch64 dist instead of fetching from the web (which it tries really, Really, REALLY hard to do, in many places).
In all of that, I'd guess that two bits would be particularly challenging: getting makepkg to build a package on one architecture for installation on another, and all of the overrides to get the Signal Desktop build infrastructure to use a local Electron dist instead of upstream*. If I can solve those two, then we might have a prayer of getting this relatively automated.
...any advice on the two challenges above, in particular?
* Simply modifying package.json to use a local Electron dist isn't sufficient. Yarn will use that during some of the build steps, but then for the final stages of application build, yarn invokes electron-builder which (believe it or not) _totally ignores the Electron dist provided by yarn_, and instead figures out what version number of Electron yarn was using, and attempts to fetch that version number fresh from upstream Electron, for whatever crazy reason.
06-26-2020, 09:04 AM
(This post was last modified: 06-26-2020, 09:12 AM by ninefathom.)
(06-25-2020, 10:10 AM)Syonyk Wrote: If I recall properly, my last attempts to build Signal on aarch64 ran into some problems with deep Node dependencies refusing to do something or other because they had no idea what aarch64 was.
Did you work around that? I'd like to get it built for Ubuntu, just haven't put too much time into it. I'm developing an allergy to Node, I think...
Yes, I managed to work around the issues. Mostly, it involves modifying Signal Desktop's package.json to select alternative dependency versions. The exact changes vary from one version of Signal Desktop to the next. Sometimes you pull down one of the dependencies locally, get it to build, then point Signal Desktop's package.json to point to it (e.g. change "foo": "1.0.1" to "foo": "file:///your/build/dir/for/foo"). Sometimes an newer version of an upstream package is fine instead (e.g. change "foo": "1.0.1" to "foo": "1.0.2").
As of Signal 1.34.2, the dependencies that need changing are "zkgroup" (Signal zero-knowledge groups, distributes a pre-compiled x86_64 lib), "ffi-napi" (Node NAPI calls out to platform-native code, newer version adds aarch64 support), and sqlcipher (Signal uses a custom fork, which distributes a pre-compiled x86_64 lib). ffi-napi is a dependency of zkgroup, rather than signal-desktop itself.
@ llsf figured all of that out as well, and has done a great job of putting together PKGBUILD files for Manjaro at https://gitlab.com/ohfp/pinebookpro-thin...al-desktop
And as for an allergy to Node, well... I'll stay silent on that subject.
Thanks a lot, @ ninefathom, for explaining your ordeal – I've thought my past experiences with packaging electron-based apps had been terrible, but it seems like things can always get worse :D
It's amazing how many different ways there are for (wrong) pre-built packages to get pulled in, oblivious to the actual architecture or requirements, either by npm or yarn directly, or by dependencies when gyp-rebuilding, or electron-builder when packaging. An allergy to node and electron, well… yeah, it would be nice if less applications I like to use were based on it ^^
--
With regards to the challenges: well, you can just run makepkg with `CARCH=aarch64 makepkg` on x86_64, which gives you an '*-aarch64.pkg.tar.*'-package – but whether that's helpful is probably questionable ^^
More specifically with regards to electron: do you know why exactly (ie. some issues / known bugs) it's not possible to natively compile electron on aarch64? Considering it's "just a somewhat modified chrome" (yeah, it's probably a bit more complex than that), which can be built natively, maybe it's possible to get this done with less hassle.
I'll certainly take a look at both of those issues and report back, maybe we'll find a way around them :)
|
