TriliumNotes PKGBUILD review

bgiovanni · 2022-06-15 19:59:24

Hello,
lately I began to use a note-taking app called Trilium Notes (an Electron app, take note) and, since I couldn't find it on the official package repositories I checked out the AUR to see if it was already available there.
It turns out that the already available Trilium desktop pkgbuild available on the AUR is *-bin only, it fundamentally downloads a pre-packaged tarball and installs the underlying files unchanged to /opt, and I wasn't really satisfied with that.

So, I thought I could produce my own packaging for this application straight from source and, unlike the *-bin package of Trilium, rely on system-wide Electron shipped in official Arch repositories via the electron* package, this in turn saves some useful space by avoiding to replicate Electron's binary runtime.

It seems like my effort was eventually successful and I was able to construct a working PKGBUILD, largely taking inspiration from the ones of other Electron apps already on Arch, in particular from Bitwarden's one.

Given that it's my first time producing a PKGBUILD for a package I would appreciate if someone could eventually review it before I publish it.

Here's where you can find it: https://codeberg.org/bgiovanni/triliumnotes-pkgbuild

I also have the following questions:
- Is it OK to publish another pkgbuild for an application that already exists BUT it's in *-bin form, while this one builds from scratch on people's own PCs?
- Do I need to add any particular suffixes to the package name? (i.e. *-git; *-stable)
- How do I ensure, and remember that we're talking about an Electron app, that I have caught all the required dependencies, both for build time and runtime?
- Everything currently builds and runs perfectly fine on my system.
- 'gcc' and 'make' are required as build time dependencies because they're required to build a native module through node-gyp, while nodejs is an actual dependency because one of the maintenance tools which come along with Trilium, “dump-db”, would require it to run. (actually I'm yet to test whether it works)
- I have looked at the prebuilt tarball and it doesn't come with any notable dependency that isn't electron stuff.

Also it should be noted that my packaging requires some patches (which come along with the PKGBUILD), specifically:
- “config-sample.ini.patch” is required because otherwise the app will spawn its own .desktop file in the user home directory causing the app to appear twice in the launcher. AFAIK, the *-bin package on the AUR places a .desktop file to root /usr/share/… with the same filename as the one spawned by Trilium on first launch, so that one of them is shadowed by the other and it only appears once in the launcher. Since I couldn't like the idea of a having a duplicate file I've patched the default Trilium config to not create the desktop entry in the home dir and I made a custom desktop entry my self which is placed in the proper system's directory.
- “copy-trilium.sh.patch” was patched fundamentally to overcome some weird build commands I couldn't really understand and to add the flag “--build-from-source”.

Thank you for your attention.

Last edited by bgiovanni (2022-06-15 20:03:24)

Trilby · 2022-06-15 20:07:50

I've not looked much at the PKGBUILD yet, but a few answers to the specific questions:

- Is it OK to publish another pkgbuild ...

Yes. There are many packages in the AUR that exist as <pkg>, <pkg>-bin, <pkg>-git, etc. It's good to avoid useless proliferation, but getting a native build rather than a precompiled binary is well worthwhile.

- Do I need to add some particular suffixes to the package name?

No. Your PKGBUILD uses a source tarball for a specific pkgver. So this package's name should just be the appropriate basename of the tool, in this case that seems to be "trillium".

- How do I ensure ... that I have caught all the required dependencies, both for build time and runtime?

Namcap is a useful tool to help in this. But it is just a tool, dont rely on it exclusively. Also test. Ideally build in a clean chroot (though I admit to not doing this myself for my packages, but I only package my own software, so I'm quite familiar with what libs I use).

- 'gcc' and 'make' are required as build time dependencies

These are both in the base-devel group and therefore should not be listed in makedepends.

EDIT: I just tested, and it builds well on my machine (which is extremely minimal, so pretty unlikely I'd have any dependencies that were not listed ... but I had to let makepkg install *lots* of dependencies to build this). Namcap notes two issues, one valid, the other almost certainly a false-positive:

$ namcap trilium-0.52.3-1-x86_64.pkg.tar.zst 
trilium W: No ELF files and not an "any" package
trilium W: Dependency included and not needed ('electron16')

The first is correct, the "arch" field should be changed to "any" as electron packages are essentially just very complicated scripts. The second is the false positive - this is not uncommon for packages containing scripts, namcap can miss the script-interpreter dependency which is what it's doing here.

EDIT 2: I just tested the built package and it's segfaulting on startup. However, this is / was due to my using wayland as electron itself died with the same segfault. But electron can run on wayland with a couple 'ozone' flags passed to it which I added to a config and confirmed electron runs, but trilium still segfaults on startup for me.

Last edited by Trilby (2022-06-15 20:32:28)

bgiovanni · 2022-06-15 23:01:53

- These are both in the base-devel group and therefore should not be listed in makedepends.
Cool, I'll remove them from the pkgbuild then.

- The first is correct, the "arch" field should be changed to "any" as electron packages are essentially just very complicated scripts.
Mhm, actually Trilium is using a native module which should be compiled with gcc by electron-builder through node-gyp (I think) during the package build time. Afaik, this module should compile just fine for ARM but I'm not sure about x86 IA32.
Given that I lack the hardware to test whether it would run in these architectures and that Trilium prebuilt releases don't even target them I wouldn't really set 'any'. Even tho it is slightly possible that it would build just fine.

- but trilium still segfaults on startup for me.
:C , that's unfortunate, I haven't tried to run it on a Wayland session yet so I don't know whether that's normal. Does it segfault immediately or does the backend print some stuff in the terminal before crashing? Which DE are you using?
According to Trilium issues on GitHub it seems that some people with Wayland are experiencing literally DE crashes on app startup (curiously one report comes from a Manjaro Gnome user dated 15/02/'22).
Either way, if it isn't a packaging issue there isn't much I can do, I'll test tomorrow on a machine with Gnome on Wayland.

Trilby · 2022-06-15 23:58:56

bgiovanni wrote:

Mhm, actually Trilium is using a native module which should be compiled...

Ah, yes, you're right. There are no binary executables or libraries in the package, but the main content is the "app.asar" which aparently is itself an archive. It looks like text / js / json at the start, but there is binary data embedded in it farther down the file - this is apparently extracted at run-time and among the contents are binary executables. So disregard the "arch" comment.

bgiovanni wrote:

Does it segfault immediately or does the backend print some stuff in the terminal before crashing? Which DE are you using?

$ trilium
DB not initialized, please visit setup page
DB size: 4 KB
App HTTP server starting up at port 37840
{
  "appVersion": "0.52.3",
  "dbVersion": 195,
  "syncVersion": 25,
  "buildDate": "2022-06-13T23:41:52+02:00",
  "buildRevision": "f0ab1fb5a1c45bf15eae46a72b46ebf132eee531",
  "dataDirectory": "/home/jmcclure/.local/share/trilium-data",
  "clipperProtocolVersion": "1.0",
  "utcDateTime": "2022-06-15T23:57:07.637Z"
}
CPU model: Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz, logical cores: 4 freq: 2693 Mhz
Listening on port 37840
[3967435:0615/185709.089969:ERROR:cursor_loader.cc(114)] Failed to load a platform cursor of type kNull
[3967474:0100/000000.129797:ERROR:gpu_init.cc(457)] Passthrough is not supported, GL is egl, ANGLE is 
Segmentation fault (core dumped)
[3967474:0100/000000.783153:ERROR:sandbox_linux.cc(376)] InitializeSandbox() called with multiple threads in process gpu-process.

No DE. Just my own compositor (Tabby).

loqs · 2022-06-16 08:53:43

I suspect --no-sandbox would bypass the issue --in-process-gpu might also work.

bgiovanni · 2022-06-16 08:56:26

Okay, I've looked around a little bit and I think I might have found the culprit, even though it doesn't depend on me: https://github.com/electron/electron/issues/32436
Fixes have been made for that but so far they haven't been backported to electron16: https://github.com/electron/electron/pu … 1085778869

Assuming that that's the actual issue nothing will change unless:
1. Arch's electron16 doesn't manually backport the patch.
2. Trilium moves to a newer Electron major version that has been patched.

EDIT: Currently I think the only way to run it on Wayland (I couldn't test) is to let it run through Xwayland, without supplying the --ozone stuff.

Also I've realized that 'dump-db', the tool I mentioned in the first post is badly packaged, I'm looking into this before publishing.

EDIT2: I've sorted out the 'dump-db' matter (I literally forgot to let it build :s), unfortunately this leads to a net change of 18MB because of the way node dependencies work.
Considered that 'dump-db' should be an emergency and optional way to dump the notes in case the main app doesn't work, and that Trilium allows within itself to export notes, I'm not really convinced that it's worth an extra 18MB of mostly DUPLICATED dependencies (and no, I can't just symlink them without risk from Trilium node_modules/ because, despite having some deps in common, they have different versions).
Should I create a separate PKGBUILD (perhaps called trilium-dumpdb) so that trilium's one can fly 18MB lighter?

Last edited by bgiovanni (2022-06-16 09:21:53)

Arch Linux

#1 2022-06-15 19:59:24

TriliumNotes PKGBUILD review

#2 2022-06-15 20:07:50

Re: TriliumNotes PKGBUILD review

#3 2022-06-15 23:01:53

Re: TriliumNotes PKGBUILD review

#4 2022-06-15 23:58:56

Re: TriliumNotes PKGBUILD review

#5 2022-06-16 08:53:43

Re: TriliumNotes PKGBUILD review

#6 2022-06-16 08:56:26

Re: TriliumNotes PKGBUILD review

Board footer