text:
Error When Trying to Insert an Image from the Server Via "Browse Server" on CE 9.11

I have upgraded from 9.10.2 to 9.11 and when using the Editor and if I want to insert an image from the server I get this message
AbsoluteURL /Providers/HtmlEditorProviders/DNNConnect.CKE/Browser/Browser.
AbsoluteURL:/Providers/HtmlEditorProviders/DNNConnect.CKE/Browser/Browser.aspx
DefaultDataProvider:DotNetNuke.Data.SqlDataProvider, DotNetNuke
ExceptionGUID:40246ed6-f275-4512-8a92-aac97147994c
AssemblyVersion:9.11.0
PortalId:12
UserId:1
TabId:1914
RawUrl:/Providers/HtmlEditorProviders/DNNConnect.CKE/Browser/Browser.aspx?Type=Image&tabid=1914&PortalID=12&mid=8016&ckid=txtTabContent&mode=Portal&lang=en-US&CKEditor=dnn_ctr8016_EditContent_txtTabContent_txtTabContent&CKEditorFuncNum
Referrer:http://mysite.com/mypage/ctl/EditContent/mid/8016/tci/-1
UserAgent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36
ExceptionHash:yZPrNxBaOiRNLOPC8YORUfP2PL4=
Message:A self closing tag cannot have child controls and/or content
StackTrace:
InnerMessage:A self closing tag cannot have child controls and/or content
InnerStackTrace:
at DNNConnect.CKEditorProvider.Controls.HtmlGenericSelfClosing.get_Controls()
at ClientDependency.Core.ControlExtensions.FlattenChildren(Control control)
at System.Linq.Enumerable.d__172.MoveNext()    at System.Linq.Enumerable.<ConcatIterator>d__591.MoveNext()
at System.Linq.Enumerable.d__172.MoveNext()    at System.Linq.Enumerable.<ConcatIterator>d__591.MoveNext()
at System.Linq.Enumerable.d__172.MoveNext()    at System.Linq.Enumerable.<ConcatIterator>d__591.MoveNext()
at System.Collections.Generic.List1..ctor(IEnumerable1 collection)
at ClientDependency.Core.Controls.ClientDependencyLoader.FindDependencies(Control control)
at ClientDependency.Core.Controls.ClientDependencyLoader.RegisterClientDependencies(WebFormsFileRegistrationProvider provider, Control control, IEnumerable`1 paths)
at ClientDependency.Core.Controls.ClientDependencyLoader.OnPreRender(EventArgs e)
at DotNetNuke.Web.Client.ClientResourceManagement.ClientResourceLoader.OnPreRender(EventArgs e)
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
Source:
FileName:
FileLineNumber:0
FileColumnNumber:0
Method:
Server Name: MyServer

I encountered the same problem. I tracked it down to a problem with the .ico file for the website.
If you leave the .ico file just as it comes out of the box, browsing to insert an image or link to a file works perfectly. If you change the .ico file from DNN.ico to anything else, the error that you report above appears. I have no idea why changing the .ico file causes any troubles.

Thanks Steve for the feedback, I realize on one of the other portals (on the same installation) the issues does not exist, let me check the size and properties of ico file on the working portal and do some testing and will revert back soonest!
Thanks again

I am curious whether the .ico file has been assigned for the portal that still works properly.
Here's an odd fact: if I assign the .ico file to a specific favicon file in the "Site Settings" control panel, the ability to browse the server is broken. If I try to reverse things by undoing the assignment (i.e. set the file to none in the "Site Settings" control panel, the server browsing is still broken. That makes no sense at all to me. I was expecting that it would work and the webserver would use whatever was in the favicon.ico file in the root folder of the website. Something seems to get messed up when one assigns the .ico file and it is not easily reversed.

I tried your solution and it did not work. I must be doing something wrong. I will investigate more tomorrow...

hmm, I used the resource manager to upload the ico file to the subfolder, made sure the ico is in a subfolder of the portal root.  Cleared the cache and restarted the app.

Did you use the "Site Settings" control panel to point at the .ico file? Or did you depend on the webserver finding it?

After uploading by the ico file by resource manager, i used the site settings to select the file from the subfolder  from browser file system

It breaks because of the LoadFavIcon method in \Providers\HtmlEditorProviders\DNNConnect.CKE\Browser\Browser.aspx.cs
It checks if the following file exists and then tries to add it to the controls collection: File.Exists(Path.Combine(this.portalSettings.HomeDirectoryMapPath, "favicon.ico"))
So I think the workaround is to not have it in the portal root or not have it named favicon.ico.
I have not been able to track down the breaking change yet.

I'm fixing a few other issues in CKE Provider this week anyway, so I'll see if I can fix this too. I guess that using FavIcon.GetHeaderLink() should do the trick.

authors: josey-baker salemkh skamphuis skarpik


text:
Edit and delete notes.

There is a few features I think that could be a good addition to the program.
BOOKS

Delete able books.

NOTES

A identification system for notes
Editable notes.
Delete able notes.

I think this would create an easier and better user experience for programmers.
The way I think we should implement this is by having an identification system for notes (as suggested by Michiel) and use that to edit or delete notes, since books already have their own UID, it would ( I think ) be similar to deleting a note with slight modification.
p.s : I rewrote the issue.

@sungwoncho This might be useful - editing a note for typos and such could come in handy. Deleting is a different matter. Of course, maybe a naming system would be required, as I'd prefer for users not to have to deal with the UID directly, as I believe this to be an implementation detail. What do you think?

Yes, UIDs are hard to remember, so I am open to the idea of adding names to notes. But I think a name should be optional so we can make notes quickly.
Here is what I am thinking:
dnote new 'curl -s makes curl silent' # create note without title (auto-generate title)
dnote new -t 'Silent Curl' 'curl -s makes curl silent' # create note with title
dnote edit 'Silent Curl' (or UID) '-s flag suppresses curl output'
dnote delete 'Silent Curl' (or UID)

A slight complication: do we allow duplicate names for notes? if there are duplicates, we might have to ask user for clarification on delete or edit. While it's too soon to worry about such case, I would like to get others feedback on this.

@sungwoncho  I submitted a pull request an hour or 2 ago, currently it forces the user to use names but I like your idea, I will see what I can do in the next few days. Currently, I am trying to implement a support for the new kind of file.

@sungwoncho About the complication stuff, I am thinking to append a number at the end of the note name so that every note would have unique names but of course the same name can be used across different books, just like how Microsoft implements their folder name system.

@sungwoncho  I have updated the code.

I have been reviewing PR from @YiiKuoChong and thinking about how I would use this new feature. Here are my thoughts:

Dnote was designed to quickly write down what we learn with minimal context switching while coding. I don't see myself or users assigning names to our notes.
Assigning names is unnecessarily complex. We need to

Ensure uniqueness

the current PR does not address this (having a predetermined format https://github.com/dnote-io/cli/pull/18/files#diff-cd575165f84eed10d10eb1460b0927b4R97 is not sufficient)
To ensure uniqueness we have to iterate over the whole notes in a book. Not efficient

Allow editing of names (the current PR does not address this.)

Instead of names, I propose that we use index of the note to refer to notes when editing/deleting.
dnote edit [book name] [index] "[content]"
dnote edit js 1 "blah blah"

We can obtain the index using dnote notes
$ dnote notes
In book JS:

[0] - Blah blah
[1] - Blah blah
[2] - Blah blah
[3] - Blah blah

By the way, I also open sourced the web client. In the long run, the web client will help devs easily consume bite-sized lessons from other developers around the world (much like twitter but for devs). To keep things minimal and stick to 'microlessons,' I don't see having a title for a note fitting with this long term plan.
Any thoughts @YiiKuoChong @michielboekhoff

I see your point, @sungwoncho. Maybe using indexes is a better way.
Thanks for open sourcing the web client. I've just had a quick look, and it looks good! I work with React at my place of employment and I'll have a better look tomorrow. I hope that soon, the server might become OSS too.
If necessary, @YiiKuoChong, I'll walk you through making the necessary changes to this PR.

@michielboekhoff Thanks for the feedback. The API and job server are already open sourced btw: https://github.com/dnote-io/api https://github.com/dnote-io/job

@sungwoncho My idea here is :

Add a Index variable in the JSON file.
Add a function which list the notes in the book.

e.g

Commandline
dnote notes ( List all the notes in current book. )
dnote notes -b "book_name" ( List all the notes in the specified book. )

Output
[ Index ] [ Note Name ]                        [ Content ]
1        book_note_001                      Note content 1.
2        book_note_002                      Note content 2.
3        book_note_003                      Note content 3.
4        book_note_004                      Note content 4.
5        book_note_005                      Note content 5.

The reason I proposed to keep the note name is that it would add another way for developers to find notes that they wants instead of reading the only the notes. It would be helpful if developers have a large note.

Add a function to make sure index is unique and does not repeat.

If it does repeat, we take appropriate action to correct it. There would be multiple reason why note index would repeat, first is that the user themselves edited .dnote file. Another is there is a previous bug in the program (I will try my best to avoid this from happening by reviewing the code a few time before pushing them to GitHub ) .
@sungwoncho @michielboekhoff Do you think we should make sure that the index is the same as the amount of notes in a book? If so, we should :

Add a function to rearrange the index.

What do you guys think?
I will start coding the solutions once we agree on what to do.

@sungwoncho utils.go is importing itself. Can you please fix it? I am not sure how to test the program with my own code while retaining GitHub link as the import.

I decided to remove the note name completely.

I think the following features are not needed:

Add a function to make sure index is unique and does not repeat.
Add a function to rearrange the index.

The reason is that we can simply use indices from Go slice.

Import was fixed by https://github.com/dnote-io/cli/pull/23.

What is the JOB server for?

Job server is a program that sends out email digest every Fridays.

if the code is not on the main branch, the program will not work

You should be able to compile and run the program even if you branch off. Let me know if you need help with that.
Merged https://github.com/dnote-io/cli/pull/26 and closing this.

source: gharchive/issue

authors: YiiKuoChong michielboekhoff sungwoncho

repo: dnote-io/cli

license: mit

license_type: permissive

license_source: bigquery


text:
Im trying to delete a chroot

THIS IS WHAT I GET WHEN I TRY TO INSTALL/REMOVE A CHROOT
chronos@localhost / $ sudo sh ~/Downloads/crouton -r trusty -t xiwi,xfce
/usr/local/chroots/trusty already has stuff in it!
Either delete it, specify a different name (-n), or specify -u to update it.
chronos@localhost / $ sudo enter-chroot -n trusty
Entering /mnt/stateful_partition/crouton/chroots/trusty...
UID 1000 not found in trusty
Not unmounting /mnt/stateful_partition/crouton/chroots/trusty as another instance is using it.
chronos@localhost / $

Please help

Your previously installed 'trusty' chroot may not have finished the installation.
You can enter it as root and see if it has an unfinished 'setup' script -
sudo enter-chroot -u root -n trusty
If so, tell it to finish the setup.
If you don't get prompted to complete the setup, then you may have to do one of the above recommendations -
Either delete it, specify a different name (-n), or specify -u to update it.

I just use delete-chroot -n  I think delete-chroot calls edit-chroot.

Okay I tried what both of you said.. I got this
chronos@localhost / $ sudo enter-chroot -u root -n trusty
Password:
Entering /mnt/stateful_partition/crouton/chroots/trusty...
(trusty)root@localhost:~# delete-chroot -n
-su: delete-chroot: command not found
(trusty)root@localhost:~#

Okay, I looked up how to delete it and I got this someone please help
chronos@localhost / $ sudo delete-chroot trusty
Unmounting /mnt/stateful_partition/crouton/chroots/trusty...
Failed to unmount /mnt/stateful_partition/crouton/chroots/trusty. Kill processes? [a/k/y/p/N] y
Sending SIGTERM to processes under /mnt/stateful_partition/crouton/chroots/trusty...
Delete /mnt/stateful_partition/crouton/chroots/trusty? [a/y/N] y
rm: cannot remove ‘/mnt/stateful_partition/crouton/chroots/trusty/tmp’: Device or resource busy
rm: cannot remove ‘/mnt/stateful_partition/crouton/chroots/trusty/dev’: Device or resource busy
rm: cannot remove ‘/mnt/stateful_partition/crouton/chroots/trusty/run’: Device or resource busy
rm: cannot remove ‘/mnt/stateful_partition/crouton/chroots/trusty/sys’: Device or resource busy
rm: cannot remove ‘/mnt/stateful_partition/crouton/chroots/trusty/proc’: Device or resource busy
rm: cannot remove ‘/mnt/stateful_partition/crouton/chroots/trusty/var/host/media’: Device or resource busy
rm: cannot remove ‘/mnt/stateful_partition/crouton/chroots/trusty/var/host/udev’: Device or resource busy
rm: cannot remove ‘/mnt/stateful_partition/crouton/chroots/trusty/var/host/cras’: Device or resource busy
rm: cannot remove ‘/mnt/stateful_partition/crouton/chroots/trusty/var/host/dbus’: Device or resource busy
rm: cannot remove ‘/mnt/stateful_partition/crouton/chroots/trusty/var/host/timezone’: Device or resource busy
rm: cannot remove ‘/mnt/stateful_partition/crouton/chroots/trusty/var/host/shill’: Device or resource busy
rm: cannot remove ‘/mnt/stateful_partition/crouton/chroots/trusty/lib/modules/3.10.18’: Device or resource busy
chronos@localhost / $

Your chroot is still running. Simple way --> reboot your chromebook and try
again.
On Mon, Nov 2, 2015 at 4:22 PM, CharlieHammons notifications@github.com
wrote:

Okay, I looked up how to delete it and I got this someone please help
chronos@localhost / $ sudo delete-chroot trusty
Unmounting /mnt/stateful_partition/crouton/chroots/trusty...
Failed to unmount /mnt/stateful_partition/crouton/chroots/trusty. Kill
processes? [a/k/y/p/N] y
Sending SIGTERM to processes under
/mnt/stateful_partition/crouton/chroots/trusty...
Delete /mnt/stateful_partition/crouton/chroots/trusty? [a/y/N] y
rm: cannot remove ‘/mnt/stateful_partition/crouton/chroots/trusty/tmp’:
Device or resource busy
rm: cannot remove ‘/mnt/stateful_partition/crouton/chroots/trusty/dev’:
Device or resource busy
rm: cannot remove ‘/mnt/stateful_partition/crouton/chroots/trusty/run’:
Device or resource busy
rm: cannot remove ‘/mnt/stateful_partition/crouton/chroots/trusty/sys’:
Device or resource busy
rm: cannot remove ‘/mnt/stateful_partition/crouton/chroots/trusty/proc’:
Device or resource busy
rm: cannot remove
‘/mnt/stateful_partition/crouton/chroots/trusty/var/host/media’: Device or
resource busy
rm: cannot remove
‘/mnt/stateful_partition/crouton/chroots/trusty/var/host/udev’: Device or
resource busy
rm: cannot remove
‘/mnt/stateful_partition/crouton/chroots/trusty/var/host/cras’: Device or
resource busy
rm: cannot remove
‘/mnt/stateful_partition/crouton/chroots/trusty/var/host/dbus’: Device or
resource busy
rm: cannot remove
‘/mnt/stateful_partition/crouton/chroots/trusty/var/host/timezone’: Device
or resource busy
rm: cannot remove
‘/mnt/stateful_partition/crouton/chroots/trusty/var/host/shill’: Device or
resource busy
rm: cannot remove
‘/mnt/stateful_partition/crouton/chroots/trusty/lib/modules/3.10.18’:
Device or resource busy
chronos@localhost / $
—
Reply to this email directly or view it on GitHub
https://github.com/dnschneid/crouton/issues/2213#issuecomment-153051249.

authors: CharlieHammons DennisLfromGA divx118 tedm

repo: dnschneid/crouton

license_source: github-api


text:
Update readme.md with AUR package

I created an AUR package for easy installation on Arch Linux.

Awesome! Have you automated the upgrade process, or will the version need to be updated manually whenever a new release comes out?

source: gharchive/pull-request

authors: dobicinaitis opensourcecheemsburgers

repo: dobicinaitis/tailwind-cli-extra

license: MIT


text:
feat: logs added for es8 index

Adding logs sequentially for all indexes in docarray according to issue

test_jac failing https://github.com/docarray/docarray/actions/runs/5011253038/jobs/8981901725?pr=1551 @samsja @JohannesMessner

Hey @samsja I have tried to debug the failed test case but have not been able to figure it out as I have just added logs here.

these tests are failing because it needs to access a token in the docarray org but because you are opening a PR trough your fork you don't have access.
Basically don't worry we will merge even if it fails

I will review asap btw

authors: agaraman0 aman-exp-infy samsja

repo: docarray/docarray


text:
docs: fix data management section not appearing in documentation

Since the path data/ exists in .gitignore, DocArray push/pull section does not appear in the documentation because it belongs to a folder named data and CD ignores it when deploying new docs.
This PR fixes the issue by renaming the folder.

Codecov Report
Base: 85.20% // Head: 23.61% // Decreases project coverage by -61.59% :warning:

Coverage data is based on head (cd70041) compared to base (b18f5da).
Patch has no changes to coverable lines.

Additional details and impacted files
@@             Coverage Diff             @@
##             main     #967       +/-   ##
===========================================
- Coverage   85.20%   23.61%   -61.60%
===========================================
  Files         155      155
  Lines        8050     8050
===========================================
- Hits         6859     1901     -4958
- Misses       1191     6149     +4958

Flag
Coverage Δ

docarray
23.61% <ø> (-61.60%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

docarray/array/redis.py
0.00% <0.00%> (-100.00%)
:arrow_down:

docarray/array/milvus.py
0.00% <0.00%> (-100.00%)
:arrow_down:

docarray/array/qdrant.py
0.00% <0.00%> (-100.00%)
:arrow_down:

docarray/array/sqlite.py
0.00% <0.00%> (-100.00%)
:arrow_down:

docarray/array/annlite.py
0.00% <0.00%> (-100.00%)
:arrow_down:

docarray/array/elastic.py
0.00% <0.00%> (-100.00%)
:arrow_down:

docarray/array/weaviate.py
0.00% <0.00%> (-100.00%)
:arrow_down:

docarray/array/opensearch.py
0.00% <0.00%> (-100.00%)
:arrow_down:

docarray/math/distance/numpy.py
0.00% <0.00%> (-100.00%)
:arrow_down:

docarray/math/distance/torch.py
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 121 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


text:
ci: increase docs deploy timeout

This PR configures a custom github actions to deploy github pages documentation, in order to increase timeout

Codecov Report
Base: 85.20% // Head: 85.20% // No change to project coverage :thumbsup:

Coverage data is based on head (5640e8c) compared to base (b18f5da).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #968   +/-   ##
=======================================
  Coverage   85.20%   85.20%
=======================================
  Files         155      155
  Lines        8050     8050
=======================================
  Hits         6859     6859
  Misses       1191     1191

Flag
Coverage Δ

docarray
85.20% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


text:
What parameters need to be passed in when running the update.sh script, can you write a demo? I am very grateful!

What parameters need to be passed in when running the update.sh script, can you write a demo? I am very grateful!

The only arguments it takes are which versions to try to find updates for ( viaversions.sh) and apply any changes (via apply-templates.sh); for examples ./update.sh 14 or ./update.sh 12 10 13.
https://github.com/docker-library/postgres/blob/271cf940d0b8e212d16309271d49a8fdd4f48978/update.sh#L6-L7
If no arguments are given, then these scripts attempts to do so for all versions in the repo.  The update.sh script does not usually need to be run manually, since there is an automated job that runs it and commits the changes.

If making a pull request to change the Dockerization, then changing the Dockerfile-alpine.template or Dockerfile-debian.template files is the correct approach followed by running apply-templates.sh and committing the changes. (which also works for changing the docker-entrypoint.sh at the root of the repo and applying the change to all the versions; but it does not currently use templating).

authors: luomengY yosifkit

repo: docker-library/postgres


text:
Add a lot more versions/variants (more Java versions, more base images, more OpenJDK implementations)

This implements a large number of new variants based on OpenJDK alternatives listed in https://hub.docker.com/_/openjdk (more Corretto, Temurin, Semeru, SAP, etc).
This is not intended as a target for merging, but rather as a placeholder for discussion (to make the scope of the problem more obvious than it has previously been).
See especially https://github.com/docker-library/tomcat/pull/248#issuecomment-1329908153, which summarizes this well:

Sorry, our current "support matrix" is already out of control, so we're still trying to decide the best path forward. :bow:
To give you an idea the scale I'm talking about, we currently support four concrete versions of Tomcat across ~3 versions of Java (both JDK and JRE) on up to three different implementation+distro combinations.  That's ~49 different builds of Tomcat, which is then multiplied by the list of supported architectures for each image we're FROM. :grimacing:
If we take this PR to the extended conclusion, that balloons to ~6 versions of Java (again, ~two builds each, JDK and JRE), from ~5 vendors across even more variants -- I have a test branch that includes those full changes, and it takes the matrix of supported versions from 49 all the way up to 228 (which still doesn't factor in the way the matrix expands along the supported architectures axis -- that's just explicit tag combinations that all support at least amd64).  Limiting that to just the three LTS versions of Java takes us down to 147, but that's still really unmanageable (even the 49 we're at now is pretty high up there). :face_exhaling:
One thing we've considered is updating the templating to generate all 228 variants, but only officially build/publish one or two "tracks" (perhaps just Temurin, for example).  That would take our actual supported list way down, but I wouldn't want to publish that many Dockerfiles unless our automated builds are also testing them, and at 228 we'd be pushing the limits of what GitHub Actions is willing to accept. :scream:
So, as you can see, this isn't as simple as just merging this PR. :disappointed:

Example docker build command to build a version/variant from this PR (adjust as needed for other combinations):
docker build --pull 'https://github.com/docker-library/tomcat.git#refs/pull/299/head:10.1/jdk17/semeru-jammy'

To make sure I get this right - the only problem is the GitHub actions limit? Have you tried reaching out to GitHub and request more capacity considering the impact of this project? Or to the ASF to pick up some of this load? If they won't bother, it should be possible to find a commercial sponsor to contribute the build systems for something like this.

No, the GitHub Actions limits are only an example to help illustrate how large this matrix becomes -- the bigger issue is the load in both maintenance and downstream in the official images program.

For a user-facing impact, see the tag listing in https://github.com/docker-library/docs/blob/eb34efeaf92428afecd5375459c3fe3e657bb9f2/tomcat/README.md#supported-tags-and-respective-dockerfile-links which is already really unwieldy. :disappointed:
Here's what it would look like with this PR:

very long tag listing example
Supported tags and respective Dockerfile links

11.0.0-M5-jdk17-temurin-jammy, 11.0.0-jdk17-temurin-jammy, 11.0-jdk17-temurin-jammy, 11.0.0-M5-jdk17-temurin, 11.0.0-jdk17-temurin, 11.0-jdk17-temurin, 11.0.0-M5-jdk17, 11.0.0-jdk17, 11.0-jdk17, 11.0.0-M5, 11.0.0, 11.0
11.0.0-M5-jre17-temurin-jammy, 11.0.0-jre17-temurin-jammy, 11.0-jre17-temurin-jammy, 11.0.0-M5-jre17-temurin, 11.0.0-jre17-temurin, 11.0-jre17-temurin, 11.0.0-M5-jre17, 11.0.0-jre17, 11.0-jre17
11.0.0-M5-jdk17-temurin-alpine, 11.0.0-jdk17-temurin-alpine, 11.0-jdk17-temurin-alpine
11.0.0-M5-jre17-temurin-alpine, 11.0.0-jre17-temurin-alpine, 11.0-jre17-temurin-alpine
11.0.0-M5-jdk17-corretto-al2023, 11.0.0-jdk17-corretto-al2023, 11.0-jdk17-corretto-al2023, 11.0.0-M5-jdk17-corretto, 11.0.0-jdk17-corretto, 11.0-jdk17-corretto
11.0.0-M5-jdk17-corretto-alpine3.17, 11.0.0-jdk17-corretto-alpine3.17, 11.0-jdk17-corretto-alpine3.17, 11.0.0-M5-jdk17-corretto-alpine, 11.0.0-jdk17-corretto-alpine, 11.0-jdk17-corretto-alpine
11.0.0-M5-jdk17-corretto-alpine3.16, 11.0.0-jdk17-corretto-alpine3.16, 11.0-jdk17-corretto-alpine3.16
11.0.0-M5-jdk17-corretto-alpine3.15, 11.0.0-jdk17-corretto-alpine3.15, 11.0-jdk17-corretto-alpine3.15
11.0.0-M5-jdk17-sapmachine, 11.0.0-jdk17-sapmachine, 11.0-jdk17-sapmachine
11.0.0-M5-jdk17-semeru-jammy, 11.0.0-jdk17-semeru-jammy, 11.0-jdk17-semeru-jammy, 11.0.0-M5-jdk17-semeru, 11.0.0-jdk17-semeru, 11.0-jdk17-semeru
11.0.0-M5-jre17-semeru-jammy, 11.0.0-jre17-semeru-jammy, 11.0-jre17-semeru-jammy, 11.0.0-M5-jre17-semeru, 11.0.0-jre17-semeru, 11.0-jre17-semeru
11.0.0-M5-jdk20-temurin-jammy, 11.0.0-jdk20-temurin-jammy, 11.0-jdk20-temurin-jammy, 11.0.0-M5-jdk20-temurin, 11.0.0-jdk20-temurin, 11.0-jdk20-temurin, 11.0.0-M5-jdk20, 11.0.0-jdk20, 11.0-jdk20
11.0.0-M5-jre20-temurin-jammy, 11.0.0-jre20-temurin-jammy, 11.0-jre20-temurin-jammy, 11.0.0-M5-jre20-temurin, 11.0.0-jre20-temurin, 11.0-jre20-temurin, 11.0.0-M5-jre20, 11.0.0-jre20, 11.0-jre20
11.0.0-M5-jdk20-temurin-alpine, 11.0.0-jdk20-temurin-alpine, 11.0-jdk20-temurin-alpine
11.0.0-M5-jre20-temurin-alpine, 11.0.0-jre20-temurin-alpine, 11.0-jre20-temurin-alpine
11.0.0-M5-jdk20-corretto-alpine3.17, 11.0.0-jdk20-corretto-alpine3.17, 11.0-jdk20-corretto-alpine3.17, 11.0.0-M5-jdk20-corretto-alpine, 11.0.0-jdk20-corretto-alpine, 11.0-jdk20-corretto-alpine
11.0.0-M5-jdk20-corretto-alpine3.16, 11.0.0-jdk20-corretto-alpine3.16, 11.0-jdk20-corretto-alpine3.16
11.0.0-M5-jdk20-corretto-alpine3.15, 11.0.0-jdk20-corretto-alpine3.15, 11.0-jdk20-corretto-alpine3.15
11.0.0-M5-jdk20-sapmachine, 11.0.0-jdk20-sapmachine, 11.0-jdk20-sapmachine
11.0.0-M5-jdk18-semeru-jammy, 11.0.0-jdk18-semeru-jammy, 11.0-jdk18-semeru-jammy, 11.0.0-M5-jdk18-semeru, 11.0.0-jdk18-semeru, 11.0-jdk18-semeru
11.0.0-M5-jre18-semeru-jammy, 11.0.0-jre18-semeru-jammy, 11.0-jre18-semeru-jammy, 11.0.0-M5-jre18-semeru, 11.0.0-jre18-semeru, 11.0-jre18-semeru
10.1.8-jdk17-temurin-jammy, 10.1-jdk17-temurin-jammy, 10-jdk17-temurin-jammy, jdk17-temurin-jammy, 10.1.8-jdk17-temurin, 10.1-jdk17-temurin, 10-jdk17-temurin, jdk17-temurin, 10.1.8-jdk17, 10.1-jdk17, 10-jdk17, jdk17, 10.1.8, 10.1, 10, latest
10.1.8-jre17-temurin-jammy, 10.1-jre17-temurin-jammy, 10-jre17-temurin-jammy, jre17-temurin-jammy, 10.1.8-jre17-temurin, 10.1-jre17-temurin, 10-jre17-temurin, jre17-temurin, 10.1.8-jre17, 10.1-jre17, 10-jre17, jre17
10.1.8-jdk17-temurin-alpine, 10.1-jdk17-temurin-alpine, 10-jdk17-temurin-alpine, jdk17-temurin-alpine
10.1.8-jre17-temurin-alpine, 10.1-jre17-temurin-alpine, 10-jre17-temurin-alpine, jre17-temurin-alpine
10.1.8-jdk17-corretto-al2023, 10.1-jdk17-corretto-al2023, 10-jdk17-corretto-al2023, jdk17-corretto-al2023, 10.1.8-jdk17-corretto, 10.1-jdk17-corretto, 10-jdk17-corretto, jdk17-corretto
10.1.8-jdk17-corretto-alpine3.17, 10.1-jdk17-corretto-alpine3.17, 10-jdk17-corretto-alpine3.17, jdk17-corretto-alpine3.17, 10.1.8-jdk17-corretto-alpine, 10.1-jdk17-corretto-alpine, 10-jdk17-corretto-alpine, jdk17-corretto-alpine
10.1.8-jdk17-corretto-alpine3.16, 10.1-jdk17-corretto-alpine3.16, 10-jdk17-corretto-alpine3.16, jdk17-corretto-alpine3.16
10.1.8-jdk17-corretto-alpine3.15, 10.1-jdk17-corretto-alpine3.15, 10-jdk17-corretto-alpine3.15, jdk17-corretto-alpine3.15
10.1.8-jdk17-sapmachine, 10.1-jdk17-sapmachine, 10-jdk17-sapmachine, jdk17-sapmachine
10.1.8-jdk17-semeru-jammy, 10.1-jdk17-semeru-jammy, 10-jdk17-semeru-jammy, jdk17-semeru-jammy, 10.1.8-jdk17-semeru, 10.1-jdk17-semeru, 10-jdk17-semeru, jdk17-semeru
10.1.8-jre17-semeru-jammy, 10.1-jre17-semeru-jammy, 10-jre17-semeru-jammy, jre17-semeru-jammy, 10.1.8-jre17-semeru, 10.1-jre17-semeru, 10-jre17-semeru, jre17-semeru
10.1.8-jdk11-temurin-jammy, 10.1-jdk11-temurin-jammy, 10-jdk11-temurin-jammy, jdk11-temurin-jammy, 10.1.8-jdk11-temurin, 10.1-jdk11-temurin, 10-jdk11-temurin, jdk11-temurin, 10.1.8-jdk11, 10.1-jdk11, 10-jdk11, jdk11
10.1.8-jre11-temurin-jammy, 10.1-jre11-temurin-jammy, 10-jre11-temurin-jammy, jre11-temurin-jammy, 10.1.8-jre11-temurin, 10.1-jre11-temurin, 10-jre11-temurin, jre11-temurin, 10.1.8-jre11, 10.1-jre11, 10-jre11, jre11
10.1.8-jdk11-temurin-alpine, 10.1-jdk11-temurin-alpine, 10-jdk11-temurin-alpine, jdk11-temurin-alpine
10.1.8-jre11-temurin-alpine, 10.1-jre11-temurin-alpine, 10-jre11-temurin-alpine, jre11-temurin-alpine
10.1.8-jdk11-corretto-al2023, 10.1-jdk11-corretto-al2023, 10-jdk11-corretto-al2023, jdk11-corretto-al2023, 10.1.8-jdk11-corretto, 10.1-jdk11-corretto, 10-jdk11-corretto, jdk11-corretto
10.1.8-jdk11-corretto-alpine3.17, 10.1-jdk11-corretto-alpine3.17, 10-jdk11-corretto-alpine3.17, jdk11-corretto-alpine3.17, 10.1.8-jdk11-corretto-alpine, 10.1-jdk11-corretto-alpine, 10-jdk11-corretto-alpine, jdk11-corretto-alpine
10.1.8-jdk11-corretto-alpine3.16, 10.1-jdk11-corretto-alpine3.16, 10-jdk11-corretto-alpine3.16, jdk11-corretto-alpine3.16
10.1.8-jdk11-corretto-alpine3.15, 10.1-jdk11-corretto-alpine3.15, 10-jdk11-corretto-alpine3.15, jdk11-corretto-alpine3.15
10.1.8-jdk11-sapmachine, 10.1-jdk11-sapmachine, 10-jdk11-sapmachine, jdk11-sapmachine
10.1.8-jdk11-semeru-jammy, 10.1-jdk11-semeru-jammy, 10-jdk11-semeru-jammy, jdk11-semeru-jammy, 10.1.8-jdk11-semeru, 10.1-jdk11-semeru, 10-jdk11-semeru, jdk11-semeru
10.1.8-jre11-semeru-jammy, 10.1-jre11-semeru-jammy, 10-jre11-semeru-jammy, jre11-semeru-jammy, 10.1.8-jre11-semeru, 10.1-jre11-semeru, 10-jre11-semeru, jre11-semeru
10.1.8-jdk20-temurin-jammy, 10.1-jdk20-temurin-jammy, 10-jdk20-temurin-jammy, jdk20-temurin-jammy, 10.1.8-jdk20-temurin, 10.1-jdk20-temurin, 10-jdk20-temurin, jdk20-temurin, 10.1.8-jdk20, 10.1-jdk20, 10-jdk20, jdk20
10.1.8-jre20-temurin-jammy, 10.1-jre20-temurin-jammy, 10-jre20-temurin-jammy, jre20-temurin-jammy, 10.1.8-jre20-temurin, 10.1-jre20-temurin, 10-jre20-temurin, jre20-temurin, 10.1.8-jre20, 10.1-jre20, 10-jre20, jre20
10.1.8-jdk20-temurin-alpine, 10.1-jdk20-temurin-alpine, 10-jdk20-temurin-alpine, jdk20-temurin-alpine
10.1.8-jre20-temurin-alpine, 10.1-jre20-temurin-alpine, 10-jre20-temurin-alpine, jre20-temurin-alpine
10.1.8-jdk20-corretto-alpine3.17, 10.1-jdk20-corretto-alpine3.17, 10-jdk20-corretto-alpine3.17, jdk20-corretto-alpine3.17, 10.1.8-jdk20-corretto-alpine, 10.1-jdk20-corretto-alpine, 10-jdk20-corretto-alpine, jdk20-corretto-alpine
10.1.8-jdk20-corretto-alpine3.16, 10.1-jdk20-corretto-alpine3.16, 10-jdk20-corretto-alpine3.16, jdk20-corretto-alpine3.16
10.1.8-jdk20-corretto-alpine3.15, 10.1-jdk20-corretto-alpine3.15, 10-jdk20-corretto-alpine3.15, jdk20-corretto-alpine3.15
10.1.8-jdk20-sapmachine, 10.1-jdk20-sapmachine, 10-jdk20-sapmachine, jdk20-sapmachine
10.1.8-jdk18-semeru-jammy, 10.1-jdk18-semeru-jammy, 10-jdk18-semeru-jammy, jdk18-semeru-jammy, 10.1.8-jdk18-semeru, 10.1-jdk18-semeru, 10-jdk18-semeru, jdk18-semeru
10.1.8-jre18-semeru-jammy, 10.1-jre18-semeru-jammy, 10-jre18-semeru-jammy, jre18-semeru-jammy, 10.1.8-jre18-semeru, 10.1-jre18-semeru, 10-jre18-semeru, jre18-semeru
9.0.74-jdk21-openjdk-bullseye, 9.0-jdk21-openjdk-bullseye, 9-jdk21-openjdk-bullseye, 9.0.74-jdk21-openjdk, 9.0-jdk21-openjdk, 9-jdk21-openjdk
9.0.74-jdk21-openjdk-buster, 9.0-jdk21-openjdk-buster, 9-jdk21-openjdk-buster
9.0.74-jdk21-openjdk-slim-bullseye, 9.0-jdk21-openjdk-slim-bullseye, 9-jdk21-openjdk-slim-bullseye, 9.0.74-jdk21-openjdk-slim, 9.0-jdk21-openjdk-slim, 9-jdk21-openjdk-slim
9.0.74-jdk21-openjdk-slim-buster, 9.0-jdk21-openjdk-slim-buster, 9-jdk21-openjdk-slim-buster
9.0.74-jdk21-openjdk-oraclelinux8, 9.0-jdk21-openjdk-oraclelinux8, 9-jdk21-openjdk-oraclelinux8
9.0.74-jdk21-openjdk-oraclelinux7, 9.0-jdk21-openjdk-oraclelinux7, 9-jdk21-openjdk-oraclelinux7
9.0.74-jdk17-temurin-jammy, 9.0-jdk17-temurin-jammy, 9-jdk17-temurin-jammy, 9.0.74-jdk17-temurin, 9.0-jdk17-temurin, 9-jdk17-temurin, 9.0.74-jdk17, 9.0-jdk17, 9-jdk17, 9.0.74, 9.0, 9
9.0.74-jre17-temurin-jammy, 9.0-jre17-temurin-jammy, 9-jre17-temurin-jammy, 9.0.74-jre17-temurin, 9.0-jre17-temurin, 9-jre17-temurin, 9.0.74-jre17, 9.0-jre17, 9-jre17
9.0.74-jdk17-temurin-focal, 9.0-jdk17-temurin-focal, 9-jdk17-temurin-focal
9.0.74-jre17-temurin-focal, 9.0-jre17-temurin-focal, 9-jre17-temurin-focal
9.0.74-jdk17-temurin-alpine, 9.0-jdk17-temurin-alpine, 9-jdk17-temurin-alpine
9.0.74-jre17-temurin-alpine, 9.0-jre17-temurin-alpine, 9-jre17-temurin-alpine
9.0.74-jdk17-corretto-al2, 9.0-jdk17-corretto-al2, 9-jdk17-corretto-al2, 9.0.74-jdk17-corretto, 9.0-jdk17-corretto, 9-jdk17-corretto
9.0.74-jdk17-corretto-al2023, 9.0-jdk17-corretto-al2023, 9-jdk17-corretto-al2023
9.0.74-jdk17-corretto-alpine3.17, 9.0-jdk17-corretto-alpine3.17, 9-jdk17-corretto-alpine3.17, 9.0.74-jdk17-corretto-alpine, 9.0-jdk17-corretto-alpine, 9-jdk17-corretto-alpine
9.0.74-jdk17-corretto-alpine3.16, 9.0-jdk17-corretto-alpine3.16, 9-jdk17-corretto-alpine3.16
9.0.74-jdk17-corretto-alpine3.15, 9.0-jdk17-corretto-alpine3.15, 9-jdk17-corretto-alpine3.15
9.0.74-jdk17-sapmachine, 9.0-jdk17-sapmachine, 9-jdk17-sapmachine
9.0.74-jdk17-semeru-jammy, 9.0-jdk17-semeru-jammy, 9-jdk17-semeru-jammy, 9.0.74-jdk17-semeru, 9.0-jdk17-semeru, 9-jdk17-semeru
9.0.74-jre17-semeru-jammy, 9.0-jre17-semeru-jammy, 9-jre17-semeru-jammy, 9.0.74-jre17-semeru, 9.0-jre17-semeru, 9-jre17-semeru
9.0.74-jdk17-semeru-focal, 9.0-jdk17-semeru-focal, 9-jdk17-semeru-focal
9.0.74-jre17-semeru-focal, 9.0-jre17-semeru-focal, 9-jre17-semeru-focal
9.0.74-jdk11-temurin-jammy, 9.0-jdk11-temurin-jammy, 9-jdk11-temurin-jammy, 9.0.74-jdk11-temurin, 9.0-jdk11-temurin, 9-jdk11-temurin, 9.0.74-jdk11, 9.0-jdk11, 9-jdk11
9.0.74-jre11-temurin-jammy, 9.0-jre11-temurin-jammy, 9-jre11-temurin-jammy, 9.0.74-jre11-temurin, 9.0-jre11-temurin, 9-jre11-temurin, 9.0.74-jre11, 9.0-jre11, 9-jre11
9.0.74-jdk11-temurin-focal, 9.0-jdk11-temurin-focal, 9-jdk11-temurin-focal
9.0.74-jre11-temurin-focal, 9.0-jre11-temurin-focal, 9-jre11-temurin-focal
9.0.74-jdk11-temurin-alpine, 9.0-jdk11-temurin-alpine, 9-jdk11-temurin-alpine
9.0.74-jre11-temurin-alpine, 9.0-jre11-temurin-alpine, 9-jre11-temurin-alpine
9.0.74-jdk11-corretto-al2, 9.0-jdk11-corretto-al2, 9-jdk11-corretto-al2, 9.0.74-jdk11-corretto, 9.0-jdk11-corretto, 9-jdk11-corretto
9.0.74-jdk11-corretto-al2023, 9.0-jdk11-corretto-al2023, 9-jdk11-corretto-al2023
9.0.74-jdk11-corretto-alpine3.17, 9.0-jdk11-corretto-alpine3.17, 9-jdk11-corretto-alpine3.17, 9.0.74-jdk11-corretto-alpine, 9.0-jdk11-corretto-alpine, 9-jdk11-corretto-alpine
9.0.74-jdk11-corretto-alpine3.16, 9.0-jdk11-corretto-alpine3.16, 9-jdk11-corretto-alpine3.16
9.0.74-jdk11-corretto-alpine3.15, 9.0-jdk11-corretto-alpine3.15, 9-jdk11-corretto-alpine3.15
9.0.74-jdk11-sapmachine, 9.0-jdk11-sapmachine, 9-jdk11-sapmachine
9.0.74-jdk11-semeru-jammy, 9.0-jdk11-semeru-jammy, 9-jdk11-semeru-jammy, 9.0.74-jdk11-semeru, 9.0-jdk11-semeru, 9-jdk11-semeru
9.0.74-jre11-semeru-jammy, 9.0-jre11-semeru-jammy, 9-jre11-semeru-jammy, 9.0.74-jre11-semeru, 9.0-jre11-semeru, 9-jre11-semeru
9.0.74-jdk11-semeru-focal, 9.0-jdk11-semeru-focal, 9-jdk11-semeru-focal
9.0.74-jre11-semeru-focal, 9.0-jre11-semeru-focal, 9-jre11-semeru-focal
9.0.74-jdk8-temurin-jammy, 9.0-jdk8-temurin-jammy, 9-jdk8-temurin-jammy, 9.0.74-jdk8-temurin, 9.0-jdk8-temurin, 9-jdk8-temurin, 9.0.74-jdk8, 9.0-jdk8, 9-jdk8
9.0.74-jre8-temurin-jammy, 9.0-jre8-temurin-jammy, 9-jre8-temurin-jammy, 9.0.74-jre8-temurin, 9.0-jre8-temurin, 9-jre8-temurin, 9.0.74-jre8, 9.0-jre8, 9-jre8
9.0.74-jdk8-temurin-focal, 9.0-jdk8-temurin-focal, 9-jdk8-temurin-focal
9.0.74-jre8-temurin-focal, 9.0-jre8-temurin-focal, 9-jre8-temurin-focal
9.0.74-jdk8-temurin-alpine, 9.0-jdk8-temurin-alpine, 9-jdk8-temurin-alpine
9.0.74-jre8-temurin-alpine, 9.0-jre8-temurin-alpine, 9-jre8-temurin-alpine
9.0.74-jdk8-corretto-al2, 9.0-jdk8-corretto-al2, 9-jdk8-corretto-al2, 9.0.74-jdk8-corretto, 9.0-jdk8-corretto, 9-jdk8-corretto
9.0.74-jdk8-corretto-al2023, 9.0-jdk8-corretto-al2023, 9-jdk8-corretto-al2023
9.0.74-jre8-corretto-al2023, 9.0-jre8-corretto-al2023, 9-jre8-corretto-al2023
9.0.74-jdk8-corretto-alpine3.17, 9.0-jdk8-corretto-alpine3.17, 9-jdk8-corretto-alpine3.17, 9.0.74-jdk8-corretto-alpine, 9.0-jdk8-corretto-alpine, 9-jdk8-corretto-alpine
9.0.74-jre8-corretto-alpine3.17, 9.0-jre8-corretto-alpine3.17, 9-jre8-corretto-alpine3.17, 9.0.74-jre8-corretto-alpine, 9.0-jre8-corretto-alpine, 9-jre8-corretto-alpine
9.0.74-jdk8-corretto-alpine3.16, 9.0-jdk8-corretto-alpine3.16, 9-jdk8-corretto-alpine3.16
9.0.74-jre8-corretto-alpine3.16, 9.0-jre8-corretto-alpine3.16, 9-jre8-corretto-alpine3.16
9.0.74-jdk8-corretto-alpine3.15, 9.0-jdk8-corretto-alpine3.15, 9-jdk8-corretto-alpine3.15
9.0.74-jre8-corretto-alpine3.15, 9.0-jre8-corretto-alpine3.15, 9-jre8-corretto-alpine3.15
9.0.74-jdk8-semeru-jammy, 9.0-jdk8-semeru-jammy, 9-jdk8-semeru-jammy, 9.0.74-jdk8-semeru, 9.0-jdk8-semeru, 9-jdk8-semeru
9.0.74-jre8-semeru-jammy, 9.0-jre8-semeru-jammy, 9-jre8-semeru-jammy, 9.0.74-jre8-semeru, 9.0-jre8-semeru, 9-jre8-semeru
9.0.74-jdk8-semeru-focal, 9.0-jdk8-semeru-focal, 9-jdk8-semeru-focal
9.0.74-jre8-semeru-focal, 9.0-jre8-semeru-focal, 9-jre8-semeru-focal
9.0.74-jdk20-temurin-jammy, 9.0-jdk20-temurin-jammy, 9-jdk20-temurin-jammy, 9.0.74-jdk20-temurin, 9.0-jdk20-temurin, 9-jdk20-temurin, 9.0.74-jdk20, 9.0-jdk20, 9-jdk20
9.0.74-jre20-temurin-jammy, 9.0-jre20-temurin-jammy, 9-jre20-temurin-jammy, 9.0.74-jre20-temurin, 9.0-jre20-temurin, 9-jre20-temurin, 9.0.74-jre20, 9.0-jre20, 9-jre20
9.0.74-jdk20-temurin-alpine, 9.0-jdk20-temurin-alpine, 9-jdk20-temurin-alpine
9.0.74-jre20-temurin-alpine, 9.0-jre20-temurin-alpine, 9-jre20-temurin-alpine
9.0.74-jdk20-corretto-al2, 9.0-jdk20-corretto-al2, 9-jdk20-corretto-al2, 9.0.74-jdk20-corretto, 9.0-jdk20-corretto, 9-jdk20-corretto
9.0.74-jdk20-corretto-alpine3.17, 9.0-jdk20-corretto-alpine3.17, 9-jdk20-corretto-alpine3.17, 9.0.74-jdk20-corretto-alpine, 9.0-jdk20-corretto-alpine, 9-jdk20-corretto-alpine
9.0.74-jdk20-corretto-alpine3.16, 9.0-jdk20-corretto-alpine3.16, 9-jdk20-corretto-alpine3.16
9.0.74-jdk20-corretto-alpine3.15, 9.0-jdk20-corretto-alpine3.15, 9-jdk20-corretto-alpine3.15
9.0.74-jdk20-sapmachine, 9.0-jdk20-sapmachine, 9-jdk20-sapmachine
9.0.74-jdk18-semeru-jammy, 9.0-jdk18-semeru-jammy, 9-jdk18-semeru-jammy, 9.0.74-jdk18-semeru, 9.0-jdk18-semeru, 9-jdk18-semeru
9.0.74-jre18-semeru-jammy, 9.0-jre18-semeru-jammy, 9-jre18-semeru-jammy, 9.0.74-jre18-semeru, 9.0-jre18-semeru, 9-jre18-semeru
9.0.74-jdk18-semeru-focal, 9.0-jdk18-semeru-focal, 9-jdk18-semeru-focal
9.0.74-jre18-semeru-focal, 9.0-jre18-semeru-focal, 9-jre18-semeru-focal
8.5.88-jdk21-openjdk-bullseye, 8.5-jdk21-openjdk-bullseye, 8-jdk21-openjdk-bullseye, 8.5.88-jdk21-openjdk, 8.5-jdk21-openjdk, 8-jdk21-openjdk
8.5.88-jdk21-openjdk-buster, 8.5-jdk21-openjdk-buster, 8-jdk21-openjdk-buster
8.5.88-jdk21-openjdk-slim-bullseye, 8.5-jdk21-openjdk-slim-bullseye, 8-jdk21-openjdk-slim-bullseye, 8.5.88-jdk21-openjdk-slim, 8.5-jdk21-openjdk-slim, 8-jdk21-openjdk-slim
8.5.88-jdk21-openjdk-slim-buster, 8.5-jdk21-openjdk-slim-buster, 8-jdk21-openjdk-slim-buster
8.5.88-jdk21-openjdk-oraclelinux8, 8.5-jdk21-openjdk-oraclelinux8, 8-jdk21-openjdk-oraclelinux8
8.5.88-jdk21-openjdk-oraclelinux7, 8.5-jdk21-openjdk-oraclelinux7, 8-jdk21-openjdk-oraclelinux7
8.5.88-jdk17-temurin-jammy, 8.5-jdk17-temurin-jammy, 8-jdk17-temurin-jammy, 8.5.88-jdk17-temurin, 8.5-jdk17-temurin, 8-jdk17-temurin, 8.5.88-jdk17, 8.5-jdk17, 8-jdk17, 8.5.88, 8.5, 8
8.5.88-jre17-temurin-jammy, 8.5-jre17-temurin-jammy, 8-jre17-temurin-jammy, 8.5.88-jre17-temurin, 8.5-jre17-temurin, 8-jre17-temurin, 8.5.88-jre17, 8.5-jre17, 8-jre17
8.5.88-jdk17-temurin-focal, 8.5-jdk17-temurin-focal, 8-jdk17-temurin-focal
8.5.88-jre17-temurin-focal, 8.5-jre17-temurin-focal, 8-jre17-temurin-focal
8.5.88-jdk17-temurin-alpine, 8.5-jdk17-temurin-alpine, 8-jdk17-temurin-alpine
8.5.88-jre17-temurin-alpine, 8.5-jre17-temurin-alpine, 8-jre17-temurin-alpine
8.5.88-jdk17-corretto-al2, 8.5-jdk17-corretto-al2, 8-jdk17-corretto-al2, 8.5.88-jdk17-corretto, 8.5-jdk17-corretto, 8-jdk17-corretto
8.5.88-jdk17-corretto-al2023, 8.5-jdk17-corretto-al2023, 8-jdk17-corretto-al2023
8.5.88-jdk17-corretto-alpine3.17, 8.5-jdk17-corretto-alpine3.17, 8-jdk17-corretto-alpine3.17, 8.5.88-jdk17-corretto-alpine, 8.5-jdk17-corretto-alpine, 8-jdk17-corretto-alpine
8.5.88-jdk17-corretto-alpine3.16, 8.5-jdk17-corretto-alpine3.16, 8-jdk17-corretto-alpine3.16
8.5.88-jdk17-corretto-alpine3.15, 8.5-jdk17-corretto-alpine3.15, 8-jdk17-corretto-alpine3.15
8.5.88-jdk17-sapmachine, 8.5-jdk17-sapmachine, 8-jdk17-sapmachine
8.5.88-jdk17-semeru-jammy, 8.5-jdk17-semeru-jammy, 8-jdk17-semeru-jammy, 8.5.88-jdk17-semeru, 8.5-jdk17-semeru, 8-jdk17-semeru
8.5.88-jre17-semeru-jammy, 8.5-jre17-semeru-jammy, 8-jre17-semeru-jammy, 8.5.88-jre17-semeru, 8.5-jre17-semeru, 8-jre17-semeru
8.5.88-jdk17-semeru-focal, 8.5-jdk17-semeru-focal, 8-jdk17-semeru-focal
8.5.88-jre17-semeru-focal, 8.5-jre17-semeru-focal, 8-jre17-semeru-focal
8.5.88-jdk11-temurin-jammy, 8.5-jdk11-temurin-jammy, 8-jdk11-temurin-jammy, 8.5.88-jdk11-temurin, 8.5-jdk11-temurin, 8-jdk11-temurin, 8.5.88-jdk11, 8.5-jdk11, 8-jdk11
8.5.88-jre11-temurin-jammy, 8.5-jre11-temurin-jammy, 8-jre11-temurin-jammy, 8.5.88-jre11-temurin, 8.5-jre11-temurin, 8-jre11-temurin, 8.5.88-jre11, 8.5-jre11, 8-jre11
8.5.88-jdk11-temurin-focal, 8.5-jdk11-temurin-focal, 8-jdk11-temurin-focal
8.5.88-jre11-temurin-focal, 8.5-jre11-temurin-focal, 8-jre11-temurin-focal
8.5.88-jdk11-temurin-alpine, 8.5-jdk11-temurin-alpine, 8-jdk11-temurin-alpine
8.5.88-jre11-temurin-alpine, 8.5-jre11-temurin-alpine, 8-jre11-temurin-alpine
8.5.88-jdk11-corretto-al2, 8.5-jdk11-corretto-al2, 8-jdk11-corretto-al2, 8.5.88-jdk11-corretto, 8.5-jdk11-corretto, 8-jdk11-corretto
8.5.88-jdk11-corretto-al2023, 8.5-jdk11-corretto-al2023, 8-jdk11-corretto-al2023
8.5.88-jdk11-corretto-alpine3.17, 8.5-jdk11-corretto-alpine3.17, 8-jdk11-corretto-alpine3.17, 8.5.88-jdk11-corretto-alpine, 8.5-jdk11-corretto-alpine, 8-jdk11-corretto-alpine
8.5.88-jdk11-corretto-alpine3.16, 8.5-jdk11-corretto-alpine3.16, 8-jdk11-corretto-alpine3.16
8.5.88-jdk11-corretto-alpine3.15, 8.5-jdk11-corretto-alpine3.15, 8-jdk11-corretto-alpine3.15
8.5.88-jdk11-sapmachine, 8.5-jdk11-sapmachine, 8-jdk11-sapmachine
8.5.88-jdk11-semeru-jammy, 8.5-jdk11-semeru-jammy, 8-jdk11-semeru-jammy, 8.5.88-jdk11-semeru, 8.5-jdk11-semeru, 8-jdk11-semeru
8.5.88-jre11-semeru-jammy, 8.5-jre11-semeru-jammy, 8-jre11-semeru-jammy, 8.5.88-jre11-semeru, 8.5-jre11-semeru, 8-jre11-semeru
8.5.88-jdk11-semeru-focal, 8.5-jdk11-semeru-focal, 8-jdk11-semeru-focal
8.5.88-jre11-semeru-focal, 8.5-jre11-semeru-focal, 8-jre11-semeru-focal
8.5.88-jdk8-temurin-jammy, 8.5-jdk8-temurin-jammy, 8-jdk8-temurin-jammy, 8.5.88-jdk8-temurin, 8.5-jdk8-temurin, 8-jdk8-temurin, 8.5.88-jdk8, 8.5-jdk8, 8-jdk8
8.5.88-jre8-temurin-jammy, 8.5-jre8-temurin-jammy, 8-jre8-temurin-jammy, 8.5.88-jre8-temurin, 8.5-jre8-temurin, 8-jre8-temurin, 8.5.88-jre8, 8.5-jre8, 8-jre8
8.5.88-jdk8-temurin-focal, 8.5-jdk8-temurin-focal, 8-jdk8-temurin-focal
8.5.88-jre8-temurin-focal, 8.5-jre8-temurin-focal, 8-jre8-temurin-focal
8.5.88-jdk8-temurin-alpine, 8.5-jdk8-temurin-alpine, 8-jdk8-temurin-alpine
8.5.88-jre8-temurin-alpine, 8.5-jre8-temurin-alpine, 8-jre8-temurin-alpine
8.5.88-jdk8-corretto-al2, 8.5-jdk8-corretto-al2, 8-jdk8-corretto-al2, 8.5.88-jdk8-corretto, 8.5-jdk8-corretto, 8-jdk8-corretto
8.5.88-jdk8-corretto-al2023, 8.5-jdk8-corretto-al2023, 8-jdk8-corretto-al2023
8.5.88-jre8-corretto-al2023, 8.5-jre8-corretto-al2023, 8-jre8-corretto-al2023
8.5.88-jdk8-corretto-alpine3.17, 8.5-jdk8-corretto-alpine3.17, 8-jdk8-corretto-alpine3.17, 8.5.88-jdk8-corretto-alpine, 8.5-jdk8-corretto-alpine, 8-jdk8-corretto-alpine
8.5.88-jre8-corretto-alpine3.17, 8.5-jre8-corretto-alpine3.17, 8-jre8-corretto-alpine3.17, 8.5.88-jre8-corretto-alpine, 8.5-jre8-corretto-alpine, 8-jre8-corretto-alpine
8.5.88-jdk8-corretto-alpine3.16, 8.5-jdk8-corretto-alpine3.16, 8-jdk8-corretto-alpine3.16
8.5.88-jre8-corretto-alpine3.16, 8.5-jre8-corretto-alpine3.16, 8-jre8-corretto-alpine3.16
8.5.88-jdk8-corretto-alpine3.15, 8.5-jdk8-corretto-alpine3.15, 8-jdk8-corretto-alpine3.15
8.5.88-jre8-corretto-alpine3.15, 8.5-jre8-corretto-alpine3.15, 8-jre8-corretto-alpine3.15
8.5.88-jdk8-semeru-jammy, 8.5-jdk8-semeru-jammy, 8-jdk8-semeru-jammy, 8.5.88-jdk8-semeru, 8.5-jdk8-semeru, 8-jdk8-semeru
8.5.88-jre8-semeru-jammy, 8.5-jre8-semeru-jammy, 8-jre8-semeru-jammy, 8.5.88-jre8-semeru, 8.5-jre8-semeru, 8-jre8-semeru
8.5.88-jdk8-semeru-focal, 8.5-jdk8-semeru-focal, 8-jdk8-semeru-focal
8.5.88-jre8-semeru-focal, 8.5-jre8-semeru-focal, 8-jre8-semeru-focal
8.5.88-jdk20-temurin-jammy, 8.5-jdk20-temurin-jammy, 8-jdk20-temurin-jammy, 8.5.88-jdk20-temurin, 8.5-jdk20-temurin, 8-jdk20-temurin, 8.5.88-jdk20, 8.5-jdk20, 8-jdk20
8.5.88-jre20-temurin-jammy, 8.5-jre20-temurin-jammy, 8-jre20-temurin-jammy, 8.5.88-jre20-temurin, 8.5-jre20-temurin, 8-jre20-temurin, 8.5.88-jre20, 8.5-jre20, 8-jre20
8.5.88-jdk20-temurin-alpine, 8.5-jdk20-temurin-alpine, 8-jdk20-temurin-alpine
8.5.88-jre20-temurin-alpine, 8.5-jre20-temurin-alpine, 8-jre20-temurin-alpine
8.5.88-jdk20-corretto-al2, 8.5-jdk20-corretto-al2, 8-jdk20-corretto-al2, 8.5.88-jdk20-corretto, 8.5-jdk20-corretto, 8-jdk20-corretto
8.5.88-jdk20-corretto-alpine3.17, 8.5-jdk20-corretto-alpine3.17, 8-jdk20-corretto-alpine3.17, 8.5.88-jdk20-corretto-alpine, 8.5-jdk20-corretto-alpine, 8-jdk20-corretto-alpine
8.5.88-jdk20-corretto-alpine3.16, 8.5-jdk20-corretto-alpine3.16, 8-jdk20-corretto-alpine3.16
8.5.88-jdk20-corretto-alpine3.15, 8.5-jdk20-corretto-alpine3.15, 8-jdk20-corretto-alpine3.15
8.5.88-jdk20-sapmachine, 8.5-jdk20-sapmachine, 8-jdk20-sapmachine
8.5.88-jdk18-semeru-jammy, 8.5-jdk18-semeru-jammy, 8-jdk18-semeru-jammy, 8.5.88-jdk18-semeru, 8.5-jdk18-semeru, 8-jdk18-semeru
8.5.88-jre18-semeru-jammy, 8.5-jre18-semeru-jammy, 8-jre18-semeru-jammy, 8.5.88-jre18-semeru, 8.5-jre18-semeru, 8-jre18-semeru
8.5.88-jdk18-semeru-focal, 8.5-jdk18-semeru-focal, 8-jdk18-semeru-focal
8.5.88-jre18-semeru-focal, 8.5-jre18-semeru-focal, 8-jre18-semeru-focal

I understand the challenge with many different variations to support. One thing I would like to point out is that all the variations mentioned but one are variations of OpenJDK using the Hotspot JVM. From that perspective, they are quite similar (even intentionally, perhaps). But IBM Semeru Runtimes Open Edition is the only JDK variant that uses OpenJDK class libraries with the Eclipse OpenJ9 JVM. As such, it's a valuable variant simply for the significant difference it represents. OpenJ9 can provide different performance characteristics (faster startup and lower memory consumption) that some users might find attractive[1]. While it might not be practical to include all the different variations, adding an IBM Semeru Runtime Open Edition variant might be worth it.
I'm the chief architect for IBM Semeru Runtimes and a project lead at Eclipse OpenJ9 (and OMR) so if you have any questions, I would be happy to help.
[1] https://blog.openj9.org/2019/11/20/tomcat-tradelite7-performance-of-openj9-with-default-shared-cache/

To continue on the last comment, OpenJ9 has important performance features for s390x and we would really appreciate a docker container with Semeru for 390x which is currently not available.

Honestly, the number of tags showing on the Dockerhub doesn't scare me, nor do I think it's getting out of control. There is a significant value in all the variants. Just as we are picky and only want Corretto on AL, there are specific reasons why others want other Xs on Ys.
If the tag list is to be trimmed, I'd argue it can be trimmed horizontally. I.e., :

10.1.8-jdk20-temurin-jammy,
10.1-jdk20-temurin-jammy,
10-jdk20-temurin-jammy
jdk20-temurin-jammy
10.1.8-jdk20-temurin,
10.1-jdk20-temurin,
10-jdk20-temurin,
jdk20-temurin,
10.1.8-jdk20,
10.1-jdk20,
10-jdk20,
jdk20

I see value in having 10.1.8, 10.1 and 10 variants.
The rest seem to be excessive. I.e., it assumes that:

JDK 20 is the "default", if not specified
Tomcat 10 is the default, if not specified
Temurin is the default JVM, if not specified
Jammy is the default distro, if not specified

I think that folks that use those would need to say, at least, which major version of Tomcat they want, which VM and distro they want. Things are just too different between the variations here, and one truly doesn't care they might as well pick randomly. So this list can be shortened to:

10.1.8-jdk20-temurin-jammy,
10.1-jdk20-temurin-jammy,
10-jdk20-temurin-jammy

And the last one is questionable as well, as there is enough incompatibilities between minor versions of Tomcat, it should be expected that it's specified.
Of course, reducing this list now would throw a wrench to folks who're already using the shortcuts, as they would stop pulling the "latest" things for them.

Regarding the maintenance - I agree that this is a problem, considering just the changes that were needed for yum->dnf support. I think that the current framework is not too maintenance-friendly. I think that if the script was broken up into individual script files for each distro, things would be easier. If a distro stops working, the builds are not published (for that distro) until somebody goes and fixes it. Yes, there will be more duplication in the script code, but it will be offset by not having the as much work in the JQ files, and reduced regressions.

Any luck we can have the alpine corretto images as there is a vulnerability every week now

We are looking to migrate our applications to Spring 6, servlet spec 6.0 and thus Tomcat 10.1.x, however since we are on AWS we would be looking to use Corretto jdk 17 and Amazon Linux.
Might there be an update as to where the support matrix is headed @tianon?

I'm not really at a place to do that validation work right at the moment, but if someone else could take one of the Dockerfiles in this PR and validate that the changes necessary to support it are minimal and work (ideally just changing FROM :crossed_fingers:), I'd be willing to consider adding it to my matrix here.

Regarding my last request, in case you missed it: https://github.com/infosiftr/tomcat/pull/2

authors: CL-Jeremy aavileli cjsr mstoodle offerbaruch tianon veselov

repo: docker-library/tomcat


text:
How do I get deleted file list and file sizes from docker slim

How do I get delete files and file sizes from docker slim.

Are you looking for a convenient way to list the files not included in the minified image?
This might be a nice feature. For now you can accomplish this by doing a diff between the files in the original and the minified container images.

Hi - How can I run the eclipse source code and figure out to list the files removed from the minified image.
So I can create a new docker-slim version to run which can give the list.

Moving this to the wishlist

authors: aparnaedu kcq

repo: docker-slim/docker-slim


text:
fix result-deployment image to use training/voting-result:v1.

result-deployment uses incorrect training/voting-app:v1. it causes voting page only, no result page.

@cl-lab-k thanks for the catch!

authors: cl-lab-k ghobrial

repo: docker-training/example-voting-app


text:
Meet Sever Error 408 when pushing a large layer to registry v2

When the docker 1.7.1 client try to pushing a very large layer(1.5GB),I get server error message like this:
4b510ee63e03: Image already exists
a1e14256259e: Image already exists
5c305d14d4ac: Image already exists
91606cc1fef1: Buffering to Disk
91606cc1fef1: Image push failed
Error pushing to registry: Server error: 408 trying to push xobo/bjtu-xiaobo blob - sha256:415c0918210d111d42e7f534e5b9225c5ab7048e5d80667b4fedc44f2a7d6fa4

The error layer size is 1.5GB. I use top and nload to monitor cpu and network metrics, it seems that the client has finished archiving the layer as CPU usage lows down and start transmitting through network, a few seconds after the network traffic lows down(not sure all data has been transmitted), client print the previous error message.
Every time I repeat pushing this image or some image with big layer over 1.5 GB, same error occurs to me. However, pushing to registry 0.9 is ok. Both registry has s3 as backend storage.
I am not sure the problem is on client side or registry side.
Here is my environment info:
ubuntu@ip-172-31-9-142:~$ sudo docker version
Client version: 1.7.1
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 786b29d
OS/Arch (client): linux/amd64
Server version: 1.7.1
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 786b29d
OS/Arch (server): linux/amd64

buntu@ip-172-31-9-142:~$ sudo docker info
Containers: 0
Images: 2787
Storage Driver: devicemapper
 Pool Name: docker-202:80-1048577-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 90.39 GB
 Data Space Total: 107.4 GB
 Data Space Available: 16.99 GB
 Metadata Space Used: 144.2 MB
 Metadata Space Total: 2.147 GB
 Metadata Space Available: 2.003 GB
 Udev Sync Supported: false
 Deferred Removal Enabled: false
 Data loop file: /mnt/docker/devicemapper/devicemapper/data
 Metadata loop file: /mnt/docker/devicemapper/devicemapper/metadata
 Library Version: 1.02.82-git (2013-10-04)
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.19.8-031908-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 2
Total Memory: 3.66 GiB
Name: ip-172-31-9-142
ID: 6NIM:UYQW:LB5L:SO7N:7RHR:NM34:ZQWD:UNW6:GMJV:UBI2:MBIR:3B2S
WARNING: No swap limit support

ubuntu@ip-172-31-1-2:~$ sudo docker exec registry registry -version
registry github.com/docker/distribution v2.0.1

I have solve this.
The root cause is that the process time of calculating checksum and writing to s3 is over 1 minute.There is no data transferring between registry and engine during this time, so the load balancer with default 1 minute timeout will close the connection.However the error message "Server error: 408" is really misleading.
Feel free to close it now.

@oilbeater I assume your load balancer is sending the 408?
What do you suggest should be done to make this feel/look better?
Thanks.

@dmp42 I use aws lb and have not investigated the close mechanism.
However, as the one trip time between registry and engine may takes huge time when a layer size is big, there should be some keepalive message during this period. Otherwise in other situation the link may still be closed due to router, switch or other network device and it is more difficult to debug.

I set the ELB idle_timeout to 3600 seconds, and still get a 408 error from a 1.6.2 client pushing to registry v2.1.1 (via an nginx proxy).
Nginx is logging a 499 which suggests that the client is giving up.

@mrwacky42 very large layer?
What happens if you push directly to the registry server (no ELB and no NGINX is the middle)?

@dmp42  - The 1.6.2 client is CircleCI. I do not have any 1.6.x docker clients otherwise available to me.
But yes, a very large layer.

@mrwacky42 ok for docker version - still, can you try pushing directly to your registry, instead of ELB+nginx+registry?

@dmp42  Yes. In fact, with 1.8.2 client I am able to push from an AWS instance to the ELB (and bypassing ELB).
Further, I've just discovered that I did not actually change the idle_timeout on the ELB, so I'm testing again.

@oilbeater Thank you so much for the info. I was also getting the the same issue with the docker. I have just increased the time out of the load balancer in amazon from 60 seconds to 500 seconds. it really did work out. I was really confused with the error of 408.
Received HTTP code 408 while uploading layer: ""
The image size which it was pushing was big 558.9 and it stucked around 558.4.

repo: docker/distribution


text:
404 at /docker-ee-for-windows/install/

URL: /docker-ee-for-windows/install/

No download possible


text:
Mismatching docker-compose.yml mapped port and localhost port.

File: get-started/part3.md
Error on the docu.
In the docker-compose.yml code, the 80 "internal" port of the service is mapped to the 4000 external port on localhost
 ports:
      - "4000:80"

A few lines after, the documentation says:

You can run curl -4 http://localhost several times in a row, or go to that URL in your browser and hit refresh a few times."

The documentation needs to indicate the 4000 port on the curl parameter.
curl -4 http://localhost:4000

Closing this ticket due to its age, and the impending refactor. If you think this is in error, feel free to reopen. Thanks!

authors: L-Hudson ghost


text:
Mention the necessity of --network host

This example is, honestly, idiotic, because it doesn't even explain what task it solves.
No one needs to "just pass *_PROXY envs to created containers", as it is useless by itself.
People want to make containers have internet access via proxy, but the proxy is usually on the host machine's host or networks, not on docker containers networks!
The example described in the docs just tells how to configure containers query THEIR 127.0.0.1:3001, not host machine's 127.0.0.1:3001. This is useless!

Proposed changes

I improved docs by adding an important mention of an extra step that is necessary to solve a common task (that the article should've explained how to solve, but instead failed to).
Unreleased project version (optional)

Related issues (optional)

@Drugoy Apologies for the inconvenience. We are looking to update this topic. Would it help if we add an example with a proxy server that has a different IP address? Thanks

@usha-mandya
Probably it'll be better the way you suggested, but then please mention that this IP address should be outside container's docker network, because otherwise it's expected that you run your own proxy in a sibling container in the same docker network (which is unusual).

@Drugoy The changes are now live on the prod site. I'm closing this ticket here for that reason. Feel free to continue the conversation after I close. Thanks.

authors: Drugoy usha-mandya


text:
Guide on how to upgrade UCP via UI

Fixes #1577
Signed-off-by: Tom Barlow tomwbarlow@gmail.com

@joaofnfernandes Updated as per your comment :smile:


text:
Update install-offline.md

Describe the proposed changes

Project version

Related issue

Related issue or PR in another project

Please take a look

Need to alert users that they need image:tag when installing from offline bundle.

Deploy preview processing.
Built with commit febecdf09f1f2029d7423c6c5860f4101009e1aa
https://app.netlify.com/sites/docker-docs/deploys/5820a2e3a7e2d2668f9cea3a

ping @joaofnfernandes

LGTM, thanks for contributing!

authors: banjot joaofnfernandes johndmulhausen


text:
Updating the minimum memory step 4GB->2GB

SQL Server can now run on a minimum of 2GB now
https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-setup?view=sql-server-linux-2017#system

Proposed changes

Unreleased project version (optional)

Related issues (optional)

Thanks for updating this. Let's ship it.

authors: joaofnfernandes vin-yu


text:
How to limit containers to only listen to vpn server

Output of docker version:
Client:
 Version:      1.10.1
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   9e83765
 Built:        Thu Feb 11 19:14:21 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.10.2
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   c3959b1
 Built:        Mon Feb 22 22:37:33 2016
 OS/Arch:      linux/amd64

Output of docker info:
Containers: 7
 Running: 6
 Paused: 0
 Stopped: 1
Images: 54
Server Version: 1.10.2
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 135
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 4.1.18-boot2docker
Operating System: Boot2Docker 1.10.2 (TCL 6.4.1); master : 611be10 - Mon Feb 22 22:47:06 UTC 2016
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.858 GiB
Name: doctify-dev
ID: HLTD:ZB4A:DRIQ:Y4AO:ZCMF:7MFK:KJU3:FHII:AWMS:YXVD:BO4W:JHVG
Debug mode (server): true
 File Descriptors: 74
 Goroutines: 113
 System Time: 2016-03-03T10:35:14.794778199Z
 EventsListeners: 1
 Init SHA1:
 Init Path: /usr/local/bin/docker
 Docker Root Dir: /mnt/sda1/var/lib/docker
Username: devotox
Registry: https://index.docker.io/v1/
Labels:
 provider=virtualbox

My Compose File:
version: '2'
volumes:
    tmp: {}
services:
    openvpn:
        image: kylemanna/openvpn
        ports:
            - 1194:1194/udp
        volumes:
            - ../openvpn:/etc/openvpn
        cap_add:
            - NET_ADMIN
        devices:
            - /dev/net/tun
    server:
        build:
            context: ../nginx
            dockerfile: Dockerfile
        volumes:
            - ../security:/var/app/current/security
            - ../sslcert:/var/app/current/sslcert
            - ../shared:/var/app/current/shared
            - ../nginx:/etc/nginx
            - /var/log/nginx
            - tmp:/tmp
        volumes_from:
            - api
            - intranet
        ports:
            - 80
            - 443
        networks:
            - container:openvpn
        extends:
            service: base
            file: ../shared/base.yml
    api:
        command: bash -c "gulp start-prod | tee -a /var/log/nodejs/api/api.log"
        build:
            context: ../api
            dockerfile: Dockerfile
        volumes:
            - ../sslcert:/var/app/current/sslcert
            - /var/app/current/api/node_modules
            - ../shared:/var/app/current/shared
            - ../api:/var/app/current/api
            - /var/log/nodejs/api
            - /tmp/api
        ports:
            - 3000
            - 3001
        extends:
            service: base
            file: ../shared/base.yml
        networks:
            - container:openvpn
    intranet:
        command: bash -c "ember build dist | tee -a /var/log/nodejs/intranet/intranet.log"
        build:
            context: ../intranet
            dockerfile: Dockerfile
        volumes:
            - /var/app/current/intranet/bower_components
            - /var/app/current/intranet/node_modules
            - ../intranet:/var/app/current/intranet
            - ../shared:/var/app/current/shared
            - /var/log/nodejs/intranet
            - /tmp/intranet
        extends:
            service: base
            file: ../shared/base.yml
    registrator:
        image: devotox/registrator
        volumes:
            - /var/run/docker.sock:/tmp/docker.sock
        depends_on:
            - consul
        links:
            - consul
        extends:
            service: base
            file: ../shared/base.yml
    consul:
        command: -data-dir=/data -ui-dir=/ui -server -bootstrap
        image: progrium/consul
        ports:
            - 53
            - 8301
            - 8302
            - 8300
            - 8400
            - 8500
            - 53/udp
            - 8301/udp
            - 8302/udp
        extends:
            service: base
            file: ../shared/base.yml
        networks:
            - container:openvpn
    consul-template:
        image: masm/consul-template
        command: >
            -consul consul:8500
            -template /etc/nginx/templates/upstream_servers.ctmpl:/etc/nginx/conf.d/upstream_servers.conf
            -template /etc/nginx/templates/upstream_stream_servers.ctmpl:/etc/nginx/conf.d/streams/upstream_servers.conf
        volumes:
            - /var/run/docker.sock:/tmp/docker.sock
        volumes_from:
            - server
        depends_on:
            - consul
            - registrator
        links:
            - consul
        extends:
            service: base
            file: ../shared/base.yml

My issue is that i am looking for a way to allow connection to to the services behind using the vpn server. I can connect to the VPN server easily and i can connect to my services. but i cannot figure out how to only allow connection trhough the vpn. I thouth the networks: -container:openvpn was the solution but alas i seem to be wrong

@devotox thanks for opening this issue, but the issue tracker is not meant as a support forum, only for reporting bugs, feature requests and pull-requests.
Could you use either of the following;

forums.docker.com
the #docker IRC channel on freenode
StackOverflow

Those are more suitable for these kind of questions.
I'm closing this issue, but feel free to comment after I've closed

authors: devotox thaJeztah

repo: docker/docker


text:
add link between -D and --log-level=debug back in

Due to popular demand :-)
See #11965
Signed-off-by: Doug Davis dug@us.ibm.com

@jfrazelle @tiborvass

LGTM

LGTM

authors: LK4D4 duglin tiborvass


text:
do not trim one char from {{.Names}} each time it is used in --format

fix #21772
ping @danielhoherd  @thaJeztah @calavera

LGTM

LGTM windows failures look unrelated

LGTM

Actually, the Windows failure is genuine;
17:23:22 ----------------------------------------------------------------------
17:23:22 FAIL: docker_cli_ps_test.go:659: DockerSuite.TestPsNamesMultipleTime
17:23:22
17:23:22 docker_cli_ps_test.go:660:
17:23:22     dockerCmd(c, "run", "--name=test1", "-d", "busybox", "top")
17:23:22 github.com/docker/docker/integration-cli/_test/_obj_test/docker_utils.go:630:
17:23:22     ...open github.com/docker/docker/integration-cli/_test/_obj_test/docker_utils.go: The system cannot find the path specified.
17:23:22 ... Error: Cannot use 'busybox top' in tests on Windows. Use runSleepingContainer()
17:23:22

it should use runSleepingContainer to start the container

@thaJeztah I'll update asap

@thaJeztah updated

thanks

Al green! Merging :)

authors: cpuguy83 duglin thaJeztah vieux


text:
vendor: update swarmkit to 8a761950f

This also brings in swarmkit root key size change that should help with arm ci.
Also updated some swarmkit dependencies to match swamkit versions.

@aaronlehmann Any idea what happened in the experimental there? It is TestSwarmInit that inits the daemon, force leaves and then runs init again. Second init seems to block. In daemon logs there are failed attempts for the agent to connect for 5 min https://gist.github.com/tonistiigi/3e0fa78d6c5df07b7232c82976794344#file-daemon-log-L227 and in stacktrace manager.Run seems to be stuck at handleLeadershipEvents  https://gist.github.com/tonistiigi/3e0fa78d6c5df07b7232c82976794344#file-daemon-stack-L415 Not sure why it can't select leader if this is the only node. Force leave should have cleared all the state from disk.

@tonistiigi: Actually manager.Run is not running. There are two handleLeadershipEvents started by different manager.Run invocations which are left over. This is unexpected, because the channel they loop over should be closed by raft when it shuts down.
I wonder if this could be related to https://github.com/docker/swarmkit/pull/1369.

@aaronlehmann manager.Run completing but not shutting down node can be explained by https://github.com/docker/swarmkit/pull/1283#issuecomment-237980007

Experimental issue is tracked in docker/swarmkit#1421 and our test works around it atm. That case should not easily happen in real-world use-cases. PTAL @aaronlehmann @LK4D4

LGTM

LGTM

authors: LK4D4 aaronlehmann tonistiigi


text:
Add a transport that uses UDP or DTLS when multiplexing streams

As I wasn't at the DockerCon I haven't heard how libchan is going to be used, but if multiple streams on top of these transports is a goal I suggest adding a datagram-based transport as well.
The reason is because of head-of-line blocking.
Obviously, HTTP/2 or SPDY is already better than HTTP/1.x or something like WebSocket at dealing with multiple streams.
But at the TCP level you can still get head-of-line blocking because if packets are lost they can not be reordered.
It's similar to the TCP tunneling in TCP problem:
http://sites.inka.de/~W1011/devel/tcp-tcp.html
It is also (one of ?) the reasons https://en.wikipedia.org/wiki/QUIC is being developed.
An other example WebRTC which uses DTLS ('SSL'/TLS over UDP) at the lowerlevel and SCTP as the datachannel protocol for the multiplexing.
Obviously I wouldn't suggest implementing all of WebRTC, it's a pretty big specification.
But they are just examples of current protocols that already do this.

What's the status of it?

@sheerun if you know of any Go libraries implementing QUIC I would love to give it a try. Also feel free to advocate for an alternative. As it stands now most this specifications are still fluid and Go implementations are not there.

authors: Lennie dmcgowan sheerun

repo: docker/libchan


text:
Give hostname and domain to drivers

In weave "classic" we register containers that have a weave IP and a hostname with DNS, so they can be looked up across the weave network. In the libnetwork driver model, the driver is told neither the container ID nor the hostname, so this feature is not viable.
I'm not sure what the preferred means would be; but being given the hostname and domain when say, creating an endpoint, could make DNS registration possible again.

If there is a "service model" interpretation then that is fine -- we're not hung up on using hostnames specifically.

@mavenugo @mrjana Any comments? There are workarounds for this, but they are, frankly, horrific -- they involve remembering state gleaned from the docker event stream and correlating it with CreateEndpoint/Join calls. It would be better to just be told the information when it is pertinent.

Actually having had a better look at the docker integration, I see that they are included in the join options, so perhaps this issue is redundant.

Actually having had a better look at the docker integration, I see that they are included in the join options, so perhaps this issue is redundant.

(sorry, wrong button; but please close if you think this issue is already addressed)

I see that they are included in the join options, so perhaps this issue is redundant.

No it's not redundant, those only set fields in the container config, and don't get given to the driver.

I've made a small, ragged patch in my own fork of docker, that supplies these as generic options on the CreateEndpoint call; but only for endpoints created as part of docker run --net=.... This is on the assumption that those endpoints are for "simple networking", rather than participating in the upcoming service discovery abstraction. (https://github.com/squaremo/docker/commit/8014c3154f10372ca3980b6a2741b4bde090db47)
I'll need to rejig it to fit with docker/docker#13441.

@squaremo It has been detected that this issue has not received any activity in over 6 months. Can you please let us know if it is still relevant:

For a bug: do you still experience the issue with the latest version?
For a feature request: was your request appropriately answered in a later version?

Thank you!
This issue will be automatically closed in 1 week unless it is commented on.
For more information please refer to https://github.com/docker/libnetwork/issues/1926

authors: GordonTheTurtle squaremo

repo: docker/libnetwork


text:
Change --boot2docker flags and filenames etc. to be OS-agnostic

Right now we have flags and code such as --virtualbox-boot2docker-url which specifically mention boot2docker, but they are being used for other, more OS-agnostic things now.  The names should be changed to be more general.  For instance, to --virtualbox-image.  Docs, tests, and things will need to be updated as well.
cc @ibuildthecloud @ehazlett @SvenDowideit

+1

This also makes more sense with the recent addition of new provisioners (RHEL, Rancher, etc).

+1
Although, could it be --virtualbox-iso instead? Might be confused with a disk image where we specifically mean an ISO image in this context.

@hairyhenderson good point -- +1

@hairyhenderson Sounds good to me.

authors: ehazlett hairyhenderson nathanleclaire

repo: docker/machine


text:
Too many retries waiting for SSH to be available

Running the following:
docker-machine create --driver amazonec2 --amazonec2-access-key <access key> --amazonec2-secret-key <secret key> --amazonec2-ami ami-06963965 --amazonec2-region ap-southeast-1 --amazonec2-vpc-id <vpc id> --amazonec2-zone a --amazonec2-security-group <security group> --amazonec2-instance-type t2.micro --amazonec2-root-size 8 <name>

Fails with:
Waiting for SSH to be available...
Error creating machine: Error detecting OS: Too many retries waiting for SSH to be available.  Last error: Maximum number of retries (60) exceeded

Executing docker-machine version:
docker-machine version 0.9.0, build 15fd4c7

Could you provide more information about the OS and version, and could you try the command with --debug option,  such as docker-machine --debug create --driver amazonec2 ..., and paste the debug information here? Thanks.

It is resolved with AWS Internet Gateway.


text:
GPU support for swarm on Mesos

Since Mesos 1.0 will add GPU support, I'm willing to see GPU support for swarm on Mesos. Is there any progress on this?

Closing this issue in light of https://github.com/docker/swarm/pull/2853

authors: liyubobj nishanttotla

repo: docker/swarm


text:
raft: Don't panic on Campaign failure

Campaign used to be passed a context that was derived from Background
(n.Ctx). Awhile ago, n.Ctx was removed, and this call to Campaign was
changed to use the context passed to Run.
This context may be cancelled before Campaign is complete. This leads to
a panic.
Remove the panic, because it can trigger accidentally and it serves no
purpose.
cc @aboch @LK4D4 @cyli

Would it make sense to continue to panic, or at least to log, if the context was not cancelled?

To reproduce, concurrently run docker swarm leave --force and docker swarm init --force-new-cluster on the manager (one node cluster)
INFO[0098] shuting down certificate renewal routine      module="node/tls" node.id=idm1vlel5xx8d6hxk6jj0d04o node.role=swarm-manager
INFO[0098] Stopping manager
ERRO[0098] LogBroker exited with an error                error="context canceled"
INFO[0098] Manager shut down
ERRO[0098] cluster exited with error: rename /var/lib/docker/swarm/certificates/.tmp-swarm-root-ca.crt903403396 /var/lib/docker/swarm/certificates/swarm-root-ca.crt: no such file or directory
ERRO[0098] Error initializing swarm: rename /var/lib/docker/swarm/certificates/.tmp-swarm-root-ca.crt903403396 /var/lib/docker/swarm/certificates/swarm-root-ca.crt: no such file or directory
ERRO[0098] Handler for POST /v1.25/swarm/init returned error: rename /var/lib/docker/swarm/certificates/.tmp-swarm-root-ca.crt903403396 /var/lib/docker/swarm/certificates/swarm-root-ca.crt: no such file or directory
INFO[0100] shuting down certificate renewal routine      module="node/tls" node.id=2o5glg5r5r14t024um7gq9udz node.role=swarm-manager
INFO[0100] Stopping manager
INFO[0100] Listening for local connections               addr="/var/run/docker/swarm/control.sock" proto=unix
INFO[0100] Listening for connections                     addr="[::]:2377" proto=tcp
INFO[0100] 7469a6b4cf1788a3 became follower at term 0
INFO[0100] newRaft 7469a6b4cf1788a3 [peers: [], term: 0, commit: 0, applied: 0, lastindex: 0, lastterm: 0]
INFO[0100] 7469a6b4cf1788a3 became follower at term 1
INFO[0100] Manager shut down
panic: raft: cannot campaign to be the leader on node restore

goroutine 4317 [running]:
panic(0x16c5780, 0xc4219e0860)
    /usr/local/go/src/runtime/panic.go:500 +0x1a1
github.com/docker/docker/vendor/github.com/docker/swarmkit/manager/state/raft.(*Node).Run(0xc421c94900, 0x250eae0, 0xc421b67340, 0x0, 0x0)
    /go/src/github.com/docker/docker/vendor/github.com/docker/swarmkit/manager/state/raft/raft.go:509 +0x9bb
github.com/docker/docker/vendor/github.com/docker/swarmkit/manager.(*Manager).Run.func4(0xc4200f06e0, 0x250eae0, 0xc421b66cc0, 0xc42220f380)
    /go/src/github.com/docker/docker/vendor/github.com/docker/swarmkit/manager/manager.go:390 +0x53
created by github.com/docker/docker/vendor/github.com/docker/swarmkit/manager.(*Manager).Run
    /go/src/github.com/docker/docker/vendor/github.com/docker/swarmkit/manager/manager.go:396 +0x10ed

Would it make sense to continue to panic, or at least to log, if the context was not cancelled?

I don't think so. Campaign calls step, which is a simple function that doesn't really have any failure modes:
// Step advances the state machine using msgs. The ctx.Err() will be returned,
// if any.
func (n *node) step(ctx context.Context, m pb.Message) error {
        ch := n.recvc
        if m.Type == pb.MsgProp {
                ch = n.propc
        }

        select {
        case ch <- m:
                return nil
        case <-ctx.Done():
                return ctx.Err()
        case <-n.done:
                return ErrStopped
        }
}

Ah ok, thanks.  LGTM

Current coverage is 54.53% (diff: 100%)

Merging #1848 into master will increase coverage by <.01%

@@             master      #1848   diff @@
==========================================
  Files           102        102
  Lines         17051      17050     -1
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           9299       9299
+ Misses         6615       6613     -2
- Partials       1137       1138     +1

Powered by Codecov. Last update 593e4d3...901187e

LGTM

authors: LK4D4 aaronlehmann aboch codecov-io cyli

repo: docker/swarmkit


text:
Rerun vndr with latest version of tool

That is, https://github.com/LK4D4/vndr/commit/e55af28bae0fa02cd6cb6b9f612b6ea9852ba77a.
Compared with whatever version was used previously this picks up many more
files which may contain licensing information.
Signed-off-by: Ian Campbell ian.campbell@docker.com

In #1965 I'm vendoring a fair bit of stuff and all these new files made it look like even more...

Codecov Report

Merging #2006 into master will decrease coverage by -0.22%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #2006      +/-   ##
==========================================
- Coverage   53.92%   53.71%   -0.22%
==========================================
  Files         109      109
  Lines       18978    18978
==========================================
- Hits        10234    10194      -40
- Misses       7514     7542      +28
- Partials     1230     1242      +12

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f12d7da...72932cb. Read the comment docs.

LGTM

LGTM

authors: aaronlehmann codecov-io cyli ijc25


text:
Lots of connections causes Unix.select to fail with EINVAL

On OSX we see fatal errors from Lwt_main.run like
proxy: internal error, uncaught exception:
       Unix.Unix_error(Unix.EINVAL, "select", "")
       Raised by primitive operation at file "src/unix/lwt_engine.ml", line 371, characters 26-60
       Called from file "src/unix/lwt_engine.ml", line 312, characters 8-39
       Called from file "src/unix/lwt_main.ml", line 41, characters 8-82

This appears to be related to [ocsigen/lwt#222]

It looks like even libev relies internally on select on OS X:
(libev) select: Invalid argument

I think we should switch to libuv as Windows is a first-class target via IOCP, it's used by node.js and they seem to know all the tricks. Apparently libuv started off as a wrapper around libev which also supported Windows via IOCP, but recently the libev dependency has been removed and it's now a standalone library.
There seem to be several incomplete bindings:

https://github.com/trevorsummerssmith/ocaml-libuv (using Ctypes)
https://github.com/fdopen/uwt (hand-written, tuned C code)

There's a discussion comparing the two here: https://www.reddit.com/r/ocaml/comments/2wop3h/ctypes_based_bindings_to_libuv/
It's probably worth starting with uwt initially since the author is the person who maintains the OCaml on Windows port we're using and hopefully the Windows support is therefore first-class.

repo: docker/vpnkit


text:
Added a drag event notification. Reason: the layout changed so a user…

… might want to save it as soon as order of panels changes.

Thanks. But can you fix whitespace so that your addition matches its surrounding before we merge it?

Am 10.10.2015 um 06:45 schrieb Lex Li:

Thanks. But can you fix whitespace so that your addition matches its
surrounding before we merge it?
—
Reply to this email directly or view it on GitHub
https://github.com/dockpanelsuite/dockpanelsuite/pull/322#issuecomment-147037211.

Yes, sorry. Forgot about that. Will check that in on monday!

Using .editorconfig now so that further enhancements on my side will automatically use spaces instead of tabs :-)

Thanks, @Romout . The white space issue has been a long time burden for this project (multiple developers use different styles at different stages).
I will soon publish a contributing guide to document out the tips. We will try to fix such issues bit by bit (align with new features and bug fixes), so as to avoid a sudden change on all files which might completely mess up GitHub inline diff view.

@roken what's your feedback on this PR? I think it is a good addition.

authors: Romout lextm

repo: dockpanelsuite/dockpanelsuite