Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
Co-authored-by: openCARP consortium <info@opencarp.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The 'multicore' backend always uses SMP, so reverse
the logic of the `conflict` clause. This resolves an issue
where the '+smp' default caused the 'backend' to switch
away from 'multicore' unintentionally (#29234).
|
|
|
|
failures (#29267)
|
|
|
|
|
|
fixes #29203
This PR fixes a subtle bug we have when importing
Spack packages as Python modules that can lead to
multiple module objects being created for the same
package.
It also fixes all the places in unit-tests where
"relying" on the old bug was crucial to have a new
"clean" state of the package class.
|
|
Update `warpx` & `py-warpx` to the latest release, `22.03`.
|
|
Co-authored-by: Nat Shineman <shineman.5@buckeyemail.osu.edu>
|
|
|
|
* llvm: fix build with Fujitsu compiler.
* Add conflict gcc 8.4 and aarch64.
* update conflicts version.
* fix version to apply patch.
|
|
* New package py-npx
* Fixed linked issue
|
|
|
|
This commit reverts the GCS fetch strategy to before commit:
d7596125231e800ca41c60e379be2b8abb47d20d
The previous commit added some s3 syntax to handle connections, but
added them into the GCS fetch strategy in a way that prevents GCS from
working anymore.
|
|
* Add checksum for gmp 6.2.0
* Update package.py
|
|
|
|
|
|
* rocmcc compiler: initial commit based on aocc and clang
Co-authored-by: luker <luke.roskop@hpe.com>
Co-authored-by: Tom Scogland <scogland1@llnl.gov>
|
|
* py-mako-1.1.6
* fix python dependency
|
|
|
|
|
|
|
|
The Kokkos sources already know AMPERE86 since some time; make
Spack accept and pass it, too.
|
|
Recipes that are not actually required for LBANN or DiHydrogen to
build. These should be concretized within the same environment or
installed via PIP using the same Python that installed LBANN.
Removing these will help eliminate build time failures that are
actually associated with Python tools, not LBANN.
|
|
Bumps [actions/setup-python](https://github.com/actions/setup-python) from 2.3.1 to 3.
- [Release notes](https://github.com/actions/setup-python/releases)
- [Commits](https://github.com/actions/setup-python/compare/f38219332975fe8f9c04cca981d674bf22aea1d3...0ebf233433c08fb9061af664d501c3f3ff0e9e20)
---
updated-dependencies:
- dependency-name: actions/setup-python
dependency-type: direct:production
update-type: version-update:semver-major
...
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
|
|
|
|
- add version 4.0-beta to available versions
- update stable version to 3.1.3
Co-authored-by: Eduardo Rothe <eduardo.rothe@epfl.ch>
|
|
|
|
|
|
|
|
|
|
|
|
Bumps [actions/checkout](https://github.com/actions/checkout) from 2 to 3.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](https://github.com/actions/checkout/compare/v2...a12a3943b4bdde767164f792f33f40b04645d846)
---
updated-dependencies:
- dependency-name: actions/checkout
dependency-type: direct:production
update-type: version-update:semver-major
...
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
|
|
Bumps [docker/login-action](https://github.com/docker/login-action) from 1.13.0 to 1.14.1.
- [Release notes](https://github.com/docker/login-action/releases)
- [Commits](https://github.com/docker/login-action/compare/6af3c118c8376c675363897acf1757f7a9be6583...dd4fa0671be5250ee6f50aedf4cb05514abda2c7)
---
updated-dependencies:
- dependency-name: docker/login-action
dependency-type: direct:production
update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
|
|
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.
|
|
|
|
|
|
|
|
|
|
|