would look
> like in test summary.
Aleksey Shipilev has updated the pull request incrementally with one additional
commit since the last revision:
Gaaah
-
Changes:
- all: https://git.openjdk.org/jdk/pull/21308/files
- new: https://git.openjdk.org/jdk/pull/21308/files/99529
would look
> like in test summary.
Aleksey Shipilev has updated the pull request incrementally with one additional
commit since the last revision:
Stylistic touchups
-
Changes:
- all: https://git.openjdk.org/jdk/pull/21308/files
- new: https://git.openjdk.org/jdk/pull/21308/file
GHA conveniently collects hs_errs from the test job runs. However, when we have
a failure during the build, e.g. javac, CDS, jmod, jlink crashes the VM, we
don't have these automatically collected. This is annoying when VM crashes on a
particular platform, and not on others.
We can add the hook
On Mon, 30 Sep 2024 10:39:33 GMT, Kim Barrett wrote:
> This change seems premature. Various companies (Oracle, SAP, others?) are
> still supporting macos-x64 on mainline.
Maybe premature, maybe not. We always run against the runner availability in
GHA. AFAIU, MacOS 13 will EOL 3 years after re
See the discussion in the bug. I think we can stop testing Mac x86 in GHA,
leaving only the build jobs.
Additional testing:
- [x] GHA passes
-
Commit messages:
- Fix
Changes: https://git.openjdk.org/jdk/pull/21257/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21257&ran
On Thu, 19 Sep 2024 05:51:00 GMT, Aleksey Shipilev wrote:
> `remove-bundles` step does not depend on `test-macos-aarch64`, which means it
> can run before macos-aarch64 tests start to run, which would fail those
> steps. This is not frequent, but will happen if macos-aarch64 ru
On Thu, 19 Sep 2024 05:51:00 GMT, Aleksey Shipilev wrote:
> `remove-bundles` step does not depend on `test-macos-aarch64`, which means it
> can run before macos-aarch64 tests start to run, which would fail those
> steps. This is not frequent, but will happen if macos-aarch64 ru
`remove-bundles` step does not depend on `test-macos-aarch64`, which means it
can run before macos-aarch64 tests start to run, which would fail those steps.
This is not frequent, but will happen if macos-aarch64 runners are lagging
behind to pick up the jobs.
-
Commit messages:
-
On Wed, 4 Sep 2024 14:40:38 GMT, Fei Yang wrote:
> Debian "sid" or "unstable" (https://httpredir.debian.org/debian) that we use
> for debootstrapping RISC-V breaks very often. Currently, the GHA
> linux-cross-build for RISC-V would not continue and is simply skipped when
> this debootstrap for
On Thu, 15 Aug 2024 10:26:17 GMT, George Adams wrote:
>> Adds Alpine build CI job to the GitHub actions matrix. Currently this only
>> builds hotspot. I can add tests too if people think that would be useful but
>> for now I've left it as just build.
>
> George Adams has updated the pull reques
On Tue, 13 Aug 2024 09:35:41 GMT, Aleksey Shipilev wrote:
> As planned in [JDK-8338285](https://bugs.openjdk.org/browse/JDK-8338285), we
> are about to deprecate the port for removal. It makes little sense to
> continue testing the port, and thus block development and integrati
On Tue, 13 Aug 2024 09:35:41 GMT, Aleksey Shipilev wrote:
> As planned in [JDK-8338285](https://bugs.openjdk.org/browse/JDK-8338285), we
> are about to deprecate the port for removal. It makes little sense to
> continue testing the port, and thus block development and integrati
On Wed, 14 Aug 2024 14:30:28 GMT, Zdenek Zambersky wrote:
> Some of bundles may not get removed. This is follows
> [JDK-8336928](https://bugs.openjdk.org/browse/JDK-8336928). Problem does not
> always show up, so I have not seen it in my test runs, but since then I have
> seen some GHA runs af
On Tue, 13 Aug 2024 09:35:41 GMT, Aleksey Shipilev wrote:
> As planned in [JDK-8338285](https://bugs.openjdk.org/browse/JDK-8338285), we
> are about to deprecate the port for removal. It makes little sense to
> continue testing the port, and thus block development and integrati
As planned in [JDK-8338285](https://bugs.openjdk.org/browse/JDK-8338285), we
are about to deprecate the port for removal. It makes little sense to continue
testing the port, and thus block development and integration of new features.
Ahead of that JEP, we can separately decide to disable the x86
On Fri, 9 Aug 2024 10:27:25 GMT, Magnus Ihse Bursie wrote:
> The XCode command lines tools is almost, but not quite, enough to build the
> JDK. We still need the metal and metallib tools. The error message given by
> configure should be improved to indicate if this is the problem with the
> us
On 07.08.24 19:39, Aleksey Shipilev wrote:
On 07.08.24 19:30, Kurt Stine wrote:
No, I am still unable to cross-compile jdk8u for ppc32. I was able to get the latest community
ppc32 build from Azul, but it isn’t the latest/most up-to-date version.
I used to build PPC32 binaries for JDK 8u with
Hi,
On 07.08.24 19:30, Kurt Stine wrote:
No, I am still unable to cross-compile jdk8u for ppc32. I was able to get the latest community ppc32
build from Azul, but it isn’t the latest/most up-to-date version.
I used to build PPC32 binaries for JDK 8u with debootstrapped sysroots and
native cro
On Mon, 5 Aug 2024 12:30:25 GMT, Christoph Langer wrote:
> Currently, we use JDK 22 GA binaries in Github Actions. Since JDK 22.0.2 is
> available in the meanwhile, we can use it. I also correct the alphabetical
> ordering of the macOS platforms.
Marked as reviewed by shade (Reviewer).
--
On Fri, 26 Jul 2024 16:21:33 GMT, Aleksey Shipilev wrote:
> I noticed that `build/$confname/configure.log` was truncated on some of my
> build nodes. Turns out, we are moving configure.log from tree root to that
> place a bit prematurely.
>
> We move `configure.log` here:
>
On Fri, 26 Jul 2024 16:21:33 GMT, Aleksey Shipilev wrote:
> I noticed that `build/$confname/configure.log` was truncated on some of my
> build nodes. Turns out, we are moving configure.log from tree root to that
> place a bit prematurely.
>
> We move `configure.log` here:
>
On Sat, 13 Jul 2024 16:48:20 GMT, Aleksey Shipilev wrote:
> Following [JDK-8257913](https://bugs.openjdk.org/browse/JDK-8257913), it
> would be more convenient to search into more paths in sysroot for ALSA as
> well. Currently, this is the only thing that is missing for me to build fr
On Sat, 13 Jul 2024 16:48:20 GMT, Aleksey Shipilev wrote:
> Following [JDK-8257913](https://bugs.openjdk.org/browse/JDK-8257913), it
> would be more convenient to search into more paths in sysroot for ALSA as
> well. Currently, this is the only thing that is missing for me to build fr
On Sun, 28 Jul 2024 22:15:05 GMT, Phil Race wrote:
> This looks reasonable to me, but someone from the build team (specifically
> @magicus or @erikj79) should approve as well.
Thanks! [You are in Build Group too](https://openjdk.org/census#build), Phil :)
Anyway, I presume both @magicus and @e
On Sat, 13 Jul 2024 13:43:42 GMT, Aleksey Shipilev wrote:
> In [JDK-8257913](https://bugs.openjdk.org/browse/JDK-8257913), we added the
> search paths for X11 libraries, but they point explicitly to `libX11.so`.
> First, this is not really correct, as `x_libraries` would be a
On Sun, 28 Jul 2024 22:18:07 GMT, Phil Race wrote:
> This is marked as an enhancement but it sure looks like a bug fix to me.
Yeah, it is a bug, changed.
Given that we have both @prrace and @TheShermanTanker (and me) in build group,
we have enough reviews for this one.
-
PR Comme
I noticed that `build/$confname/configure.log` was truncated on some of my
build nodes. Turns out, we are moving configure.log from tree root to that
place a bit prematurely.
We move `configure.log` here:
https://github.com/openjdk/jdk/blob/4f194f10a1481cdc9df4e6338f6cabd07a34c84c/make/autoconf/
On Sat, 13 Jul 2024 13:43:42 GMT, Aleksey Shipilev wrote:
> In [JDK-8257913](https://bugs.openjdk.org/browse/JDK-8257913), we added the
> search paths for X11 libraries, but they point explicitly to `libX11.so`.
> First, this is not really correct, as `x_libraries` would be a
On Sat, 13 Jul 2024 16:48:20 GMT, Aleksey Shipilev wrote:
> Following [JDK-8257913](https://bugs.openjdk.org/browse/JDK-8257913), it
> would be more convenient to search into more paths in sysroot for ALSA as
> well. Currently, this is the only thing that is missing for me to build fr
On Wed, 17 Jul 2024 03:37:36 GMT, Vladimir Kozlov wrote:
> Citing David Holmes from bug report:
> "We provided the ability to leave out certain VM services (JVMTI, GC's other
> than serial, ...) as part of the design of the MinimalVM to support Java SE
> Embedded, along with the Compact Profile
On Wed, 17 Jul 2024 04:57:38 GMT, David Holmes wrote:
> It highlights the problem we have with optional components in that you either
> have to work things so that semantically we have a do-nothing implementation
> of that component, or else you have to put the guards around every piece of
> c
On Tue, 16 Jul 2024 14:12:54 GMT, Nizar Benalla wrote:
> Can I please have a review for this bug fix to make file used to generate the
> OpenJDK documentation. It adds the missing `` tag after `OTHER
> SPECIFICATIONS`, this should help remove some HTML warnings in out generated
> docs.
>
> Th
Following JDK-8257913, it would be more convenient to search into more paths in
sysroot for ALSA as well. Currently, this is the only thing that is missing for
me to build from the crosstool-ng generated sysroot. Without these, we have to
provide the additional `--with-alsa-lib` configuration pa
In [JDK-8257913](https://bugs.openjdk.org/browse/JDK-8257913), we added the
search paths for X11 libraries, but they point explicitly to `libX11.so`.
First, this is not really correct, as `x_libraries` would be added to a search
path. Second, this apparently does not work for sysroots created by
On Thu, 18 Apr 2024 14:28:37 GMT, Aleksey Shipilev wrote:
> We have added these long time ago with
> [JDK-8308086](https://bugs.openjdk.org/browse/JDK-8308086) and
> [JDK-8293165](https://bugs.openjdk.org/browse/JDK-8293165) to stabilize
> x86_32 sysroot a bit. We never backported
> We have added these long time ago with
> [JDK-8308086](https://bugs.openjdk.org/browse/JDK-8308086) and
> [JDK-8293165](https://bugs.openjdk.org/browse/JDK-8293165) to stabilize
> x86_32 sysroot a bit. We never backported those below JDK 21.
Aleksey Shipilev has updated the pull
We have added these long time ago with
[JDK-8308086](https://bugs.openjdk.org/browse/JDK-8308086) and
[JDK-8293165](https://bugs.openjdk.org/browse/JDK-8293165) to stabilize x86_32
sysroot a bit. We never backported those below JDK 21.
-
Commit messages:
- Merge branch 'master' in
On Mon, 3 Jun 2024 08:58:55 GMT, Julian Waters wrote:
> Don't forget about me! :)
Ah yes, you are also in Build Group now! Apologies.
-
PR Comment: https://git.openjdk.org/jdk/pull/19511#issuecomment-2144667812
On Sun, 2 Jun 2024 02:49:47 GMT, SendaoYan wrote:
> Hi all,
> This PR try to fix linux x86_32 configure fail with `--with-hsdis=binutils
> --with-binutils-src`. The libiberty.a locates in
> `build/linux-x86-server-fastdebug/configure-support/binutils-install/lib32`
> on linux ubuntu20. The c
On Sun, 2 Jun 2024 02:49:47 GMT, SendaoYan wrote:
> Hi all,
> This PR try to fix linux x86_32 configure fail with `--with-hsdis=binutils
> --with-binutils-src`. The libiberty.a locates in
> `build/linux-x86-server-fastdebug/configure-support/binutils-install/lib32`
> on linux ubuntu20. The c
On Fri, 26 Apr 2024 03:32:25 GMT, SendaoYan wrote:
> Hi,
>
> The curl command lack of "-L" option, cause download file fail, the size of
> download file is empty.
>
> curl download fail without `-L`:
>```log
>> rm -rf jmh-core-1.37.jar ; curl -O --fail
>> https://maven.aliyun.com/repo
On Mon, 25 Mar 2024 15:40:45 GMT, Aleksey Shipilev wrote:
> When doing [JDK-8326960](https://bugs.openjdk.org/browse/JDK-8326960), I
> missed the case when sysroot would be restored from the cache. This would
> skip the configure and build steps, because it would only consult the stat
On Mon, 25 Mar 2024 15:40:45 GMT, Aleksey Shipilev wrote:
> When doing [JDK-8326960](https://bugs.openjdk.org/browse/JDK-8326960), I
> missed the case when sysroot would be restored from the cache. This would
> skip the configure and build steps, because it would only consult the stat
On Mon, 25 Mar 2024 15:40:45 GMT, Aleksey Shipilev wrote:
> When doing [JDK-8326960](https://bugs.openjdk.org/browse/JDK-8326960), I
> missed the case when sysroot would be restored from the cache. This would
> skip the configure and build steps, because it would only consult the stat
When doing [JDK-8326960](https://bugs.openjdk.org/browse/JDK-8326960), I missed
the case when sysroot would be restored from the cache. This would skip the
configure and build steps, because it would only consult the status for
create-sysroot job. This is only a problem when PR gets tested the _
On Thu, 21 Mar 2024 16:57:40 GMT, Aleksey Shipilev wrote:
> Noticed this while fixing other GHA issues.
>
> We pass build JDK to cross-compilation jobs, which makes them dependent on
> Linux-x64 builds. But we only build hotspot in all those jobs, so AFAICS
> there is no nee
On Fri, 22 Mar 2024 14:18:39 GMT, Aleksey Shipilev wrote:
>> Noticed this while fixing other GHA issues.
>>
>> We pass build JDK to cross-compilation jobs, which makes them dependent on
>> Linux-x64 builds. But we only build hotspot in all those jobs, so AFAICS
>&
On Fri, 22 Mar 2024 14:18:39 GMT, Aleksey Shipilev wrote:
>> Noticed this while fixing other GHA issues.
>>
>> We pass build JDK to cross-compilation jobs, which makes them dependent on
>> Linux-x64 builds. But we only build hotspot in all those jobs, so AFAICS
>&
> Untying cross-compilation jobs from Linux-x64 builds make GHA more parallel.
>
> Additional testing:
> - [ ] GHA
Aleksey Shipilev 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
On Thu, 21 Mar 2024 15:33:21 GMT, Aleksey Shipilev wrote:
> Debian "unstable" is currently undergoing t64 (hello, Y2038) transition,
> which breaks "sid" repo that we use for debootstrapping RISC-V very often.
> This is seen across multiple repositories,
On Thu, 21 Mar 2024 15:33:21 GMT, Aleksey Shipilev wrote:
> Debian "unstable" is currently undergoing t64 (hello, Y2038) transition,
> which breaks "sid" repo that we use for debootstrapping RISC-V very often.
> This is seen across multiple repositories,
On Thu, 21 Mar 2024 15:33:21 GMT, Aleksey Shipilev wrote:
> Debian "unstable" is currently undergoing t64 (hello, Y2038) transition,
> which breaks "sid" repo that we use for debootstrapping RISC-V very often.
> This is seen across multiple repositories,
Noticed this while fixing other GHA issues.
We pass build JDK to cross-compilation jobs, which makes them dependent on
Linux-x64 builds. But we only build hotspot in all those jobs, so AFAICS there
is no need for build JDK, and therefore no need for the dependency. Untying
cross-compilation job
On Thu, 21 Mar 2024 16:57:40 GMT, Aleksey Shipilev wrote:
> Noticed this while fixing other GHA issues.
>
> We pass build JDK to cross-compilation jobs, which makes them dependent on
> Linux-x64 builds. But we only build hotspot in all those jobs, so AFAICS
> there is no nee
Debian "unstable" is currently undergoing t64 (hello, Y2038) transition, which
breaks "sid" repo that we use for debootstrapping RISC-V very often. This is
seen across multiple repositories, and requires everyone to look through GHA
failures all the time. This PR tries to fix this: if debootstra
On Tue, 12 Mar 2024 18:42:48 GMT, Erik Joelsson wrote:
>> Chad Rakoczy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Code cleanup
>
> I'm fine with just using VERSION_FEATURE. I think it's a simple and
> straightforward enough simplif
On Wed, 13 Mar 2024 17:11:25 GMT, Chad Rakoczy wrote:
>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>>
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are
>> the same. Updates test to include check for version. Also tested manually by
>> replacing
On Tue, 12 Mar 2024 19:22:25 GMT, Chad Rakoczy wrote:
>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>>
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are
>> the same. Updates test to include check for version. Also tested manually by
>> replacing
On Tue, 12 Mar 2024 23:44:45 GMT, Magnus Ihse Bursie wrote:
>> Chad Rakoczy has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Print to stdout instead of stderr
>> - Compare version using VERSION_STRING
>
> make/modules/java.base/Launche
On Mon, 11 Mar 2024 19:12:33 GMT, Chad Rakoczy wrote:
>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>>
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are
>> the same. Updates test to include check for version. Also tested manually by
>> replacing
On Mon, 11 Mar 2024 18:56:21 GMT, Bernd wrote:
> with a protocol version you don’t have to care about micro versions and also
> it is more tolerant about the usual cpu updates which do not introduce
> incompatibilities most of the time.
I think we can only reasonably guarantee that jspawnhelpe
On Mon, 11 Mar 2024 18:16:53 GMT, Erik Joelsson wrote:
> If you really want to require an exact match for jspawnhelper, then these 4
> numbers aren't necessarily enough, but a rather arbitrarily chosen
> approximation.
I think for our purposes, a version number quadruplet is enough to provide
On Fri, 8 Mar 2024 10:17:08 GMT, Magnus Ihse Bursie wrote:
> We should match the building of jspawnhelper in
> make/modules/java.base/Launcher.gmk with the usage for all unix platforms in
> src/java.base/unix/classes/java/lang/ProcessImpl.java.
>
> Granted, the list of OSes in the makefile amo
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/openjdk/jdk/
On Wed, 6 Mar 2024 17:17:28 GMT, Magnus Ihse Bursie wrote:
> I agree that it is good to get rid of this. However, the reason it has stuck
> around for so long is, eh, that it has been around for so long, so it is a
> bit unclear what or who could be relying on this.
The example I know is to ge
On Tue, 5 Mar 2024 07:12:09 GMT, Kim Barrett wrote:
>> Please review this change to update the HotSpot Style Guide's discussion of
>> nullptr and its use.
>>
>> I suggest this is an editorial rather than substantive change to the style
>> guide. As such, the normal HotSpot PR process can be use
On Mon, 4 Mar 2024 08:38:09 GMT, Kim Barrett wrote:
> Please review this change to update the HotSpot Style Guide's discussion of
> nullptr and its use.
>
> I suggest this is an editorial rather than substantive change to the style
> guide. As such, the normal HotSpot PR process can be used for
On Mon, 4 Mar 2024 08:41:46 GMT, Kim Barrett wrote:
>> Please review this change to update the HotSpot Style Guide's discussion of
>> nullptr and its use.
>>
>> I suggest this is an editorial rather than substantive change to the style
>> guide. As such, the normal HotSpot PR process can be use
On Sat, 17 Feb 2024 08:28:56 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of gcc
> to be used for building OpenJDK from 6.0 to 10.0.
>
> This permits enabling C++17 (JDK-8314488), though gcc 9.0 might suffice for
> that. A minimum of gcc 10 also
On Sat, 17 Feb 2024 08:28:56 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of gcc
> to be used for building OpenJDK from 6.0 to 10.0.
>
> This permits enabling C++17 (JDK-8314488), though gcc 9.0 might suffice for
> that. A minimum of gcc 10 also
On Mon, 26 Feb 2024 23:07:02 GMT, Dan Lutker wrote:
> Local fastdebug builds are working with GCC 13.2.1 on Linux aarch64.
Marked as reviewed by shade (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/18017#pullrequestreview-1902721965
On Wed, 7 Feb 2024 19:50:51 GMT, Christoph Langer wrote:
> The
> [change](https://github.com/openjdk/jdk/commit/d1c82156ba6ede4b798ac15f935289cfcc99d1a0)
> for [JDK-8325194](https://bugs.openjdk.org/browse/JDK-8325194) broke
> get-jtreg because the way to determine the build jdk was not correc
On Wed, 7 Feb 2024 19:50:51 GMT, Christoph Langer wrote:
> The
> [change](https://github.com/openjdk/jdk/commit/d1c82156ba6ede4b798ac15f935289cfcc99d1a0)
> for [JDK-8325194](https://bugs.openjdk.org/browse/JDK-8325194) broke
> get-jtreg because the way to determine the build jdk was not correc
On Sat, 3 Feb 2024 21:55:25 GMT, George Adams wrote:
>> Now that macOS M1 executors are [available in GitHub
>> actions](https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/)
>> it makes sense to move the build to run on M1 (rathe
On Sat, 3 Feb 2024 16:22:14 GMT, George Adams wrote:
>> Now that macOS M1 executors are [available in GitHub
>> actions](https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/)
>> it makes sense to move the build to run on M1 (rathe
On Tue, 30 Jan 2024 10:34:40 GMT, Aleksey Shipilev wrote:
> See the description in the bug. This mitigates the issue by splitting out the
> only test job that has two test suites in it.
This pull request has now been integrated.
Changeset: 1aba78f2
Author:Aleksey Shipile
On Tue, 30 Jan 2024 19:05:02 GMT, Magnus Ihse Bursie wrote:
>> See the description in the bug. This mitigates the issue by splitting out
>> the only test job that has two test suites in it.
>
> I think this combination of two tests were made due to fear of too much
> overhead of creating a smal
On Tue, 30 Jan 2024 19:05:02 GMT, Magnus Ihse Bursie wrote:
> or was it just a premature optimization that is causing us headache now?
This one. When I did this originally, I thought why have another job when we
can stash some groups together? But the cost for additional job is not actually
th
See the description in the bug. This mitigates the issue by splitting out the
only test job that has two test suites in it.
-
Commit messages:
- Revert test breakage and touchups
- Break the tier1_compiler test and see what happens
- Fix
Changes: https://git.openjdk.org/jdk/pull/
On Thu, 25 Jan 2024 14:48:40 GMT, Aleksey Shipilev wrote:
> Current GHA runs produce lots of warnings:
>
> Node.js 16 actions are deprecated. Please update the following actions to use
> Node.js 20: actions/cache@v3, actions/download-artifact@v3,
> actions/upload-artifa
On Fri, 26 Jan 2024 19:33:49 GMT, Aleksey Shipilev wrote:
>> Current GHA runs produce lots of warnings:
>>
>> Node.js 16 actions are deprecated. Please update the following actions to
>> use Node.js 20: actions/cache@v3, actions/download-artifact@v3,
>> action
On Mon, 29 Jan 2024 11:23:55 GMT, Magnus Ihse Bursie wrote:
> To really "unpin" msys would be to require just a specific major version,
> like `msys2/setup-msys2@v2`. You are not doing that, and I don't recommend
> doing that. :-)
Right. I meant to say that we are effectively undoing the lates
On Fri, 26 Jan 2024 19:33:49 GMT, Aleksey Shipilev wrote:
>> Current GHA runs produce lots of warnings:
>>
>> Node.js 16 actions are deprecated. Please update the following actions to
>> use Node.js 20: actions/cache@v3, actions/download-artifact@v3,
>> action
On Fri, 26 Jan 2024 19:33:49 GMT, Aleksey Shipilev wrote:
>> Current GHA runs produce lots of warnings:
>>
>> Node.js 16 actions are deprecated. Please update the following actions to
>> use Node.js 20: actions/cache@v3, actions/download-artifact@v3,
>> action
On Mon, 29 Jan 2024 10:11:02 GMT, Severin Gehwolf wrote:
> Thanks for doing this cleanup! Seems fine to me. Not really sure how to test
> the msys2 pinning issue...
[We pinned it](https://bugs.openjdk.org/browse/JDK-8310259) because there were
weird failures in jtreg builds on Windows due to m
On Fri, 26 Jan 2024 19:33:49 GMT, Aleksey Shipilev wrote:
>> Current GHA runs produce lots of warnings:
>>
>> Node.js 16 actions are deprecated. Please update the following actions to
>> use Node.js 20: actions/cache@v3, actions/download-artifact@v3,
>> action
On Thu, 25 Jan 2024 14:48:40 GMT, Aleksey Shipilev wrote:
> Current GHA runs produce lots of warnings:
>
> Node.js 16 actions are deprecated. Please update the following actions to use
> Node.js 20: actions/cache@v3, actions/download-artifact@v3,
> actions/upload-artifa
e 20:
> https://github.com/msys2/setup-msys2/blob/main/CHANGELOG.md. I think we can
> unpin msys2 at this point.
>
> I don't think any of the migration problems outlined in those notes apply to
> our workflows.
>
> Additional testing:
> - [x] 3x GHA with cleaned ca
On Thu, 25 Jan 2024 12:02:35 GMT, Aleksey Shipilev wrote:
> When looking at [JDK-8324647](https://bugs.openjdk.org/browse/JDK-8324647), I
> was surprised to see that GHA has this output:
>
>
> Running test 'jtreg:test/lib-test:tier1'
> /home/runner/work/jdk/j
On Fri, 26 Jan 2024 08:42:36 GMT, Thomas Stuefe wrote:
> Is this problem also in older releases?
Yes, I think so. I'll backport it everywhere I can reach.
-
PR Comment: https://git.openjdk.org/jdk/pull/17568#issuecomment-1911680352
Current GHA runs produce lots of warnings:
Node.js 16 actions are deprecated. Please update the following actions to use
Node.js 20: actions/cache@v3, actions/download-artifact@v3,
actions/upload-artifact@v3. For more information see:
https://github.blog/changelog/2023-09-22-github-actions-tran
On Thu, 25 Jan 2024 12:02:35 GMT, Aleksey Shipilev wrote:
> When looking at [JDK-8324647](https://bugs.openjdk.org/browse/JDK-8324647), I
> was surprised to see that GHA has this output:
>
>
> Running test 'jtreg:test/lib-test:tier1'
> /home/runner/work/jdk/j
When looking at [JDK-8324647](https://bugs.openjdk.org/browse/JDK-8324647), I
was surprised to see that GHA has this output:
Running test 'jtreg:test/lib-test:tier1'
/home/runner/work/jdk/jdk/test/lib-test/TEST.groups: group all: group includes
itself
Error: One or more groups are invalid
Finis
On Tue, 23 Jan 2024 16:07:51 GMT, Magnus Ihse Bursie wrote:
> This pull request contains a backport of commit
> [9049402a](https://github.com/openjdk/jdk/commit/9049402a1b9394095b04287eef1f2d46c4da60e9)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit being back
On Tue, 23 Jan 2024 15:37:19 GMT, Magnus Ihse Bursie wrote:
> With [JDK-8318696](https://bugs.openjdk.org/browse/JDK-8318696), the explicit
> addition of -D_FILE_OFFSET_BITS=64 for two hotspot files in
> JvmOverrideFiles.gmk became unnecessary.
>
> I didn't think of checking this in the origin
On Thu, 11 Jan 2024 13:23:45 GMT, Julian Waters wrote:
>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Require clang 13 in toolchain.m4
For me,
On Mon, 15 Jan 2024 13:02:48 GMT, Magnus Ihse Bursie wrote:
> I did not think such a run would show up in the check status in the PR..? But
> maybe the bots are more intelligent than I give them credit for. 🤖 I'll try
> that next time, thanks!
They would show up here, just not instantaneously.
On Mon, 15 Jan 2024 11:23:32 GMT, Magnus Ihse Bursie wrote:
>> From the bug report:
>>
>> jdk/.github/scripts/gen-test-results.sh is capable of capture hs_err_* file
>> for erroneous and failed tests. They are also exposed under tag
>> `View HotSpot error log`.
>>
>> I think we can do the sam
On Fri, 12 Jan 2024 10:08:57 GMT, Magnus Ihse Bursie wrote:
> From the bug report:
>
> jdk/.github/scripts/gen-test-results.sh is capable of capture hs_err_* file
> for erroneous and failed tests. They are also exposed under tag
> `View HotSpot error log`.
>
> I think we can do the same thing
On Tue, 24 Oct 2023 01:36:32 GMT, Sam James wrote:
> The LFS64 symbols provided by glibc are not part of any standard and were
> gated behind -D_LARGEFILE64_SOURCE in musl 1.2.4 (to be removed in 1.2.5).
> This commit replaces the usage of LFS64 symbols with their regular
> counterparts and de
1 - 100 of 397 matches
Mail list logo
