pool/spack
SHA256
2
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Accepting request 1234924 from network:cluster

Browse Source 
- Fix version of spack package to build documentation with (forwarded request 1234923 from eeich)

OBS-URL: https://build.opensuse.org/request/show/1234924
OBS-URL: https://build.opensuse.org/package/show/openSUSE:Factory/spack?expand=0&rev=47
This commit is contained in:
Ana Guerrero 2025-01-05 14:30:48 +00:00 committed by Git OBS Bridge
commit 3e1a106672
6 changed files with 240 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
Fix-error-during-documentation-build-due-to-recursive-module-inclusion.patch
View File

@ -1,27 +0,0 @@
From c24349cb54442da8e49fd40a299453e56b404a90 Mon Sep 17 00:00:00 2001
From: Egbert Eich <eich@suse.com>
Date: Thu, 7 Apr 2022 20:25:46 +0200
Subject: [PATCH] Fix error during documentation build due to recursive module
inclusion
Signed-off-by: Egbert Eich <eich@suse.com>
Signed-off-by: Egbert Eich <eich@suse.de>
---
lib/spack/spack/environment/environment.py | 4 ++++
1 file changed, 4 insertions(+)
Index: spack-0.20.3/lib/spack/spack/environment/environment.py
===================================================================
--- spack-0.20.3.orig/lib/spack/spack/environment/environment.py
+++ spack-0.20.3/lib/spack/spack/environment/environment.py
@@ -40,6 +40,10 @@ import spack.stage
import spack.store
import spack.subprocess_context
import spack.user_environment as uenv
+try:
+ import spack.user_environment as uenv
+except AttributeError:
+ pass
import spack.util.cpus
import spack.util.environment
import spack.util.hash

3
spack-0.22.2.tar.gz
View File

@ -1,3 +0,0 @@
version https://git-lfs.github.com/spec/v1
oid sha256:aef1a5ce16fe1a8bcced54c40012b19a0f4ade1cd9c5379aca081e96ec5b18ac
size 11117111

3
spack-0.23.0.tar.gz Normal file
View File

@ -0,0 +1,3 @@
version https://git-lfs.github.com/spec/v1
oid sha256:ddb8220c46743e45c9484622370a1e17e193acba6a43230868c2dbc717e88b56
size 11847230

3
spack-rpmlintrc
View File

@ -22,3 +22,6 @@ addFilter("spack-recipes.noarch: .* non-executable-script")
# 3rd party modules - not used stand-alone
addFilter(".* non-executable-script /usr/lib/spack/external/_vendoring")
addFilter(".* non-executable-script /usr/share/spack/gitlab/cloud_pipelines/scripts/common/aggregate_package_logs.spack.py")
# We need to test doc builds for SLE in OBS which depend in spack being built:
# for this, we need to defeat the 'backport policy'.
addFilter(".* E: SUSE_Backports_policy-SLE_conflict .*")

231
spack.changes
View File

@ -1,3 +1,234 @@
-------------------------------------------------------------------
Fri Jan 3 13:40:08 UTC 2025 - Egbert Eich <eich@suse.com>
- Update to version v0.23.0. This is a major release.
* Features in this Release
+ Spec splicing
To make binary installation more seamless in Spack, `v0.23`
introduces "splicing", which allows users to deploy binaries
using local, optimized versions of a binary interface, even
if they were not built with that interface. For example, this
would allow you to build binaries in the cloud using `mpich`
and install them on a system using a local, optimized version
of `mvapich2` *without rebuilding*. Spack preserves full
provenance for the installed packages and knows that they
were built one way but deployed another.
The intent is to leverage this across many key HPC binary
packages, e.g. MPI, CUDA, ROCm, and libfabric.
Fundamentally, splicing allows Spack to redeploy an existing
spec with different dependencies than how it was built. There
are two interfaces to splicing.
a. Explicit Splicing
In the concretizer config, you can specify a target spec
and a replacement by hash.
```yaml
concretizer:
splice:
explicit:
- target: mpi
replacement: mpich/abcdef
```
Here, every installation that would normally use the target
spec will instead use its replacement. Above, any spec using
*any* `mpi` will be spliced to depend on the specific `mpich`
installation requested. This *can* go wrong if you try to
replace something built with, e.g., `openmpi` with `mpich`,
and it is on the user to ensure ABI compatibility between
target and replacement specs. This currently requires some
expertise to use, but it will allow users to reuse the
binaries they create across more machines and environments.
b. Automatic Splicing (experimental)
In the concretizer config, enable automatic splicing:
```yaml
concretizer:
splice:
automatic: true
```
or run:
```console
spack config add concretizer:splice:automatic:true
```
The concretizer will select splices for ABI compatibility
to maximize package reuse. Packages can denote ABI
compatibility using the `can_splice` directive. No packages
in Spack yet use this directive, so if you want to use this
feature you will need to add `can_splice` annotations to
your packages. We are working on ways to add more ABI
compatibility information to the Spack package repository,
and this directive may change in the future.
Further documentation:
* https://spack.readthedocs.io/en/latest/build_settings.html#splicing
* https://spack.readthedocs.io/en/latest/packaging_guide.html#specifying-abi-compatibility
+ Broader variant propagation
You can specify propagated variants like
`hdf5 build_type==RelWithDebInfo` or `trilinos ++openmp` to
propagate a variant to all dependencies for which it is
relevant. This is valid *even* if the variant does not exist
on the package or its dependencies.
See https://spack.readthedocs.io/en/latest/basic_usage.html#variants.
+ Query specs by namespace
Allow a package's namespace (indicating the repository it came
from) to be treated like a variant. You can request packages
from particular repos like this:
```console
spack find zlib namespace=builtin
spack find zlib namespace=myrepo
```
Previously, the spec syntax only allowed namespaces to be prefixes of spec
names, e.g. `builtin.zlib`. The previous syntax still works.
+ `spack spec` respects environment settings and `unify:true`
`spack spec` did not previously respect environment lockfiles
or unification settings, which made it difficult to see
exactly how a spec would concretize within an environment.
Now it does, so the output you get with `spack spec` will
be *the same* as what your environment will concretize to
when you run `spack concretize`. Similarly, if you provide
multiple specs on the command line with `spack spec`, it will
concretize them together if `unify:true` is set.
+ Less noisy `spack spec` output
`spack spec` previously showed output like this:
```console
> spack spec /v5fn6xo
Input spec
--------------------------------
- /v5fn6xo
Concretized
--------------------------------
[+] openssl@3.3.1%apple-clang@16.0.0~docs+shared arch=darwin-sequoia-m1
...
```
But the input spec is redundant, and we know we run
`spack spec` to concretize the input spec. `spack spec` now
*only* shows the concretized spec. See #47574.
+ Better output for `spack find -c`
In an environment, `spack find -c` lets you search the
concretized, but not yet installed, specs, just as you would
the installed ones. As with `spack spec`, this should make
it easier for you to see what *will* be built before building
and installing it.
+ `spack -C <env>`: use an environment's configuration without activation
Spack environments allow you to associate:
1. a set of (possibly concretized) specs, and
2. configuration
When you activate an environment, you're using both of these.
Previously, we supported:
* `spack -e <env>` to run spack in the context of a specific
environment, and
* `spack -C <directory>` to run spack using a directory with
configuration files.
You can now also pass an environment to `spack -C` to use
*only* the environment's configuration, but not the specs or
lockfile.
* New commands, options, and directives
+ The new `spack env track` command (#41897) takes a non-managed
Spack environment and adds a symlink to Spack's
`$environments_root` directory, so that it will be included
for reference counting for commands like `spack uninstall`
and `spack gc`. If you use free-standing directory environments,
this is useful for preventing Spack from removing things
required by your environments. You can undo this tracking
with the `spack env untrack` command.
+ Add `-t` short option for `spack --backtrace`
`spack -d / --debug` enables backtraces on error, but it
can be very verbose, and sometimes you just want the
backtrace. `spack -t / --backtrace` provides that option.
+ `gc`: restrict to specific specs (#46790)
If you only want to garbage-collect specific packages, you can
now provide them on the command line. This gives users finer-grained
control over what is uninstalled.
+ oci buildcaches now support `--only=package`. You can now push
*just* a package and not its dependencies to an OCI registry.
This allows dependents of non-redistributable specs to be
stored in OCI registries without an error.
* Notable refactors
* Highlighted bugfixes
+ Externals no longer override the preferred provider.
External definitions could interfere with package preferences.
Now, if `openmpi` is the preferred `mpi`, and an external
`mpich` is defined, a new `openmpi` *will* be built if
building it is possible. Previously we would prefer `mpich`
despite the preference.
+ Composable `cflags`.
This release fixes a longstanding bug that concretization
would fail if there were different `cflags` specified in
`packages.yaml`, `compilers.yaml`, or on `the` CLI. Flags
and their ordering are now tracked in the concretizer and
flags from multiple sources will be merged.
+ Fix concretizer Unification for included environments.
* Deprecations, removals, and syntax changes
+ The old concretizer has been removed from Spack, along with
the `config:concretizer` config option. Spack will emit a
warning if the option is present in user configuration,
since it now has no effect. Spack now uses a simpler
bootstrapping mechanism, where a JSON prototype is tweaked
slightly to get an initial concrete spec to download.
+ Best-effort expansion of spec matrices has been removed.
This feature did not work with the "new" ASP-based concretizer,
and did not work with `unify: True` or `unify: when_possible`.
Use the
[exclude key](https://spack.readthedocs.io/en/latest/environments.html#spec-matrices)
for the environment to exclude invalid components, or use
multiple spec matrices to combine the list of specs for
which the constraint is valid and the list of specs for
which it is not.
+ The old Cray `platform` (based on Cray PE modules) has been
removed, and `platform=cray` is no longer supported. Since
`v0.19`, Spack has handled Cray machines like Linux clusters
with extra packages, and we have encouraged using this option
to support Cray. The new approach allows us to correctly handle
Cray machines with non-SLES operating systems, and it is much
more reliable than making assumptions about Cray modules. See
the `v0.19` release notes and #43796 for more details.
+ The `config:install_missing_compilers` config option has been
deprecated, and it is a no-op when set in `v0.23`. Our new
compiler dependency model will replace it with a much more
reliable and robust mechanism in `v1.0`.
+ Config options that deprecated in `v0.21` have been removed
in `v0.23`. You can now only specify preferences for
`compilers`, `targets`, and `providers` globally via the
`packages:all:` section. Similarly, you can only specify
`versions:` locally for a specific package.
+ Spack's old test interface has been removed (#45752), having
been deprecated in `v0.22.0` (#34236). All `builtin` packages
have been updated to use the new interface. See the
[stand-alone test documentation](
https://spack.readthedocs.io/en/latest/packaging_guide.html#stand-alone-tests)
+ The `spack versions --safe-only` option, deprecated since
`v0.21.0`, has been removed.
+ The `--dependencies` and `--optimize` arguments to `spack ci`
have been deprecated.
- Binary caches
+ Public binary caches now include an ML stack for Linux/aarch64.
We now build an ML stack for Linux/aarch64 for all pull
requests and on develop. The ML stack includes both CPU-only
and CUDA builds for Horovod, Hugging Face, JAX, Keras, PyTorch,
scikit-learn, TensorBoard, and TensorFlow, and related packages.
The CPU-only stack also includes XGBoost.
See https://cache.spack.io/tag/develop/?stack=ml-linux-aarch64-cuda.
- Architecture support
* archspec has been updated to `v0.2.5`, with support for
`zen5`.
* Spack's CUDA package now supports the Grace Hopper `9.0a`
compute capability.
- Other notable changes
+ Bugfix: `spack find -x` in environments.
+ Spec splices are now robust to duplicate nodes with the
same name in a spec.
+ Cache per-compiler libc calculations for performance.
+ Fixed a bug in external detection for openmpi.
+ Mirror configuration allows username/password as environment
variables.
+ Default library search caps maximum depth/
+ Unify interface for `spack spec` and `spack solve` commands.
+ Spack no longer RPATHs directories in the default library
search path.
+ Improved performance of Spack database.
+ Enable package reuse for packages with versions from git refs.
+ Improved tracking of task queueing/requeueing in the installer.
- Deleted: Fix-error-during-documentation-build-due-to-recursive-module-inclusion.patch
Patch no longer required for target versions.
-------------------------------------------------------------------
Fri Nov 1 06:32:35 UTC 2024 - Egbert Eich <eich@suse.com>

7
spack.spec
View File

@ -1,7 +1,7 @@
#
# spec file for package spack
#
# Copyright (c) 2024 SUSE LLC
# Copyright (c) 2025 SUSE LLC
#
# All modifications and additions to the file contributed by third parties
# remain the property of their copyright owners, unless otherwise agreed
@ -63,7 +63,7 @@ ExclusiveArch: do_not_build
%define mypython python%{?mypyver}
Name: spack
Version: 0.22.2
Version: 0.23.0
Release: 0
Summary: Package manager for HPC systems
License: Apache-2.0 AND MIT AND Python-2.0 AND BSD-3-Clause
@ -81,7 +81,6 @@ Source6: spack_get_libs.sh
Patch2: Adapt-shell-scripts-that-set-up-the-environment-for-different-shells.patch
Patch4: added-target-and-os-calls-to-output-of-spack-spec-co.patch
Patch5: Make-spack-paths-compliant-to-distro-installation.patch
Patch6: Fix-error-during-documentation-build-due-to-recursive-module-inclusion.patch
Patch7: Fix-Spinx-configuration-to-avoid-throwing-errors.patch
Patch8: Set-modules-default-to-lmod.patch
Patch9: Add-support-for-container-building-using-a-SLE-base-container.patch
@ -127,7 +126,7 @@ BuildRequires: makeinfo
# Hardcode this - there is no python2 version of this around any more.
BuildRequires: %{mypython}-Sphinx >= 3.4
BuildRequires: %{mypython}-sphinxcontrib-programoutput
BuildRequires: spack
BuildRequires: spack = %version
# html
BuildRequires: graphviz
# info