On Thu, 3 Apr 2025 21:41:21 GMT, Phil Race wrote:
> works for me on Windows 11 aarch64 generated the right configure and the
> build seems to be doing aarch64 things.
same here.
backported it locally to 21u and it works there, too.
thx
Have you made it work with WSL2? made the configure work
On Wed, 2 Apr 2025 23:25:28 GMT, Magnus Ihse Bursie wrote:
> Configure does not properly detect Windows/aarch64 on Cygwin. One
> complicating factor here is that no native aarch64 version of Cygwin exists,
> so it is running x64 binaries in emulated mode.
Marked as reviewed by skateb...@github
ll exit the VM and only if symbol files are
> available (which is normally not the case when using Java release builds as a
> user).
>
> Special thanks to @tschatzl for giving me some pointers to start based on his
> knowledge from a DWARF 2 parser he once wrote in Pascal and f
ll exit the VM and only if symbol files are
> available (which is normally not the case when using Java release builds as a
> user).
>
> Special thanks to @tschatzl for giving me some pointers to start based on his
> knowledge from a DWARF 2 parser he once wrote in Pascal and fo
On Mon, 8 Apr 2024 09:20:44 GMT, Daniel Jeliński wrote:
> The RejectedExecutionException was thrown when the thread executing
> `Server.start` managed to shut down the `compilerThreadPool` before the
> thread executing `Server.handleRequest` submitted the compilation task.
>
> This patch remov
On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan wrote:
> Hi all,
> This PR several extra empty spaces and extra empty lines in several
> Makefiles. It's trivial fix, no risk.
>
> Thanks.
Looks good! Somehow the integrate command did not work.
-
Marked as reviewed by chagedorn (Revie
Please review the change to update to using `jtreg` **7.4**.
The primary change is to the `jib-profiles.js` file, which specifies the
version of jtreg to use, for those systems that rely on this file. In addition,
the `requiredVersion` has been updated in the various `TEST.ROOT` files.
Testing:
On Thu, 2 May 2024 09:48:51 GMT, Christian Stein wrote:
> Please review the change to update to using `jtreg` **7.4**.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
>
On Thu, 2 May 2024 09:48:51 GMT, Christian Stein wrote:
> Please review the change to update to using `jtreg` **7.4**.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
>
On Thu, 2 May 2024 09:48:51 GMT, Christian Stein wrote:
> Please review the change to update to using `jtreg` **7.4**.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
>
ll exit the VM and only if symbol files are
> available (which is normally not the case when using Java release builds as a
> user).
>
> Special thanks to @tschatzl for giving me some pointers to start based on his
> knowledge from a DWARF 2 parser he once wrote in Pascal and fo
On Tue, 16 Aug 2022 08:07:52 GMT, Christian Hagedorn
wrote:
>> When printing the native stack trace on Linux (mostly done for hs_err
>> files), it only prints the method with its parameters and a relative offset
>> in the method:
>>
>> Stack: [0x7f6e017
Please review the change to update to using jtreg 7.
The primary change is to the `jib-profiles.js` file, which specifies the
version of jtreg to use, for those systems that rely on this file. In addition,
the `requiredVersion` has been updated in the various `TEST.ROOT` files.
-
C
On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the `
.ROOT`
> files.
Christian Stein has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 10 commits:
- Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
- Revert junit.java
Commit
https://g
.ROOT`
> files.
Christian Stein has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 11 commits:
- Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
- Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
-
.ROOT`
> files.
Christian Stein has updated the pull request incrementally with one additional
commit since the last revision:
Update configure to check for jtreg 7 or later
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9393/files
- new: https://git.openjdk.org/jdk/pull/9
.ROOT`
> files.
Christian Stein has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 13 commits:
- Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
- Update configure to check for jtreg 7 or later
- Merge branch '
On Tue, 16 Aug 2022 08:07:52 GMT, Christian Hagedorn
wrote:
>> When printing the native stack trace on Linux (mostly done for hs_err
>> files), it only prints the method with its parameters and a relative offset
>> in the method:
>>
>> Stack: [0x7f6e017
On Tue, 16 Aug 2022 08:07:52 GMT, Christian Hagedorn
wrote:
>> When printing the native stack trace on Linux (mostly done for hs_err
>> files), it only prints the method with its parameters and a relative offset
>> in the method:
>>
>> Stack: [0x7f6e017
On Tue, 18 Jan 2022 13:19:39 GMT, Christian Hagedorn
wrote:
> When printing the native stack trace on Linux (mostly done for hs_err files),
> it only prints the method with its parameters and a relative offset in the
> method:
>
> Stack: [0x7f6e01739000,0x7f6
On Tue, 30 Aug 2022 09:14:12 GMT, Jaikiran Pai wrote:
> Hello Christian, is it intentional that in some file the minimum required
> jtreg version is represented as `7` (`lib-tests.m4`) and in some other files
> as `7+1` (GitHub actions config file, then the TEST.ROOT files)?
Yes. Som
.ROOT`
> files.
Christian Stein has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 14 commits:
- Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
- Merge branch 'openjdk:master' into JDK-8289798-jtreg-7
- Up
On Mon, 5 Sep 2022 06:36:04 GMT, Thomas Stuefe wrote:
> Is jtreg 7 downward compatible? Can I use it to test older JDKs, if yes, down
> to which version?
Yes, down to JDK 11.
Quote from [Coming soon: jtreg
7](https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006869.html)
> Also starting
On Mon, 5 Sep 2022 07:38:33 GMT, Thomas Stuefe wrote:
> So I guess at the minimum we would have to downport those test changes to be
> able to test older JDKs with the new jtreg, right?
Yes. Otherwise those tests will fail as they still do depend on hard-coded
names of 3rd-party JAR files. Fin
On Wed, 6 Jul 2022 08:24:21 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
> addition, the `
On Tue, 4 Oct 2022 22:20:57 GMT, Mikael Vidstedt wrote:
> With the JDK 19 GA out it's time to bump the minimum boot JDK version for
> mainline/JDK 20.
>
> Testing: tier1-5, GHA builds
Marked as reviewed by ctornqvi (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/10564
On Tue, 11 Oct 2022 08:18:08 GMT, Christian Hagedorn
wrote:
>> The DWARF debugging symbols emitted by Clang is different from what GCC is
>> emitting. While GCC produces a complete `.debug_aranges` section (which is
>> required in the DWARF parser), Clang does not. As a
On Wed, 12 Oct 2022 14:28:02 GMT, Magnus Ihse Bursie wrote:
> If is is a big change or not depends on how it affects builds on macos. I
> assume that clang functionality that was published in 2017 is already
> incorporated in the minimum supported version of Xcode on mac. (This needs to
> be v
On Tue, 11 Oct 2022 08:18:08 GMT, Christian Hagedorn
wrote:
>> The DWARF debugging symbols emitted by Clang is different from what GCC is
>> emitting. While GCC produces a complete `.debug_aranges` section (which is
>> required in the DWARF parser), Clang does not. As a
On Tue, 11 Oct 2022 08:18:08 GMT, Christian Hagedorn
wrote:
>> The DWARF debugging symbols emitted by Clang is different from what GCC is
>> emitting. While GCC produces a complete `.debug_aranges` section (which is
>> required in the DWARF parser), Clang does not. As a
On Tue, 11 Oct 2022 08:18:08 GMT, Christian Hagedorn
wrote:
>> The DWARF debugging symbols emitted by Clang is different from what GCC is
>> emitting. While GCC produces a complete `.debug_aranges` section (which is
>> required in the DWARF parser), Clang does not. As a
On Wed, 16 Nov 2022 13:22:43 GMT, Magnus Ihse Bursie wrote:
> The sjavac ("smart javac") was an ambitious project. It should parallelize
> java compilation, create a background daemon process that kept the JVM "hot"
> with the JITted javac code, define a public api so only noticeable changes in
On Wed, 16 Nov 2022 14:06:16 GMT, Erik Joelsson wrote:
> Or is the replacement so imminent that it's not worth the effort?
This. I aim to replace `javacserver` with a well-tested `javatoolportal`
buildtool in the coming months. An almost working POC is already available -
but forcing it to go
On Wed, 16 Nov 2022 12:23:50 GMT, Thomas Stuefe wrote:
>> Christian Hagedorn 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
On Wed, 16 Nov 2022 11:59:19 GMT, Thomas Stuefe wrote:
>> Christian Hagedorn 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
On Wed, 16 Nov 2022 16:07:36 GMT, Thomas Stuefe wrote:
>> In theory, they don't need to be exposed in the sense of being declared in
>> the header. But in terms of readability, I've decided to put them in the
>> private block of class `LineNumberProgram` which is the only user of these
>> meth
lang__` `ifdef` to bail out in `get_source_info()` and disable
> the `gtests`. I've noticed that we are currently running the `gtests` with
> `NOT PRODUCT` which I think is not necessary - the gtests should also work
> fine with product builds. I've corrected this as well but tha
lang__` `ifdef` to bail out in `get_source_info()` and disable
> the `gtests`. I've noticed that we are currently running the `gtests` with
> `NOT PRODUCT` which I think is not necessary - the gtests should also work
> fine with product builds. I've corrected this as well but tha
On Wed, 16 Nov 2022 08:48:51 GMT, Thomas Stuefe wrote:
>> Yes, I think it would be good to get a second review of the DWARF parser
>> changes. Maybe @tstuefe?
>
>> Yes, I think it would be good to get a second review of the DWARF parser
>> changes. Maybe @tstuefe?
>
> I'm a bit swamped, but tr
On Fri, 18 Nov 2022 16:06:38 GMT, Christian Hagedorn
wrote:
>> The DWARF debugging symbols emitted by Clang is different from what GCC is
>> emitting. While GCC produces a complete `.debug_aranges` section (which is
>> required in the DWARF parser), Clang does not. As a
lang__` `ifdef` to bail out in `get_source_info()` and disable
> the `gtests`. I've noticed that we are currently running the `gtests` with
> `NOT PRODUCT` which I think is not necessary - the gtests should also work
> fine with product builds. I've corrected this as well but tha
On Wed, 21 Sep 2022 10:47:38 GMT, Thomas Schatzl wrote:
>> Thanks Thomas for that link. I was not aware of this `-gdwarf-aranges` flag.
>> I've tried it out and it indeed seems to work. But I was not able to build
>> with `-flto=thin` as it resulted in build failures. So, I'm not sure what
>>
On Thu, 15 Sep 2022 11:59:08 GMT, Christian Hagedorn
wrote:
> The DWARF debugging symbols emitted by Clang is different from what GCC is
> emitting. While GCC produces a complete `.debug_aranges` section (which is
> required in the DWARF parser), Clang does not. As a result, the DWA
On Tue, 22 Nov 2022 23:40:30 GMT, Magnus Ihse Bursie wrote:
>> Now that the javacserver no longer has any ambitions outside being a
>> buildtool customized for the JDK build process, a lot of abstractions and
>> generalizations can be removed.
>>
>> This will allow the actual behavior to be mo
Please review the change to update to using jtreg `7.1`.
The primary change is to the `jib-profiles.js` file, which specifies the
version of jtreg to use, for those systems that rely on this file. In addition,
the requiredVersion has been updated in the various `TEST.ROOT` files.
This pull requ
On Tue, 29 Nov 2022 14:44:12 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg `7.1`.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
>
Please review the change to update to using jtreg 7.1.1.
The primary change is to the `jib-profiles.js` file, which specifies the
version of jtreg to use, for those systems that rely on this file. In addition,
the requiredVersion has been updated in the various `TEST.ROOT` files.
This pull requ
On Tue, 6 Dec 2022 16:07:44 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.1.1.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
>
On Tue, 6 Dec 2022 16:07:44 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.1.1.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
>
.ROOT`
> files.
>
> This pull request was created by copying the following and using 7.1.1 at
> appropriate places:
> - https://github.com/openjdk/jdk/pull/11416
Christian Stein has updated the pull request incrementally with two additional
commits since the last revision:
.ROOT`
> files.
>
> This pull request was created by copying the following and using 7.1.1 at
> appropriate places:
> - https://github.com/openjdk/jdk/pull/11416
Christian Stein has refreshed the contents of this pull request, and previous
commits have been removed. Incremental vie
On Tue, 6 Dec 2022 17:45:06 GMT, Christian Stein wrote:
>> Please review the change to update to using jtreg 7.1.1.
>>
>> The primary change is to the `jib-profiles.js` file, which specifies the
>> version of jtreg to use, for those systems that rely on this fi
On Tue, 6 Dec 2022 16:07:44 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.1.1.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
>
Please review the change to update to using jtreg 7.2.
The primary change is to the `jib-profiles.js` file, which specifies the
version of jtreg to use, for those systems that rely on this file. In addition,
the requiredVersion has been updated in the various `TEST.ROOT` files.
-
C
On Mon, 17 Apr 2023 14:56:16 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.2.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
>
Please review this change to use the pre-installed JDK 17 for building jtreg
when running on GitHub Actions.
-
Commit messages:
- Use JDK 17 to build jtreg
Changes: https://git.openjdk.org/jdk/pull/14448/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14448&range=00
Issue
> Please review this change to use the pre-installed JDK 17 for building jtreg
> when running on GitHub Actions.
Christian Stein has updated the pull request incrementally with one additional
commit since the last revision:
Update action.yml
-
Changes:
- all:
On Tue, 13 Jun 2023 13:38:16 GMT, Christian Stein wrote:
> Please review this change to use the pre-installed JDK 17 for building jtreg
> when running on GitHub Actions.
This pull request has now been integrated.
Changeset: 8aad881e
Author:Christian Stein
URL:
On Wed, 14 Jun 2023 09:49:33 GMT, Thomas Stuefe wrote:
> Do you know why this helped?
No, unfortunately not: _"Switching from 11 to 17 seems to mend the (unknown
underlying) issue for the time being."_
A test build using the same JDK as pre-installed on GitHub-hosted runners on my
local machin
Hi all,
This pull request contains a backport of commit
[8aad881e](https://github.com/openjdk/jdk/commit/8aad881e803fddc26f45270f779ff0c0e5a095d8)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Christian Stein on 13 Jun 2023 and
was
On Wed, 14 Jun 2023 12:39:00 GMT, Martin Doerr wrote:
> Could you enable GitHub Actions and run the tests, please?
I enabled workflows on the fork the bot created for me - how do I trigger a run
now? Manually via
https://github.com/openjdk-bots/jdk21/actions/workflows/main.yml and use the
def
> Hi all,
>
> This pull request contains a backport of commit
> [8aad881e](https://github.com/openjdk/jdk/commit/8aad881e803fddc26f45270f779ff0c0e5a095d8)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit being backported was authored by Chri
On Wed, 14 Jun 2023 18:45:04 GMT, Christian Stein wrote:
>> Hi all,
>>
>> This pull request contains a backport of commit
>> [8aad881e](https://github.com/openjdk/jdk/commit/8aad881e803fddc26f45270f779ff0c0e5a095d8)
>> from the [openjdk/jdk](https://git.openjdk.o
On Wed, 14 Jun 2023 10:07:01 GMT, Christian Stein wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [8aad881e](https://github.com/openjdk/jdk/commit/8aad881e803fddc26f45270f779ff0c0e5a095d8)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
Please review this change to use the boot JDK for building jtreg when running
on GitHub Actions.
This is a best-effort follow-up change to
- #14448
which didn't have the desired results - the `Bad address` error does still
appear with using the pre-installed JDKs 11 and 17.
Tests using the boot
On Fri, 16 Jun 2023 08:45:01 GMT, Aleksey Shipilev wrote:
> Wait, so why does it fix the bug? Is it a MSYS path conversion bug?
It does not fix the bug, it works around it. Something (in MSYS) failes to work
(calling `javac`) that used to work without problem until some week ago (new
version o
On Fri, 16 Jun 2023 06:05:16 GMT, Christian Stein wrote:
> Please review this change to use the boot JDK for building jtreg when running
> on GitHub Actions.
>
> This is a best-effort follow-up change to
> - #14448
> which didn't have the desired results - the `Bad ad
On Fri, 16 Jun 2023 11:14:10 GMT, Jaikiran Pai wrote:
>> Please review this change to use the boot JDK for building jtreg when
>> running on GitHub Actions.
>>
>> This is a best-effort follow-up change to
>> - #14448
>> which didn't have the desired results - the `Bad address` error does still
On Fri, 16 Jun 2023 06:05:16 GMT, Christian Stein wrote:
> Please review this change to use the boot JDK for building jtreg when running
> on GitHub Actions.
>
> This is a best-effort follow-up change to
> - #14448
> which didn't have the desired results - the `Bad ad
On Fri, 16 Jun 2023 11:14:10 GMT, Jaikiran Pai wrote:
>> Please review this change to use the boot JDK for building jtreg when
>> running on GitHub Actions.
>>
>> This is a best-effort follow-up change to
>> - #14448
>> which didn't have the desired results - the `Bad address` error does still
On Fri, 16 Jun 2023 11:08:41 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to address the recent
> github actions failures?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8310259 the commit in this PR
> pins the `msys2/setup-msys2` to a previous releas
On Mon, 19 Jun 2023 11:39:21 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which backports the fixes for
> https://bugs.openjdk.org/browse/JDK-8310259?
>
> This wasn't a clean backport because this also brings in
> https://bugs.openjdk.org/browse/JDK-8309934 which in theo
Please review the change to update to using jtreg 7.3.
The primary change is to the `jib-profiles.js` file, which specifies the
version of jtreg to use, for those systems that rely on this file. In addition,
the `requiredVersion` has been updated in the various `TEST.ROOT` files.
Testing: tier1
On Wed, 26 Jul 2023 09:06:19 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.3.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
>
On Wed, 16 Aug 2023 11:45:54 GMT, Coleen Phillimore wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Make elf fields 64 bits removing some static casts.
>
> src/hotspot/share/utilities/elfFile.cpp line 1426:
>
On Wed, 16 Aug 2023 12:33:47 GMT, Coleen Phillimore wrote:
>> When we read the 64 bit values in the code, the values are 64 bits though.
>> So static_cast<> to narrow the result is more correct ?
>
> This code:
>
> uint64_t isa;
> if (!_reader.read_uleb128(&isa, 4)) {
> //
On Thu, 17 Aug 2023 02:06:22 GMT, David Holmes wrote:
>> src/hotspot/share/utilities/elfFile.hpp line 486:
>>
>>> 484: DwarfFile* _dwarf_file;
>>> 485: MarkedDwarfFileReader _reader;
>>> 486: uintptr_t _section_start_address;
>>
>> This seems suspicious - is this a 32-bit value or 6
ss it's fine to just go with a `static_cast` when storing to a field
>> for the few cases we have.
>
> Thanks Christian. I'll revert to use the static cast. One of the cases has
> a comment why.
That looks good!
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15233#discussion_r1296820975
On Thu, 17 Aug 2023 01:01:02 GMT, Coleen Phillimore wrote:
>> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion
>> warnings in runtime code. This is the last one I'm going to do for runtime
>> for a while.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pul
On Thu, 17 Aug 2023 12:37:03 GMT, Coleen Phillimore wrote:
>> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion
>> warnings in runtime code. This is the last one I'm going to do for runtime
>> for a while.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pul
Please review the change to update to using jtreg 7.3,1.
The primary change is to the `jib-profiles.js` file, which specifies the
version of jtreg to use, for those systems that rely on this file. In addition,
the `requiredVersion` has been updated in the various `TEST.ROOT` files.
This change
On Thu, 17 Aug 2023 07:24:14 GMT, Christian Stein wrote:
> Please review the change to update to using jtreg 7.3,1.
>
> The primary change is to the `jib-profiles.js` file, which specifies the
> version of jtreg to use, for those systems that rely on this file. In
>
Please review this change to update all workflows to use `actions/checkout@v4`.
Find the associated release notes here:
https://github.com/actions/checkout/releases/tag/v4.0.0
-
Commit messages:
- 8315863: [GHA] Update checkout action to use v4
Changes: https://git.openjdk.org/jdk
On Thu, 7 Sep 2023 14:47:41 GMT, Christian Stein wrote:
> Please review this change to update all workflows to use
> `actions/checkout@v4`.
>
> Find the associated release notes here:
> https://github.com/actions/checkout/releases/tag/v4.0.0
Mainly because the underlying Node
On Thu, 7 Sep 2023 14:47:41 GMT, Christian Stein wrote:
> Please review this change to update all workflows to use
> `actions/checkout@v4`.
>
> Find the associated release notes here:
> https://github.com/actions/checkout/releases/tag/v4.0.0
This pull request has now
On Thu, 7 Sep 2023 16:16:36 GMT, Aleksey Shipilev wrote:
> Please wait for GHA to complete before integrating GHA patches!
Yes, sure. Next time, I'll wait for completion - this time, I checked that
`actions/checkout@v4` steps were successfully run in
https://github.com/openjdk/jdk/pull/15620/c
On Thu, 10 Oct 2024 06:36:13 GMT, Christian Hagedorn
wrote:
> [JDK-8338884](https://bugs.openjdk.org/browse/JDK-8338884) is causing build
> failures on linux-x64 in tier1 in our CI:
>
> [2024-10-10T01:31:30,270Z] ERROR: Build failed for target 'default
> (product-bundles
On Thu, 10 Oct 2024 06:36:13 GMT, Christian Hagedorn
wrote:
> [JDK-8338884](https://bugs.openjdk.org/browse/JDK-8338884) is causing build
> failures on linux-x64 in tier1 in our CI:
>
> [2024-10-10T01:31:30,270Z] ERROR: Build failed for target 'default
> (product-bundles
x27;
[2024-10-10T01:31:30,298Z]96 | pid_t pid;
[2024-10-10T01:31:30,298Z] | ^
Let's back this change out (pinging @sendaoYan). Revert was clean.
I created a [REDO](https://bugs.openjdk.org/browse/JDK-8341881).
Thanks,
Christian
-
Commit mess
On Tue, 29 Oct 2024 12:40:59 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Mon, 28 Oct 2024 12:29:07 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Fri, 25 Oct 2024 20:13:52 GMT, Roger Riggs wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 150 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>> - Merge
>> - Update
On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote:
> Currently, the man pages are stored as troff (a text format) in the open
> repo, and a content-wise identical copy is stored as markdown (another text
> format) in the closed repo.
>
> Since markdown is preferred to troff in terms o
On Fri, 15 Nov 2024 14:46:33 GMT, Magnus Ihse Bursie wrote:
>> Currently, the man pages are stored as troff (a text format) in the open
>> repo, and a content-wise identical copy is stored as markdown (another text
>> format) in the closed repo.
>>
>> Since markdown is preferred to troff in te
On Fri, 15 Nov 2024 14:50:21 GMT, Magnus Ihse Bursie wrote:
>> Currently, the man pages are stored as troff (a text format) in the open
>> repo, and a content-wise identical copy is stored as markdown (another text
>> format) in the closed repo.
>>
>> Since markdown is preferred to troff in te
On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote:
> Currently, the man pages are stored as troff (a text format) in the open
> repo, and a content-wise identical copy is stored as markdown (another text
> format) in the closed repo.
>
> Since markdown is preferred to troff in terms o
1 - 100 of 114 matches
Mail list logo
