On Tue, May 14 2019, Jonathan Nieder wrote: > Todd Zullinger wrote: > >> The JGIT prereq uses 'type jgit' to determine whether jgit is present. >> While this should be sufficient, if the jgit found is broken we'll waste >> time running tests which fail due to no fault of our own. >> >> Use 'jgit --version' instead, to catch some badly broken jgit >> installations. >> >> Signed-off-by: Todd Zullinger <tmz@xxxxxxxxx> >> --- >> I ran into such a broken jgit on Fedora >= 30¹. This is clearly a >> problem in the Fedora jgit package which will hopefully be resolved >> soon. But it may be good to avoid wasting time debugging tests which >> fail due to a broken tool outside of our control. >> >> ¹ https://bugzilla.redhat.com/1709624 > > Reviewed-by: Jonathan Nieder <jrnieder@xxxxxxxxx> > > It would be nice to describe that bug in the commit message, to save > readers some head scratching. FWIW the jgit in Debian testing/unstable is similarly broken right now: $ apt policy jgit-cli jgit-cli: Installed: 3.7.1-6 Candidate: 3.7.1-6 Version table: *** 3.7.1-6 900 900 http://ftp.nl.debian.org/debian testing/main amd64 Packages 800 http://ftp.nl.debian.org/debian unstable/main amd64 Packages 100 /var/lib/dpkg/status 3.7.1-4 700 700 http://ftp.nl.debian.org/debian stable/main amd64 Packages $ jgit --version; echo $? Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.lang.NoClassDefFoundError: org/kohsuke/args4j/CmdLineException at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2701) at java.lang.Class.privateGetMethodRecursive(Class.java:3048) at java.lang.Class.getMethod0(Class.java:3018) at java.lang.Class.getMethod(Class.java:1784) at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544) at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526) Caused by: java.lang.ClassNotFoundException: org.kohsuke.args4j.CmdLineException at java.net.URLClassLoader.findClass(URLClassLoader.java:382) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 7 more 1 So rather than describe specific bugs on RedHat/Debian maybe just say: This guards against cases where jgit is present on the system, but will fail to run, e.g. because of some JRE issue, or missing Java dependencies. Seeing if it gets far enough to process the "--version" argument isn't perfect, but seems to be good enough in practice. It's also consistent with how we detect some other dependencies, see e.g. the CURL and UNZIP prerequisites.