Giter VIP home page Giter VIP logo

containers's Introduction

Containers

DockerPulls Docker Stars OpenSSF Scorecard

This repository contains the Dockerfiles for the official Adoptium images of the Eclipse Temurin distribution (OpenJDK). These images are made available in Docker Hub.

If you are looking for the usage README then please head to the Official Docker Hub Documentation.

Supported Images

In general, we support Alpine, UBI, Ubuntu and Windows containers.

List of Supported Images By Tag

Update Policy

As these are official Docker Hub images, Docker Inc maintains the base image and so any critical CVEs in the base O/S layer gets updated by them in short order.

Note that the eclipse-temurin images include openssl as a prerequisite of the wget and ca-certificates packages but they are NOT included in the Ubuntu base image so updates to openssl will not necessarily trigger an rebuild to pick up fixes. In general, low severity vulnerabilities can wait until the next rebuild. See this comment for some details and also the docker-library FAQ.

The Debian and Ubuntu images are generally also built periodically (about once a month) and may also be triggered by dockerhub if another high security vulnerability is detected, such as in openssl. Adoptium has no mechanism - other than putting an update to the Dockerfiles - to explicitly trigger a rebuild at dockerhub.

For JDK version updates, we update the dockerfiles and release on a quarterly cadence Temurin releases a Patch Set Update (PSU).

Maintenance of Dockerfiles

This section is for maintainers of the containers repository.

Hourly automated Job

A Updater GitHub Action runs every 30 mins which triggers the ./generate_dockerfiles.py script to update the Dockerfiles by creating a Pull Request containing any changes.

generate_dockerfiles.py

./generate_dockerfiles.py is a python script which uses the jinja templates defined in docker_templates to generate the docker updates. It uses the Adoptium API to fetch the latest artefacts for each release.

Manual Release

During a release you can also run ./generate_dockerfiles.py manually by heading to The GitHub Action definition and clicking the Run Workflow button and making sure the main (default) branch is selected, then click the next Run Workflow button.

Review and Merge PR

Once the PR is created you can review that PR (which itself tests all of the Docker Images that we have generate configuration for).

Update Official Docker Hub Manifest

Once you've merged the PR, you can update the official Docker Hub manifest. This is done by running the following command in the containers repo on your local machine:

# Get the latest changes
git fetch --all
# Checkout the main branch
git checkout main
./dockerhub_doc_config_update.sh

This script will create a file called eclipse-temurin by default.

Create a new PR to replace the Manifest on Docker Hub with the new contents of eclipse-temurin

In the next screen click on the Create Pull Request button.

Once that PR has been created it will be automatically tested and reviewed by Docker Hub staff and eventually released.

Diff Output at Docker Hub

It can be useful to look at the "Diff for XXX:" output created by one of the Docker Hub GitHub Actions on the Pull Request. This output should not be read as a traditional PR (since Docker Hub bots do move things around, so you may see what looks like odd deletions) but as a sanity check to make sure you see the platforms/architectures that you expect.

containers's People

Contributors

andrew-m-leonard avatar dalbani avatar dependabot[bot] avatar domenjesenovec avatar droppelt avatar eclipse-temurin-bot avatar elliotth avatar gdams avatar github-actions[bot] avatar jsoref avatar karianna avatar pgerhard avatar poikilotherm avatar rassie avatar step-security-bot avatar sxa avatar tellison avatar tinours avatar vinrk avatar zdtsw avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

containers's Issues

jdk-11.0.14.1+1 not available for 11-alpine yet

When visiting adoptium.net, I am greeted with a

11th February 2022: If you have recently picked up the jdk-11.0.14+9 release, please update to jdk-11.0.14.1+1 to pick up a fix for a regression in the HTTPClient code.

But I cannot find an jdk-11-alpine container with 11.0.14.1, only the 11.0.14 (when mentioned explicitly tagger) or "11-jdk-alpine" that have a "last updated 22 days ago" (== before 11th February)

I am not familiar with the update process in this repo, I can try to submit a PR, but would gladly leave it up to someone who could get it out the door fast. I am not familiar with the severity of the regression.

If it is not urgent, I would like to help with a PR?

armv7 images

Hi,

previously I was using the Adoptopenjdk images, but as they are not longer maintained, I switched to the eclipse-temurin images. One thing I noticed however is, that there are no armv7 images. Are there any plans to support armv7 as well, or will support for that architecture completely dropped?

Many thanks,
Bernhard

push images to quay.io

To avoid errors like docker.io/library/openjdk: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit'
Let me know if I can help on this.

openjdk14 version possible?

I've noticed that this repository does not contain a Dockerfile or build instructs for openjdk14.. is there any possibility of it appearing in the future?

alpine images can't run RocksDBJNI

When running a project that has rocksdbjni on the classpath, the JVM will encounter the following error:

/tmp/librocksdbjni7856201673520504504.so: Error loading shared library libstdc++.so.6: No such file or directory (needed by /tmp/librocksdbjni7856201673520504504.so)

Image used: eclipse-temurin:8-alpine

This is due to libstdc++ not being installed. The problem can be resolved with

apk add --no-cache libstdc++

I'm not sure if this is a goal of the project to support, so feel free to close if it isn't.

Build images without curl/wget and other packages

All Dockerfiles rely on downloading the JDK package from the Adoptium server.

Instead of this, I'd suggest to have the Dockerfile simplified with an ADD command instead, where the package has already been downloaded in the same folder next to the Dockerfile. How the package is downloaded can be automated with shell scripts. The advantage here is separating responsibilities.

The infrastructure where the Docker image gets created at, and the image is published from, is responsible of pulling all necessary artifacts prior to the build.

For reference, this is how Oracle WebLogic Docker images are produced, as well as Oracle Java images.

Cannot run jlink in 17-alpine image

I tried to use jlink to make a 'jre-like' image of 17-alpine. It seems that perhaps a required program is missing from the base image?

Dockerfile:

FROM eclipse-temurin:17-jdk-alpine as jre-build

# Create a custom Java runtime
RUN $JAVA_HOME/bin/jlink \
         --add-modules java.base \
         --strip-debug \
         --no-man-pages \
         --no-header-files \
         --compress=2 \
         --output /javaruntime

FROM alpine
ENV JAVA_HOME=/opt/java/openjdk
ENV PATH "${JAVA_HOME}/bin:${PATH}"
COPY --from=jre-build /javaruntime $JAVA_HOME

docker build output error

 => ERROR [jre-build 2/2] RUN /opt/java/openjdk/bin/jlink          --add-modules java.base          --strip-debug          --no-man-pages          --no-header-files          --com  3.6s
------
 > [jre-build 2/2] RUN /opt/java/openjdk/bin/jlink          --add-modules java.base          --strip-debug          --no-man-pages          --no-header-files          --compress=2          --output /javaruntime:
#7 3.369 Error: java.io.IOException: Cannot run program "objcopy": error=2, No such file or directory

It seems that the required objcopy is not in the alpine base image?

Support alpine images for arm32v7/armhf

Hi,

are there any plans to build the Alpine-based containers for the arm32v7 (aka. armhf) architecture? So far, there are Alpine builds for other architectures, and non-Alpine builds for arm32v7, but the combination doesn't exist.

I believe such images would be very useful, since devices with this architecture tend to have little resources, making Alpine a nice fit.

Automate dockerfile image updating

We can likely pull some of the code from the openjdk-docker repo at AdoptOpenJDK but it would be good to review the code and make any enhancements

Unrecognized option: --add-exports

I am using the official docker image eclipse-temurin:17 and get the following error on startup of the container when using the add-exports jvm flag:

Unrecognized option: --add-exports java.xml.crypto/com.sun.org.apache.xml.internal.security=ALL-UNNAMED
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

Alpine images in Docker Hub

Looks the support for Alpine based images has just landed a few days ago, but no images uploaded into Docker Hub yet. Any ETA?

Libssl Bug in eclipse-temurin:11-jdk

Hello, i just wanted to mention, that i found out the image eclipse-temurin:11-jdk, and i think all other images as well, where build with an buggy (debian?) base image that includes an libssl bug (assumption due to research). This bug is already solved in later versions.

Found this while pulling maven:3.8.4-eclipse-temurin-11 which is based on eclipse-temurin:11-jdk.
Pulling maven:3.8.4-openjdk-11, this bug/failure does not appear.

I'm running this on an MacBook Pro with an M1 (arm64) processor.
Dockerfile to reproduce:

FROM eclipse-temurin:11-jdk

RUN apt-get update && apt-get install -y --no-install-recommends gnupg2
RUN curl -fsSL https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -
RUN echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list
RUN apt-get update && apt-get install -y yarn

Error:

Warning: apt-key output should not be parsed (stdout is not a terminal)
Segmentation fault
gpg: no valid OpenPGP data found.

Official Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989604

Action:
Rebuild the image(s) with an updated (debian?) base image where the libssl bug was patched.

Provide Docker Image for 17.0.1

Hi ๐Ÿ‘‹, from my understanding the are no images for the latest Java 17 release yet. If you provide me some pointers I'm happy to create a pull request for it.

Missing Docker/Alpine images for ARM64

I sadly recognized, that there are no ARM64 Docker images based on Alpine available. ๐Ÿ˜ข
Alpine itself provides images for ARM64.

Would like to use Temurin in Docker/Alpine on my Apple silicon CPU.

docker pull eclipse-temurin:17-jre-alpine
17-jre-alpine: Pulling from library/eclipse-temurin
no matching manifest for linux/arm64/v8 in the manifest list entries

Question: Will there be open9 images again?

AdoptOpenJDK also provided images with openj9 as an alternative to hotspot.
Is the deployment through adoptium also planned again?

It would be good to document the status of openj9-images on the Dockerhub page since Adopt links directly to the page.

Provide Ubuntu 22.04 based image

In the known issues of Docker 3.4.0 they report

On Apple Silicon in native arm64 containers, older versions of libssl in debian:buster, ubuntu:20.04 and centos:8 will segfault when connected to some TLS servers, for example curl https://dl.yarnpkg.com. The bug is fixed in newer versions of libssl in debian:bullseye, ubuntu:21.04 and fedora:35.

I would like to suggest that in addition to the LTS version of each respective distribution (Ubuntu and CentOS, I believe) that an "edge" variant be provided for the newest regular release, such as Ubuntu 21.04. With that said, I am still a huge proponent of the mainline/latest images being based on LTS, so I would not want to see a change to that philosophy.

Originally posted by @itzg in #1 (comment)

Deprecate Microsoft ltsc2016 images

The upstream image has now been deprecated the the docker hub folks won't accept anymore pull requests with these files inside. I suggest we remove the dockerfiles here.

Support to other OS

Hello,

I would like to ask if you are accepting pull requests to make available more OS ? For example Debian ?

Design the offerings for Docker images containing Adoptium runtimes

A significant proportion of downloads for Adopt' builds traditionally come via the Docker image repository.
However, the Docker images have evolved over time to include number ous OS base images, tags, supporting libraries, and version support.

This issue is to capture the design for Eclipse Temurin images, with a goal of making the Docker repository simpler, easy to navigate and consume, while maintaining the information and resources that our users require. Discussion and raising requirements is encouraged!

The AdoptOpenJDK builds currently are published in a project managed repository (u/adoptopenjdk), in the official AdoptOpenJDK repository (_/adoptopenjdk), and in some instances also in the official OpenJDK repository.

For Adoptium, the proposal is as follows for Eclipse Temurin binaries:

Reduce the set of base images, and introduce a policy for removing obsolete versions

Too many distros make it difficult to produce and maintain them in a timely manner. The Adoptium project should be very selective about the base images that are being used, and should have a policy in pace to remove base images that fall out of support by their community.

Consider using a single base image OS, and encourage users to extract the Eclipse Temurin runtime into their own preferred distros using the Docker COPY operation.

Use the official repo at Docker exclusively.

Having a project repository and an official Docker repository can be confusion for end users. Providing we can transition the existing official repository we will use that exclusively for publishing the Eclipse Temurin images, rather than set up a new one owned by the Adoptium project.

Clear transition document for users who are used to having multiple distros.

To enable users to transition from the existing Docker image availability it will be necessary for the project to produce good documentation that explains how the Adoptium images can be used to achieve equivalence on each of the main different platforms and operating systems.

Ubuntu images contain python3

#120 added python-is-python3 package to Ubuntu images. The problem is that python-is-python3 depends on python3 so that gets installed as well.

According to the discussion in #116, the intent of adding the python-is-python3 package was not to install python3, and that the intent is to have as small diff to bare-bones base image as possible. It seems to me that adding python3 to the images was unintentional.

The Ubuntu images did not contain python3 before (as far as I can see), and its inclusion can be seen in the increased sizes of the images, e.g:
docker-library/repo-info@fa669f5#diff-bae803386ba8e4c8e39c393889244a818bc0355b2bac8a0b9bc7dab236dea324

REPOSITORY             TAG                    IMAGE ID       CREATED         SIZE
eclipse-temurin        11-jre                 4520f806b3be   30 hours ago    270MB
eclipse-temurin        <none>                 a52f9ce88ddf   2 months ago    270MB
eclipse-temurin        <none>                 dd3751bc18f2   2 months ago    244MB
adoptopenjdk           11-jre                 2c57fb3bc67b   4 months ago    244MB

`docker pull adoptopenjdk/openjdk11-openj9:latest` gives `no matching manifest for linux/amd64 in the manifest list entries`

A clone of issue adoptium/temurin-build#2719


What are you trying to do?

docker pull adoptopenjdk/openjdk11-openj9:latest

Expected behaviour:

image pulled

Observed behaviour:

$ docker pull adoptopenjdk/openjdk11-openj9:latest
latest: Pulling from adoptopenjdk/openjdk11-openj9
no matching manifest for linux/amd64 in the manifest list entries

Any other comments:

The latest image (published 2 hours ago) seems to only be published for the linux/ppc64le OS/arch as per:
https://hub.docker.com/layers/adoptopenjdk/openjdk11-openj9/latest/images/sha256-77fc0dd8ea293637ca1631752ffcb80dd9e3928328823c562838200ca4d4240d?context=explore

Support alpine images for aarch64

Building the alpine images on an Apple silicon (M1) Mac currently fails with an "Unsupported arch: aarch64" error, e.g. from this code. Would it be possible to add support for this architecture? Thanks in advance!

`slim` container jdk releases

It looks like slim version of container has been missing. Any plans to implement? I would happy to work on a PR if needed

JVM core dump when run couchbase client

I just test the simple Couchbase client on
docker image: eclipse-temurin:11.0.13_8-jdk-alpine
it will crash

Stack: [0x00007f67062c9000,0x00007f67063c9ad8],  sp=0x00007f67063c5d18,  free space=1011k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x0000000000003efe
C  [libcom_couchbase_client_core_deps_netty_transport_native_epoll_x86_643497901388108310511.so+0xb487]  netty_jni_util_JNI_OnLoad+0x67
C  [libjava.so+0xfc8a]  Java_java_lang_ClassLoader_00024NativeLibrary_load0+0xba

but the same code could run in
docker image: adoptopenjdk/openjdk11:jdk-11.0.13_8-alpine-slim

reproduce step

docker run -it --rm --mount type=bind,source="$(pwd)"/,target=/src  --entrypoint /bin/sh eclipse-temurin:11.0.13_8-jdk-alpine
 cd src
 ./run.sh 
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000000003efe, pid=26, tid=27
#
# JRE version: OpenJDK Runtime Environment Temurin-11.0.13+8 (11.0.13+8) (build 11.0.13+8)
# Java VM: OpenJDK 64-Bit Server VM Temurin-11.0.13+8 (11.0.13+8, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# C  0x0000000000003efe
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /src/hs_err_pid26.log
#
# If you would like to submit a bug report, please visit:
#   https://github.com/adoptium/adoptium-support/issues
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Aborted

Test code: https://rak.box.com/s/jqjxz3fkbirpd3zzo4bj3216yjo16e0n

Provide documentation to allow users to produce their own images.

Something like:

If you prefer an OS base image distribution that we don't provide an image for, you can copy the JDK using the COPY --from instruction in a Dockerfile, similar to the following example:

Dockerfile

# Example of using Temurin image to create a new image with a different base image
FROM debian:buster-slim
ENV JAVA_HOME /usr/lib/jvm/temurin-11-amd64
ENV PATH "${JAVA_HOME}/bin:${PATH}"
COPY --from=dockerhub.com/eclipse-temurin/jdk:11-ubuntu $JAVA_HOME $JAVA_HOME

# Continue with your application deployment
RUN mkdir /opt/app
COPY japp.jar /opt/app
CMD ["java", "-jar", "/opt/app/japp.jar"]
To create a custom Java runtime image, use a Dockerfile similar to the following example:

Docker image for JRE

Thanks for all the work on producing solid Docker containers for OpenJDK. ๐Ÿ™Œ๐Ÿผ

Will there be Docker images for JRE based on JDK 17? I used to rely on JRE and eclipse-temurin:11-jre specifically, but for JDK 17 there are only images that include full JDK. Will it be up to users to rely on jlink and build their own containers for JRE?

please support cgroupv2 resource limits for Java 11

Apparently cgroupv2 is not supported for Java 11:

% docker run -m 128m --cpus 0.5 -it --rm eclipse-temurin:11.0.13_8-jdk-centos7 java -XX:+UseContainerSupport -XshowSettings:system -version
Unable to find image 'eclipse-temurin:11.0.13_8-jdk-centos7' locally
11.0.13_8-jdk-centos7: Pulling from library/eclipse-temurin
2d473b07cdd5: Pull complete 
3df6893209e3: Pull complete 
bba8d1b451eb: Pull complete 
16ca8e6cd0a4: Pull complete 
Digest: sha256:8170c0c5ace869bf9ab963bcc8c5b30d7494cdeecd5bf61338654f95220d03b5
Status: Downloaded newer image for eclipse-temurin:11.0.13_8-jdk-centos7
Operating System Metrics:
    No metrics available for this platform
openjdk version "11.0.13" 2021-10-19
OpenJDK Runtime Environment Temurin-11.0.13+8 (build 11.0.13+8)
OpenJDK 64-Bit Server VM Temurin-11.0.13+8 (build 11.0.13+8, mixed mode)

This is fatal. For Java 17 there is no such problem

% docker run -m 128m --cpus 0.5 -it --rm eclipse-temurin:17.0.1_12-jdk-centos7 java -XX:+UseContainerSupport -XshowSettings:system -version
Unable to find image 'eclipse-temurin:17.0.1_12-jdk-centos7' locally
17.0.1_12-jdk-centos7: Pulling from library/eclipse-temurin
2d473b07cdd5: Already exists 
5eafaeccaf7b: Pull complete 
b02d4877e7b0: Pull complete 
ec4de886ffc6: Pull complete 
Digest: sha256:97f57417e3e5da2da2dc8c4a43ba268d5546948221666f736377943382011ba1
Status: Downloaded newer image for eclipse-temurin:17.0.1_12-jdk-centos7
Operating System Metrics:
    Provider: cgroupv2
    Effective CPU Count: 1
    CPU Period: 100000us
    CPU Quota: 50000us
    CPU Shares: -1
    List of Processors: N/A
    List of Effective Processors, 8 total: 
    0 1 2 3 4 5 6 7 
    List of Memory Nodes: N/A
    List of Available Memory Nodes, 1 total: 
    0 
    Memory Limit: 128.00M
    Memory Soft Limit: 0.00K
    Memory & Swap Limit: 256.00M

openjdk version "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)

Would it be possible to backport cgroupv2 support into Java 11, making it suitable for Docker and Kubernetes on today's Linux systems (Debian 11, Redhat 8, etc)?

JDK_JAVA_OPTIONS picked up twice

When using the JDK_JAVA_OPTIONS environment variable it's picked up twice.

$ echo 'public class Test { public static void main(String[] args) { System.out.println("Should pick once"); } }' > Test.java
$ docker run --rm -it -v $(pwd)/Test.java:/Test.java:Z -e JDK_JAVA_OPTIONS="-Dsomehow=duplicated" eclipse-temurin:17.0.1_12-jdk-alpine java Test.java
NOTE: Picked up JDK_JAVA_OPTIONS: -Dsomehow=duplicated
NOTE: Picked up JDK_JAVA_OPTIONS: -Dsomehow=duplicated
Should pick once

Visible also by running an app in the background and doing

$ jps -lvm
6 jdk.compiler/com.sun.tools.javac.launcher.Main Test.java -Dsomehow=duplicated -Dsomehow=duplicated --add-modules=ALL-DEFAULT

Also visible from JMX.

Explicitly install packages in alpine so that "apk del apk-tools" does not break the JVM

Hi guys,

I very much appreciate the effort towards the native musl integration with the JVM and alpine.

In our setup, we do so custom hardening of images (i.e. rootless) and as part of it, we drop "apk-tools" to remove the ability to add any package and possibly alter a running service in a production environment.

We noticed that the musl-native images appear to have a dependency that is dropped when apk-tools is removed. Sounds a lot like there is an implicit dependency that is removed.

$ java -version
#6 0.554 Error loading shared library libz.so.1: No such file or directory (needed by /opt/java/openjdk/bin/../lib/jli/libjli.so)
#6 0.554 Error relocating /opt/java/openjdk/bin/../lib/jli/libjli.so: inflate: symbol not found
#6 0.554 Error relocating /opt/java/openjdk/bin/../lib/jli/libjli.so: inflateEnd: symbol not found
#6 0.554 Error relocating /opt/java/openjdk/bin/../lib/jli/libjli.so: inflateInit2_: symbol not found

With some tinkering & looking at apk info --depends apk-tools I found that following 2 libs seem to do the trick

/ # apk del apk-tools -s
WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.14/main: No such file or directory
WARNING: Ignoring https://dl-cdn.alpinelinux.org/alpine/v3.14/community: No such file or directory
(1/7) Purging ssl_client (1.33.1-r6)
(2/7) Purging apk-tools (2.12.7-r0)
(3/7) Purging libretls (3.3.3p1-r2)
(4/7) Purging ca-certificates-bundle (20191127-r5)
(5/7) Purging libssl1.1 (1.1.1l-r0)
(6/7) Purging libcrypto1.1 (1.1.1l-r0)
(7/7) Purging zlib (1.2.11-r3)
OK: 9 MiB in 17 packages
/ # apk add zlib libretls
fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.14/community/x86_64/APKINDEX.tar.gz
OK: 9 MiB in 17 packages
/ # apk del apk-tools -s
(1/1) Purging apk-tools (2.12.7-r0)
OK: 9 MiB in 17 packages
/ #

-> with apk add libretls zlib, no dependencies are uninstalled.

And java -version (and likely any other startup of the JVM) works again

I believe these packages should be explicitly installed as they are required for the jvm.

Any thoughts on this`?

Here 2 Dockerfiles to reproduce the issue:

FROM eclipse-temurin:11.0.13_8-jre-alpine

RUN apk info --depends apk-tools
RUN apk del apk-tools
# Breaking
RUN java -version
FROM eclipse-temurin:11.0.13_8-jre-alpine

RUN apk info --depends apk-tools
RUN apk add libretls zlib
RUN apk del apk-tools
# Fixed
RUN java -version

It looks like just "zlib" would be enough, but I added "libretls" as it results in not a single deletion of a package, just apk-tools itself.
Not sure what either of them do in context of apk-tools and why zlib seems to be necessary for the JVM

How to get notified when a new JVM version is released

Sorry to misuse the issue tracker for a question, and thanks for the great JVM containers you are providing!

We are using a specific docker tag (eclipse-temurin:17.0.1_12-jdk-focal). And we' would like to be notified whenever a new tag is available.

When the project was under the umbrella of adoptopenjdk, I was using the RSS feeds to get notified on new JVM releases: https://blog.adoptopenjdk.net/rss.xml

I'm trying to find similar option now, but with no luck so far.

If you have any idea, that would be great!
Thanks a lot.

Support for /usr/bin/python

During the removal of Python 2 Ubuntu also removed /usr/bin/python. This previously pointed to Python 2, hence why it was removed.
Since the containers provided by Adoptium are akin to a newly installed system (to use the wording provided in the release notes by Ubuntu), I was wondering if it would be possible to installed the package python-is-python3 by default? That way we can run python in our builds instead of having to explicitly write python3 which is just a little cleaner in my opinion

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.