Package Details: libsignal-client 0.62.0-1

Git Clone URL: https://aur.archlinux.org/libsignal-client.git (read-only, click to copy)
Package Base: libsignal-client
Description: Library for the Signal Protocol.
Upstream URL: https://github.com/signalapp/libsignal
Licenses: AGPL-3.0-only
Submitter: AsamK
Maintainer: AsamK
Last Packager: AsamK
Votes: 8
Popularity: 0.000705
First Submitted: 2021-01-09 18:17 (UTC)
Last Updated: 2024-11-30 15:27 (UTC)

Dependencies (10)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3 4 Next › Last »

AsamK commented on 2024-02-18 20:11 (UTC)

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.

marcool04 commented on 2024-02-17 19:35 (UTC)

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.

twitmuck commented on 2023-10-20 11:04 (UTC)

@dreieck add -x javadoc to the gradle cmd in the PKGBUILD, fixed it for me.

HC6505 commented on 2023-08-22 11:06 (UTC)

@dreieck jdk17-openjdk seems, as you suggest, not to be needed, thank you

I can also build version 0.31.0 with the PKGBUILD from here and java-environment or just jdk-openjdk in makedepends.

So if anyone else need version 0.31.0 without being forced to use jdk17-openjdk, it can be done with this:

In PKGBUILD change: pkgver=0.31.0

makedepends=('cargo' 'gradle' 'git' 'zip' 'protobuf' 'cmake' 'clang' 'jdk-openjdk')

sha512sums=('a066ab3e654b4b9b31acd8fb603d8ad148f05c79f5003a3246311186b3169db699a7d4ca7925170de49eafa2768863243f69f0af46853e0435a235e06737dcac')

save and run makepkg --install

dreieck commented on 2023-08-17 09:37 (UTC) (edited on 2023-08-17 09:40 (UTC) by dreieck)

A note on Java version:

I successfully built (version 0.31.0-git) with just having java-environment as make dependency and having this fulfilled by currently most up to date jdk-openjdk version 20.0.2.u9-3.

So maybe jdk17-openjdk is not specifically needed, and java-environment might be a good make dependency instead.
But you could add versioned dependencies if needed, e.g. java-environment>=17 or/ and java-environment<29.

Regards and thanks for maintaining!

dreieck commented on 2023-08-17 08:41 (UTC)

Build fails for me with Task :client:javadoc FAILED:

> Task :client:javadoc FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':client:javadoc'.
> Javadoc generation failed. Generated Javadoc options file (useful for troubleshooting): '/tmp/makepkg/build/libsignal-client/src/libsignal-0.30.0/java/client/build/tmp/javadoc/javadoc.options'

The mentioned file /tmp/makepkg/build/libsignal-client/src/libsignal-0.30.0/java/client/build/tmp/javadoc/javadoc.options is quite big; it is uploaded ↗ here. It starts as follows:

-Xdoclint:none '-quiet'
-classpath '/tmp/makepkg/build/libsignal-client/src/libsignal-0.30.0/java/client/build/classes/java/main:/tmp/makepkg/build/libsignal-client/src/libsignal-0.30.0/java/client/build/resources/main'
-d '/tmp/makepkg/build/libsignal-client/src/libsignal-0.30.0/java/client/build/docs/javadoc'
-doctitle 'client 0.30.0 API'
-encoding 'UTF-8'
-notimestamp 
-quiet 
-windowtitle 'client 0.30.0 API'
'/tmp/makepkg/build/libsignal-client/src/libsignal-0.30.0/java/client/src/main/java/org/signal/libsignal/cds2/Cds2Client.java'
'/tmp/makepkg/build/libsignal-client/src/libsignal-0.30.0/java/client/src/main/java/org/signal/libsignal/crypto/jce/Mac.java'
'/tmp/makepkg/build/libsignal-client/src/libsignal-0.30.0/java/client/src/main/java/org/signal/libsignal/crypto/jce/MessageDigest.java'
[...]

Regards!

dreieck commented on 2023-08-17 08:25 (UTC) (edited on 2023-08-17 08:53 (UTC) by dreieck)

I think cargo should also be added to checkdepends array.

Regardiing the comment from @yar from 2023-05-30:

This should depend on rust, not on cargo. There is no package called cargo, but rust provides it.

I think you are wrong. provides entries are exactly for the case that different packages can be dropped-in to provide the same functionality. cargo is fine here.

Regards!

yar commented on 2023-05-30 22:08 (UTC)

This should depend on rust, not on cargo. There is no package called cargo, but rust provides it.

david.chung commented on 2023-05-15 23:24 (UTC) (edited on 2023-05-15 23:27 (UTC) by david.chung)

I see the following when attempting to build:

error: edition 2021 is unstable and only available with -Z unstable-options.

error: could not compile `base64ct`

My workaround was to remove --frozen and add -Z unstable-options to cargo build under prepare(); remove --frozen from cargo test under check(); and replace stable with nightly in all instances of export RUSTUP_TOOLCHAIN=stable.

EDIT: formatting

sylphio commented on 2023-03-25 16:35 (UTC)

I faced the following error:

Error: LinkageError occurred while loading main class org.gradle.launcher.GradleMain
        java.lang.UnsatisfiedLinkError: /usr/lib/jvm/java-17-openjdk/lib/libnio.so: /usr/lib/jvm/java-17-openjdk/lib/libnio.so: undefined symbol: reuseport_available

This was solved by removing /usr/lib from LD_LIBRARY_PATH. See: https://bugs.archlinux.org/task/77183

Perhaps this will help someone else in the future.