Apparently Linux 86 is broken because Loom needs work for that port ..
so really completely ignore it for now.
-phil
On 5/22/22 3:21 PM, Philip Race wrote:
Oh and if it "x86" then it really isn't something you need to worry
about much
since "x64" is passing and maintaining x86 is someone's hobby perhaps
.. but
not a big issue for mainline. I don't know why we even have that there.
-phil
On 5/22/22 3:14 PM, Philip Race wrote:
Where are these files ? I can't see them.
Is it something under "Pre-submit tests - Linux x86" in the list of
"Some checks were not successful" ?
The reason I see for errors under there is just the odd
"Error: Unable to find an artifact with the name:
transient_jtreg_mickleness_88346f4d"
Means nothing to me I'm afraid.
And if you look at the open PRs
https://github.com/openjdk/jdk/pulls?q=type%3Apr+is%3Aopen+label%3Arfr
All of them seem to have *some* failures .. so I treat these as
completely untrustworthy
In any case NONE of the tests these actions will run are REMOTELY
related to anything you
can affect with changes to Path2D .. they only run hotspot, javac
compiler tests and some
very critical "core" tests for packages like java/lang
They run NO java.desktop tests *at all*
-phil.
On 5/22/22 2:56 PM, Jeremy Wood wrote:
I have a PR <https://github.com/openjdk/jdk/pull/8828> that is
failing <https://github.com/mickleness/jdk/actions/runs/2367246796>
some Linux pre-submit tests, but I don’t have a linux machine handy
to test against.
I tried running the tests 3 times in case the failure was random,
but it persists.
Any pointers on how to debug/resolve this? The error mentions:
# newfailures.txt
# other_errors.txt
Do those files explain the failures, and if so how do I access them?
If I can get to a place where I understand Java code that is failing
I can probably solve that, but I could use some help making sense of
this output.
Regards,
- Jeremy
