[Desktop] arm64 builds

[chaserene]

Following up on our Slack convo, let's track here what's the status of building Standard Notes desktop for the arm64 architecture (also called arch64).

Currently it seems it's not possible. JohnnyA's experience has been that it's due to missing dependencies. Karol said doing it non-dockerized would be even harder. whichever the format, it would be greatly appreciated!

[maxdesalle]

As a Mac ARM user, I'm fully in favor of this. It should also make the app much smoother.

[JaspalSuri]

Hi @maxdesalle, we are still waiting for the dependencies that the desktop app relies on to support M1 Macs first.

[chaserene]

@JaspalSuri I just realized that my original request could have been interpreted in the context of the M1 Mac (which i didn't even have in mind). how about building for non-Apple arm64, like Cortex CPUs that are all over SoC's?

[JaspalSuri]

Hi @chaserene, no worries. We understand the difference between the requests. In both cases it's a matter of waiting for the maintainers to update the dependencies that desktop app relies on.

(For anyone else reading this thread, the web app will work on any unsupported system, like a Raspberry Pi, a BSD distro/variant, etc. 🙂)

[chaserene]

In both cases it's a matter of waiting for the maintainers to update the dependencies that desktop app relies on.

@JaspalSuri can you please list the dependencies that still block Linux arm64 builds from becoming part of the officially released builds? and can you describe how great of an effort would each be to update?

[chaserene]

I'd really like to see this happen, so I'm offering $500 to anyone (even SN team members) who succeeds in making arm64 Linux builds a sustainable part of the Standard Notes CI system.
requirements:

• you solve all blockers to making Linux arm64 (aarch64) desktop builds available in the Snap Store format and the AppImage format. you'll need to coordinate with the Standard Notes team about the specifics. as a result of your work, it becomes easy for them to officially support the above build types on the long-term.
• feature set and quality is on parity with the major desktop Standard Notes builds, especially when running on Manjaro XFCE and Armbian Buster XFCE (I can provide testing, you won't need to install these systems yourself).

the bounty will be paid out in your preferred major cryptocurrency, using rates from Coingecko at the time of sending.

if the outcome is a team effort, the involved will have to agree on a distribution before the bounty is paid out.

there's no bounty if the blockers are solved independently of your work.

if you're someone who is also excited about seeing this realized, add to the bounty in a comment below.

if there won't be serious takers, or those who take it don't progress, I maintain the right to take back this offer.

[JaspalSuri]

@JaspalSuri can you please list the dependencies that still block Linux arm64 build from becoming part of the officially released builds? and can you describe how great of an effort would each be to update?

Hi @chaserene, I'll get in touch with @johnny243 on this and get back to you.

[lsfxz]

Thanks for notifying me of this @chaserene – I've picked up working on it again and hope I'll get things somewhat sorted again (in such a way that the standard notes team can work with and easily maintain things in the future).
After all, I did manage to build it for several months until only a few weeks back, so it shouldn't be impossible :D

[lsfxz]

Potentially good news: dir and AppImage cross compilation works (even with electron 13 with a few smaller workarounds).

Snapcraft build is (seemingly) not possible to achieve on amd64, still working on that – looking promising, though.

Native compilation of dir targets works (and thus AUR/PKGBUILDs work again – I've just updated the AUR package on https://aur.archlinux.org/packages/standardnotes-desktop/ to get arm64 builds back ^^), as well as AppImage targets.

Most of the required changes are surprisingly small and only slightly more complex when building / running with a more up-to-date electron.

So once I've finished the snap process as well, I'll collect it all and present it / create PRs, if that's fine with the team.

It seems like the main leftover step would be building natively on arm64 (which seems to be required for snap builds): I don't really understand the CI/build system used (I'm usually working with gitlab and docker based runners on my own dedicated machines), so I don't know how much would complicate matters. Can you easily have parts of your release process run on arm64 machines?

Additionally: should a deb target also be striven for, or would that be covered by AppImage and snap releases?
(This should be not too much extra work, considering the main build process seems to work on a recent Ubuntu system at least; there are a few potential (known) issues with fpm when used for deb builds, which should be 'work-aroundable' by using a system fpm (via an env var), but hopefully nothing else insurmountable)

[lsfxz]

So that took a bit longer than expected (it seems like it's not possible to build a snap on Manjaro or in a (simple) docker environment, so I went with full-on qemu-system-aarch64 virtualization/emulation instead).

To sum it all up: Debian, AppImage and "unpacked" (dir) targets can be cross-built on amd64 with no changes in packages, dependencies etc. and only small changes in the build process (this was done directly on an Arch system).
This is also possible using electron 13 with only minor (and at least on the surface non-breaking) changes to dependencies.

Snaps cannot be produced on an amd64 system, but it is possible to create a snap release natively on arm64 (and with only minor changes to the build process as well). Arch / AUR packages are usually built "natively" on the target system, which is also possible.

Debian, AppImage and "unpacked" targets can also be built natively on arm64 systems with only minor changes as well.

For native arm64 builds, the same changes mentioned above allow building with electron 13 as well.

It might be possible to use a cross-built unpacked target output as a basis for packaging Snap and Arch builds. This could allow skipping the more extensive / time intensive build steps on arm64, so only the packaging steps would need to be run natively. This is just an assumption though and not tested – my assumption being that if we have to use an arm64 machine anyway, we could as well do everything there.

Furthermore, it might be possible to package an arm64 Arch package on amd64 with a few more or less ugly workarounds. Considering it's probably not a first level release target anyway (as in: it's on the AUR, that should be enough), that is probably not necessary anyway / out of scope.

I've uploaded the artifacts from my attempts at:

https://privacyshark.zero-credibility.net/privacyshark/standard-notes-3.8.18-linux-arm64.AppImage
https://privacyshark.zero-credibility.net/privacyshark/standard-notes-3.8.18-linux-arm64.deb
https://privacyshark.zero-credibility.net/privacyshark/standard-notes-3.8.18-linux-arm64.snap
https://privacyshark.zero-credibility.net/privacyshark/standardnotes-desktop-3.8.18-1-aarch64.pkg.tar.zst (this one is built using electron 13)

It would be great if someone would be willing to test those to ensure everything works properly – I'm currently not actively using standard-notes myself, so I don't really know what to look for specifically – I've only checked that things "seem to run" (and only throw updated related warnings in the terminal during launch).

Once this is done and it's ensured my attempts have lead to fully working builds, I'll happily share my process / create PRs where appropriate and try to lend a hand integrating them into the release process :)