On Thu, 26 May 2022 16:07:56 GMT, Christoph Langer wrote:
> This fixes the Windows GHA test failures that popped up short time ago, e.g.
> [these](https://github.com/RealCLanger/jdk/runs/6598399845)
>
> Failing tests:
> tools/javac/Paths/MineField.sh
> tools/javac/Pa
On Thu, 26 May 2022 16:07:56 GMT, Christoph Langer wrote:
> This fixes the Windows GHA test failures that popped up short time ago, e.g.
> [these](https://github.com/RealCLanger/jdk/runs/6598399845)
>
> Failing tests:
> tools/javac/Paths/MineField.sh
> tools/javac/Pa
On Thu, 26 May 2022 16:07:56 GMT, Christoph Langer wrote:
> This fixes the Windows GHA test failures that popped up short time ago, e.g.
> [these](https://github.com/RealCLanger/jdk/runs/6598399845)
>
> Failing tests:
> tools/javac/Paths/MineField.sh
> tools/javac/Pa
On Thu, 26 May 2022 12:04:41 GMT, Magnus Ihse Bursie wrote:
> It is currently both tricky and tedious to figure out what went wrong when a
> jtreg test fails in GHA.
>
> We should utilize the full potential of GitHub Action summaries and error
> annotations to make finding failures easier and
On Thu, 26 May 2022 16:07:56 GMT, Christoph Langer wrote:
> This fixes the Windows GHA test failures that popped up short time ago, e.g.
> [these](https://github.com/RealCLanger/jdk/runs/6598399845)
>
> Failing tests:
> tools/javac/Paths/MineField.sh
> tools/javac/Pa
This fixes the Windows GHA test failures that popped up short time ago, e.g.
[these](https://github.com/RealCLanger/jdk/runs/6598399845)
Failing tests:
tools/javac/Paths/MineField.sh
tools/javac/Paths/wcMineField.sh
I've debugged it and it comes down to calls to javac/java in the test through
On Wed, 25 May 2022 17:17:12 GMT, Christoph Langer wrote:
> This fixes the issue on GHA when the branch contains a patch version.
>
> Here you can see the problem:
> https://github.com/openjdk-bots/jdk18u/actions/runs/2385040187
> And here you see how it looks if it's
On Wed, 25 May 2022 17:50:29 GMT, Aleksey Shipilev wrote:
>> This fixes the issue on GHA when the branch contains a patch version.
>>
>> Here you can see the problem:
>> https://github.com/openjdk-bots/jdk18u/actions/runs/2385040187
>> And here you see how it looks if it's fixed:
>>
This fixes the issue on GHA when the branch contains a patch version.
Here you can see the problem:
https://github.com/openjdk-bots/jdk18u/actions/runs/2385040187
And here you see how it looks if it's fixed:
https://github.com/RealCLanger/jdk18u/actions/runs/2384983103
I plan to backport this
On Tue, 24 May 2022 06:41:52 GMT, Christoph Langer wrote:
> It seems that it was forgotten to add the macOS aarch64 platform to the
> default platforms of workflow_dispatch. Let's fix this.
This pull request has now been integrated.
Changeset: f7a37f58
Author:Christoph Lange
It seems that it was forgotten to add the macOS aarch64 platform to the default
platforms of workflow_dispatch. Let's fix this.
-
Commit messages:
- JDK-8287202
Changes: https://git.openjdk.java.net/jdk/pull/8861/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8861=00
On Sat, 9 Apr 2022 07:10:50 GMT, Christoph Langer wrote:
> Let's update some github actions versions. No really interesting or breaking
> changes but we should stay current.
This pull request has now been integrated.
Changeset: 5851631d
Author:Christoph Langer
URL:
On Tue, 12 Apr 2022 10:13:37 GMT, Magnus Ihse Bursie wrote:
> Looks OK.
>
> But there is really a LOT of redundancy in this file! :-( It is in desperate
> need of some refactoring to keep it a bit more DRY.
I completely agree. Thanks for the review.
-
PR:
Let's update some github actions versions. No really interesting or breaking
changes but we should stay current.
-
Commit messages:
- Update github actions versions
Changes: https://git.openjdk.java.net/jdk/pull/8171/files
Webrev:
On Thu, 7 Apr 2022 07:53:38 GMT, Christoph Langer wrote:
> In GitHub Actions the step "Check that all tests executed successfully" will
> be marked as failing when the "Run tests" step did not run but some earlier
> step already failed. This is irritating and
On Thu, 7 Apr 2022 15:29:59 GMT, Magnus Ihse Bursie wrote:
>> In GitHub Actions the step "Check that all tests executed successfully" will
>> be marked as failing when the "Run tests" step did not run but some earlier
>> step already failed. This is irritating and it can be corrected by doing
On Thu, 7 Apr 2022 07:53:38 GMT, Christoph Langer wrote:
> In GitHub Actions the step "Check that all tests executed successfully" will
> be marked as failing when the "Run tests" step did not run but some earlier
> step already failed. This is irritating and
In GitHub Actions the step "Check that all tests executed successfully" will be
marked as failing when the "Run tests" step did not run but some earlier step
already failed. This is irritating and it can be corrected by doing the test
check only if testing was not skipped.
Here is a link to
On Tue, 5 Apr 2022 20:57:45 GMT, Christoph Langer wrote:
> Make cygwin usage in GHA more reliable
>
> With this change we now attempt to retrieve the cygwin installer from cache
> every time we need it.
> We would also only try to download it once per build job, in the begi
On Wed, 6 Apr 2022 11:12:39 GMT, Christoph Langer wrote:
>> Make cygwin usage in GHA more reliable
>>
>> With this change we now attempt to retrieve the cygwin installer from cache
>> every time we need it.
>> We would also only try to download it once p
ill make potential errors
> more obvious
> (e.g. in the download step in the beginning of the build).
>
> I also replaced actions/cache@v2 with v3. Didn't see issues.
Christoph Langer has updated the pull request incrementally with one additional
commit since the last revision:
On Wed, 6 Apr 2022 07:40:41 GMT, Aleksey Shipilev wrote:
> Let's not switch `v2` -> `v3` in this PR.
You're right. I'll do another PR to update the actions versions. There are also
updates possible for upload and donwload actions.
> So `windows_aarch64_build`, `windows_x64_build` checks the
Make cygwin usage in GHA more reliable
With this change we now attempt to retrieve the cygwin installer from cache
every time we need it.
We would also only try to download it once per build job, in the beginning.
During testing we rely on it being cached which will make potential errors more
On Wed, 12 Jan 2022 09:42:07 GMT, Johannes Bechberger
wrote:
> Simple change to `make/autoconf/toolchain.m4` to fix the bug as described in
> its title and description.
You’re too quick. This needs a review from somebody in the build group.
-
PR:
On Mon, 3 Jan 2022 11:34:14 GMT, Aleksey Shipilev wrote:
> Current GHA workflow only prints `newfailures.txt` when tests fail. But the
> tests can also "ERROR" out. In which case, we want to print
> `other_errors.txt` as well. In current mainline GHA, we have a x86_32
> langtools_tier1
On Wed, 10 Nov 2021 10:39:04 GMT, Aleksey Shipilev wrote:
> It is my mistake. Sorry for rushing and breaking the etiquette. I will ensure
> that this does not happen again.
That was also my mistake (probably even more than Anirvan's) since I sponsored
this too early and I should have taken
On Tue, 9 Nov 2021 20:47:29 GMT, Anirvan Sarkar wrote:
> Use version `3.2.0` of `cygwin` instead of latest version `3.3.2` on GitHub
> Actions.
> `make` SEGVs on the latest version.
>
> Version number format obtained from
> https://cygwin.com/packages/summary/cygwin.html
Cool. Thanks for
On Fri, 23 Jul 2021 14:04:35 GMT, Matthias Baesken wrote:
>> Please review the following change.
>> On SUSE Linux 15 configure was running into this error, because of a missing
>> X11 header :
>>
>> checking for X11/extensions/Xrandr.h... no
>> configure: error: Could not find all X11 headers
On Fri, 23 Jul 2021 08:18:48 GMT, Matthias Baesken wrote:
> > Makes sense to me.
>
> Hi Christoph, thanks for looking into it. Should we do the same for the other
> package managers in the case statement (like yum, apt-get) as well ? I only
> observed it on SLES15 (where zypper was detected)
On Thu, 22 Jul 2021 13:42:09 GMT, Matthias Baesken wrote:
> Please review the following change.
> On SUSE Linux 15 configure was running into this error, because of a missing
> X11 header :
>
> checking for X11/extensions/Xrandr.h... no
> configure: error: Could not find all X11 headers
On Wed, 7 Apr 2021 18:48:01 GMT, Lutz Schmidt wrote:
>> May I please request reviews for this small build fix. It removes a linker
>> warning by adding a assembly-time parameter which was previously missing.
>> The same parameter is used at c++ compile time.
>
> Lutz Schmidt has updated the
On Thu, 7 Jan 2021 22:47:35 GMT, Christoph Langer wrote:
> 8258484: AIX build fails in Harfbuzz with XLC 16.01..0006
This pull request has now been integrated.
Changeset: 677802d2
Author: Christoph Langer
URL: https://git.openjdk.java.net/jdk16/commit/677802d2
Stats: 6 li
8258484: AIX build fails in Harfbuzz with XLC 16.01..0006
-
Commit messages:
- Backport 3f9f86f0d3f918b9955ba6ba73c9c58ae8fcf7cb
Changes: https://git.openjdk.java.net/jdk16/pull/95/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk16=95=00
Issue:
On Thu, 7 Jan 2021 09:19:27 GMT, Matthias Baesken wrote:
>> Hello, for a while the AIX build fails with the following error in the
>> harfbuzz build
>> 1500-004: (U) INTERNAL COMPILER ERROR while compiling
>>
On Wed, 11 Nov 2020 12:35:07 GMT, Matthias Baesken wrote:
> The script make/autoconf/configure should give a bit more output in case
> various errors occur (e.g. missing autoconf).
> The new output in case of missing autoconf adds the PATH; additionally we
> show on AIX some info on how to
On Thu, 22 Oct 2020 08:55:09 GMT, Aleksey Shipilev wrote:
> Bisection shows it started to happen after
> [JDK-8253660](https://bugs.openjdk.java.net/browse/JDK-8253660). I believe
> `toString()` there is not very resilient in the face of `null` causes.
>
> Example output:
> $ make run-test
36 matches
Mail list logo
