The hdf5_vol_rest_fetchcontent job fails at "Install HSDS dependencies"
because HSDS pins numpy==2.4.6, which publishes no distributions for
Python 3.10:
ERROR: Could not find a version that satisfies the requirement
numpy==2.4.6 (from versions: ... 2.2.5, 2.2.6)
numpy 2.4.6 declares requires_python >= 3.11, and HSDS's pyproject.toml
now says requires-python = ">=3.11". Move the matrix to Python 3.12,
which is what HSDS uses for its own unix-socket test job - the same
configuration this job exercises.
Also drop the "Fix requests version" step that force-downgraded to
requests==2.31.0. HSDS now pins requests-unixsocket==0.4.1, which fixed
the requests 2.32 breakage that step worked around, so the downgrade only
fights HSDS's own pins. Upstream HSDS has already commented the same step
out of its socket-test job.
Fixes#6657
Claude-Session: https://claude.ai/code/session_011qUw9C11arB1WftiT56EA4
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
HDF5 discovers Java twice, through mechanisms with opposite search
precedence, and never reconciles them:
find_package(Java) in CMakeLists.txt sets Java_JAVA_EXECUTABLE,
Java_JAVAC_EXECUTABLE and Java_VERSION_STRING. FindJava searches
JAVA_HOME via HINTS, which outrank $PATH.
project(HDF5_JAVA C Java) in java/CMakeLists.txt sets
CMAKE_Java_COMPILER/RUNTIME/ARCHIVE. CMakeDetermineJavaCompiler searches
$ENV{JAVA_HOME}/bin only as a PATHS entry, the lowest priority slot,
below $PATH, and ignores the CMake variable JAVA_HOME entirely.
When JAVA_HOME and PATH refer to different JDKs the two diverge, so the
FFM/JNI version gate in java/CMakeLists.txt is evaluated against one JDK
while the code is compiled and tested with another. On macOS both resolve
to the /usr/bin stubs, which re-select a JDK from JAVA_HOME on every
invocation, so javac and java can differ inside a single build and every
Java test fails to load its class files with UnsupportedClassVersionError.
Propagate the probed toolchain before the Java language is enabled, filling
each variable independently. The guard in CMakeDetermineJavaCompiler.cmake
is if(NOT CMAKE_Java_COMPILER) and it closes only after the runtime and
archive lookups, so a caller passing just
-DJAVA_HOME=$JAVA_HOME -DCMAKE_Java_COMPILER=$JAVA_HOME/bin/javac
suppresses the other two lookups entirely and ends up with an empty
CMAKE_Java_RUNTIME and an empty TEST_JAVA in the generated CTest files.
Filling them one at a time keeps an explicit override working while still
completing the toolchain.
Verified two ways. Configuring with PATH -> JDK 11 and JAVA_HOME -> JDK 20
previously reported Java 20 and selected the JNI implementation while
CMAKE_Java_COMPILER, CMAKE_Java_RUNTIME and the generated TEST_JAVA all
pointed at JDK 11; they now all resolve to JDK 20. On macOS 26 arm64 with
JAVA_HOME -> JDK 25 the same build went from 95 failing Java tests to none.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
On SunOS the C and C++ flag files appended the single string
"-erroff=%none -DBSD_COMP" to HDF5_CMAKE_C/CXX_FLAGS. Because that is one
list element, target_compile_options() hands it to the compiler as one
argument, and -erroff is an Oracle Developer Studio option to begin with.
gcc silently ignores the result (it parses the leading -e as the linker
entry-symbol option), but clang errors out:
clang: error: unknown argument: '-erroff=%none -DBSD_COMP'
which breaks the build on the first object file. As a side effect,
-DBSD_COMP was never actually reaching the compiler as a define.
Emit -erroff=%none only for SunPro, and append -DBSD_COMP as its own list
element so it is passed as a separate argument on all Solaris compilers.
Fixes#6569
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
The HDF-EOS5 compatibility test downloads a source tarball from
git.earthdata.nasa.gov, an external host that has proven unreliable and
frequently times out, causing spurious PR-check failures unrelated to the
code under review.
Move the test off the pull_request/push triggers onto a daily schedule
(plus workflow_dispatch) so transient network failures no longer block PR
merges, while still catching genuine HDF-EOS5 regressions on a daily
cadence. Guard the job with an owner check so it does not run on forks.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Update NVHPC version from 25.7 to 25.9
- Update CUDA version from 12.9 to 13.0
- Update MPI paths from openmpi4/bin to hpcx/bin
This aligns with the latest NVHPC SDK distribution which uses hpcx for MPI libraries.
* Set UCX_WARN_UNUSED_ENV_VARS to 'n' in workflow
Closes#5917
We don't test parallel in other GitHub actions, so this also converts the
NVHPC check to configure and build only while we discuss how we'll
test parallel HDF5 in GitHub.
There is a blocking GitHub issue to address the test failures for
HDF5 1.14.5 (#4571).
H. Joe LeeandClaude Opus 5