Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v6]

2022-06-08 Thread Iris Clark
On Thu, 9 Jun 2022 01:03:47 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > Joe Darcy has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull

Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v6]

2022-06-08 Thread Joe Darcy
> Time to start getting ready for JDK 20... Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 44 additional commits since the last revision:

Re: RFR: 8287906: Rewrite of GitHub Actions (GHA) sanity tests [v2]

2022-06-08 Thread Magnus Ihse Bursie
> With project Skara, the ability to run a set of sanity build and test jobs on > selected platforms was added. This functionality was driven by > `.github/workflows/submit.yml`. This file unfortunately lacks any real > structure, and contains a lot of code duplication and redundancy. This has

Re: RFR: 8287828: Fix so that one can select jtreg test case by ID from make [v5]

2022-06-08 Thread Magnus Ihse Bursie
On Tue, 7 Jun 2022 18:15:30 GMT, Leo Korinth wrote: >> One can select a testcase by ID when running a jtreg test case directly from >> jtreg (using the testcase.java#testID syntax). However, this has not been >> possible to do when launching jtreg indirectly from make. >> >> This fix attempts

Integrated: 8287894: Use fixed timestamp as an alternative of __DATE__ macro in jdk.jdi to make Windows build reproducible

2022-06-08 Thread Alexey Pavlyutkin
On Tue, 7 Jun 2022 19:57:48 GMT, Alexey Pavlyutkin wrote: > Hi! > > Here is a fix to jdk.jdi that fixes reproducible build for Windows. The idea > of the fix is to re-use value of --with-hotspot-build-time option to generate > deterministic timestamp exactly like it's done to hotspot

Re: RFR: 8287894: Use fixed timestamp as an alternative of __DATE__ macro in jdk.jdi to make Windows build reproducible

2022-06-08 Thread Magnus Ihse Bursie
On Tue, 7 Jun 2022 19:57:48 GMT, Alexey Pavlyutkin wrote: > Hi! > > Here is a fix to jdk.jdi that fixes reproducible build for Windows. The idea > of the fix is to re-use value of --with-hotspot-build-time option to generate > deterministic timestamp exactly like it's done to hotspot

Re: RFR: JDK-8284858: Start of release updates for JDK 20 [v5]

2022-06-08 Thread Magnus Ihse Bursie
On Thu, 2 Jun 2022 17:00:35 GMT, Joe Darcy wrote: >> Time to start getting ready for JDK 20... > > Joe Darcy has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull

Re: RFR: 8287894: Use fixed timestamp as an alternative of __DATE__ macro in jdk.jdi to make Windows build reproducible

2022-06-08 Thread Erik Joelsson
On Tue, 7 Jun 2022 19:57:48 GMT, Alexey Pavlyutkin wrote: > Hi! > > Here is a fix to jdk.jdi that fixes reproducible build for Windows. The idea > of the fix is to re-use value of --with-hotspot-build-time option to generate > deterministic timestamp exactly like it's done to hotspot

Re: RFR: 8287828: Fix so that one can select jtreg test case by ID from make [v5]

2022-06-08 Thread Erik Joelsson
On Tue, 7 Jun 2022 18:15:30 GMT, Leo Korinth wrote: >> One can select a testcase by ID when running a jtreg test case directly from >> jtreg (using the testcase.java#testID syntax). However, this has not been >> possible to do when launching jtreg indirectly from make. >> >> This fix attempts

Re: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default

2022-06-08 Thread Magnus Ihse Bursie
On Wed, 8 Jun 2022 07:47:24 GMT, KIRIYAMA Takuya wrote: > At default configuration, SOURCE_DATE_EPOCH is exported as environment > variable in SetupReproducibleBuild. Then, gcc is affected of > SOURCE_DATE_EPOCH environment variable. This value is used only to set > SOURCE_DATE_ISO_8601

Re: RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default

2022-06-08 Thread Severin Gehwolf
On Wed, 8 Jun 2022 07:47:24 GMT, KIRIYAMA Takuya wrote: > At default configuration, SOURCE_DATE_EPOCH is exported as environment > variable in SetupReproducibleBuild. Then, gcc is affected of > SOURCE_DATE_EPOCH environment variable. This value is used only to set > SOURCE_DATE_ISO_8601

RFR: 8288001: SOURCE_DATE_EPOCH should not be set by default

2022-06-08 Thread KIRIYAMA Takuya
At default configuration, SOURCE_DATE_EPOCH is exported as environment variable in SetupReproducibleBuild. Then, gcc is affected of SOURCE_DATE_EPOCH environment variable. This value is used only to set SOURCE_DATE_ISO_8601 (except below), so I removed "export" for SOURCE_DATE_EPOCH in