| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
Co-authored-by: LMS Bioinformatics <bioinformatics@lms.mrc.ac.uk>
|
|
* [py-markdown-it-py] added linkify variant
* [py-markdown-it-py] added version 2.2.0
|
|
* fortrilinos: release 2.3.0 compatible with trilinos@14.0
|
|
py-transformers (#39432)
|
|
* WarpX 23.08
Update WarpX and related Python packages to the lastest releases.
* fix style
---------
Co-authored-by: eugeneswalker <eugenesunsetwalker@gmail.com>
|
|
well (#39498)
|
|
In the HPC package manager, we want the fastest `zlib` implementation by default. `zlib-ng` is up to 4x faster than stock `zlib`, and it can do things like take advantage of AVX-512 instructions. This PR makes `zlib-ng` the default `zlib-api` provider (`zlib-api` was introduced earlier, in #37372).
As far as I can see, the only issues you can encounter are:
1. Build issues with packages that heavily rely on `zlib` internals. In Gitlab CI only one out of hundreds of packages had that issue (it extended zlib with deflate stuff, and used its own copy of zlib sources).
2. Packages that like to detect `zlib-ng` separately and rely on `zlib-ng` internals. The only issue I've found with this among the hundreds of packages built in CI is `perl` trying to report more specific zlib-ng version details, and relied on some internals that got refactored. But yeah... that warrants a patch / conflict and is nothing special.
At runtime, you cannot really have any issues, given that zlib and zlib-ng export the exact same symbols (and zlib-ng tests this in their CI).
You can't really have issues with externals when using zlib-ng either. The only type of issue is when system zlib is rather new, and not marked as external; if another external uses new symbols, and Spack builds an older zlib/zlib-ng, then the external might not find the new symbols. But this is a configuration issue, and it's not an issue caused by zlib-ng, as the same would happen with older Spack zlib.
* zlib-api: use zlib-ng +compat by default
* make a trivial change to zlib-ng to trigger a rebuild
* add `haampie` as maintainer
|
|
|
|
|
|
|
|
|
|
(#39480)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
e.g. 3.1.1 produces this during configuration when trying to install:
ERROR: This version of Botan requires at least gcc 11.0
|
|
|
|
|
|
(#39454)
|
|
|
|
|
|
-Wno-error=incompatible-function-pointer-types (#39453)
|
|
|
|
* Fixed HeFFTe package spec to not do the smoke test prior to 2.2.0, where it breaks
* Convert test return to 'raise SkipTest'
---------
Co-authored-by: Tamara Dahlgren <35777542+tldahlgren@users.noreply.github.com>
|
|
|
|
For the time being this directive prevents the vendored package
to be in the same DAG as the one vendoring it.
|
|
To avoid paying the cost of setup and of a full grounding again,
move cycle detection into a separate program and check first if
the solution has cycles.
If it has, ground only the integrity constraint preventing cycles
and solve again.
|
|
|
|
|
|
|
|
* initial commit for adding new rpp package
* fix styling
|
|
|
|
* Add version HDF5 1.14.2
|
|
* arborx: patch 1.4 for Trilinos 14.0
* arborx: version 1.4.1
|
|
|
|
|
|
|
|
* ports-of-call: new version 1.5.2
* spiner: new version 1.6.2
|
|
Windows executable paths can have spaces in them, which was leading to
errors when constructing Executable objects: the parser was intended
to handle cases where users could provide an executable along with one
or more space-delimited arguments.
* Executable now assumes that it is constructed with a string argument
that represents the path to the executable, but no additional arguments.
* Invocations of Executable.__init__ that depended on this have been
updated (this includes the core, tests, and one instance of builtin
repository package).
* The error handling for failed invocations of Executable.__call__ now
includes a check for whether the executable name/path contains a
space, to help users debug cases where they (now incorrectly)
concatenate the path and the arguments.
|
|
|
|
|
|
* The module-level skip for tests in `cmd.install` on Windows is removed.
A few classes of errors still persist:
* Cdash tests are not working on Windows
* Tests for failed installs are also not working (this will require
investigating bugs in output redirection)
* Environments are not yet supported on Windows
overall though, this enables testing of most basic uses of "spack install"
* Git repositories cached for version lookups were using a layout that
mimicked the URL as much as possible. This was useful for listing the
cache directory and understanding what was present at a glance, but
the paths were overly long on Windows. On all systems, the layout is
now a single directory based on a hash of the Git URL and is shortened
(which ensures a consistent and acceptable length, and also avoids
special characters).
* In particular, this removes util.url.parse_git_url and its associated
test, which were used exclusively for generating the git cache layout
* Bootstrapping is now enabled for unit tests on Windows
|
|
|
|
|
