jdk8u322 release and packaging
Andrew Hughes
gnu.andrew at redhat.com
Fri Feb 4 04:22:29 UTC 2022
On 22:07 Sat 22 Jan , Thorsten Glaser wrote:
> Hi,
>
> I’m currently packaging openjdk-8 for Debian (unstable, where
> it is tested for LTS/ELTS updating older releases). I have
> taken it over from the previous maintainer, but I am “mostly”
> keeping this alive.
>
Welcome to OpenJDK maintenance :-)
> I see that the 8u322 release (which I had put into my calendar
> https://wiki.openjdk.java.net/display/jdk8u/Main#Main-Timelines
> from ↑) seems to be delayed because of repository changes.
>
No, it was delayed a little to allow time for the large number
of security patches in the release to be fully tested. The changes
themselves were pushed to the repositories on the 18th, to allow
others to test as well. This was a relatively moderate security
update, and so we believe allowing this extra time to be the
preferred course of action, rather than running the risk of
making a release with regressions.
The transition to the new Mercurial monorepository took place
back at the end of November and didn't affect the security
update. If anything, it was a little easier working with
one repository rather than over half a dozen.
> These repository changes are a problem. The packaging depends
> heavily on being able to download the individual hg releases’
> tarballs, plus aarch32 and aarch64-shenandoah, separately and
> put them together in suitable ways depending on the architecture
> building for.
>
I'm not familiar with how each vendor chooses to package OpenJDK.
Source code repositories are primarily targeted at developers, who
need to work with them on a daily basis. The use of multiple
Mercurial repositories, with some patches needing to be duplicated
across all of them, has been causing extra work for those working
on 8u for some time. Having a completely different process for 8u
compared to later maintained versions (11u, 13u, 15u, 17u) - which
are now all handled via GitHub pull requests - further impedes work
on 8u.
It's also worth noting that 7u decided to follow us down the same
route in December for similar reasons.
We have tried to minimise the effect of this on downstream consumers.
I myself handle packaging for Fedora & RHEL, as well as still
maintaining IcedTea for 7u & 8u, so I have considerable experience
of the packaging side.
Primarily, we provide a release tarball for downstream consumers,
so they do not have to care about the source code repositories
at all. The tarball for this release [0] and the last [1] only
differ by a number of new files and directories being added:
$ tar -xJf /home/downloads/java/drops/openjdk8/openjdk8u312-ga.tar.xz
$ tar -xJf /home/downloads/java/drops/openjdk8/openjdk8u322-ga.tar.xz
$ pushd jdk8u312-ga; find | sort > /tmp/8u312 ; popd
$ pushd jdk8u322-ga; find | sort > /tmp/8u322 ; popd
$ diff -u /tmp/8u3{1,2}2
+./.hgtags-top-repo
+./hotspot/test/compiler/arraycopy
+./hotspot/test/compiler/arraycopy/TestInitializingACLoadWithBadMem.java
-./jdk/make/data/cacerts/globalsignr2ca
-./jdk/make/data/cacerts/identrustdstx3
+./jdk/src/share/classes/jdk/internal/misc
+./jdk/src/share/classes/jdk/internal/misc/TerminatingThreadLocal.java
+./jdk/src/share/classes/sun/security/util/KnownOIDs.java
+./jdk/test/com/sun/net/httpserver/bugs/TruncatedRequestBody.java
+./jdk/test/java/awt/ColorClass
+./jdk/test/java/awt/ColorClass/EqualityTest
+./jdk/test/java/awt/ColorClass/EqualityTest/EqualityTest.java
+./jdk/test/java/awt/event/MouseEvent/AltGraphModifierTest
+./jdk/test/java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java
+./jdk/test/java/awt/font/Rotate/A.ttf
+./jdk/test/java/awt/font/Rotate/RotatedItalicsTest.java
+./jdk/test/java/awt/image/RescaleOp
+./jdk/test/java/awt/image/RescaleOp/ImageRescaleOpTest.java
+./jdk/test/java/awt/image/RescaleOp/RescaleAlphaTest.java
+./jdk/test/java/awt/print/PrinterJob/ExceptionFromPrintableIsIgnoredTest.java
+./jdk/test/java/awt/print/PrinterJob/PageDialogMarginTest.java
+./jdk/test/java/awt/Robot/NonEmptyErrorStream.java
+./jdk/test/java/beans/XMLEncoder/ReferenceToNonStaticField.java
-./jdk/test/java/net/MulticastSocket/JoinGroup.java
-./jdk/test/java/net/MulticastSocket/Leave.java
+./jdk/test/java/net/MulticastSocket/JoinLeave.java
+./jdk/test/java/net/NetworkConfigurationProbe.java
+./jdk/test/java/nio/channels/FileChannel/TempDirectBuffersReclamation.java
+./jdk/test/java/nio/file/etc/MacVolumesTest.java
+./jdk/test/java/util/TimeZone/Bug8066652.java
+./jdk/test/java/util/TimeZone/Bug8066652.sh
+./jdk/test/javax/swing/JEditorPane/5076514
+./jdk/test/javax/swing/JEditorPane/5076514/bug5076514.java
+./jdk/test/javax/swing/plaf/metal/MetalUtils
+./jdk/test/javax/swing/plaf/metal/MetalUtils/bug6190373.java
+./jdk/test/jdk/internal/misc
+./jdk/test/jdk/internal/misc/TerminatingThreadLocal
+./jdk/test/jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java
+./jdk/test/jdk/java/awt/font
+./jdk/test/jdk/java/awt/font/Rotate
+./jdk/test/jdk/java/awt/font/Rotate/RotatedItalicsTest.java
+./jdk/test/lib/testlibrary/jdk/testlibrary/NetworkConfiguration.java
+./jdk/test/sun/net/www/http/RequestMethodCheck
+./jdk/test/sun/net/www/http/RequestMethodCheck/RequestMethodEquality.java
+./jdk/test/sun/net/www/http/RequestMethodCheck/sun
+./jdk/test/sun/net/www/http/RequestMethodCheck/sun/net
+./jdk/test/sun/net/www/http/RequestMethodCheck/sun/net/www
+./jdk/test/sun/net/www/http/RequestMethodCheck/sun/net/www/http
+./jdk/test/sun/net/www/http/RequestMethodCheck/sun/net/www/http/HttpClientAccess.java
+./jdk/test/sun/security/tools/jarsigner/warnings/LowerCaseManifest.java
Downstream are, of course, welcome to consume the code directly from
the source code repositories if they wish. We specifically made sure
that a read-only Git mirror of the mono repositories was active
straight away, so downstream could ignore the transition phase and
move to consuming from GitHub straight away. The only people who need
to be interacting with the mono Mercurial repositories are those who
need to write to them.
> As I said above, I’ve taken this over because nobody else was
> doing it so I’m not heavily invested in this packaging. I’m
> trying to not change too much.
>
Again, this really depends on what you were doing to begin with.
The changes we made for Fedora were very minimal [2]; change the
download command from 'hg' to 'git' and remove the need to
download any subtrees.
> Is there any way (which will stay stable, even when you’re going
> to move repositories *again*, to git) to split the download into
> what the old repositories have been, so I can still get my tarballs
> in the way the current packaging requires?
>
As I said above, our release tarballs have remained stable and will
continue to do so.
I might be able to help more if you can describe how you obtain
your tarballs.
> Otherwise I’d have to change things a lot, which will be tricky
> *and* time-consuming (and I’d have to ask $employer for more time
> than I can currently use for this).
>
> I’d prefer best if you would just push the new releases also to
> the old repositories and tag them appropriately. But I understand
> chances for this going to happen are small as you seem to be very
> interested in this new-fangled git thingy :/
>
Well, yes, it would require applying every single patch to a different
set of repositories, including altering metadata and paths so they apply
to subrepositories. In other words, exactly the work we've made this
transition to try and reduce with patches from later JDK versions.
Recreating it just for building the source is considerably easier:
$ git clone -b jdk8u322-ga https://github.com/openjdk/jdk8u.git openjdk
$ mv openjdk/{corba,jaxp,jaxws,langtools,nashorn,jdk,hotspot} .
$ for repos in openjdk corba jaxp jaxws langtools nashorn jdk hotspot ; do
tar cJf ${repos}.tar.xz ${repos}
done
That will give you the original eight individual repository
tarballs. You can also replace the git clone step with just using the
release tarball instead.
> Thanks in advance,
> //mirabilos
> --
> Infrastrukturexperte • tarent solutions GmbH
> Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
> Telephon +49 228 54881-393 • Fax: +49 228 54881-235
> HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
> Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
>
> ****************************************************
> /⁀\ The UTF-8 Ribbon
> ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
> ╳ HTML eMail! Also, https://www.tarent.de/newsletter
> ╱ ╲ header encryption!
> ****************************************************
>
[0] https://bitly.com/openjdk8u322
[1] https://bitly.com/openjdk8u312
[2] https://src.fedoraproject.org/rpms/java-1.8.0-openjdk/c/1df9f60904f8e1ac182c80755a94cfca094e8844?branch=f35
Hope that helps,
--
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222
More information about the jdk8u-dev
mailing list