Bug#1068629: testng7 backport for bullseye needed for latest Java LTS releases
Please excuse the top-post and the slow response-time. I am fully in agreement with the vendoring approach for jtreg7. If there aren't any concerns from the team, I will review the MR and prepare an upload in the next few days. Cheers, tony On Tue, Apr 09, 2024 at 02:02:13PM +1200, Vladimir Petko wrote: > Hi, > > I have realized that I have not submitted the bug report for this > issue, so the decision to try vendoring dependencies for JTREG is not > visible anywhere. > > Starting from the April OpenJDK release, JTREG 7.3 will be used for > openjdk-11 and up, which will require having it in Buster and up. > > In Ubuntu, the January OpenJDK update used the vendored version, and > we have not found any test regression issues caused by it. > > I have an MR open[1] that does not update the source tree and a > branch[2] with imported sources. > > Best Regards, > Vladimir. > > [1] https://salsa.debian.org/java-team/jtreg7/-/merge_requests/1 > [2] > https://salsa.debian.org/vpa1977/jtreg7/-/tree/jtreg_with_sources?ref_type=heads > > On Sun, Oct 22, 2023 at 10:01 AM Emmanuel Bourg wrote: > > > > Le 21/10/2023 à 20:55, tony mancill a écrit : > > > > > My secondary concern is how we would respond to CVEs in the vendored > > > components. We can debate whether the attack surface area in a tool > > > like jtreg warrants patching the vendored components, but as a general > > > principle, that's why we avoid vendoring in the first place. > > > > > > But if vendoring is acceptable in some circumstances, I can imagine > > > cases where it helps with bootstrapping too, but that's probably a topic > > > for a different thread. > > > > > > In any event, I'm glad that we're having the discussion and that the > > > Security Team has taken a look. Let's see how it goes with jtreg7. > > > > jtreg is only used to run the openjdk tests, that's not a security > > sensitive package, so embedding the package isn't a concern. > > > > Emmanuel Bourg > > signature.asc Description: PGP signature
Bug#1068629: testng7 backport for bullseye needed for latest Java LTS releases
Hi, Sorry for the misleading statement: openjdk-11 will add the jtreg7 requirement in the next (July) release[1] not in April. Best Regards, Vladimir. [1] https://github.com/openjdk/jdk11u-dev/blob/583477f96f58a2608ced8bf75bdc7670dc24d180/test/jdk/TEST.ROOT#L65
Bug#1068629: testng7 backport for bullseye needed for latest Java LTS releases
Hi Vladimir, if you have any suggestions as to what to do best with openjdk-8, feel free to say. In Debian, it’s only relevant in unstable, ELTS stretch and jessie, but for Ubuntu it’s used in more. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1068629: testng7 backport for bullseye needed for latest Java LTS releases
Am Tue, Apr 09, 2024 at 02:02:13PM +1200 schrieb Vladimir Petko: > Hi, > > I have realized that I have not submitted the bug report for this > issue, so the decision to try vendoring dependencies for JTREG is not > visible anywhere. > > Starting from the April OpenJDK release, JTREG 7.3 will be used for > openjdk-11 and up, which will require having it in Buster and up. > > In Ubuntu, the January OpenJDK update used the vendored version, and > we have not found any test regression issues caused by it. > > I have an MR open[1] that does not update the source tree and a > branch[2] with imported sources. Thanks, using a vendored version seems perfectly fine here and makes our life significantly easier for stable/oldstable updates (and jtreg isn't used outside of OpenJDK anyway) Cheers, Moritz
Bug#1068629: testng7 backport for bullseye needed for latest Java LTS releases
Hi, I have realized that I have not submitted the bug report for this issue, so the decision to try vendoring dependencies for JTREG is not visible anywhere. Starting from the April OpenJDK release, JTREG 7.3 will be used for openjdk-11 and up, which will require having it in Buster and up. In Ubuntu, the January OpenJDK update used the vendored version, and we have not found any test regression issues caused by it. I have an MR open[1] that does not update the source tree and a branch[2] with imported sources. Best Regards, Vladimir. [1] https://salsa.debian.org/java-team/jtreg7/-/merge_requests/1 [2] https://salsa.debian.org/vpa1977/jtreg7/-/tree/jtreg_with_sources?ref_type=heads On Sun, Oct 22, 2023 at 10:01 AM Emmanuel Bourg wrote: > > Le 21/10/2023 à 20:55, tony mancill a écrit : > > > My secondary concern is how we would respond to CVEs in the vendored > > components. We can debate whether the attack surface area in a tool > > like jtreg warrants patching the vendored components, but as a general > > principle, that's why we avoid vendoring in the first place. > > > > But if vendoring is acceptable in some circumstances, I can imagine > > cases where it helps with bootstrapping too, but that's probably a topic > > for a different thread. > > > > In any event, I'm glad that we're having the discussion and that the > > Security Team has taken a look. Let's see how it goes with jtreg7. > > jtreg is only used to run the openjdk tests, that's not a security > sensitive package, so embedding the package isn't a concern. > > Emmanuel Bourg >
