Bump actions/setup-python from 3.1.2 to 4.6.0 #69

Co-authored-by: mahendrapaipuri <[email protected]>

* kokkos-kernels: add variant 'shared' * Update var/spack/repos/builtin/packages/kokkos-kernels/package.py

* ci: Enable more packages in the DVSDK CI pipeline * doxygen: Add conflicts for gcc bugs * dray: Add version constraints for api breakage with newer deps

…27069)

glib has a few tests which have external dependencies or try to access the X server. We cannot run those. Co-authored-by: Massimiliano Culpo <[email protected]>

Add version 1.20, fix including the glib-2.0 header files and add missing dependencies: libunwind and kmod.

* adios2: Fix compile errors for gcc 11 * unifyfs: Suppress bogus warnings for gcc 11 * conduit: Fix compile errors for gcc 11

This PR adds a "spack tags" command to output package tags or (available) packages with those tags. It also ensures each package is listed in the tag cache ONLY ONCE per tag.

* py-pylint: needs py-pip for build * alphabetize py- dependencies * add comment pointing to issue * fix style

Bumps [actions/checkout](https://github.com/actions/checkout) from 2.3.4 to 2.3.5. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@5a4ac90...1e204e9) --- updated-dependencies: - dependency-name: actions/checkout dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

The `--generic` argument allows printing the best generic target for the current machine. This can be quite handy when wanting to find the generic architecture to use when building a shared software stack for multiple machines.

- add version 6.0.5 - add patch to allow fsl to use newer gcc versions - add patch to allow fsl to use newer cuda versions - remove constraints on gcc and cuda versions - add filters to prevent using system headers and libraries - clean up the installed tree

- added more versions in case packages request a specific version of docbook-xml - added a "current" alias to handle when packages use that

spack#26538 introduced a typo that causes the Docker image build to fail.

gconf depends on gettext and libintl (dep: intltool) glibmm, gtkmm, libcanberra and cups need pkgconfig glibmm needs libsigc++ < 2.9x(which are 3.x pre-releases) libsigc++@:2.9 depends on m4 for the build Co-authored-by: Massimiliano Culpo <[email protected]>

Co-authored-by: Bernhard Kaindl <[email protected]> Co-authored-by: Massimiliano Culpo <[email protected]>

…ck#27150)

* package/qgis_revert_incorrect_constraint * fix bug * also update dependency constraints * also update python version constraints Co-authored-by: sbulut <[email protected]>

@tmdelellis

…pack#27139) After spack#26608 I got a report about missing rpaths when building a downstream package independently using a spack-installed toolchain (@tmdelellis). This occurred because the spack-installed libraries were being linked into the downstream app, but the rpaths were not being manually added. Prior to spack#26608 autotools-installed libs would retain their hard-coded path and would thus propagate their link information into the downstream library on mac. We could solve this problem *if* the mac linker (ld) respected `LD_RUN_PATH` like it does on GNU systems, i.e. adding `rpath` entries to each item in the environment variable. However on mac we would have to manually add rpaths either using spack's compiler wrapper scripts or manually (e.g. using `CMAKE_BUILD_RPATH` and pointing to the libraries of all the autotools-installed spack libraries). The easier and safer thing to do for now is to simply stop changing the dylib IDs.

spack#19834) This removes `-lpytrilinos` from Makefile.export.Trilinos so that C code trying to link against a Trilinos built with PyTrilinos does not fail due to undefined references to python routines (libpytrilinos is only used when importing PyTrilinos in python, in which case those references are already defined by Python). There was already a bit of code to do something similar for C codes importing Trilinos via a CMake mechanism, this extends that to a basic Makefile mechanism as well. This patch also updates the comments to remove a stale link discussing this issue, and replacing with links to the some Trilinos issue reports related to the matter.

* New versions of py-jupyter-server; fix tests * Update package.py

This PR adds error message sentinels to the clingo solve, attached to each of the rules that could fail a solve. The unsat core is then restricted to these messages, which makes the minimization problem tractable. Errors that can only be generated by a bug in the logic program or generating code are prefaced with "Internal error" to make clear to users that something has gone wrong on the Spack side of things. * minimize unsat cores manually * only errors messages are choices/assumptions for performance * pre-check for unreachable nodes * update tests for new error message * make clingo concretization errors show up in cdash reports fully * clingo: make import of clingo.ast parsing routines robust to clingo version Older `clingo` has `parse_string`; newer `clingo` has `parse_files`. Make the code work wtih both. * make AST access functions backward-compatible with clingo 5.4.0 Clingo AST API has changed since 5.4.0; make some functions to help us handle both versions of the AST. Co-authored-by: Todd Gamblin <[email protected]>

* trilinos: add @13.2.0, and switch default to cxxstd=14 * trilinos: fix python dependency when using +ifpack or +ifpack2 * trilinos: add conflict for ~epetra +ml when @13.2.0: * trilinos: keep 13.0.1 as the preferred version * Update var/spack/repos/builtin/packages/trilinos/package.py Co-authored-by: Seth R. Johnson <[email protected]> * update Co-authored-by: Seth R. Johnson <[email protected]>

* Add build editions for catalyst builds. * Fix style. * Build edition works only for 5.8:

Bumps [actions/checkout](https://github.com/actions/checkout) from 2.3.5 to 2.4.0. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@1e204e9...ec3a7ce) --- updated-dependencies: - dependency-name: actions/checkout dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* Update spack load docs

* GnuPG: allow bootstrapping from buildcache and sources * Add a test to bootstrap GnuPG from binaries * Disable bootstrapping in tests * Add e2e test to bootstrap GnuPG from sources on Ubuntu * Add e2e test to bootstrap GnuPG on macOS

A common question from users has been how to model variants that are new in new versions of a package, or variants that are dependent on other variants. Our stock answer so far has been an unsatisfying combination of "just have it do nothing in the old version" and "tell Spack it conflicts". This PR enables conditional variants, on any spec condition. The syntax is straightforward, and matches that of previous features.

…pack#27030) Version 2.5.4 adds an option which allows Nemsio to be built without MPI

Update `warpx` & `py-warpx` to the latest release, `21.11`.

* trilinos: fix @13.0.1+tpetra^cuda@11 * Mark CUDA conflict with old versions and always define TPL * trilinos: patch doesn't build so just mark as conflict

Co-authored-by: Bernhard Kaindl <[email protected]>

The Makefile expects the "other" libtool, not the GNU libtool we have in Spack. Closes spack#26993 Co-authored-by: Bernhard Kaindl <[email protected]>

Define new variants asdf, hdf5, rnpl, silo to allow disabling or enabling dependencies.

* scr: 3.0rc2 release, variants and deps updates This adds 3.0rc2 release for end users to aid in testing scr for upcoming 3.0 release. Included in this change: - Require most recent component versions for this release - Add a variant for PDSH as it is now an optional dependency with this release - Add bbapi and datawarp (dw) variants - bbapi_fallback variant now requires bbapi variant with latest release - Add variants to enable/disable examples and tests - Add shared variant and current conflicts with ~shared - Update cmake_args to account for added variants where needed Additional updates: - Add maintainers - Use lists and for loops to clean up repetitive code involving all components - Use self.define and self.define_from_variant to clean up cmake_args - Use consistent quoting throughout package * Un-deprecate v2 and legacy * Use new conditional variants

* add exaworks spack meta package * add maintainer * switch to `BundlePackage` * flake8 * another flake8 fix * remove incorrect dependency

…27194) Co-authored-by: Tamara Dahlgren <[email protected]>

Co-authored-by: Tamara Dahlgren <[email protected]>

ensure that none of ^intel-mkl, ^intel-mpi, and ^mkl are used, unless the compiler is intel. Fix bad logic in the src/src_xs/m_makespectrum.f90 file in the oxygen version. Add the -fallow-argument-mismatch for gcc >= 10.

…7137)

If we don't rename Spack will fail with: ``` ImportError: cannot bootstrap the "clingo" Python module from spec "clingo-bootstrap@spack+python %gcc target=x86_64" due to the following failures: 'spack-install' raised ValueError: Invalid config scope: 'bootstrap'. Must be one of odict_keys(['_builtin', 'defaults', 'defaults/cray', 'bootstrap/cray', 'disable_modules', 'overrides-0']) Please run `spack -d spec zlib` for more verbose error messages ``` in case bootstrapping from binaries fails and we are falling back to bootstrapping from sources.

Co-authored-by: Tamara Dahlgren <[email protected]>

Co-authored-by: sbulut <[email protected]> Co-authored-by: Tamara Dahlgren <[email protected]>

The concretizer doesn't get a say in whether constraints from concrete specs are imposed, so use body facts for them.

The OS logic in the concretizer is still the way it was in the first version. Defaults are implemented in a fairly inflexible way using straight logic. Most of the other sections have been reworked to leave these kinds of decisions to optimization. This commit does that for OS's as well. As with targets, we optimize for target matches. We also try to optimize for OS matches between nodes. Additionally, this commit adds the notion of "OS compatibility" where we allow for builds to depend on binaries for certain other OS's. e.g, for macos, a bigsur build can depend on an already installed (concrete) catalina build. One cool thing about this is that we can declare additional compatible OS's later, e.g. CentOS and RHEL.

Many of the integrity constraints in the concretizer are there to restrict how solves are done, but they ignore that past solves may have had different initial conditions. For example, for things we're building, we want the allowed variants to be restricted to those currently in Spack packages, but if we are reusing a concrete spec, we need to be flexible about names that may have existed in old packages. Similarly, restrictions around compatibility of OS's, compiler versions, compiler OS support, etc. are really only about what is supported by the *current* set of compilers/build tools known to Spack, not about what we may get from concrete specs. - [x] restrict certain integrity constraints to only apply to packages that we need to build, and omit concrete specs from consideration.

Make the first minimization conditional on whether `--reuse` is enabled in the solve. If `--reuse` is not enabled, there will be nothing in the set to minimize and the objective function (for this criterion) will be 0 for every answer set.

The constraints in the `spack diff` test were very specific and assumed a lot about the structure of what was being diffed. Relax them a bit to make them more resilient to changes.

Minimizing builds is tricky. We want a minimizing criterion because we want to reuse the avaialble installs, but we also want things that have to be built to stick to *default preferences* from the package and from the user. We therefore treat built specs differently and apply a different set of optimization criteria to them. Spack's *first* priority is to reuse what it can, but if it builds something, the built specs will respect defaults and preferences. This is implemented by bumping the priority of optimization criteria for built specs -- so that they take precedence over the otherwise topmost-priority criterion to reuse what is installed. The scheme relies on all of our optimization criteria being minimizations. That is, we need the case where all specs are reused to be better than any built spec could be. Basically, if nothing is built, all the build criteria are zero (the best possible) and the number of built packages dominates. If something *has* to be built, it must be strictly worse than full reuse, because: 1. it increases the number of built specs 2. it must have either zero or some positive number for all criteria Our optimziation criteria effectively sum into two buckets at once to accomplish this. We use a `build_priority()` number to shift the priority of optimization criteria for built specs higher.

Multi-valued variants previously maximized default values to handle cases where the default contained two values, e.g.: variant("foo", default="bar,baz") This is because previously we were minimizing non-default values, and `foo=bar`, `foo=baz`, and `foo=bar,baz` all had the same score, as none of them had any "non-default" values. This commit changes the approach and considers a non-default value to be either a value set to something not default *or* the absence of a default value from the set value. This allows multi- and single-valued variants to be handled the same way, with the same minimization criterion. It alse means that the "best" value for every optimization criterion is now zero, which allows us to make useful assumptions about the optimization criteria.

Variants in concrete specs are "always" correct -- or at least we assume them to be b/c they were concretized before. Their variants need not match the current version of the package.

CNL, debian6 and Suse are not compatible

- [x] Get rid of forgotten maximize directive. - [x] Simplify variant handling - [x] Fix bug in treatment of defaults on externals (don't count non-default variants on externals against them)

…auses In switching to hash facts for concrete specs, we lost the transitive facts from dependencies. This was fine for solves, because they were implied by the imposed constraints from every hash. However, for `spack diff`, we want to see what the hashes mean, so we need another mode for `spec_clauses()` to show that. This adds a `expand_hashes` argument to `spec_clauses()` that allows us to output *both* the hashes and their implications on dependencies. We use this mode in `spack diff`.

… rules Concrete specs that are already installed or that come from a buildcache may have compilers and variant settings that we do not recognize, but that shouldn't prevent reuse (at least not until we have a more detailed compiler model). - [x] make sure compiler and variant consistency rules only apply to built specs - [x] don't validate concrete specs on input, either -- they're concrete and we shouldn't apply today's rules to yesterday's build

In our tests, we use concrete specs generated from mock packages, which *only* occur as inputs to the solver. This fixes two problems: 1. We weren't previously adding facts to encode the necessary `depends_on()` relationships, and specs were unsatisfiable on reachability. 2. Our hash lookup for reconstructing the DAG does not consider that a hash may have come from the inputs.

Reformulate variant rules so that we minimize both 1. The number of non-default values being used 2. The number of default values not-being used This is crucial for MV variants where we may have more than one default value

Add docs for `--reuse`, along with a warning that it will likely be removed and refactored.

…27184) See spack#25249 and spack#27159 (comment). This adds `spack load --list` as an alias for `spack find --loaded`. The new command is not as powerful as `spack find --loaded`, as you can't combine it with all the queries or formats that `spack find` provides. However, it is more intuitively located in the command structure in that it appears in the output of `spack load --help`. The idea here is that people can use `spack load --list` for simple stuff but fall back to `spack find --loaded` if they need more. - add help to `spack load --list` that references `spack find` - factor some parts of `spack find` out to be called from `spack load` - add shell tests - update docs Co-authored-by: Peter Josef Scheibel <[email protected]> Co-authored-by: Richarda Butler <[email protected]>

* make version docs reflect reality * typo and make things * 2.6 -> 2.7 in example

Fixes spack#27188 (comment)

…7068)

* package/py-zarr_add_v2.10.2 * improve python dep version constraints Co-authored-by: sbulut <[email protected]>

…ecs (spack#27240) * Prevent additional properties to be in the answer set when reusing specs fixes spack#27237 The mechanism to reuse concrete specs relies on imposing the set of constraints stemming from the concrete spec being reused. We also need to prevent that other constraints get added to this set.

Add the latest release.

* py-mpi4py: Add newer versions * Address PR comments

…its (spack#27241) Noting that missing numeric_limits was the cause of the compile issues with gcc-11, I tested adding -include limits fixing @5.9:5.14%gcc@11. Therefore, we can replace the conflicts('%gcc@11:', when='@5.9:5.14'). Co-authored-by: Bernhard Kaindl <[email protected]>

Adds a new package for the AMPX/SCALE implementation of the GNDS interface, https://www.oecd.org/publications/specifications-for-the-generalised-nuclear-database-structure-gnds-94d5e451-en.htm .

When running `spack install --log-format junit|cdash ...`, install errors were ignored. This made spack continue building dependents of failed install, ignoring `--fail-fast`, and exit 0 at the end.

Commands should not reuse option names defined in main.

Some tests assume the base branch is develop, but this branch may not have been checked out.

…pack#21447) Fix builds which produce a lines with non-UTF8 output while logging The alternative is to read in binary mode, and then decode while ignoring errors.

This broke in spack#24858

* upcxx: Update the UPC++ package to 2021.9.0 * Add the new release, and a missing older one. * Remove the spack package cruft for supporting the obsolete build system that was present in older versions that are no longer supported. * General cleanups. Support for library versions older than 2020.3.0 is officially retired, for two reasons: 1. Releases prior to 2020.3.0 had a required dependency on Python 2, which is [officially EOL](https://www.python.org/doc/sunset-python-2/) as of Jan 1 2020, and is no longer considered secure. 2. (Most importantly) The UPC++ development team is unable/unwilling to support releases more than two years old. UPC++ provides robust backwards-compatibility to earlier releases of UPC++ v1.0, with very rare well-documented/well-motivated exceptions. Users are strongly encouraged to update to a current version of UPC++. NOTE: Most of the lines changed in this commit are simply re-indentation, and thus might be best reviewed in a diff that ignores whitespace. * upcxx: Detect Cray XC more explicitly This change is necessary to prevent false matches occuring on new Cray Shasta systems, which do not use the aries network but were incorrectly being treated as a Cray XC + aries platform. UPC++ has not yet deployed official native support for Cray Shasta, but this change is sufficient to allow building the portable backends there.

…t performance (spack#27970) Co-authored-by: Harmen Stoppels <[email protected]>

* Provide a meaningful failure message for installation of an empty environment * Allow regenerating view per offline discussion

Co-authored-by: Massimiliano Culpo <[email protected]>

otherwise spack breaks using system man pages by default. Co-authored-by: Harmen Stoppels <[email protected]>

…pack#27625) This reverts commit c5ca0db.

This commit introduces the command spack module tcl setdefault <package> similar to the one already available for lmod Co-authored-by: Massimiliano Culpo <[email protected]>

…k#25764) Co-authored-by: Todd Gamblin <[email protected]> Co-authored-by: Tamara Dahlgren <[email protected]>

* py-vermin: add latest version 1.3.2 * [vermin] Fixed usages of super() without arguments (v3+)

With this commit: ``` $ spack env activate --temp $ spack install zlib ==> All of the packages are already installed ==> Updating view at /tmp/spack-faiirgmt/.spack-env/view $ spack install zlib ==> All of the packages are already installed ``` Before this PR: ``` $ spack env activate --temp $ spack install zlib ==> All of the packages are already installed $ spack install zlib ==> All of the packages are already installed ``` No view was generated

* locks: allow locks to work under high contention This is a bug found by Harshitha Menon. The `lock=None` line shouldn't be a release but should be ``` return (lock_type, None) ``` to inform the caller it couldn't get the lock type requested without disturbing the existing lock object in the database. There were also a couple of bugs due to taking write locks at the beginning without any checking or release, and not releasing read locks before requeueing. This version no longer gives me read upgrade to write errors, even running 200 instances on one box. * Change lock in check_deps_status to read, release if not installed, not sure why this was ever write, but read definitely is more appropriate here, and the read lock is only held out of the scope if the package is installed. * Release read lock before requeueing to reduce chance of livelock, the timeout that caused the original issue now happens in roughly 3 of 200 workers instead of 199 on average.

This avoids dangling symlink errors. ignore_dangling_symlinks option would be more-targeted but is only available for Python >= 3.2 (spack#28318)

The option `spack -C` was broken if another flag that touched config was also set (`spack -C ... -d`, `-c config:...` etc...).

* Fix reindex with uninstalled deps When a prefix of a dep is removed, and the db is reindexed, it is added through the dependent, but until now it incorrectly listed the spec as 'installed'. There was also some questionable behavior in the db when the same spec was added multiple times, it would always be marked installed. * Always reserve path * Only add installed spec's prefixes to install prefixes set * Improve warning, and ensure ensure only ensures * test: reindex with every file system remnant removed except for the old index; it should give a database with nothing installed, including records with installed==False,external==False,ref_count==0,explicit=True, and these should be removable from the database

A few calls use `deptypes=...` instead of `deptype=...`

`stat`'ing a file in the dst dir is the wrong thing to do, you should `lstat` to capture broken symlinks.

…med spack (spack#29518)

* stacks: add regression tests for matrix expansion * Use constrain semantics to construct spec lists for stacks * Fix semantics for constraining an anonymous spec. Add tests

…pack#29475)

…ck#29636) Currently `old_root` is computed by reading the symlink at `self.root`. We should be more defensive in removing it by checking that it is in the same directory as the new root. Otherwise, in the worst case, when someone runs `spack env create --with-view=./view -d .` and `view` already exists and is a symlink to `/`, Spack effectively runs `rm -rf /`.

Known issues reports only 2 issues, among the bugs reported on GitHub. One of the two is also outdated, since the issue has been solved with the new concretizer. Thus, this commit removes the section.

The status displayed in the terminal title could be wrong when doing distributed builds. For instance, doing `spack install glib` in two different terminals could lead to the current package being reported as `40/29` due to the way Spack handles retrying locks. Work around this by keeping track of the package IDs that were already encountered to avoid counting packages twice.

…ack#30042) Ubuntu patched git v2.25.1 with a security fix that also introduced a breaking change, so v2.25.1 behaves like v2.35.2 with respect to the use cases in CVE-2022-24765

Fedora updated git, so we need to apply, again, the workaround for CVE-2022-24765

- [x] Add `mkdir -p` and `chmod` to ensure `/home/spack-test` exists and has correct permissions. - [x] Remove version comments from dependabot-managed action commits - [x] Don't duplicate comment describing required fixes for distros with patched git

…spack#30448)

) * Disable globbing * Split on bell char when dumping cmd to out.log

When an upstream is specified but the directory does not exist, don't create the directory for it, it might not be yours.

A non-existent upstream should not be fatal: it could only mean it is not deployed yet. In the meantime, it should not block the user to rebuild anything it needs. A warning is still emitted, to let the user decide if this is ok or not.

Fixes missing chgrp on symlinks in package installations, and errors on symlinks referencing non-existent or non-writable locations. Note: `os.chown(.., follow_symlinks=False)` is python3 only, but `os.lchown` exists in both versions.

…ge specs as a reference

The updated packages and dependency chains included in this commit were used to deploy the new candidate production spack instance expanse/0.17.3/gpu/a on Expanse in the /cm/shared Ceph filesystem. Also added the new SPECS.md file with the aim to help improve documentation of the package dependency chains.

The updated packages and dependency chains included within this commit were used to deploy the new candidate production spack instance expanse/0.17.3/cpu/a on Expanse in the /cm/shared Ceph filesystem. Also added its SPECS.md file.

During the update to spack v0.17.3, +knem and +xpmem were reset for ucx to more closely match the AMD spack spec for openmpi [1]. However, it was found that one or both variants when enabled in the latest deployed pre-production test instances led to reduced performance for several applications, namd with a charmpp backend=mpi in particular. In the next iteration of the spack stack, which will be tested on devexp soon, we will revisit this issue and attempt to set knem and xpmem as external packages coming directly from the Mellanox OFED distribution installed by the HPC Systems Group. [1] https://developer.amd.com/spack/hpc-applications-openmpi

Contributed by Jerry Greenberg @ SDSC

Required for building [email protected] from source. However, the build is currently failing. The gaussian package in the custom sdsc package repo likely needs some refactoring to support [email protected].

Required for building [email protected] from source. However, the build is currently failing. As mentioned in the last commit, the gaussian package in the custom sdsc package repo likely needs some refactoring.

Successfully built as part of the pre-production expanse/0.17.3/cpu/a test instance currently deployed on Expanse. Waiting for testing. An amber@20 spec build script was also include here. Note, however, the build failed to deploy in the same instance. We may will revisit, if necessary. e.g., if requested by user after production deployment of the new instance.

Contributed by Jerry Greenberg @ SDSC

This is a modified version of the upstream spack/spack vasp package captured on this date from the project's develop branch. The major changes were to rename the package vasp6 --- in order allow different vasp group permissions between vasp6 and vasp5 on Expanse --- and add vasp v6.2.1.

Contributed by Jerry Greenberg @ SDSC

The aim here is to simplify the structure of the packages.yaml file. There are currently appears to be no advantages in specifying the supported architecture(s) when referring to external packages. However, we have observed Spack concretization and build issues when they are not specified correctly and/or maintained properly. Hence, this simplification to a non-architecture-specific definition of external packages in the packages.yaml file should eliminate these problems and, hopefully, not create any new ones.

Minor changes made to expanse/0.17.3/gpu during testing on devexp in preparation for production deployment. More specific changes like the deployment of [email protected] backend=multicore will again be noted prior to production deployment when the package depenency chains undergo a final adjustment.

Minor changes made to expanse/0.17.3/cpu during testing on devexp in preparation for production deployment. More specific changes like will be noted prior to production deployment when the package depenency chains undergo a final adjustment.

On systems like Expanse or TSSC, we rely on NVIDIA's Bright Cluster Manager to install a host OS and other software packages that will serve Spack as external packages. In this case, lmod is provided by Bright and is not needed (internally) for our Spack deployments on SDSC's HPC systems.

Here, we have attempted to simplify the modules.yaml configuration file prior to production deployment of the expanse/0.17.3/cpu Spack instance. The primary change is to eliminate as many package-specific suffixes entries that need to maintained over time by using generic, global sufixes where it makes sense. e.g., +openmp: omp

We are reorganzing the Spack package dependency chains one final time before completing the first production depolyments of expanse/0.17.3/cpu. One task as part of this effort is to remove all spec build scripts for packages that have a manual_download = True requirement from the dependency chains as they will need to be run manually as a separate process once the more automated builds have been successfully deployed.

….17.3/cpu

Attempting to support Trinity within Spack will likely be quite difficult long-term. However, the developers already distribute Trinity via Singularity containers that they build and maintain [1]. We plan to provide support for Trinity on Expanse (and TSCC?) using these official containers. [1] https://data.broadinstitute.org/Trinity/TRINITY_SINGULARITY

…e/0.17.3/cpu We are reorganzing the Spack package dependency chains one final time before completing the first production depolyments of expanse/0.17.3/cpu. One task as part of this effort is to remove all spec build scripts for packages that have a manual_download = True requirement from the dependency chains as they will need to be run manually as a separate process once the more automated builds have been successfully deployed.

Bumps [actions/setup-python](https://github.com/actions/setup-python) from 3.1.2 to 4.6.0. - [Release notes](https://github.com/actions/setup-python/releases) - [Commits](actions/setup-python@v3.1.2...57ded4d) --- updated-dependencies: - dependency-name: actions/setup-python dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bump actions/setup-python from 3.1.2 to 4.6.0 #69

Bump actions/setup-python from 3.1.2 to 4.6.0 #69

Commits on Nov 1, 2021

Commits on Nov 2, 2021

Commits on Nov 3, 2021

Commits on Nov 4, 2021

Commits on Nov 5, 2021

Commits on Nov 6, 2021

Commits on Nov 14, 2021

Commits on Dec 23, 2021

Commits on Apr 14, 2022

Commits on Jul 14, 2022

Commits on Jul 15, 2022

Commits on Jan 18, 2023

Commits on Jan 27, 2023

Commits on Feb 5, 2023

Commits on Feb 9, 2023

Commits on Mar 9, 2023

Commits on Mar 10, 2023

Commits on Mar 11, 2023

Commits on Mar 12, 2023

Commits on Mar 14, 2023

Commits on Mar 24, 2023

Commits on Mar 29, 2023

Commits on Apr 4, 2023

Commits on Apr 14, 2023

Commits on Apr 15, 2023

Commits on Apr 16, 2023

Commits on Apr 18, 2023

Commits on Apr 20, 2023

Bump actions/setup-python from 3.1.2 to 4.6.0 #69

Are you sure you want to change the base?

Bump actions/setup-python from 3.1.2 to 4.6.0 #69

Commits on Nov 1, 2021

Commits on Nov 2, 2021

Commits on Nov 3, 2021

Commits on Nov 4, 2021

Commits on Nov 5, 2021

Commits on Nov 6, 2021

Commits on Nov 14, 2021

Commits on Dec 23, 2021

Commits on Apr 14, 2022

Commits on Jul 14, 2022

Commits on Jul 15, 2022

Commits on Jan 18, 2023

Commits on Jan 27, 2023

Commits on Feb 5, 2023

Commits on Feb 9, 2023

Commits on Mar 9, 2023

Commits on Mar 10, 2023

Commits on Mar 11, 2023

Commits on Mar 12, 2023

Commits on Mar 14, 2023

Commits on Mar 24, 2023

Commits on Mar 29, 2023

Commits on Apr 4, 2023

Commits on Apr 14, 2023

Commits on Apr 15, 2023

Commits on Apr 16, 2023

Commits on Apr 18, 2023

Commits on Apr 20, 2023