On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes wrote:
> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the
> internal version string since before the JDK was open-sourced, so the
> reasoning for this is not in the public history. See
> https://github.com
On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes wrote:
> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the
> internal version string since before the JDK was open-sourced, so the
> reasoning for this is not in the public history. See
> https://github.com
On Thu, 7 Mar 2024 17:32:02 GMT, Frederic Thevenet
wrote:
> Also, it might be worth repeating one of my long-standing wishes: that the
> version string should not be hard-coded into the build, but e.g. stored as a
> string in the `release` file, and read from there. If we did that, the cost
On Thu, 7 Mar 2024 17:07:05 GMT, Magnus Ihse Bursie wrote:
> There is an inherent conflict with creating a version string that is very
> much up-to-date and includes ephemeral build data, and creating a robustly
> reproducible build. If this patch were to remove HOTSPOT_BUILD_USER, and we
>
On Wed, 6 Mar 2024 13:57:37 GMT, Erik Joelsson wrote:
> I'm fine with this change. I wasn't around when this was introduced, but my
> guess is that it was relevant back when Hotspot and the rest of the JDK were
> often built separately. We have the username in the default $OPT string for
>
On Wed, 6 Mar 2024 11:57:27 GMT, Andrew John Hughes wrote:
> The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the
> internal version string since before the JDK was open-sourced, so the
> reasoning for this is not in the public history. See
> https://github.com
The HotSpot code has inserted the value of `HOTSPOT_BUILD_USER` into the
internal version string since before the JDK was open-sourced, so the reasoning
for this is not in the public history. See
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/abstract_vm_version.cpp#L284
On Tue, 22 Aug 2023 02:14:54 GMT, Andrew John Hughes wrote:
> GHA regularly breaks because we specify a very explicit GCC version, even
> down to the release versioning of the Ubuntu package. In just this last
> week, it has caused issues with the testing of PRs on 11u
> (https:
On Tue, 22 Aug 2023 02:14:54 GMT, Andrew John Hughes wrote:
> GHA regularly breaks because we specify a very explicit GCC version, even
> down to the release versioning of the Ubuntu package. In just this last
> week, it has caused issues with the testing of PRs on 11u
> (https:
On Tue, 22 Aug 2023 13:01:03 GMT, Erik Joelsson wrote:
> > I did notice that this is set for the riscv64 build in
> > `make/conf/jib-profiles.js`
>
> This configuration only exists to verify that the build works. We don't
> currently use the binaries for anything. Using "bundled" made devkit
On Tue, 22 Aug 2023 13:35:18 GMT, Volker Simonis wrote:
> In principle I very much prefer locking down dependency versions to keep the
> build as reliable as possible. Unfortunately, as we have experienced so far,
> this isn't possible with GHA because the exact package versions aren't kept
>
On Tue, 22 Aug 2023 07:30:15 GMT, Aleksey Shipilev wrote:
> This looks okay.
>
Thanks.
> That said, it is rather unnatural to forward-port the patches. Next time, I
> would like to see a clean mainline RFE, which would then be cleanly
> backported to each of the JDK updates trees.
Agreed.
On Tue, 22 Aug 2023 06:49:21 GMT, Aleksey Shipilev wrote:
> Current GHA bootstraps fail for some arches with the incompatibility between
> libfreetype-dev and libfreetype6-dev. libfreetype6-dev. Current RISC-V GHA
> bootstrap fails due to this conflict.
>
> In both sid and bullseye and sid,
GHA regularly breaks because we specify a very explicit GCC version, even down
to the release versioning of the Ubuntu package. In just this last week, it
has caused issues with the testing of PRs on 11u
(https://github.com/openjdk/jdk11u-dev/pull/2084) and 17u
14 matches
Mail list logo
