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.

@purejava I agree, thanks again for your input.

We could think about adding a javac -v check in the prepare() state which would fail if someone have a JRE and a JDK installed and the JRE selected.

I doubt it’s correct the the AUR package jre-jetbrains provides java-environment. See: https://archlinux.org/packages/?sort=&q=java-environment&maintainer=&flagged=

I was confused by e.g. https://aur.archlinux.org/packages/jre-jetbrains and some others with jre in the name but if you look at the sources it is actually a JDK so from that point it is fine that they provide a java-environment haha but they cannot be more confusing with their names xD

@SailReal I agree on adhering to standards and use what is used in the Arch main repo. That’s why I made the suggestion below: the common jdk package someone would install is java-openjdk, as an Arch package, not from the AUR. This package and the other Arch jdk packages provide java-environment, whereas the Arch jre packages all provide java-runtime.

I doubt it’s correct that the AUR package jre-jetbrains provides java-environment. See: https://archlinux.org/packages/?sort=&q=java-environment&maintainer=&flagged=

@purejava thanks for your feedback. If I look into e.g. https://aur.archlinux.org/packages/keepassxc-cryptomator, there you see the list of packages that provides the java-environment, e.g. jre-jetbrains but in total 4.

Also, we've had multiple issues with certain Java implementations in the past so I thought in sum it would make sense to use what the Arch main repos are using to build so we have one less error cause and not so Java-savvy people don't have to deal with what they want/need to install. But yes, is definitely debatable.

@garlicbreadwolfs thanks for your feedback. I was aware that the solution is not perfect with both points you raised, how would you solve it? You are very welcome to describe it also in the upstream issue https://github.com/cryptomator/cryptomator/issues/1985

@SailReal I am not sure, if the last change is needed. java-environment is only provided by jdks, not jres and therefore should be fine. :)

To begin with, this problem occurs not only in Japanese but also in Chinese. And this is an upstream bug. You should participate in the upstream discussion and not show your lack of understanding of the CJK languages.

ttf-hanazono is not the only Japanese font. There are many other Japanese fonts available. Please understand the situation in which Japanese is placed.

Please remove ttf-hanazono from optdepends. You need some kind of ttf that supports Japanese, but it does not have to be hanazono.

ttf-hanazono is not the only Japanese font. There are many other Japanese fonts available. Please understand the situation in which Japanese is placed.

To begin with, this problem occurs not only in Japanese but also in Chinese. And this is an upstream bug. You should participate in the upstream discussion and not show your lack of understanding of the CJK languages.

@SailReal Thanks for the quick patch!

@Munzu makedepends contains now directly jdk17-openjdk which should fix this problem for other users in the future...thanks again for your feedback :)