* Remove vestigial code to be compatible with Spack v0.9.X
* ArchSpec: reworked __repr__ to be more adherent to common Python idioms
* ArchSpec: simplified __init__.py and copy()
closes #26354 and #26358
Previously we did not pass paths for GDB or GMP and ./configure would
get confused about which one to pull from. Be more specific.
Built with all variants enabled and fixed the fixable versions and variants:
@:8.1 were fixable by limiting python versions for these to @:3.6.
7.10.1 and 7.11(.1) were fixable to build with glibc-2.25 and newer
using two long patches.
gdb 7.8 and 7.9 weren't fixable as there is no backport if the fix
to build these with glibc-2.25 and newer:
http://lists.busybox.net/pipermail/buildroot/2017-March/188055.html
Co-authored-by: Bernhard Kaindl <bernhardkaindl7@gmail.com>
Modifications:
- Modify the workflow to build container images without pushing when the workflow file itself is modified
- Strip the leading ghcr.io/spack/ from env.container env.versioned to prepare pushing to multiple registries
- Fixed CentOS 7 and Amazon Linux builds
- Login and push to Docker Hub as well as Github Action
- Add a badge to README.md with the status of docker images
- Specify CMake minimum version more precisely
- Ensure rocBLAS is available at build time
- Limit workaround for missing rocblas include path
to the only affected version (4.1.0)
- Make hip a build and link dependency
- Remove hip's link dependencies
Co-authored-by: Harmen Stoppels <harmenstoppels@gmail.com>
CMake 3.21.3 disables the broken hipcc-as-rocmclang detection again.
From the release notes:
> The AMD ROCm Platform hipcc compiler was identifed by CMake 3.21.0
> through 3.21.2 as a distinct compiler with id ROCMClang. This has been
> removed because it caused regressions. Instead:
> * hipcc may no longer be used as a HIP compiler because it interferes
> with flags CMake needs to pass to Clang. Use Clang directly.
> * hipcc may once again be used as a CXX compiler, and is treated as
> whatever compiler it selects underneath, as CMake 3.20 and below
> did.
* py-snappy: add patch to fix dependencies
* Update var/spack/repos/builtin/packages/py-snappy/req.patch
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
* py-jupyter-packaging: add 0.7.12 and 0.10.6
* Update var/spack/repos/builtin/packages/py-jupyter-packaging/package.py
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
* Update var/spack/repos/builtin/packages/py-jupyter-packaging/package.py
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
The format of the HPE/Cray supplied module for cray-mvapich2 on HPE apollo systems is
very different from the cray-mpich module supplied on Cray EX and XE
systems.
Recent changes to the cray-mpich package -
https://github.com/spack/spack/pull/23470
broke support for cray-mvapich2 and relies now on the structure of the
cray-mpich module to work properly.
Rather than try to support two very different vendor mpich modules
using the same spack package, just add another one specialized for
the cray-mvapich2 module.
Signed-off-by: Howard Pritchard <hppritcha@gmail.com>
