Bump Score-P to v10.1 & OPARI2 to v2.0.10 - #2665
Conversation
📦 Package Count Analysis ResultsEnvironment: UBI 10 Container 🏭 Factory RepositoriesStatus: ✅ Factory repositories analysis completed successfully
Analysis performed by OpenHPC Package Count CI |
There was a problem hiding this comment.
Pull request overview
Updates the OpenHPC packaging and validation for the Score-P performance tool stack by bumping Score-P and OPARI2 to newer upstream releases, and removing now-obsolete Score-P v10.0 workaround artifacts.
Changes:
- Bump Score-P RPM spec from 10.0 to 10.1 and drop the Intel MPI linker workaround patch and related install-time symlink workaround.
- Bump OPARI2 RPM spec from 2.0.9 to 2.0.10.
- Update the Score-P test to validate the presence of the current license documentation file (
README.LICENSES.md) instead of the olderCOPYINGpath.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| tests/perf-tools/scorep/tests/test_module | Updates license-file availability check for the new Score-P doc layout. |
| components/serial-libs/opari2/SPECS/opari2.spec | Bumps OPARI2 packaged version to 2.0.10. |
| components/perf-tools/scorep/SPECS/scorep.spec | Bumps Score-P to 10.1 and removes v10.0-only patch/symlink workarounds. |
| components/perf-tools/scorep/SOURCES/Score-P-10.0_fix-intel-mpi-linker-error.patch | Removes obsolete v10.0 Intel MPI linker workaround patch. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
🚀 CCache Statistics
📊 Detailed StatisticsopenEuler (aarch64)openEuler (x86_64)RHEL (aarch64/gnu15)RHEL (x86_64/gnu15)RHEL (x86_64/intel)🤖 Generated from workflow run |
|
Some tests are failing with: I'm guessing Score-P was built with the old OPARI2 in the CI, but then the new version of this PR was installed, causing the error? |
|
@adrianreber I probably need to split OPARI2 and Score-P into two PRs again, right? |
In theory that is no longer necessary. There is a step to calculate the right order. I can take a look later today. |
|
Build order analysis failed on openEuler: This needs to be fixed. It works on RHEL. On RHEL based clones the test failures is because of mvapich tests are failing. They work sometimes but sometimes they don't. You can add a commit that removes the lines 145-147 in tests/ci/setup_slurm_and_run_tests.sh. This should fix the failures on RHEL and clones. If you are motivated you can also take a look at the build order analysis error on openEuler. As we do not build the lustre package for a long time you could probably just skip any lustre based build order analysis. There is already some code to ignore errors. Let me know if you do not want to deal with this then I can do it. |
Thanks for the pointer. I probably won't have the time to look into why the build order analysis fails on openEuler, due to courses and upcoming vacation. |
|
Let's ignore the openeuler CI failure for now. It works locally for me in a container. Not sure why it fails in CI. |
Signed-off-by: Jan Andre Reuter <jan@zyten.de>
Signed-off-by: Jan Andre Reuter <jan@zyten.de>
No description provided.