NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
1f0a550b6d
kumquat-buildroot/package/openjdk-bin/openjdk-bin.hash

10 lines
601 B
Plaintext
Raw Normal View History

package/openjdk{-bin}: bump version to 17.0.1+12 OpenJDK 17 is a new LTS release, which leaves the Buildroot Config option of "LTS" and "LATEST" as a misnomer because both 11 and 17 are LTS releases. There are two options in this case: 1) Remove "LATEST" and update OpenJDK 11 to 17, and only support 17. 2) Change "LTS" to "11" and "LATEST" to "17" and only support the latest 2 LTS OpenJDK releases. After some discussion with Thomas Petazzoni and Peter Korsgaard, and testing, option 2 is the best course of action for a few reasons: - OpenJDK 11 and 17 have very long support cycles: - OpenJDK 11 has two years of Active and five years of security support left. - OpenJDK 17 has five years of Active and ten years of security support left. - Both OpenJDK versions build with the same parameters. - The maintenance cost of both versions is meager. - Both versions pass tests.package.test_openjdk without issue. Changes: - Change BR2_OPENJDK_VERSION_LATEST -> BR2_OPENJDK_VERSION_17 - Change BR2_OPENJDK_VERSION_LTS -> BR2_OPENJDK_VERSION_11 Signed-off-by: Adam Duskett <aduskett@gmail.com> [Peter: add Config.in.legacy, use BR2_PACKAGE_OPENJDK_ prefix] Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2021-11-04 19:47:26 +01:00
# https://github.com/adoptium/temurin17-binaries/releases
sha256 6ea18c276dcbb8522feeebcfc3a4b5cb7c7e7368ba8590d3326c6c3efc5448b6 OpenJDK17U-jdk_x64_linux_hotspot_17.0.1_12.tar.gz
package/openjdk-bin: new package Paradoxically, building OpenJDK requires a pre-existing JDK. This pre-existing JDK is called the "boot JDK." The boot JDK for building JDK major version N should be a JDK of major version N-1, so for building JDK11, JDK10 would be needed. This requirement is an issue when building on most distributions, as the host JDK tends to be JDK8. The AdoptOpenJDK project provides binaries that can act as the boot JDK to build the target JDK, which is what this package provides. Currently, only a x86_64 host is supported, for two reasons: 1) A 32bit x86 binary distribution is not available from AdoptOpenJDK 2) We didn't had access to a host machine using an architecture other than x86-64 The provided unpack200 has an invalid RPATH and relies on libzlib. When host-libzlib runs the install step, the following error is generated: *** ERROR: package host-libzlib installs executables without proper RPATH: *** $(HOST_DIR)/bin/unpack200 Because unpack200 is a deprecated tool, removing it after installation is safe and fixes the issue. Signed-off-by: Adam Duskett <Aduskett@gmail.com> [Thomas: - fix comments in the code - use the more usual "cp -dpfr" command to copy files over] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 15:31:24 +01:00
package/openjdk{-bin}: bump versions to 11.0.12+7 and 16.0.2+7 As the github repository has changed from github.com/AdoptOpenJDK/ to github.com/adoptium, both versions are updated in the same patch. Signed-off-by: Adam Duskett <aduskett@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2021-09-18 02:50:27 +02:00
# From https://github.com/adoptium/temurin11-binaries/releases
package/openjdk{-bin}: security bump LTS to version 11.0.13+8 Fixes the following security issues: - JDK-8163326, CVE-2021-35550: Update the default enabled cipher suites preference - JDK-8254967, CVE-2021-35565: com.sun.net.HttpsServer spins on TLS session close - JDK-8263314: Enhance XML Dsig modes - JDK-8265167, CVE-2021-35556: Richer Text Editors - JDK-8265574: Improve handling of sheets - JDK-8265580, CVE-2021-35559: Enhanced style for RTF kit - JDK-8265776: Improve Stream handling for SSL - JDK-8266097, CVE-2021-35561: Better hashing support - JDK-8266103: Better specified spec values - JDK-8266109: More Resilient Classloading - JDK-8266115: More Manifest Jar Loading - JDK-8266137, CVE-2021-35564: Improve Keystore integrity - JDK-8266689, CVE-2021-35567: More Constrained Delegation - JDK-8267086: ArrayIndexOutOfBoundsException in java.security.KeyFactory.generatePublic - JDK-8267712: Better LDAP reference processing - JDK-8267729, CVE-2021-35578: Improve TLS client handshaking - JDK-8267735, CVE-2021-35586: Better BMP support - JDK-8268193: Improve requests of certificates - JDK-8268199: Correct certificate requests - JDK-8268205: Enhance DTLS client handshake - JDK-8268506: More Manifest Digests - JDK-8269618, CVE-2021-35603: Better session identification - JDK-8269624: Enhance method selection support - JDK-8270398: Enhance canonicalization - JDK-8270404: Better canonicalization For more details, see the announcement: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-October/009368.html Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2021-10-30 21:02:05 +02:00
sha256 3b1c0c34be4c894e64135a454f2d5aaa4bd10aea04ec2fa0c0efe6bb26528e30 OpenJDK11U-jdk_x64_linux_hotspot_11.0.13_8.tar.gz
package/{openjdk, openjdk-bin}: add support for building either lts or latest As Java is used quite a bit in the enterprise world, having the option to build the LTS version of OpenJDK is quite convenient and also a requirement for many companies wanting to use Java. As such, there are three options: 1) Continue only to support the latest version of OpenJDK. 2) Downgrade our existing OpenJDK package from 14 to 11. 3) Add an option to support either OpenJDK 11 or 14. OpenJDK 11 and 14 currently have: - The same configure options. - The same license files and hashes for those license files. - The same dependencies. - The same method to build and install. As such, supporting both 11 and 14 is not only an easy option to add to Buildroot, but also a nice feature for users who wish to use Java in an embedded environment with a company that mandates the use of the LTS version. To make it explicit that this choice really is about LTS vs. latest, and not about 11 vs. 14, the options are really named with LTS and LATEST, so that future defconfigs will not have to migrate when the versions changes (e.g. we update from 14->15, or from 11 to the next LTS). Signed-off-by: Adam Duskett <Aduskett@gmail.com> [yann.morin.1998@free.fr: - keep latest as the default, for existing defconfigs - rename options: drop numbers, use LTS and LATEST ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-04-22 21:21:18 +02:00
package/openjdk-bin: new package Paradoxically, building OpenJDK requires a pre-existing JDK. This pre-existing JDK is called the "boot JDK." The boot JDK for building JDK major version N should be a JDK of major version N-1, so for building JDK11, JDK10 would be needed. This requirement is an issue when building on most distributions, as the host JDK tends to be JDK8. The AdoptOpenJDK project provides binaries that can act as the boot JDK to build the target JDK, which is what this package provides. Currently, only a x86_64 host is supported, for two reasons: 1) A 32bit x86 binary distribution is not available from AdoptOpenJDK 2) We didn't had access to a host machine using an architecture other than x86-64 The provided unpack200 has an invalid RPATH and relies on libzlib. When host-libzlib runs the install step, the following error is generated: *** ERROR: package host-libzlib installs executables without proper RPATH: *** $(HOST_DIR)/bin/unpack200 Because unpack200 is a deprecated tool, removing it after installation is safe and fixes the issue. Signed-off-by: Adam Duskett <Aduskett@gmail.com> [Thomas: - fix comments in the code - use the more usual "cp -dpfr" command to copy files over] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-02-05 15:31:24 +01:00
# Locally calculated
package/{openjdk, openjdk-bin}: bump version to 14.0.1+7 Signed-off-by: Adam Duskett <Aduskett@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-04-22 21:21:17 +02:00
sha256 4b9abebc4338048a7c2dc184e9f800deb349366bdf28eb23c2677a77b4c87726 legal/java.prefs/LICENSE
sha256 a44eb7b5caf5534c6ef536b21edb40b4d6babf91bf97d9d45596868618b2c6fb legal/java.prefs/ASSEMBLY_EXCEPTION
Reference in New Issue Copy Permalink