06-26-2020, 07:58 AM
(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).
...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.