Arch Linux User Repository

This fails to compile for me in aurutils with various errors including:

src/main/java/io/finn/signald/db/IProfilesTable.java:123: error: cannot infer type arguments for com.fasterxml.jackson.core.type.TypeReference<T>
      return JSONUtil.GetMapper().readValue(encoded, new TypeReference<>() {});
                                                                      ^  reason: cannot use '<>' with anonymous inner classes

> Task :compileJava FAILED

FAILURE: Build failed with an exception.

But seems to work fine in a clean chroot?

Thanks for updating the permissions.

For those wishing to use java 11

archlinux-java set java-11-openjdk

Using environment variables below will make a hard dep on OpenJDK, while this just needs java-environment less than 16.

For those interested in installing signald without removing an installation of a more recent version of Java, I found that the following patch to PKGBUILD allowed me to install signald by using a java-11 install:

--- PKGBUILD.old        2021-12-10 21:48:08.304075884 -0500
+++ PKGBUILD.new        2021-12-10 21:48:01.240736923 -0500
@@ -26,7 +26,7 @@

 build() {
     cd "${srcdir}/${pkgname}-${pkgver}"
-    make installDist
+    env JAVA_HOME=/usr/lib/jvm/java-11-openjdk make installDist
 }

 package() {

@binarypenguin

looks like it does in fact still compile with openjdk java-11. I've added "java-runtime<16" in depends=() to reflect this.

I'll keep track of the issue and remove this when this is settled. thanks for the bug report.

Hi, the build is currently broken with current versions openjdk and gradle

See the issue https://gitlab.com/signald/signald/-/issues/166

Hey,

thanks, that was fast :) Unfortunately, I might have forgotten to add that sysusers.d is executed as a pacman-hook. So during initial installation, the chown might try to chown towards a yet nonexistant user. To fix this, official packages use tmpfiles.d, whose hook is guaranteed to run AFTER the sysusers.d hook, for such operations:

Z     /path-or-glob/to/adjust/mode/recursively mode user group -           -

So the equivalent to your chown in this case would be (e.g. in /usr/lib/tmpfiles.d/signald.conf):

Z /var/lib/signald 0700 signald signald - -

If the directory should be created you can use D instead of Z. This mechanism is really powerful and also covers cases such as acls, etc.pp., which is quite nice.

Sorry that I've forgotten to add that vital information during the first comment...

Hey, thank you for maintaining that package!

However I noticed that you are still creating (and even removing!) users/groups in your .install file, which was deprecated by Arch in 2017 [0] in favor of the sysuser mechanism. Would it be possible to maybe switch this package over to that format as well? Basically, it should boil down to replacing the explicit user-management operations in the postinstall with a plain configuration file /usr/lib/sysusers.d/signald.conf:

u signald - "Signald daemon user"

A matching group will automatically be created. Advantages are: no more hardcoded UID, a fitting, free, system-user uid will automatically be selected. Furthermore, if required, the mechanism allows users to selectively override this user generation if required by means of a template mechansim. Details can be found in man 5 sysusers.d.

There further exists a complementary mechanism to create directories with fitting permissions (see man 5 tmpfiles.d), which can be used to generate the data directory, e.g. using /usr/lib/tmpfiles.d/signald.conf:

d /var/lib/signald 0700 signald signald - -

So, what do you think? I'd be happy to answer any questions or help out if desired.

Thanks again for your work!

0: https://archlinux.org/todo/switch-to-systemd-sysusers/

Hi GI_Jack, mautrix-signal indicated an issue with permissions: Permission denied: '/var/lib/signald/avatars/d2[..]' To fix this, I changed the permissions of /var/lib/signald/avatars from 700 to 750. (besides making the user of mautrix-signal member of the group signald)

I generally don't write -git packages unless I have to. They do not fit my workflow of stable releases, and reproducible builds.

Feel free to fork if this suits your need.