jabref does not build in clean chroot about aur

[danielshub]

Thanks for maintaining the jabref package. Trying to use archlinux-java-run is dommed. It requires the symlink created by archlinux-java fix. You do not want to manually create the symlink in the PKGBUILD since this would be change the build machine configuration and not simply the build environment.

I looked at the PKGBUILDs for the packages in the community repo that depend on gradle and set JAVA_HOME (keycloak-archlinux-theme, freeplane, and zaproxy) and they all set JAVA_HOME directly.

I think this would work for jabref also since it requires a specific java version so you know the path in advance.

[michaellass]

I think this would work for jabref also since it requires a specific java version so you know the path in advance.

Not really. I suggest installing jdk18-openj9-bin currently but there are other JDK 18 packages in the AUR (although only few). And hopefully JabRef will be updated for newer (supported) JDKs soon.

I think this is actually an issue with the jdk18-openj9-bin package which is currently lacking any installation script that sets itself as default if no other JDK is installed. I am going to add one so that the java environment is valid within the chroot and archlinux-java-run will be able to work as expected.

[michaellass]

Could you please retry building jabref in a clean chroot, now with jdk18-openj9-bin-18.0.2.1-2 released?

[danielshub]

Still does not build in a clean chroot with makechrootpkg:

==> Starting build()...
Using JDK from /usr/lib/jvm/java-18-j9 to build JabRef.
16:02:16.063 0x16f00    j9vm.224    *   ** ASSERTION FAILED ** at ../../../../../openj9/runtime/vm/FlushProcessWriteBuffers.cpp:85: ((0 == mlockrc))
JVMDUMP039I Processing dump event "traceassert", detail "" at 2022/12/08 11:02:16 - please wait.
JVMDUMP032I JVM requested System dump using '/build/jabref/src/jabref-5.7/core.20221208.110216.877.0001.dmp' in response to an event
JVMPORT030W /proc/sys/kernel/core_pattern setting "|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h" specifies that the core dump is to be piped to an external program.  Attempting to rename either core or core.902.

JVMDUMP012E Error in System dump: The core file created by child process with pid = 902 was not found. Expected to find core file with name "/build/jabref/src/jabref-5.7/core.902"
JVMDUMP032I JVM requested Java dump using '/build/jabref/src/jabref-5.7/javacore.20221208.110216.877.0002.txt' in response to an event
JVMDUMP010I Java dump written to /build/jabref/src/jabref-5.7/javacore.20221208.110216.877.0002.txt
JVMDUMP032I JVM requested Snap dump using '/build/jabref/src/jabref-5.7/Snap.20221208.110216.877.0003.trc' in response to an event
JVMDUMP010I Snap dump written to /build/jabref/src/jabref-5.7/Snap.20221208.110216.877.0003.trc
JVMDUMP013I Processed dump event "traceassert", detail "".
==> ERROR: A failure occurred in build().
    Aborting...

I have the new release of jdk18

resolving dependencies...
looking for conflicting packages...

Packages (6) java-environment-common-3-3  java-runtime-common-3-3  nspr-4.35-1  nss-3.85-1  archlinux-java-run-9-1  jdk18-openj9-bin-18.0.2.1-2

[michaellass]

Thanks for testing. So the initial issue with archlinux-java-run is now solved. I can reproduce the new issue:

• OpenJ9 uses mlock() and fails with the shown error when this syscall fails: https://github.com/eclipse-openj9/openj9/blob/master/runtime/vm/FlushProcessWriteBuffers.cpp#L84
• mlock() is not available in chroot environments spawned by systemd-nspawn (which is used by makechrootpkg under the hood): systemd/systemd#9414

I really do not want to add another JDK 18 package to the AUR which I think would be the only way to fix this. So unfortunately I have to close this as wontfix. For now, jabref will not build using makechrootpkg.

[danielshub]

Thanks for looking into this. I agree that it is no longer the original issue. Based on your links, the new issue does not seem like it is an issue with jabref and trying to patch out or spend extra effort packaging out of date java versions seems silly.

[michaellass]

I just pushed JabRef 5.8 to AUR which uses Java 17 to build, i.e., it can use the standard jdk17-openjdk package from the official repositories. it might be worth retrying to build JabRef in a chroot.