Backports: v0.22.1 #44221
Open
Backports: v0.22.1 #44221
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
which should be more generic
spackbot-app
bot
added
core
|
Needs more things |
|
@alecbcs FYI, these backports PRs are to be "rebase and merged" rather than "squashed and merged" to keep track of what was cherry-picked on the release branch. Usually they are kept open until we are ready for a point release, and merged when the CHANGELOG and version bump are there. |
* py-matplotlib: qualify when to do a post install Older versions of py-matplotlib don't seem to have some of the files that the post install step is trying to install. Looks like the files first appeared in 3.6.0 and later. Signed-off-by: Howard Pritchard <hppritcha@gmail.com> * Change install paths for older matplotlib --------- Signed-off-by: Howard Pritchard <hppritcha@gmail.com> Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
When multiple gcc-runtime packages exist in the same link sub-dag, only rpath the latest.
spackbot-app
bot
added
build-environment
python
tests
This fixes an issue where ghcr, gitlab and possibly other container registries paginate tags by default, which violates the OCI spec v1.0, but is common practice (the spec was broken itself). After this commit, you can create build cache indices of > 100 specs on ghcr. Co-authored-by: Harmen Stoppels <me@harmenstoppels.nl>
This fixes a bug occurring when two root specs need to select old versions, and these versions have the same penalty in the optimization. This sometimes caused an older version to be preferred to a more recent one. The issue was the omission of `PackageNode` in the optimization tuple.
on some distros it is in lib64/
to make macOS's linker happy.
`glibc` and `musl` provide a basic implementation of `iconv` (`iconv`, `iconv_open`, `iconv_close`), but in practice the installation may be missing the character encoding methods to make them usable. On Fedora for example, users need to ```yum install glibc-gconv-extra``` to get the character encodings that `gettext` requires during configure, namely EUC-JP. Users may not have permissions to install the missing parts of glibc. Since Spack can install `libiconv`, it is simpler to use that by default.
* Remove mesa18 and libosmesa mesa18 was introduced in #19528 as a way to maintain the old autotools build of mesa separate from the new meson build. We could add a second build system to mesa, but since mesa18 has been deprecated for a long time, we'll just remove it. libosmesa was used to multiplex the gl provider between mesa18 and mesa, and is thus unecessary. Remove it to reduce complexity in the graphical stack. * Remove references to mesa18 and libosmesa * vtk: rework dependency on gl and osmesa * memsurfer: rework dependency on vtk * visit: minimal fix to avoid having both osmesa and glx
* glew: rework dependency on gl
This simplifies the package and ensures a single gl implementation is
pulled in. Before we were adding direct dependencies, and those are
not unified through the virtual.
* mesa-demos: rework dependency on gl
This simplifies the package and ensures a single gl implementation is
pulled in. Before we were adding direct dependencies, and those are
not unified through the virtual.
* mesa-glu: rework dependency on gl
This simplifies the package and ensures a single gl implementation is
pulled in. Before we were adding direct dependencies, and those are
not unified through the virtual.
* paraview: fix dependency on glew
* mesa: group dependency on when("+glx")
* Add missing dependency on libxml2
* paraview: remove the "osmesa" and "egl" variant
Instead, enforce consistency using the "gl" virtual that allows
only one provider.
* visit: remove osmesa variant
* Disable paraview in the aws-isc stacks
* data-vis-sdk: rework constrains to enforce front-ends
* e4s-power: remove redundant paraview
* Pipelines: update osmesa variants
* trilinos-catalyst-ioss-adapter: make gl a run dependency
We need to tell clingo the libc compatibility of external nodes in buildcaches or stores, to allow reuse.
avoid calling `spec.target` when None.
When an external compiler package has an `os` set but no `target` set, Spack
currently falls into a codepath that calls `spec.target` (which itself calls
`spec.architecture.target.Microarchitecture`) when `spec.architecture.target`
is None, throwing an error.
e.g.
```
packages:
gcc:
externals:
- spec: gcc@12.3.1 os=rhel7
prefix: /usr
```
---------
Co-authored-by: Todd Gamblin <tgamblin@llnl.gov>
Before this PR, if Spack could see a possibility to reuse a spec that doesn't match a strong preference, it would do so. After the PR, a strong preference would take precedence.
Use correct path separator in get_all_package_diffs for all platforms. Ensures correct package change computation on Windows when pruning unchanged specs in Gitlab CI
Symlinks on Windows can use longpath prefixes (\\?\); these are fine in the context of win32 API interactions but break numerous facets of Spack behavior that rely on string parsing/matching (archiving, binary distributions, tarball extraction, view regen, etc). Spack's internal readlink method (llnl.util.symlink.readlink) gracefully handles this by removing the prefix and otherwise behaving exactly as os.readlink does, so we should prefer that in all cases.
* Add timeout to cdash reporter PUT request Add cdash timeout everywhere Correct mock responder api * Style * brief doc
* archive: relative links only Ensure all links written into tarfiles generated from Spack prefixes do not contain symlinks pointing outside the prefix * binary_distribution: limit extraction to prefix Ensure files extracted from spackballs are not links pointing outside of the prefix * Ensure rpaths are properly set on Windows * hard error on extraction of absolute links * refactor for non link-modifying approach * Restore tarball extraction to original impl * use custom readlink * cleanup symlink module * make lstrip
spackbot-app
bot
added
architecture
binary-packages
compilers
conflicts
environments
gitlab
Add support for Gitlab CI on Windows This PR adds the config changes required to configure and execute Gitlab pipelines running Windows builds on Windows runners using the existing Gitlab CI infrastructure (and newly added Windows infrastructure). * Adds support for generating child pipelines dispatched to Windows runners * Refactors the relevant pre-scripts, scripts, and post scripts to be compatible with Windows * Adds Windows config section describing Windows jobs * Adds VTK as Windows build stack (to be expanded later) * Modifies proj to build on Windows * Refactors Windows rpath symlinking to avoid system libs and externals --------- Co-authored-by: Ryan Krattiger <ryan.krattiger@kitware.com> Co-authored-by: Mike VanDenburgh <michael.vandenburgh@kitware.com> Co-authored-by: Todd Gamblin <tgamblin@llnl.gov> Co-authored-by: Scott Wittenburg <scott.wittenburg@kitware.com>
* Quote python for shlex * Remove python path quoting patch * spack env: Allow `C` "protocol" for config_path When running spack on windows, a path beginning with `C://...` is a valid path. * Remove makefile from ci rebuild * GPG use llnl.util.filesystem.getuid * Cleanup process_command * Remove unused lines * Fix tyop in encode_path * Double quote arguments * Cleanup process_command * Pass cdash args with = * Escape parens in CMD script * escape parens doesn't only apply to paths * Install deps * sfn prefix * use sfn with libxml2 * Add hash to dep install * WIP * REview * Changes missed in prior review commit * Style * Ensure we handle Windows paths with config scopes * clarify docstring * No more MAKE_COMMAND * syntax cleanup * Actually correct is_path_url * Correct call * raise on other errors * url2path behaves differently on unix * Ensure proper quoting * actually prepend slash in slash_hash --------- Co-authored-by: Ryan Krattiger <ryan.krattiger@kitware.com> Co-authored-by: Mike VanDenburgh <michael.vandenburgh@kitware.com>
* protobuf: update hash for patch needed when="@3.4:3.21" * Update var/spack/repos/builtin/packages/protobuf/package.py Co-authored-by: Wouter Deconinck <wdconinc@gmail.com> * Update var/spack/repos/builtin/packages/protobuf/package.py Co-authored-by: Wouter Deconinck <wdconinc@gmail.com> --------- Co-authored-by: Wouter Deconinck <wdconinc@gmail.com>
#40773 introduced python-venv, which improved build isolation and avoids issues with, e.g., `ubuntu`'s system python modifying `sysconfig` to include a (very unwanted) `local` directory within the default install layout. This addresses a few cases where #40773 removed functionality, without harming the default cases where we use `python-venv`. Traditionally, *every* view with `python` in it was essentially a virtual environment, because we would copy the `python` interpreter and `os.py` into every view when linking. We now rely on `python-venv` to do that, but only when it's used (i.e. new builds) and only for packages that have an `extends("python")` directive. This again makes every view with `python` in it a virtual environment, but only if we're not already using a package like `python-venv`. This uses a different mechanism from before -- instead of using the `virtualenv` trick of copying `python` into the prefix, we instead create a `pyvenv.cfg` like `venv` (the more modern way to do it). This fixes two things: 1. If you already had an environment before Spack `v0.22` that worked, it would stop working without a reconcretize and rebuild in `v0.22`, because we no longer copy the python interpreter on link. Adding `pyvenv.cfg` fixes this in a more modern way, so old views will keep working. 2. If you have an env that only includes python packages that use `depends_on("python")` instead of `extends("python")`, those packages will now be importable as before, though they won't have the same level of build isolation you'd get with `extends` and `python-venv`. * views: avoid making client code deal with link functions Users of views and ViewDescriptors shouldn't have to deal with link functions -- they should just say what type of linking they want. - [x] views take a link_type, not a link function - [x] views work out the link function from the link type - [x] view descriptors and commands now just tell the view what they want. * python: simplify logic for avoiding pyvenv.cfg in copy views Signed-off-by: Todd Gamblin <tgamblin@llnl.gov>
|
@spackbot run pipeline |
|
I've started that pipeline for you! |
|
I've started that pipeline for you! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
v0.22.1 will be released soon ™️
libsproperty #44214glproviders #44307venv#44382Pipelines and unit tests failure
x86_64_v3runners to match build jobs #44582