search

adoptium / installer

Installer scripts for Eclipse Temurin binaries
Apache License 2.0
150 stars 75 forks source link

Complete new `linuxNew` based packaging #330

Closed karianna closed 2 years ago

karianna commented 3 years ago

Initial List before we split into an Epic etc.

rpardini commented 3 years ago

@perlun @berndschatz @mfriedenhagen https://github.com/adoptium/installer/issues/330#issuecomment-926987965

smlambert commented 3 years ago

re: https://github.com/adoptium/installer/issues/330#issuecomment-953814170, the work in now assigned and underway to push them to github releases repo.

persicsb commented 2 years ago

It ssems it never will be finished. We just switched to Zulu, as they are reliable. Adoptium/Temurin for Linux is a no-go.

ilgrosso commented 2 years ago

@persicsb FYI we did the same :-(

StrangeNoises commented 2 years ago

the tarball is ok for jlinking an embedded jre, which you don't even need to be running linux to do, but yeah; for our systems that need to have it installed at system are either still stuck on adoptopenjdk 16.0.1 or are moving to ubuntu's own packaging (but they're slow too)

sxa commented 2 years ago

It ssems it never will be finished.

I can assure you that is not the case. We're going to get this fixed, and I fully agree that the delay here in getting these out at Adoptium has not been great. Believe me, we're very much aware of it and have taken steps in the last week or so to get this driven to completion and are working out some versioning issues with the packaging. Does everyone on this thread need the yum/apt repository or would the straight rpm/deb files be adequate for most of your use cases, as we're looking at probably just pushing them up into github as a first step.

byF commented 2 years ago

The problem is Github Actions uses adoptium, so no JDK17 until this issue is done.

On Wed, Nov 10, 2021, 12:22 Rachel Greenham @.***> wrote:

the tarball is ok for jlinking an embedded jre, which you don't even need to be running linux to do, but yeah; for our systems that need to have it installed at system are either still stuck on adoptopenjdk 16.0.1 or are moving to ubuntu's own packaging (but they're slow too)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/adoptium/installer/issues/330#issuecomment-965036205, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEQWKUK722H4C4KUKAHWCLULJIXXANCNFSM5BVTOWSA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

StrangeNoises commented 2 years ago

Does everyone on this thread need the yum/apt repository or would the straight rpm/deb files be adequate for most of your use cases, as we're looking at probably just pushing them up into github as a first step.

standalone deb/rpms were expected at some point and are useful to help with testing (there was an ask for that earlier), but ultimately a repo is strongly preferred as it lets it become part of a routine software update process.

SekiBetu commented 2 years ago

It ssems it never will be finished.

I can assure you that is not the case. We're going to get this fixed, and I fully agree that the delay here in getting these out at Adoptium has not been great. Believe me, we're very much aware of it and have taken steps in the last week or so to get this driven to completion and are working out some versioning issues with the packaging. Does everyone on this thread need the yum/apt repository or would the straight rpm/deb files be adequate for most of your use cases, as we're looking at probably just pushing them up into github as a first step.

yum/apt repository is better, but it seems to take you guys more time to prepare. so it would be nice if rpm/deb files could be pushed onto github first for everyone to use.

persicsb commented 2 years ago

Does everyone on this thread need the yum/apt repository or would the straight rpm/deb files be adequate for most of your use cases, as we're looking at probably just pushing them up into github as a first step.

Repositories are the nicest (as many security regulations does not enable direct GitHub fetching) , but around 3 weeks ago the community here seemed to agree on providing rpms/debs as GitHub releases are enough as the absolute minimum.

mfriedenhagen commented 2 years ago

I am looking for alternatives as well after reading that JREs are not supported anymore (adoptium/adoptium#64) but jlink would be the way to go. We run hundreds of Apps in Kubernetes based on the same JRE base images. Switching to jlink would just increase the build time without the benefit of saving diskspace at all. And now even packages for JDK 8 an d 11 are outdated.

mveroone commented 2 years ago

Agreed with previous comments. RPM/DEB on github releases is a good workaround but apt/dnf/yum repos are ideal eventually. At least for our use-case.

sfc-gh-pbennes commented 2 years ago

I can assure you that is not the case. We're going to get this fixed, and I fully agree that the delay here in getting these out at Adoptium has not been great. Believe me, we're very much aware of it and have taken steps in the last week or so to get this driven to completion and are working out some versioning issues with the packaging.

Thanks for the update. It seems like AdoptOpenJDK should have kept producing releases until the Adoptium transition is done. And I understand that issues and delays happen, but the lack of communication has been an issue for me. Whenever I get asked when we'll be ready to push the next patch release of Java 11 my answer is "I don't know, the state of our upstream provider is in transition since August with no ETA" and have to refer to this issue. Not great. Is there another place I should be looking for updates? Can we get more frequent updates on the status, some kind of ETA, what issues are being worked through, how people can potentially help? What workarounds have been explored so people can stop offering the same suggestions?

Does everyone on this thread need the yum/apt repository or would the straight rpm/deb files be adequate for most of your use cases, as we're looking at probably just pushing them up into github as a first step.

My org is primarily based on CentOS 7, x64 and ARM. yum repositories we can mirror internally would be ideal. Straight RPMs would be enough to unblock us, which echos the discussion already had on this issue.

askmike1 commented 2 years ago

Agreed with all the above. RPM would be a decent workaround, but it should be published to a yum repo.

sxa commented 2 years ago

The problem is Github Actions uses adoptium, so no JDK17 until this issue is done. … On Wed, Nov 10, 2021, 12:22 Rachel Greenham @.***> wrote: the tarball is ok for jlinking an embedded jre, which you don't even need to be running linux to do, but yeah; for our systems that need to have it installed at system are either still stuck on adoptopenjdk 16.0.1 or are moving to ubuntu's own packaging (but they're slow too) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#330 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEQWKUK722H4C4KUKAHWCLULJIXXANCNFSM5BVTOWSA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Hi @byF - I was under the impression that setup-java already supports Temurin via tarballs - what is it that's blocked on the native install packages?

sxa commented 2 years ago

Thanks for the update [...] the lack of communication has been an issue for me.

Understood and I agree 100% on the sentiments.

Is there another place I should be looking for updates? Can we get more frequent updates on the status, some kind of ETA, what issues are being worked through, how people can potentially help?

We've got multiple people on this just now. The overall strategy is as per this issue. We've got a job in our CI to create Temurin packages at https://ci.adoptopenjdk.net/view/work-in-progress/job/adoptium-packages-linux-pipeline/ but there are some failures occurring in some parts of the process so they're not quite ready for release yet and some of the names may change. I'm working with the people doing the work to make the issues more public and some are now in this repository but there are a few others that are not yet logged in there.

sxa commented 2 years ago

Unfortunately, it has a cyclic dependency on the JDK because the program to generate the keystore is written in Java. Some script in that package acts as a tie breaker, but it can only do that for JDK it knows. And it knows only JDKs shipped as part of Debian. We tried it in the past and failed.

@StrangeNoises has been digging around today and thinks that we might be able to avoid that by setting our temurin packages as providing the virtual javaXX-runtime-headless ones which act as a suitable dependency for ca-certificates-java. If we can legitimately do that it could well be a valid way of avoiding the extra package.

byF commented 2 years ago

Hi @byF - I was under the impression that setup-java already supports Temurin via tarballs - what is it that's blocked on the native install packages?

@sxa You're right, if you're using setup-java action, then yes. However, virtual environment contains Java LTS versions directly as well: https://github.com/actions/virtual-environments/issues/4085#issuecomment-930956468 (and that's what we want to keep using)

MarkMielke commented 2 years ago

Does everyone on this thread need the yum/apt repository or would the straight rpm/deb files be adequate for most of your use cases, as we're looking at probably just pushing them up into github as a first step.

Just to call out a different opinion from others, but the same conclusion...

The expectation of being able to pull from an upstream Apt/Yum repository is convenient for one-off users, but it is probably a bad idea for anybody with long-term commitments.

For the upstream project, it is a bad idea, because it has a significant expense related to hosting costs. It is possible that the costs can be directed towards an organization already willing to pay for such things, such as Github.com, but the cost exists nonetheless.

For users, and particularly for large groups of users, such as a company, it is generally a bad idea to have an open dependency on a public web site for business critical functions. Upstream URL change, and upstream organizations change (AdoptOpenJDK -> Adoptium in this very threat). Content appears and disappears at the whim of somebody else. "Appears" means that a "yum upgrade" may pick up a package which has never been tested, and this could be automated and happen across hundreds or thousands of machines.

As a result of the above, I think it is important to warn people that any serious users of upstream packages should be taking their own local copies, and serving it from their own repositories to their user bases. And, this means that the .rpm and .deb are the most important artifacts. Whether they are published to "Github Releases" pages, or to a "Yum Repository", my first action will be to download it and test it, and my next action will be to publish it in our own Yum repositories for local consumption.

persicsb commented 2 years ago

Just my 2 cents: if YUM/APT repositories are not provided at all, that is a serious regression compared to AdoptOpenJDK, however, this was not communicated when it was announced, that AdoptOpenJDK joins the Eclipse Foundation.

Users expected improvements (Eclipse-provided runtime, additional quality checks), but this is a drawback. It would certainly make some feel that Eclipse Foundation is just a cemetery for open-source projects.

StrangeNoises commented 2 years ago

I agree with the sentiment that it's a significant regression from what we had before to not have hosted repositories that could deliver the minor version upgrades in a routine fashion.

It is normal in the Linux world for packages to be distributed this way, assuming competent hosting and packaging (with cryptographic signing in place, we would expect to add adoptium's public key to our systems' keychain, which allows for automatic verification of packages by the package manager). Not supporting it makes adoptium weird and less useful, and people will rather find alternatives. I understand as well as Azul, Microsoft offers deb/rpm repos for their openjdk builds now... which for those of us who have been around a while, is superbly ironic, but nevertheless a fact.

Sites that don't want to be a part of that can then choose to opt out and download and install the packages manually, or make use of the various version "pinning" facilities offered by their respective distros for precisely this purpose. (eg: as an administrator you can "pin" production machines to a specific version, allow upgrades to a test instance, and when satisfied "pin" the production systems to that version instead. No need then for a local repo.)

MarkMielke commented 2 years ago

^--- "No need then for a local repo"... This depends upon "small mom/pop shop" vs "big user base". In the former case, it can seem easier to let somebody else manage this for you. But, this then subjects you to the other person.

The idea of one central repository that is the center of the Universe, and machines in the world pull for it, is a recipe for global failure.

That said... I'm not saying it isn't an expectation and requirement for one-off users who don't know how to, or haven't yet recognized the need to keep local copies, and distribute from local copies.

StrangeNoises commented 2 years ago

providing the repos in the normal linux fashion does not prevent people using their own local repo or being as paranoid as they want. but being weird and not fitting into normal package management will make adoptium far less useful to everyone else.

sxa commented 2 years ago

Just my 2 cents: if YUM/APT repositories are not provided at all, that is a serious regression compared to AdoptOpenJDK, however, this was not communicated when it was announced, that AdoptOpenJDK joins the Eclipse Foundation.

One this topic I will reiterate that it was NEVER our intention to stop having such repositories, which is why it was not communicated :-) We just haven't done a great job of getting the new setup ready :'(

sxa commented 2 years ago

On the topic of whether to have a local repo, that's obviously entirely up to each organisation. One of the nice things about Adoptium is that we place absolutely no restrictions on redistribution, so you're welcome to do so if it's beneficial for your business (The only disadvantage from our perspective is that it wouldn't show up in any of our download metrics :-) )

persicsb commented 2 years ago

One this topic I will reiterate that it was NEVER our intention to stop having such repositories, which is why it was not communicated :-) We just haven't done a great job of getting the new setup ready :'(

I know, but the person before me argued against YUM/APT repositories. And from what I see, and what was communicated, the current target is to push RPMs/DEBs to Github releases.

For example, some comments ago you asked, if we really need repositories:

Does everyone on this thread need the yum/apt repository or would the straight rpm/deb files be adequate for most of your use cases, as we're looking at probably just pushing them up into github as a first step.

This wording suggested, that if no one on this thread needs a repo, it won't be done.

StrangeNoises commented 2 years ago

... whereas earlier than that there was talk of producing deb/rpms for direct download first, as a stopgap and to allow wider testing that the packages themselves were ok, but... it was always expressed as being that, with proper repos later.

what's the opposite of feature-creep? 😀

sxa commented 2 years ago

This wording suggested, that if no one on this thread needs a repo, it won't be done.

Gotcha - that absolutely wasn't my intention with the question - I was attempting to guage "Is it a waste of our time if we put that interim solution in place before we have the apt/yum repos ready"

mfriedenhagen commented 2 years ago

@sxa, first of all, thanks for your efforts so far.

sxa commented 2 years ago

We've managed to get a repository set up that should be possible to make Temurin live in apt/yum purposes early next week, so it's likely that we'll now skip the publishing direclty to github and go straight to that assuming no other blockers show up. We're also hard at work making sure the packages are signed (a prereq for putting them in those repos) and ensuring we have them available for all the platforms we support. We're very close now, finally :-)

nudgegoonies commented 2 years ago

Thank you very much! Is there any problem with the signing key? I installed the key:

pub   rsa2048 2021-11-16 [SC]
      3B04 D753 C905 0D9A 5D34  3F39 843C 48A5 65F8 F04B
uid           [ unknown] Adoptium GPG Key (DEB/RPM Signing Key) <temurin-dev@eclipse.org>
sub   rsa2048 2021-11-16 [E]

But i get this:

E: The repository 'https://adoptium.jfrog.io/artifactory/deb bullseye Release' is not signed.

I used debian bullseye.

smlambert commented 2 years ago

Good progress has been made, but there are a couple of draft PRs still being worked for deb files including what you have noted in https://github.com/adoptium/installer/issues/330#issuecomment-979320890. (See draft PRs at: https://github.com/adoptium/installer/pull/382 and https://github.com/adoptium/installer/pull/386).

Also good progress on the rpms (https://github.com/adoptium/installer/pull/388 and others in the merged PRs list that add support for several archs).

Current view of artifacts being pushed to adoptium.jfrog.io

Screen Shot 2021-11-25 at 3 00 35 PM

Thanks to everyone (@sophia-guo @gdams @sxa @karianna @jerboaa @aahlenst and others I am likely forgetting) who has helped progress on this work, hopefully only a few tasks left.

Automated testing for the non-x86 archs also still needs to be added (https://github.com/adoptium/installer/issues/375). Meantime, we'll reach out for manual testing help for aarch64 (that will be pushed shortly, related: https://github.com/adoptium/installer/pull/389 and https://github.com/adoptium/installer/pull/391).

SekiBetu commented 2 years ago

Thank you very much! Is there any problem with the signing key? I installed the key:

pub   rsa2048 2021-11-16 [SC]
      3B04 D753 C905 0D9A 5D34  3F39 843C 48A5 65F8 F04B
uid           [ unknown] Adoptium GPG Key (DEB/RPM Signing Key) <temurin-dev@eclipse.org>
sub   rsa2048 2021-11-16 [E]

But i get this:

E: The repository 'https://adoptium.jfrog.io/artifactory/deb bullseye Release' is not signed.

I used debian bullseye.

an sources.list example: 

deb [signed-by=/usr/share/keyrings/adoptopenjdk-archive-keyring.gpg] https://adoptopenjdk.jfrog.io/adoptopenjdk/deb $(lsb_release -cs) main

you need to add [signed-by=/usr/share/keyrings/adoptopenjdk-archive-keyring.gpg] if you want a repo be signed by a gpg key(https://wiki.debian.org/DebianRepository/UseThirdParty)

markozajc commented 2 years ago

@SekiBetu The issue here seems to be that the repository itself doesn't have a Release.gpg, not that the signature isn't trusted.

vojkny commented 2 years ago

To be precise – this fails for me:

# wget -qO - https://adoptium.jfrog.io/artifactory/api/security/keypair/default-gpg-key/public  | apt-key add -
# echo "deb https://adoptium.jfrog.io/artifactory/deb bullseye Release" > /etc/apt/sources.list.d/adoptium.list
# apt-get update
E: The repository 'https://adoptium.jfrog.io/artifactory/deb bullseye Release' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
SekiBetu commented 2 years ago

To be precise – this fails for me:

# wget -qO - https://adoptium.jfrog.io/artifactory/api/security/keypair/default-gpg-key/public  | apt-key add -
# echo "deb https://adoptium.jfrog.io/artifactory/deb bullseye Release" > /etc/apt/sources.list.d/adoptium.list
# apt-get update
E: The repository 'https://adoptium.jfrog.io/artifactory/deb bullseye Release' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

just want you to know apt-key is deprecated, people should use gpg instead(https://wiki.debian.org/DebianRepository/UseThirdParty), example:

curl -fsSL https://adoptopenjdk.jfrog.io/adoptopenjdk/api/gpg/key/public | sudo gpg --dearmor --yes -o /usr/share/keyrings/adoptopenjdk-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/adoptopenjdk-archive-keyring.gpg] https://adoptopenjdk.jfrog.io/adoptopenjdk/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/adoptopenjdk.list
sudo apt update && sudo apt install -y adoptopenjdk-11-hotspot
vojkny commented 2 years ago

This leads to:

curl -fsSL https://adoptopenjdk.jfrog.io/adoptopenjdk/api/gpg/key/public | gpg --dearmor -o /usr/share/keyrings/adoptopenjdk-archive-keyring.gpg \
     && echo "deb [signed-by=/usr/share/keyrings/adoptopenjdk-archive-keyring.gpg] https://adoptopenjdk.jfrog.io/adoptopenjdk/deb $(lsb_release -cs) main" | tee /etc/apt/sources.list.d/adoptopenjdk.list \
     && apt update && apt install --no-install-recommends -qy adoptopenjdk-11-hotspot

E: Malformed entry 1 in list file /etc/apt/sources.list.d/adoptopenjdk.list (Component)
E: The list of sources could not be read.

# cat /etc/apt/sources.list.d/adoptopenjdk.list
deb [signed-by=/usr/share/keyrings/adoptopenjdk-archive-keyring.gpg] https://adoptopenjdk.jfrog.io/adoptopenjdk/deb  main
mveroone commented 2 years ago

Would it be possible to generate RHEL 6 RPMs too? It's still supported especially on ELS.

Thanks

SekiBetu commented 2 years ago

This leads to:

curl -fsSL https://adoptopenjdk.jfrog.io/adoptopenjdk/api/gpg/key/public | gpg --dearmor -o /usr/share/keyrings/adoptopenjdk-archive-keyring.gpg \
     && echo "deb [signed-by=/usr/share/keyrings/adoptopenjdk-archive-keyring.gpg] https://adoptopenjdk.jfrog.io/adoptopenjdk/deb $(lsb_release -cs) main" | tee /etc/apt/sources.list.d/adoptopenjdk.list \
     && apt update && apt install --no-install-recommends -qy adoptopenjdk-11-hotspot

E: Malformed entry 1 in list file /etc/apt/sources.list.d/adoptopenjdk.list (Component)
E: The list of sources could not be read.

# cat /etc/apt/sources.list.d/adoptopenjdk.list
deb [signed-by=/usr/share/keyrings/adoptopenjdk-archive-keyring.gpg] https://adoptopenjdk.jfrog.io/adoptopenjdk/deb  main

the new repo is not out yet, i'm just showing the old one as an example to let people know that the apt-key is deprecated, people should use gpg with [signed-by=] in sources.list instead (https://wiki.debian.org/DebianRepository/UseThirdParty), your error here is caused by lsb_release not installed, you need to replace $(lsb_release -cs) with bullseye manually or install lsb_release

svenofix commented 2 years ago

just want you to know apt-key is no longer used, try gpg instead, example:

'apt-key' should still work. I think the actual issue is that the new repository does not yet have any "Release.gpg" files.

the new repo is not out yet

Some of us are just impatient ;) This should be the new repo: https://adoptium.jfrog.io/ui/packages

nudgegoonies commented 2 years ago

@knyttl @SekiBetu Please don't mix examples with the old adoptopenjdk repo. The adoptium temurin repo has problems and is not usable yet and @knyttl s example should work (with the component main). Also with buster and stretch. The "signed-by" syntax is optional but the apt-key way and storing the gpg store in /etc/apt/trusted.gpg.d should work as well.

nudgegoonies commented 2 years ago

Thank you for correctly signing the debian repository!

But please fix these two property problems that makes the debian reposity unusable: https://github.com/adoptium/installer/issues/400 https://github.com/adoptium/installer/issues/401

nudgegoonies commented 2 years ago

Thanks you @gdams . I can now install Temurin 8,11 and 17 on Debian 9,10 and 11.

vojkny commented 2 years ago

@nudgegoonies so what is your complete script for installation?

nudgegoonies commented 2 years ago

Manually i tested with Debian 9,10 and 11 Docker Images with these interactive commands (example for debian:bullseye image):

apt update
apt install wget gpg
wget -qO - https://adoptium.jfrog.io/artifactory/api/security/keypair/default-gpg-key/public  | apt-key add -
echo "deb https://adoptium.jfrog.io/artifactory/deb bullseye main" > /etc/apt/sources.list.d/adoptium.list
apt update
apt install temurin-8-jdk temurin-11-jdk temurin-17-jdk

For our inhouse temurin docker images based on debian i use the pepared gpg file in /etc/apt/trusted.gpg.d rather than apt-key. So this should work too:

wget -qO - https://adoptium.jfrog.io/artifactory/api/security/keypair/default-gpg-key/public  |  gpg --dearmor --yes -o /etc/apt/trusted.gpg.d/temurin.gpg
vojkny commented 2 years ago

This fails for me:

E: Failed to fetch https://jfrog-prod-usw2-shared-oregon-main.s3.amazonaws.com/aol-adoptium/filestore/18/18e4eba26b7de862ace87b1e0a53e98c80d22a92?X-Artifactory-repositoryKey=deb&X-Artifactory-projectKey=temurin&x-jf-traceId=163ef43197e5d8bb&response-content-type=application/x-debian-package&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20211216T095738Z&X-Amz-SignedHeaders=host&X-Amz-Expires=60&X-Amz-Credential=AKIASG3IHPL6RZALTNGC/20211216/us-west-2/s3/aws4_request&X-Amz-Signature=c072600fa00f4e1f2d96e3632618b2bb705db237ec7d7645a876cba5dcb46bda  File has unexpected size (163938604 != 163938492). Mirror sync in progress? [IP: 52.92.128.209 443]
persicsb commented 2 years ago

Seems promising. Can you please make RPMs available for Fedora 34 and 35? It may be just a simple symbolic link from the current Fedora 33 RPM. Fedora 33 is EOL now, Fedora 35 is the current production release. Oftentimes, people use $releasever in the repository path, to make updates seamless, however, since the repository only contains Fedora 33 packages, it may not be suitable for most users.

gdams commented 2 years ago

. Can you please make RPMs available for Fedora 34 and 35? It may be just a simple symbolic link from the current Fedora 33 RPM. Fedora 33 is EOL now

@sophia-guo could you please remove the Fedora 33 release and add support to push 34 and 35?

SekiBetu commented 2 years ago

Manually i tested with Debian 9,10 and 11 Docker Images with these interactive commands (example for debian:bullseye image):

apt update
apt install wget gpg
wget -qO - https://adoptium.jfrog.io/artifactory/api/security/keypair/default-gpg-key/public  | apt-key add -
echo "deb https://adoptium.jfrog.io/artifactory/deb bullseye main" > /etc/apt/sources.list.d/adoptium.list
apt update
apt install temurin-8-jdk temurin-11-jdk temurin-17-jdk

For our inhouse temurin docker images based on debian i use the pepared gpg file in /etc/apt/trusted.gpg.d rather than apt-key. So this should work too:

wget -qO - https://adoptium.jfrog.io/artifactory/api/security/keypair/default-gpg-key/public  |  gpg --dearmor --yes -o /etc/apt/trusted.gpg.d/temurin.gpg
Err:5 https://adoptium.jfrog.io/artifactory/deb bullseye/main amd64 temurin-17-jdk amd64 17.0.1.0.0+12-1
  File has unexpected size (163938604 != 163938492). Mirror sync in progress? [IP: 52.92.128.25 443]
  Hashes of expected file:
   - SHA256:c58199f37de694227cb6d2288a838a520a590a0587f74dadc8cbc2e464872197
   - SHA1:4053b7d65ec2a417d31ecee3aa75e6bc6987b391 [weak]
   - Filesize:163938492 [weak]
Fetched 2,602 kB in 1s (5,147 kB/s) 
E: Failed to fetch https://jfrog-prod-usw2-shared-oregon-main.s3.amazonaws.com/aol-adoptium/filestore/18/18e4eba26b7de862ace87b1e0a53e98c80d22a92?X-Artifactory-repositoryKey=deb&X-Artifactory-projectKey=temurin&x-jf-traceId=7c9953e1337c3fc6&response-content-type=application%2Fx-debian-package&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20211216T112033Z&X-Amz-SignedHeaders=host&X-Amz-Expires=60&X-Amz-Credential=AKIASG3IHPL6RZALTNGC%2F20211216%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-Signature=bebdf1777f77dd685bc82c8d3e6e44aa6cd6a03e60ff81c59e723d4a5f8f3164  File has unexpected size (163938604 != 163938492). Mirror sync in progress? [IP: 52.92.128.25 443]
   Hashes of expected file:
    - SHA256:c58199f37de694227cb6d2288a838a520a590a0587f74dadc8cbc2e464872197
    - SHA1:4053b7d65ec2a417d31ecee3aa75e6bc6987b391 [weak]
    - Filesize:163938492 [weak]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

same error here, i just did this:

curl -OJL https://adoptium.jfrog.io/artifactory/api/security/keypair/default-gpg-key/public | sudo gpg --dearmor --yes -o /usr/share/keyrings/temurin-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/temurin-archive-keyring.gpg] https://adoptium.jfrog.io/artifactory/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/temurin.list
sudo apt update && sudo apt install -y temurin-17-jdk
SekiBetu commented 2 years ago

nvm, it's working now. I guess it's because the release was not fully uploaded before everyone started downloading it

sekibetu@debian:~$ java --version
openjdk 17.0.1 2021-10-19
OpenJDK Runtime Environment Temurin-17.0.1+12 (build 17.0.1+12)
OpenJDK 64-Bit Server VM Temurin-17.0.1+12 (build 17.0.1+12, mixed mode, sharing)