Arch Linux User Repository

Those repositories aren't git submodules. They're cargo git dependencies defined in Cargo.toml. cargo clones them to a custom directory in ~/.cargo/git

Please, follow the Arch Linux guidelines on Git submodules and download the submodules via the source array and reference them in prepare(), instead of downloading them in the prepare() function:

==> Starting prepare()...
    Updating git repository `https://github.com/signalapp/boring`
    Updating git submodule `https://github.com/google/boringssl.git`
       Fetch [==>                      ]  14.02%, 257.38KiB/s             
[...]

Regards!

Ahoj,

Yes, this is just the java part (jar and jni so file)

I think then you should rename this package to reflect that it only provides part of the whole upstream, e.g. rename it to libsignal-client-java, and maybe if there are common files which also would be present in other parts of libsignal installation than make a separate package libsignal-client-common and depend on it, so that the other packages can also be installed without conflict.

Regards!

For me, it fails with java-21-openjdk as well. But with a slightly different error:

> BUG! exception in phase 'semantic analysis' in source unit '_BuildScript_' Unsupported class file major version 65

(notice 65 instead of 66)

For me, it compiles correctly with java-17-openjdk. Also, I don't think you need to uninstall other version, once you switch with archlinux-java set.

I was able to work around the new build failures by installing JDK 21 explicitly and removing the generic JDK package that is currently pointing to JDK 22. I expect it's using a newer bytecode version that isn't supported by build tools being used.

pacman -S jdk21-openjdk
archlinux-java set java-21-openjdk
pacman -Rsn jdk-openjdk

Build fails for me:

==> Making package: libsignal-client 0.39.2-1 (Fri 29 Mar 2024 13:30:31 CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found libsignal-0.39.2.tar.gz
==> Validating source files with sha512sums...
    libsignal-0.39.2.tar.gz ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
  -> Extracting libsignal-0.39.2.tar.gz with bsdtar
==> Starting prepare()...
==> Sources are ready.
==> Making package: libsignal-client 0.39.2-1 (Fri 29 Mar 2024 13:30:41 CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> WARNING: Using existing $srcdir/ tree
==> Removing existing $pkgdir/ directory...
==> Starting build()...
cargo build --frozen -p libsignal-jni --release
[...]
    Finished release [optimized + debuginfo] target(s) in 15m 33s
mkdir -p java/shared/resources
cp target/release/libsignal_jni.so java/shared/resources/

Welcome to Gradle 7.6.4!

Here are the highlights of this release:
 - Added support for Java 19.
 - Introduced `--rerun` flag for individual task rerun.
 - Improved dependency block for test suites to be strongly typed.
 - Added a pluggable system for Java toolchains provisioning.

For more details see https://docs.gradle.org/7.6.4/release-notes.html

To honour the JVM settings for this build a single-use Daemon process will be forked. See https://docs.gradle.org/7.6.4/userguide/gradle_daemon.html#sec:disabling_the_daemon.
Daemon will be stopped at the end of the build

FAILURE: Build failed with an exception.

* What went wrong:
Could not open cp_settings generic class cache for settings file '/home/arch/.cache/yay/libsignal-client/src/libsignal-0.39.2/java/settings.gradle' (/home/arch/.cache/yay/libsignal-client/src/.gradle/caches/7.6.4/scripts/c5uid1ri8esi9ij0j7q87vc39).
> BUG! exception in phase 'semantic analysis' in source unit '_BuildScript_' Unsupported class file major version 66

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 6s
==> ERROR: A failure occurred in build().
    Aborting...
 -> error making: libsignal-client-exit status 4

Could you please provide the libsignal-client-bin and signal-cli-bin versions? My supercomputer takes ages to compile them...

Yep thanks for the info. Here's my PKBGUILD for the C ABI called libsignal_ffi that the go version of mautrix-signal uses: https://aur.archlinux.org/packages/libsignal-ffi

Yes, this is just the java part (jar and jni so file). It would probably be best if you provide a separate package, I mainly maintain this package for signal-cli, which also requires a specific libsignal-client version.

Hi @AsamK,

Just a quick message as I maintain the mautrix-signal PKGBUILD, and the switch from a signald-based to a go-based build has just happened with release 0.5.0. It now uses libsignal under the hood. Am I right in my observation that this libsignal-client is in fact just the java aspect of libsignal? In the installation process of mautrix-signal, it expects libsignal_ffi.a which, unless I've missed something, is not provided by this PKGBUILD.

I've started trying to get libsignal to build with the terse cargo build instructions from the libsignal README, but I have some boringssl errors... Still working on those.

Would you consider rewriting this PKGBUILD so it actually provides the rust component of libsignal? Or would you prefer me to keep that separate in another PKGBUILD (if I can get the thing to build that is...), something like libsignal-client-rust maybe?

Thanks for your input, Regards, Mark.

PS: I know there is a binary release, mautrix-signal-bin, I'm interesting in an Arch Linux-built binary though.