OpenJDK 17 for bullseye-backports

[Adrian Bunk]

The problem:

OpenJDK 11 LTS is the default JDK in both buster and bullseye.

The next LTS OpenJDK 17 is already in unstable, but it will not even
have a stable release by the time bullseye releases.

OpenJDK 17 is expected to be the OpenJDK in bookworm.

Some users will want to use OpenJDK 17 on bullseye.

The security team is (understandably) strictly against security
supporting two OpenJDK versions in a stable release.

bullseye-backports would be the perfect place for providing
OpenJDK 17 to users on bullseye.

OpenJDK can only be built with the previous version, and doing a
11 -> 12 -> 13 -> 14 -> 15 -> 16 -> 17
bootstrap for 9 release architectures in bullseye-backports would be
quite painful.

Shipping without any security support either OpenJDK 16 or a pre-release
of OpenJDK 17 in bullseye only for avoiding an OpenJDK bootstrap in
bullseye-backports would sound very wrong.


My suggestion:

No OpenJDK other than 11 is shipped in bullseye.

If at the time of the bullseye release openjdk-17 in unstable is ready
to migrate to testing except for the freeze, this means that:
1. it will migrate at the first migration of bookworm, and
2. the binaries will be installable on all architectures in bullseye

The bootstrap could then be avoided by verbatim copying of this
openjdk-17 sources and binaries for all architectures from bookworm
to bullseye-backports.

Subsequent updates of openjdk-17 in bullseye-backports would then follow
the normal backports rules.

This suggestion requires:
1. that (temporarily) having the same version in bookworm+unstable and
bullseye-backports is not a problem for the archive or backports
software, and
2. willingness from the ftp team to do that, and
3. agreement from the backports team


cu
Adrian

[Emmanuel Bourg]

Le 02/02/2021 à 19:04, Adrian Bunk a écrit :

> bullseye-backports would be the perfect place for providing
> OpenJDK 17 to users on bullseye.
>
> OpenJDK can only be built with the previous version, and doing a
> 11 -> 12 -> 13 -> 14 -> 15 -> 16 -> 17
> bootstrap for 9 release architectures in bullseye-backports would be
> quite painful.

I did that to backport openjdk-11 to stretch and that was indeed
tedious. It consisted in uploading openjdk-{9,10,11} to
stretch-backports, not as separate packages but sequentially as the
final openjdk-11 package. At each step I had to wait for the builders to
complete the build before uploading the next version. And it took a lot
of time on some architectures (especially mipsel if I remember well, the
backport queue is processed with a lower priority and the builder is
constantly used for higher priority builds).

The whole backport was completed in 2 weeks. I guess a similar process
to bootstrap openjdk-17 from openjdk-11 would take 1 month.

> Shipping without any security support either OpenJDK 16 or a pre-release
> of OpenJDK 17 in bullseye only for avoiding an OpenJDK bootstrap in
> bullseye-backports would sound very wrong.

I agree that shipping a non LTS release of OpenJDK (12 to 16) is a bad
idea. Shipping OpenJDK 17 is worth considering though.

> My suggestion:
>
> No OpenJDK other than 11 is shipped in bullseye.
>
> If at the time of the bullseye release openjdk-17 in unstable is ready
> to migrate to testing except for the freeze, this means that:
> 1. it will migrate at the first migration of bookworm, and
> 2. the binaries will be installable on all architectures in bullseye
>
> The bootstrap could then be avoided by verbatim copying of this
> openjdk-17 sources and binaries for all architectures from bookworm
> to bullseye-backports.
>
> Subsequent updates of openjdk-17 in bullseye-backports would then follow
> the normal backports rules.

If openjdk-17 can't be shipped in bullseyes even with prominent warnings
that it's unsupported, then this sounds like a good idea.

Emmanuel Bourg

[Thorsten Glaser]

On Sat, 6 Feb 2021, Emmanuel Bourg wrote:

> If openjdk-17 can't be shipped in bullseyes even with prominent warnings
> that it's unsupported

Users will probably ignore that and use it anyway. It would have been
good if it could be included and kept up to date, but that’s doubling
of efforts, not worth the hassle, plus it would mean people would ex‐
pect Java packages shipped with bullseye to work with 17, which isn’t
the case (plus shipping only one makes it easier/clearer).

>, then this sounds like a good idea.

FWIW there is some discussion around this near
https://lists.debian.org/debian-java/2020/11/threads.html#00025
and we sincerely hope that a one-time copying of the binary packages
from sid to bullseye-backports, followed by either binNMUing or a
regular upload, can be done.

The situation is currently like this:

$ rmadison openjdk-1{1,2,3,4,5,6,7,8}
openjdk-11 | 11.0.4+11-1~bpo9+1 | stretch-backports | source
openjdk-11 | 11.0.4+11-1~deb10u1 | stable | source
openjdk-11 | 11.0.4+11-1 | unstable | source
openjdk-11 | 11.0.6+10-1~bpo9+1 | stretch-backports | source
openjdk-11 | 11.0.9.1+1-1~deb10u2 | stable | source
openjdk-11 | 11.0.10+9-1 | testing | source
openjdk-11 | 11.0.10+9-1 | unstable | source
openjdk-15 | 15.0.2+7-1 | unstable | source
openjdk-16 | 16~34-1 | testing | source
openjdk-16 | 16~35-1 | buildd-unstable | source
openjdk-16 | 16~35-1 | unstable | source
openjdk-17 | 17~7-1 | testing | source
openjdk-17 | 17~8-1 | buildd-unstable | source
openjdk-17 | 17~8-1 | unstable | source

The idea here is to drop all but openjdk-11 from testing (→ bullseye)
while waiting for the official release of 17 in sid and backporting
that one it has migrated to testing/bookworm.

Adrian’s suggestion to use bpo version numbers in sid for this…

>>Slightly less bending of the rules and only marginally more effort would
>>be to build ~bpo11+1 binaries for all bullseye release architectures
>>in unstable before the release of bullseye.

… sounds interesting, this keeps users’ expectations for backports
and is easily fixed in sid by uploading, once the copying is done.
(And, if needed, doing a ~bpo11+1b1 or ~bpo11+2 in backports.)

bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*************************************************

Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.

Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.

*************************************************

[Emmanuel Bourg]

Le 07/02/2021 à 00:43, Thorsten Glaser a écrit :

> Users will probably ignore that and use it anyway. It would have been
> good if it could be included and kept up to date, but that’s doubling
> of efforts, not worth the hassle,

I wonder if the effort of maintaining OpenJDK 17 in bullseyes could be
significantly reduced by automating the process. The upstream LTS branch
is going to be extremely stable, the releases are clearly tagged in the
upstream repository, and the Debian packaging is very flexible and
compatible with several Debian releases. It should be possible to fetch
the upstream security updates, rebase the Debian packaging and upload
the package automatically.

That wasn't possible a few years ago, I vaguely remember Matthias
telling me that up to Java 8 the security updates were not easily
identifiable in the upstream repository (if available at all), and that
some architectures required changes cherry picked from alternative
repositories.

If we can't rely on the main upstream repository to support all the
Debian architectures, maybe we can restrict the automatic updates to
those supported upstream (at least amd64 and i386, maybe arm64 too).


> plus it would mean people would expect Java packages shipped with bullseye

> to work with 17, which isn’t the case (plus shipping only one makes
> iteasier/clearer).

The compatibility of the Java packages in bullseye with OpenJDK 17 is
rather good. I ran a mass rebuild this week and the success rate was
around 85%. There were many trivial build issues (javadoc errors,
language level to change from 6 to 7) so the runtime compatibility is
likely to be higher. I've filed the issues in the BTS:

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=default-java17;users=debia...@lists.debian.org

Emmanuel Bourg

[Matthias Klose]

[please ignore this thread started by Adrian; he's making statements on behalf
of other teams, which are not correct. Also he "forgot" to CC the security team
and the package maintainers. The issue is handled in #975016.]

See #975016.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975016#98
lists the proposals made.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975016#123
lists the OK of the security team for all proposals.

So I'm going with option 1, preparing for an openjdk-17 in bullseye, and
preparing release notes and notes for security support. This is more
conservative than option 2, but allows to do better than the commitment made.

The option also has the advantage that approval is only needed by the security
team. openjdk-17 already is in testing. granting unblock requests for new
snapshot builds by the release team would be appreciated, but isn't strictly
necessary as long as we can build newer snapshots. And that can be checked in
unstable.

Matthias

[Holger Levsen]

hi,

almost exactly a year ago...

On Sun, Feb 07, 2021 at 11:59:23AM +0100, Matthias Klose wrote:
> So I'm going with option 1, preparing for an openjdk-17 in bullseye, and
> preparing release notes and notes for security support. This is more
> conservative than option 2, but allows to do better than the commitment made.
>
> The option also has the advantage that approval is only needed by the security
> team. openjdk-17 already is in testing. granting unblock requests for new
> snapshot builds by the release team would be appreciated, but isn't strictly
> necessary as long as we can build newer snapshots. And that can be checked in
> unstable.

so, as I see it, openjdk-17 is in bullseye and now I'm wondering what
I should do with #975016 titled "OpenJDK 17 support state for Bullseye"
and filed against src:debian-security-support, as openjdk-17 seems to be
supported and src:debian-security-support's purpose is to documented what's
unsupported.

so, should I just close this bug?


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

A ship is always safe at shore, but that is not what it's built for.
(Albert Einstein)

[Thorsten Glaser]

Hi Holger,

> and filed against src:debian-security-support, as openjdk-17 seems to be
> supported and src:debian-security-support's purpose is to documented what's

no, 11 is supported, 17 is just for users to run third-party
stuff on (IIUC).

bye,
//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!
****************************************************

[Moritz Mühlenhoff]

Am Thu, Feb 03, 2022 at 03:59:00PM +0100 schrieb Thorsten Glaser:
> Hi Holger,
>
> > and filed against src:debian-security-support, as openjdk-17 seems to be
> > supported and src:debian-security-support's purpose is to documented what's
>
> no, 11 is supported, 17 is just for users to run third-party
> stuff on (IIUC).

In Bullseye 11 is the default Java and fully covered by security support.

17 can be installed (and it can also take over the typical alternatives),
but nothing pulls it in via dependencies. But if anyone needs to run an
application requiring 17, this is the JRE of choice (those are rare at
this point, but it will change over the life time of Bullseye).

And yes there have been security updates for 17 already, but it's a best effort
thing. If someone commits to rebuild the openjdk-17 uploads to unstable
for bullseye-security (along with proper testing), we can also omit a note
for src:debian-security-support.

Cheers,
Moritz

[Matthias Klose]

"along with proper testing" means, that we can turn on again the tests during
the build, which requires a heap of new upstream versions for jtreg, jtharness,
testng, groovy, and probably much more.

Matthias

[Salvatore Bonaccorso]

Hi Holger,

On Wed, Aug 17, 2022 at 10:47:25AM +0000, Holger Levsen wrote:
> hi,
>
> as both openjdk-11 and openjdk-17 have received security updates and
> as I understand this very bug report, we can close this bug as nothing
> regarding the security-status of openjdk-(11|17) in bullseye needs to
> be documented right now, as they are both supported.

Sort of. Just for exanding the context, there is a note about it in
https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#limited-security-support
.

Moritz might give a better overview though than me.

Regards,
Salvatore

[Holger Levsen]

Hi Carnil,

On Wed, Aug 17, 2022 at 09:38:27PM +0200, Salvatore Bonaccorso wrote:
> Sort of. Just for exanding the context, there is a note about it in
> https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#limited-security-support

thanks, I've added openjdk-17 to security-support-limited now and used
https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#openjdk-17
as a link/reason why.

I've done this for the master and bullseye branch and intend to get
this into the next point release.

btw, it would be great if there were
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html
already as that would be more appropriate for unstable right now.

--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

"I became an antifascist out of a sense of common decency.” – Marlene Dietrich