Re: Bug#975016: OpenJDK 15 support state for Bullseye
On Tue, Jan 26, 2021 at 04:36:13PM +0100, Matthias Klose wrote: >... > 4) Provide OpenJDK 17 in bullseye-backports only. I don't know >how it can land there. >... My suggestion for that is in https://lists.debian.org/debian-release/2021/02/msg00031.html If this suggesion is not acceptable, the Plan B would be that someone who wants OpenJDK 17 in bullseye-backports uploads binaries for all release architectures (built on unstable before the release of bullseye) to bullseye-backports with the initial upload that anyway needs binaries due to NEW. > Matthias cu Adrian
Re: Bug#975016: OpenJDK 15 support state for Bullseye
Am Tue, Jan 26, 2021 at 04:36:13PM +0100 schrieb Matthias Klose: > On 12/2/20 5:42 PM, Holger Levsen wrote: > > On Fri, Nov 20, 2020 at 08:40:22AM +, Holger Levsen wrote: > >>> Thanks for the upload. > >> :) note however that "#975016: OpenJDK 15 support state for Bullseye" is > >> still > >> open... > > > > ping, has there been any progress on this? > > chatting with Moritz from the security team, we found four options: > > 1) Ship a snapshot of OpenJDK 17 in bullseye. The package is >marked as a snapshot build. Mention in debian-security-support >and the Release Notes, that the package is unsupported. The >package should be updated to the final OpenJDK 17 release via >debian-security (final release is expected in October 2021). >I volunteer to do that, I also volunteer to prepare follow-up >updates, but unlikely for every security update which is >expected every three months. > > 2) Like option 1), but find somebody committing to constant security >updates. Mentioning in debian-security-support and the Release >Notes is not needed. > > 3) Provide OpenJDK 17 in the same archive area as planned for all >the go dependencies. I don't know what would be involved with >that. > > 4) Provide OpenJDK 17 in bullseye-backports only. I don't know >how it can land there. The backports section also might not be >enabled for everybody. Ack, ideally we can come up with someone committing to 2), but those are all workable options. Cheers, Moritz
Re: Bug#975016: OpenJDK 15 support state for Bullseye
On 1/26/21 6:53 PM, Holger Levsen wrote: > On Tue, Jan 26, 2021 at 06:30:25PM +0100, Matthias Klose wrote: >> On 1/26/21 5:55 PM, Holger Levsen wrote: >>> On Tue, Jan 26, 2021 at 04:36:13PM +0100, Matthias Klose wrote: >> :) note however that "#975016: OpenJDK 15 support state for Bullseye" is >> still > ping, has there been any progress on this? chatting with Moritz from the security team, we found four options: 1) Ship a snapshot of OpenJDK 17 in bullseye. [...] >>> >>> I'm confused, the bug title is about OpenJDK 15?! >>> >>> So besides OpenJDK 17, what about 15 and 16? >> >> see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975016#10 > > thanks > >> the bug title is about one, and only one more, additional openjdk-N version, >> which is supposed to be an openjdk LTS version again: 17. > > so if 17 were shipped, 15 would not be shipped?!? (and 16 neither) please read above: "one, and only one more, additional openjdk-N version"
Re: Bug#975016: OpenJDK 15 support state for Bullseye
On Tue, Jan 26, 2021 at 06:30:25PM +0100, Matthias Klose wrote: > On 1/26/21 5:55 PM, Holger Levsen wrote: > > On Tue, Jan 26, 2021 at 04:36:13PM +0100, Matthias Klose wrote: > :) note however that "#975016: OpenJDK 15 support state for Bullseye" is > still > >>> ping, has there been any progress on this? > >> chatting with Moritz from the security team, we found four options: > >> 1) Ship a snapshot of OpenJDK 17 in bullseye. [...] > > > > I'm confused, the bug title is about OpenJDK 15?! > > > > So besides OpenJDK 17, what about 15 and 16? > > see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975016#10 thanks > the bug title is about one, and only one more, additional openjdk-N version, > which is supposed to be an openjdk LTS version again: 17. so if 17 were shipped, 15 would not be shipped?!? (and 16 neither) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ There are no jobs on a dead planet. (Also many other things but people mostly seem to care about jobs.) signature.asc Description: PGP signature
Re: Bug#975016: OpenJDK 15 support state for Bullseye
On 1/26/21 5:55 PM, Holger Levsen wrote: > On Tue, Jan 26, 2021 at 04:36:13PM +0100, Matthias Klose wrote: :) note however that "#975016: OpenJDK 15 support state for Bullseye" is still >>> ping, has there been any progress on this? >> chatting with Moritz from the security team, we found four options: >> 1) Ship a snapshot of OpenJDK 17 in bullseye. [...] > > I'm confused, the bug title is about OpenJDK 15?! > > So besides OpenJDK 17, what about 15 and 16? see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975016#10 the bug title is about one, and only one more, additional openjdk-N version, which is supposed to be an openjdk LTS version again: 17.
Re: Bug#975016: OpenJDK 15 support state for Bullseye
On Tue, Jan 26, 2021 at 04:36:13PM +0100, Matthias Klose wrote: > >> :) note however that "#975016: OpenJDK 15 support state for Bullseye" is > >> still > > ping, has there been any progress on this? > chatting with Moritz from the security team, we found four options: > 1) Ship a snapshot of OpenJDK 17 in bullseye. [...] I'm confused, the bug title is about OpenJDK 15?! So besides OpenJDK 17, what about 15 and 16? -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C ⠈⠳⣄ If secure encryption is outlawed, only criminals will have it. signature.asc Description: PGP signature
Re: Bug#975016: OpenJDK 15 support state for Bullseye
On 12/2/20 5:42 PM, Holger Levsen wrote: > On Fri, Nov 20, 2020 at 08:40:22AM +, Holger Levsen wrote: >>> Thanks for the upload. >> :) note however that "#975016: OpenJDK 15 support state for Bullseye" is >> still >> open... > > ping, has there been any progress on this? chatting with Moritz from the security team, we found four options: 1) Ship a snapshot of OpenJDK 17 in bullseye. The package is marked as a snapshot build. Mention in debian-security-support and the Release Notes, that the package is unsupported. The package should be updated to the final OpenJDK 17 release via debian-security (final release is expected in October 2021). I volunteer to do that, I also volunteer to prepare follow-up updates, but unlikely for every security update which is expected every three months. 2) Like option 1), but find somebody committing to constant security updates. Mentioning in debian-security-support and the Release Notes is not needed. 3) Provide OpenJDK 17 in the same archive area as planned for all the go dependencies. I don't know what would be involved with that. 4) Provide OpenJDK 17 in bullseye-backports only. I don't know how it can land there. The backports section also might not be enabled for everybody. My personal preference would be option 1. Matthias
Re: Bug#975016: OpenJDK 15 support state for Bullseye
On Thu, Nov 19, 2020 at 07:47:14PM +0100, Moritz Mühlenhoff wrote: > On Wed, Nov 18, 2020 at 10:31:30PM +0100, Thorsten Glaser wrote: > > I think nobody wants to switch default-jdk to 17 or even not ship > > 11 at all any more or stop supporting it during bullseye’s lifetime. > > Maybe that also was too implicit? > > Exactly, the supported Java release for the entire Bullseye lifetime will > be 11 (which packages will build-depend on and what's provided by > default-jdk. > > The idea is to include 15/16 so that later on when 17 is ready, 17 > can be made available in addition via backports (since at some point > later in the bullseye lifecycle might be software one wants to run > which requires 17 as the next LTS. 17 can be in unstable before the release of bullseye. If this is then eligible for testing migration except for the freeze, it would enter testing in the first migration after the release. With slight bending of the rules someone with ftp powers could then copy the sources+binaries from bookworm/testing to bullseye-backports. 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. Either option sounds better to me than shipping 15 or 16 in a stable release solely for bootstrapping 17 in backports. > Cheers, > Moritz cu Adrian
Re: Bug#975016: OpenJDK 15 support state for Bullseye
On Wed, Nov 18, 2020 at 10:31:30PM +0100, Thorsten Glaser wrote: > I think nobody wants to switch default-jdk to 17 or even not ship > 11 at all any more or stop supporting it during bullseye’s lifetime. > Maybe that also was too implicit? Exactly, the supported Java release for the entire Bullseye lifetime will be 11 (which packages will build-depend on and what's provided by default-jdk. The idea is to include 15/16 so that later on when 17 is ready, 17 can be made available in addition via backports (since at some point later in the bullseye lifecycle might be software one wants to run which requires 17 as the next LTS. Cheers, Moritz
Re: Bug#975016: OpenJDK 15 support state for Bullseye
On Wed, 18 Nov 2020, Matthias Klose wrote: > On 11/18/20 8:03 PM, Adrian Bunk wrote: > > New OpenJDK versions tend to cause both buildtime and runtime breakages > > in reverse dependencies, some of them hard to resolve and requiring > > updates to new upstream versions which in turn require new dependencies > > that might not even be in Debian. > > New upstream versions likely do that, that's not an attribute of OpenJDK. Which is why new upstream versions _generally_ don’t end up in stable. > What's your point? I think the point is about packages with the JDK in Build-Depends. The JDK has two use cases, one is people using it as JRE or JDK to independently develop software, the other is using it in B-D to build Debian packages (usually via default-jdk-headless). Making 17 available as the latter is certainly a no-go. Maybe that was what Adrian’s point was. I think your point is about making it available as the former, and so that people can test their things with it already, and to allow backporting packages that actually do need it. I think that is a good thing but perhaps bullseye-backports is indeed the better place for it (especially if the copying of binary packages into the suite to bootstrap is possible). I think nobody wants to switch default-jdk to 17 or even not ship 11 at all any more or stop supporting it during bullseye’s lifetime. Maybe that also was too implicit? 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. *
