Reinstate libfreetype install on JDK21

[sxa]

Fixes adoptium/temurin-build#3624 (comment) (hopefully!)

Note that I haven't adjusted redhat/src/main/packaging/microsoft/21/msopenjdk-21.spec which still has the rm

I have not tested this, so if a review can fdire off a test and see if the package contains libfreetype.so after this then that would be appreciated.

[karianna]

CC @joe-braley @d3r3kk to see if we need to do the same for MSFT installers.

[steelhead31]

LGTM

[andrew-m-leonard]

Unable to test due to: adoptium/infrastructure#3362

[andrew-m-leonard]

Running a test here: https://ci.adoptium.net/job/adoptium-packages-linux-pipeline_new/1201/

[karianna]

Could not compile settings file '/home/jenkins/workspace/adoptium-packages-linux-pipeline_new/linuxRedHat/settings.gradle'.

startup failed:
General error during conversion: Unsupported class file major version 65

Looks like a 'Code was compiled with Java version X vs being run as Java version Y problem

[sxa]

Could not compile settings file '/home/jenkins/workspace/adoptium-packages-linux-pipeline_new/linuxRedHat/settings.gradle'.

startup failed:
General error during conversion: Unsupported class file major version 65

Looks like a 'Code was compiled with Java version X vs being run as Java version Y problem

That is correct, although I'm surprised it hit it in this run because I mitigated that yesterday by changing the default java to be 8 on the machine (See adoptium/infrastructure#3352 (comment) - my understanding from a Slack conversion this week is that the version of gradle we've got needed 8 or something similar). That should not block merging of this PR as it's sure to be a machine specific issue.

https://ci.adoptium.net/job/adoptium-packages-linux-pipeline_new/1202/ is a re-run of Andrew's earlier job on aarch64 instead of x86-64 so will be a better test. I'll try and look at why that (new) machine is misbehaving tomorrow.

[sxa]

https://ci.adoptium.net/job/adoptium-packages-linux-pipeline_new/1202/ is a re-run of Andrew's earlier job on aarch64 instead of x86-64 so will be a better test. I'll try and look at why that (new) machine is misbehaving tomorrow.

That didn't work. Apparently the packaging job is forcing itself to run on an x64 docker host

Still waiting to schedule task
All nodes of label ‘[dockerBuild&&linux&&x64](https://ci.adoptium.net/label/dockerBuild&&linux&&x64/)’ are offline
Running on [dockerhost-equinix-ubuntu2004-x64-1](https://ci.adoptium.net/computer/dockerhost%2Dequinix%2Dubuntu2004%2Dx64%2D1/) in /home/jenkins/workspace/adoptium-packages-linux-pipeline_new

so even using the parameter to build for aarch64 it was still being scheduled on the new machine. I've re-enabled an equinix machine temporarily so we can test this on a known-working configuration - it's at https://ci.adoptium.net/job/adoptium-packages-linux-pipeline_new/1203/console

[sxa]

so even using the parameter to build for aarch64 it was still being scheduled on the new machine. I've re-enabled an equinix machine temporarily so we can test this on a known-working configuration - it's at https://ci.adoptium.net/job/adoptium-packages-linux-pipeline_new/1203/console

That ran green. It's past midnight for me so I've locked the job so the output won't get deleted and we can do some verification / comparison with the GA builds tomorrow (If anyone wants to do so before I go for it then, of course, feel free :-) )

[sxa]

Confirmed that the aarch64 deb and rpm archives from job 1203 linked above are identical other than the presence of the libfreetype.so file, so this change seems good.

[andrew-m-leonard]

looks good

[sxa]

Merging, noting that the Alpine apk has the libfreetype.so included so is unaffected and doesn't need a modification.