@Flamefire (or @branfosj) Are you up for submitting a test report for this on a POWER system?

Test report by @branfosj
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in this PR)
bear-pg0305u19a.bear.cluster - Linux RHEL 7.6, 8335-GTX, Python 2.7.5
See https://gist.github.com/402b4b115aee14a3e7c6491b04779a75 for a full test report.

Currently running (again)

Just wanted to highlight the option --disable-headful added which removes X support and therefore the X dependency. IMO for HPC this is OK. I don't really like the e.g. freetype dependency either, and was thinking about adding a dependency on the freetype ECs, but this is a SYSTEM package. Creating a SYSTEM toolchain freetype is also possible but I'm not sure if this can lead to conflicts as jvm/openjdk-1.8.0-internal/jre/lib/ppc64/libfontmanager.so depends on libfreetype.so.6. Was there a similar situation already? How was it solved?

Test report by @Flamefire
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in this PR)
taurusml8 - Linux RHEL 7.6, 8335-GTX, Python 2.7.5
See https://gist.github.com/3663e2955401671858ecdbe27aab2c0b for a full test report.

@Flamefire Adding freetype as a dependency also implies relying on the system compiler to compile freetype (and all its (build) dependencies), which may lead to surprises/problems too.

@branfosj Any objections to the changes made here?

Just wanted to highlight the option --disable-headful added which removes X support and therefore the X dependency. IMO for HPC this is OK.

Would this be for this particular Java easyconfig or everything?

On our site we install software with GUI components on our windowing-capable login nodes. It's not unfathomable that some of those UIs may be in Java, and it's definitely an aspect of "HPC" that EasyBuild tends to cover.

I'd prefer not adding the --disable-headful. We certainly have applications that are GUI based that we'd make available. Also, this would make this Java different to the other versions available.

Sure. What would the right osdependencies be in this case? The build suggests You might be able to fix this by running 'sudo yum install libXtst-devel libXt-devel libXrender-devel'.

Test report by @Flamefire
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in this PR)
taurusml8 - Linux RHEL 7.6, 8335-GTX, Python 2.7.5
See https://gist.github.com/123cc5ef533e8a30d24a5ddccdf28f3e for a full test report.

Sure. What would the right osdependencies be in this case? The build suggests You might be able to fix this by running 'sudo yum install libXtst-devel libXt-devel libXrender-devel'.

This sounds like at least:

osdependencies = ['libXtst-devel', 'libXt-devel', 'libXrender-devel']

Ideally also the equivalent package name for non-RedHat based Linux distros are added as alternatives by promoting the single string value to a tuple with alternative package names, but I'm not sure that's worth the effort here (is anyone brave enough to use a non RHEL-based distro on POWER)?
Maybe @akesandgren knows the equivalents for Ubuntu/Debian though...

They are:
libxtst-dev, libxt-dev, and libxrender-dev

Ideally also the equivalent package name for non-RedHat based Linux distros are added as alternatives by promoting the single string value to a tuple with alternative package names

So that would be osdependencies = [..., ('libXtst-devel', 'libxtst-dev'), ...] ?

Ideally also the equivalent package name for non-RedHat based Linux distros are added as alternatives by promoting the single string value to a tuple with alternative package names

So that would be osdependencies = [..., ('libXtst-devel', 'libxtst-dev'), ...] ?

Exactly.

Ok done. I added the other debian packages too and squashed the commits

Test report by @Flamefire
SUCCESS
Build succeeded for 1 out of 1 (1 easyconfigs in this PR)
taurusml8 - Linux RHEL 7.6, 8335-GTX, Python 2.7.5
See https://gist.github.com/964739b18fee9b11ad9a82cfa97f8361 for a full test report.

Going in, thanks @Flamefire!