Mooninaut
commented
1 year ago The column headers under "JDK21.0.XX+Y ????" say "jdk20" instead of "jdk21".
Closed sophia-guo closed 1 year ago
Mooninaut
commented
1 year ago The column headers under "JDK21.0.XX+Y ????" say "jdk20" instead of "jdk21".
jerboaa
commented
1 year ago The column headers under "JDK21.0.XX+Y ????" say "jdk20" instead of "jdk21".
Thanks, fixed.
Siedlerchr
commented
1 year ago JDK 21.0.1 is now also officially released https://www.oracle.com/java/technologies/javase/21-0-1-relnotes.html
rec-bln
commented
1 year ago When can we expect JDK 17.0.9 for windows x64?
sophia-guo
commented
1 year ago @rec-bln it's blocked by https://github.com/adoptium/aqa-tests/issues/4831, which we are working on right now.
wendigo
commented
1 year ago Is there a plan to release JDK 21 ppc64 build?
h-vetinari
commented
1 year ago Is there a plan to release JDK 21 ppc64 build?
See https://github.com/adoptium/adoptium-support/issues/917 (TL;DR: maybe)
rec-bln
commented
1 year ago @rec-bln it's blocked by adoptium/aqa-tests#4831, which we are working on right now.
thanks! Looking forward to get the release :) thanks for your work on this!
sxa
commented
1 year ago Is there a plan to release JDK 21 ppc64 build?
Do you mean aix/ppc64 or Linux/ppc64le? The former is a definite no for now as some of the new features are not yet implemented on AIX. Linux/ppc64le has been shipped now.
wendigo
commented
1 year ago @sxa Linux/ppc64le :) We (@trinodb/trino) release for linux x64, arm64 and ppc64le platforms, hence the question
chadlwilson
commented
1 year ago Hi folks - The Windows x64 builds seem to be separated into a separate release at https://github.com/adoptium/temurin17-binaries/releases/tag/jdk-17.0.9%2B9.1 , I guess due to https://github.com/adoptium/aqa-tests/issues/4831 - are these going to be merged into the same GitHub release as everything else or is this the permanent situation for this release?
sxa
commented
1 year ago It will be permanent to avoid any confusion for people who picked up the old one and may have a record of the SHAs etc. If you pull from the API you should receive the latest version that is available.
chadlwilson
commented
1 year ago @sxa the x64 binaries were never published to the old release though.
This is a bit unfortunate. We didn't use the APIs - IIRC due to rate limiting (not sure if relevant now), and 1 less dependency on external infra. Guess will need to migrate.
huczas
commented
1 year ago During update, there is a problem with package version under ubuntu 2004,
curl https://packages.adoptium.net/artifactory/deb/pool/main/t/temurin-11/temurin-11-jdk_11.0.21.0.0+9_amd64.deb
{
"errors" : [ {
"status" : 404,
"message" : "File not found."
} ]
}Also output from apt-get during packer installation:
azure-arm: Err:1 https://packages.adoptium.net/artifactory/deb focal/main amd64 temurin-11-jdk amd64 11.0.21.0.0+9
azure-arm: 400 Bad Request [IP: 146.75.123.42 443]
azure-arm: E: Failed to fetch [https://packages.adoptium.net/artifactory/deb/pool/main/t/temurin-11/temurin-11-jdk_11.0.21.0.0+9_amd64.deb](https://packages.adoptium.net/artifactory/deb/pool/main/t/temurin-11/temurin-11-jdk_11.0.21.0.0+9_amd64.deb) 400 Bad Request [IP: 146.75.123.42 443]@sxa Unfortunately the API doesn't really work cleanly either, as to get a deterministic version (compulsory in order to do reproducible builds when repackaging Temurin), it still requires the caller to be aware of the .1 special case for Windows, since the relevant parameter is the adoptium release name, not the canonical version:
404s: https://api.adoptium.net/v3/binary/version/jdk-17.0.9%2B9/windows/x64/jre/hotspot/normal/eclipse?project=jdk works: https://api.adoptium.net/v3/binary/version/jdk-17.0.9%2B9.1/windows/x64/jre/hotspot/normal/eclipse?project=jdk
andrew-m-leonard
commented
1 year ago @sxa Unfortunately the API doesn't really work cleanly either, as to get a deterministic version (compulsory in order to do reproducible builds when repackaging Temurin), it still requires the caller to be aware of the
.1special case for Windows, since the relevant parameter is the adoptium release name, not the canonical version:404s: https://api.adoptium.net/v3/binary/version/jdk-17.0.9%2B9/windows/x64/jre/hotspot/normal/eclipse?project=jdk works: https://api.adoptium.net/v3/binary/version/jdk-17.0.9%2B9.1/windows/x64/jre/hotspot/normal/eclipse?project=jdk
@chadlwilson You can use "latest", try: https://api.adoptium.net/v3/binary/latest/17/ga/windows/x64/jre/hotspot/normal/eclipse?project=jdk
chadlwilson
commented
1 year ago @andrew-m-leonard Thanks, but latest is not deterministic and doesn't allow for reproducible builds. GoCD repackages and redistributes Temurin JREs as part of a bigger package. Aside from that, using the GitHub URLs directly allows pulling the sha256sums to validate the integrity without intercepting the 30x from the API call, so there is an additional advantage on top of using the API. Will just hack for this release.
sophia-guo
commented
1 year ago @huczas updated. temurin-11-jdk_11.0.21.0.0+9_amd64.deb should be there now. Could you try it again? Thanks!
andrew-m-leonard
commented
1 year ago @andrew-m-leonard Thanks, but
latestis not deterministic and doesn't allow for reproducible builds. GoCD repackages and redistributes Temurin JREs as part of a bigger package. Aside from that, using the GitHub URLs directly allows pulling the sha256sums to validate the integrity without intercepting the30xfrom the API call, so there is an additional advantage on top of using the API. Will just hack for this release.
Thanks for the feedback @chadlwilson we will bear that scenario in mind for next time.
sxa
commented
1 year ago @sxa Unfortunately the API doesn't really work cleanly either, as to get a deterministic version (compulsory in order to do reproducible builds when repackaging Temurin),
Yep I do understand the concern and it has to be balanced with the ability for us to respin with platform-specific fixes without changing the artefacts which have already been uploaded which has caused us some problems in the past. The way we've implemented the rebuilds by giving it a new identifier is generally the safest option.
it still requires the caller to be aware of the .1 special case for Windows, since the relevant parameter is the adoptium release name, not the canonical version:
Unfortunately yes that is correct if you require full reproducibility of a specific build.
huczas
commented
1 year ago @huczas updated. temurin-11-jdk_11.0.21.0.0+9_amd64.deb should be there now. Could you try it again? Thanks!
Thank you for fast fix, it's working now :-)
sophia-guo
commented
1 year ago All done, close this one.
Sharing information in this issue since the TCK work is being tracked in temurin-compliance private repo not visible to the community (as per the OCTLA). Risks and expectations for timing on the release are listed in this issue comment. Primary platforms (x64 Linux/Windows/OSX and aarch64 Linux/OSX) in bold are prioritized, secondary platforms not in bold follow in no particular order (as machine resources are available). We retrospectively measure and track how well we do against these targets in these Adoptium Release Scorecards in order to continuously assess and improve.
✔️ results in these Tables means the activity has successfully completed.
⏳ results means that we are actively working on closing off the runs needed for this version, platform, binaryType.
⛔ means there is no build planned for that version/platform combination.
⏸️ means activity not yet started.
JDK8u392-b08
jdk-11.0.21+9
jdk-17.0.9+9
JDK21.0.1+12