Arch Linux User Repository

the pkgbuild makes no sense:

1. Bash is part of the base package and shouldn't be listed in the depends, as makepkg depends on it.
2. This package doesn't depend on xorg-xrandr.
3. Why does it include jdk17 when you are exporting java 11 to path?

This package should not depends on jdk17-openjdk since it only requires jre to run.

In the launcher script Unciv.sh it prepends /usr/lib/jvm/java-11-openjdk/bin/ to PATH, but the dependency was jdk17-openjdk. Maybe it should just depends on java-runtime like the unciv-bin package.

This fails the source file validation for me.

==> Validating source files with md5sums...
    4.9.5.zip ... FAILED
    gradle-7.2-bin.zip ... Passed
    Unciv.sh ... Passed
    unciv.desktop ... Passed
==> ERROR: One or more files did not pass the validity check!
==> ERROR: Could not download sources.

The libgdx 1.11.0 update is irrelevant for Linux users. Please do check whether an update is actually needed before flagging this package out-of-date.

Build fails if JAVA_HOME is set and points to 1.8. Probably it would be better to unset JAVA_HOME or point it to 11 instead. The following worked for me

diff --git a/PKGBUILD b/PKGBUILD
index 31309af..dd2c3cd 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -38,6 +38,7 @@ prepare() {
 build() {
   cd $_srcdir
   unset _JAVA_OPTIONS
+  unset JAVA_HOME
   export PATH=/usr/lib/jvm/java-11-openjdk/bin/:$PATH
   GRADLE_USER_HOME="$srcdir" ./gradlew desktop:dist
 }

Why is GRADLE_USER_HOME set to $srcdir in PKGBUILD? This essentially ignores any user specific settings such as proxy for gradle set in gradle.properties. Is it really necessary to do so?

@kleintux Hmmm not sure how this happened. Let me check later (or maybe the game will be updated before I even check...)

@rs410ga: This PKGBUILD never deletes any asset in the Android directory. It only removes build scripts because they somehow keep asking for the Android SDK even when not building for Android. A lot of assets are always located inside the android/ subdirectory and they have been fine till now.

There's a new version from upstream that fixes the image packing issue. I don't think there's any change necessary for this PKGBUILD. Just wait for the update later (I am thinking about how to handle the exotic -imagePacking version suffix).