Search Criteria
Package Details: mindustry-bin 1:7.0_146-2
Package Actions
Git Clone URL: | https://aur.archlinux.org/mindustry-bin.git (read-only, click to copy) |
---|---|
Package Base: | mindustry-bin |
Description: | A sandbox tower defense game written in Java |
Upstream URL: | https://github.com/Anuken/Mindustry |
Licenses: | GPL3 |
Conflicts: | mindustry |
Provides: | mindustry |
Submitter: | dmitmel |
Maintainer: | dmitmel |
Last Packager: | dmitmel |
Votes: | 31 |
Popularity: | 1.02 |
First Submitted: | 2019-10-08 13:45 (UTC) |
Last Updated: | 2024-03-23 22:15 (UTC) |
Dependencies (4)
- hicolor-icon-theme (hicolor-icon-theme-gitAUR)
- java-runtime (jre10AUR, jre12AUR, jdk10AUR, jdk10-openj9-binAUR, jdk7AUR, jre7AUR, amazon-corretto-16AUR, jdk8-graalvm-binAUR, jdk16-graalvm-binAUR, jdk16-adoptopenjdkAUR, liberica-jre-11-binAUR, jdk11-j9-binAUR, jre11-jbr-xdgAUR, jre16-openjdkAUR, jre14-openjdkAUR, jre15AUR, jre14AUR, jre13AUR, jre16AUR, jre18-openjdkAUR, amazon-corretto-19-binAUR, jdk19-graalvm-binAUR, liberica-jre-11-full-binAUR, jdk19-graalvm-ee-binAUR, jdk13-openjdk-binAUR, liberica-jre-8-full-binAUR, jdk11-graalvm-binAUR, jre-openj9AUR, jdk11-graalvm-ee-binAUR, jre12-openjdkAUR, jdk11-dragonwell-standard-binAUR, jdk11-jetbrains-binAUR, jdk20-graalvm-binAUR, jdk17-graalvm-binAUR, jdk20-openj9-binAUR, zulu-13-binAUR, jdk8-dragonwell-extended-binAUR, jdk8-dragonwell-standard-binAUR, jdk11-dragonwell-extended-binAUR, jdk17-dragonwell-standard-binAUR, jdk8-j9-binAUR, jdk7-j9-binAUR, jdk7r1-j9-binAUR, jre13-openjdkAUR, jre15-openjdkAUR, jdk21-graalvm-binAUR, jre17-jetbrainsAUR, microsoft-openjdk-11-binAUR, microsoft-openjdk-17-binAUR, microsoft-openjdk-21-binAUR, liberica-nik-24-full-binAUR, jre21-jetbrains-gitAUR, jdk21-jetbrains-gitAUR, zulu-8-binAUR, mandrel-binAUR, mandrel24-binAUR, liberica-jdk-11-lite-binAUR, liberica-jdk-11-binAUR, jdk17-graalvm-ee-binAUR, jdk22-graalvm-ee-binAUR, jdk20-graalvm-ee-binAUR, jdk22-graalvm-binAUR, jre19-openjdkAUR, jdk17-jetbrains-binAUR, zulu-jdk-fx-binAUR, jre21-jetbrainsAUR, jdk17-zulu-prime-binAUR, jdk8-perfAUR, zulu-jre-fx-binAUR, zulu-fx-binAUR, zulu8-fx-binAUR, zulu11-fx-binAUR, zulu17-fx-binAUR, zulu21-fx-binAUR, jdk11-openj9-binAUR, jre-openjdk-wakefieldAUR, jdk-openjdk-wakefieldAUR, jre-zulu-binAUR, jre-zulu-fx-binAUR, jdk21-dragonwell-standard-binAUR, jdk21-dragonwell-extended-binAUR, jdk-android-studioAUR, zing-8-binAUR, zing-21-binAUR, jdk-openj9-binAUR, zulu-11-binAUR, jdk8-graalvm-ee-binAUR, jdk8-dragonwell-extendedAUR, java-openjdk-binAUR, zulu-23-binAUR, jdk21-jetbrains-binAUR, jre11AUR, jdk-temurinAUR, jdk21-temurinAUR, jdk17-temurinAUR, jdk11-temurinAUR, jre17AUR, amazon-corretto-8AUR, amazon-corretto-11AUR, jdk21-graalvm-ee-binAUR, jdk8-openj9-binAUR, liberica-jdk-full-binAUR, liberica-jdk-21-full-binAUR, liberica-jdk-8-full-binAUR, jre21-zulu-binAUR, jre17-zulu-binAUR, jre-zuluAUR, jre-zulu-fxAUR, jdk8-temurinAUR, zulu-21-binAUR, jre8AUR, jdk8AUR, jre-jetbrainsAUR, openjdk-zulu-ca-fx-binAUR, openjdk-zulu8-ca-fx-binAUR, openjdk-zulu11-ca-fx-binAUR, openjdk-zulu17-ca-fx-binAUR, openjdk-zulu21-ca-fx-binAUR, jdk21-openj9-binAUR, jdk17-openj9-binAUR, zulu-17-binAUR, amazon-corretto-17AUR, amazon-corretto-21-binAUR, jdk23-graalvm-ee-binAUR, jreAUR, jdkAUR, jre-ltsAUR, jdk-ltsAUR, liberica-jdk-11-full-binAUR, liberica-jdk-17-full-binAUR, zulu-17-fx-binAUR, java-openjdk-ea-binAUR, jdk-openjdk, jdk11-openjdk, jdk17-openjdk, jdk21-openjdk, jre-openjdk, jre11-openjdk, jre17-openjdk, jre21-openjdk, jre8-openjdk)
- sh (dashbinshAUR, bash-devel-static-gitAUR, zshbinshAUR, bash-devel-gitAUR, busybox-coreutilsAUR, bash-gitAUR, bash)
- libicns (make)
Latest Comments
« First ‹ Previous 1 2 3 Next › Last »
dmitmel commented on 2020-11-29 17:05 (UTC) (edited on 2020-11-29 17:05 (UTC) by dmitmel)
Eisfunke: Interesting. I suppose the upstream has updated updated the tag for v118. Because as you can see from the commit history I did update the checksum. I still have the "counterfeit" JAR file for v118 with the hash
4a724410d7a3c6f3ca076037713e7da357bfc6199ca661cc73a7805f901a44af
, if you want I can investigate.Eisfunke commented on 2020-11-29 17:02 (UTC)
dmitmel: Thanks for replying and sorry for the wrong link.
That's exactly my point: the checksum of the JAR is
a07fbd97e245ebe571fcfd1179f0292f449f2dd2d2cafdd6012631c61e24f1e7
, as I wrote and as you confirmed. But the PKGBUILD says4a724410d7a3c6f3ca076037713e7da357bfc6199ca661cc73a7805f901a44af
.When I edit the PKGBUILD and paste
a07fbd97e245ebe571fcfd1179f0292f449f2dd2d2cafdd6012631c61e24f1e7
, the checksum you confirmed, it builds correctly.But that's probably irrelevant now, as 119 has been released half an hour ago :D
dmitmel commented on 2020-11-29 16:14 (UTC)
Eisfunke: First of all, you linked to the JAR of a wrong version (108 instead of 118), secondly, this is a problem on your end. I've re-downloaded the latest JAR and its SHA256 checksum is
a07fbd97e245ebe571fcfd1179f0292f449f2dd2d2cafdd6012631c61e24f1e7
, as expected. I also ranupdpkgsums
just in case, nothing has been updated.Eisfunke commented on 2020-11-29 15:48 (UTC)
Validity check fails for me for Build 118, the checksum seems to be wrong. https://github.com/Anuken/Mindustry/releases/download/v108/Mindustry.jar has the checksum a07fbd97e245ebe571fcfd1179f0292f449f2dd2d2cafdd6012631c61e24f1e7 for me, but the PKGBUILD has one starting with 4a.
Firstbober commented on 2019-10-25 11:21 (UTC)
dmitmel: Sure, it should work well.
dmitmel commented on 2019-10-25 10:55 (UTC)
Firstbober: Thanks, didn't consider that, I'll change that later (I don't have a access to my machine right now). Although I think that the version should instead look like
major.minor_build
to show that the build number isn't reset on each new minor/major version.Firstbober commented on 2019-10-25 09:15 (UTC) (edited on 2019-10-25 09:16 (UTC) by Firstbober)
I think the version number should look like major.minor.patch.0.build or something similar to mark the version of the game. For example 5.0.0.0.97.
dmitmel commented on 2019-10-08 17:32 (UTC)
eschwartz: Thanks for your help very much!
eschwartz commented on 2019-10-08 17:30 (UTC)
Yes, you'll need to have the existing additional pkgname deleted (or merged, but there are no comments or votes to merge anyway) before you can push an update containing an additional pkgname in this .SRCINFO.
dmitmel commented on 2019-10-08 17:17 (UTC)
eschwartz: Yeah, I'm probably going to do that way. Also: if I make a split package with
pkgbase=mindustry
and which contains two packagesmindustry
andmindustry-server
, should I ask for deletion ofmindustry-server
?« First ‹ Previous 1 2 3 Next › Last »