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.

@SailReal I think ttf-dejavu should be an optional dependency.

@dr460nf1r3 It is debatable, Cryptomator can be build with JDK 19 but I would suggest to stay as close as possible to upstream and the other releases like PPA, AppImage and Flatpak so that we can easier pinpoint problems. Cryptomator using JDK 19 is on the way https://github.com/cryptomator/cryptomator/pull/2509, will not take that much time until v1.6.16 will be shipped.

It seems that the Java dependency should be updated:

==> Starting prepare()...
You don't have a Java 17 or 18 JDK selected as your Java environment but the following installed on your system:
       java-19-openjdk (default)

@AvianaCruz Thanks again for your feedback! Pushed it and will be applied within the next update.

@SailReal The icon locations may be wrong. They should be:

  install -Dm644 "${srcdir}/cryptomator-${pkgver}/dist/linux/common/org.cryptomator.Cryptomator256.png" "${pkgdir}/usr/share/icons/hicolor/256x256/apps/org.cryptomator.Cryptomator.png"
  install -Dm644 "${srcdir}/cryptomator-${pkgver}/dist/linux/common/org.cryptomator.Cryptomator512.png" "${pkgdir}/usr/share/icons/hicolor/512x512/apps/org.cryptomator.Cryptomator.png"
  install -Dm644 "${srcdir}/cryptomator-${pkgver}/dist/linux/common/org.cryptomator.Cryptomator.svg" "${pkgdir}/usr/share/icons/hicolor/scalable/apps/org.cryptomator.Cryptomator.svg"

@AvianaCruz thanks for the hint. Pushed it and will be applied within the next update.

The upstream added --strip-native-commands parameter on jlink command. https://github.com/cryptomator/cryptomator/blob/bcfda68bef1211f57d85a3321c1521146563ce9d/.github/workflows/appimage.yml#L64

@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.