Arch Linux User Repository

Everyone, with great thanks to @SailReal, this package now builds Cryptomator from source. If you wish to continue using the binary AppImage build, you need only to install cryptomator-bin.

We made this change to better align with the desires of the community (you've asked a few times to make this a "build from source" package) as well as better align to the package naming convention within the AUR.

@ixidion finally it got fixed :)

https://github.com/cryptomator/aur/commit/c5b3ba46a48f1b44a0bd76bac57bc7f12c85ae3b

Hello! I can't update to the latest version. I get an error:

Archive:  openjfx.zip
  inflating: jmods/javafx.graphics.jmod  
  inflating: jmods/javafx.controls.jmod  
  inflating: jmods/javafx.fxml.jmod  
  inflating: jmods/javafx.base.jmod  
The JAVA_HOME environment variable is not defined correctly,
this environment variable is needed to run this program.

but

echo $JAVA_HOME                                                                                             ✔ 
/usr/lib/jvm/java-21-openjdk/bin/

Checksums are failing. ==> Überprüfe source_x86_64 Dateien mit sha256sums... jdk.tar.gz ... FEHLGESCHLAGEN openjfx.zip ... FEHLGESCHLAGEN

@fosskers because we already hat different problems with different JDKs (Temurin, Zulu, Oracle, ...) and different JDK versions which makes testing and troubleshooting a nightmare.

Also the required JavaFX needs to be compatible with the JDK. Archlinux dropped JavaFX from the main repos for some reason. Installing the correct JavaFX to an existing JDK is quiet difficult for a "normal" user (you need to sync those versions etc).

For these reasons we decided to build Cryptomator with the same JDK and JavaFX flavour and version everywhere where we build Cryptomator.

Why does this package download a custom version of the JDK instead of depending on Arch packages?

@SailReal No worries. And can confirm the update does indeed fix the problem. Thanks!

@JanetGonzalez creating something like ttf-cjk sounds great in the first place, but how does this virtual package tell the user which fonts provide a ttf-cjk font? The ttf-cjk could have all possible fonts as an optional dependency but I'm not sure if this really helps because you can install then ttf-cjk without having any ttf-cjk installed because all dependencies of this package are optional.

Otherwise we have to duplicate all ttf-cjk fonts and only change that they provide ttf-cjk, then if you install a ttf-cjk it is sure that you have one installed but that creates too much noise imo...hmmmm

Maybe we should simply remove ttf-hanazono and add a note that in cjk you need to install something like ttf-hanazono?

Since this problem affects not only Japanese but also Chinese and Korean, the virtual package name ttf-cjk-font is more appropriate. My apologies.

ttf-hanazono should be removed from the dependency. Ideally, a virtual package called ttf-japanese-font should be created and added to the dependencies, like ttf-font. For use in a Japanese environment, Cryptomator requires a Japanese font in ttf format (not OTF, it must be TTF), but not necessarily hanazono. There are many other Japanese fonts besides hanazono.

@CrashTD sorry for the late response, wasn't able to reproduce it and thought there was a problem on your machine but it is indeed a problem of the build chain of Cryptomator or more precisely Maven. @purejava fixed it in https://github.com/cryptomator/aur/pull/6