Earlier quoted context omitted.
Core library of what programming language, if you haven't picked a language yet?
I think the OP's talking about stuff like Qt, OpenGL, BLAS/LAPACK.
[deleted]
Mystery meat OpenJDK builds strike again
21–30 of 56 posts
Re: Mystery meat OpenJDK builds strike again
#22Unrelated, but one thing that's confused me, as someone who doesn't really use Docker. I don't think of a programming language as being the thing upon which I would base my layers of containers. My expectation, as someone coming from not-containers, would be that I should first start with a core-libraries container, _then_ a language container, and then packages on top. Having this clarity of composition, I think, is…
> It also makes it easier to know when a layer needs to be upgraded, for example because of a security issue.
This doesn't really apply. You rebuild when one of the dependencies needs to be updated. It didn't matter how deep it is into the stack or which position.
Re: Mystery meat OpenJDK builds strike again
#23Not completely related, but this is one of the reasons why I prefer to add commits bumping the version number when a release is made instead of before–it means that any builds made from source don't have version number they shouldn't.
It took me a long time to understand why Maven uses version strings like 4.2.1-SNAPSHOT but this is exactly why it's useful. (The standard practice is to strip the "-SNAPSHOT" off for the release commit, then stick it back on for the next commit, but with a bumped minor version. Both commits are then pushed at once, so stuff built locally always is marked as a SNAPSHOT.)
The problem here is that Debian's OpenJDK maintainer removed the "work in progress" indicator string manually. No approach protects against this.
Re: Mystery meat OpenJDK builds strike again
#24This is indeed not the first time something like this happens and a good reason to get your openjdk builds from someone that has licensed the test suites and supports their builds.
I remember having weird issues a few years ago with builds for both Centos and Debian/Ubuntu where they first took ages to get release builds out and then made it worse by basing their builds of pre-release versions rather than actual stable releases. This was several months into the JDK 8 cycle. In their defense, JDK 8 had some nasty bugs early on. But still, a lot of this seemed accidental to me and not intentional.
You can get decent openjdk builds from Amazon, Azul and Red Hat. They each put in quite a bit of effort to ensure these builds are solid and tested and they each offer these builds for free they also each offer Docker images with their builds and make it very easy to use them. I've been using Azul docker images for quite some time.
Amazon particularly seems to have made an effort with their openjdk builds. If you read their commit log: https://github.com/corretto/corretto-8/commits/develop, you'll see a few backports of fixes from openjdk 9 and lots of efforts to get the packaging right. The last bug fix they added was from just a few months ago. I'm currently considering switching to this.
BTW. Oracle seems to have stepped away from this and only offers limited time support for their own JDKs which also cost money. So, not including them in this list on purpose. Unless you must use them (for legal/business reasons) and fully understand the legal situation that implies, you should avoid using them.
Re: Mystery meat OpenJDK builds strike again
#25A few emails later in the thread[0], it is noted... > ...who actually maintains the "official" Docker images for 8u and 11u? Github history for Dockerfiles points to no one I recognize from around OpenJDK. That, I think, is the main problem. [0]: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/0... Edit: Actually linking to source (which I should've done from the beginning…)
[deleted]
Re: Mystery meat OpenJDK builds strike again
#26This is indeed not the first time something like this happens and a good reason to get your openjdk builds from someone that has licensed the test suites and supports their builds. I remember having weird issues a few years ago with builds for both Centos and Debian/Ubuntu where they first took ages to get release builds out and then made it worse by basing their builds of pre-release versions rather than actual stab…
I'm thinking of moving us to the Azul images. I'm not actually that concerned about this myself, especially with the attention this is receiving, but I know I'm going to get my ear bent about it for the next few weeks.
Re: Mystery meat OpenJDK builds strike again
#27A few emails later in the thread[0], it is noted... > ...who actually maintains the "official" Docker images for 8u and 11u? Github history for Dockerfiles points to no one I recognize from around OpenJDK. That, I think, is the main problem. [0]: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/0... Edit: Actually linking to source (which I should've done from the beginning…)
Jikes
Re: Mystery meat OpenJDK builds strike again
#28The AdoptOpenJDK community (a consortium of vendors and users that produce business ready OpenJDK binaries) will work with the Debian maintainers to course correct this going forwards. If you’d like to get involved see https://AdoptOpenJDK.net
Re: Mystery meat OpenJDK builds strike again
#29[deleted]
Re: Mystery meat OpenJDK builds strike again
#30Ubuntu Java packages are a joke as well and I stopped using them when I was having issues with the OpenJDK-11 package from apt. It turned out the the package wasn't packaging Java 11, but Java 10 instead, with a fake name [0]. I didn't check but they might rely on bad Debian packages just like Docker.
---