| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* py-fastpath: new package
* Update var/spack/repos/builtin/packages/py-fastpath/package.py
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
|
|
|
|
|
|
|
|
|
|
Historically, development of the Octopus code was done on the "develop" branch
on https://gitlab.com/octopus-code/octopus but now development takes place on
"main" (since Q3 2022).
The suggestion in this PR to solve the issue is to keep the spack label
`octopus@develop` as this better indicates this is the development branch on git
than `octopus@main`, but of course to use the `main` branch (there is no choice
here - the `develop` branch is not touched anymore). Sticking to
`octopus@develop` as the version label also keeps backwards compatibility.
|
|
* And add the option to compile support for Intel GPU's
|
|
This reverts commit d06fd26c9ac8dd525fc129096188e2ea9fd2d0d7.
The problem is that Bitbucket's API forwards download requests to an S3 bucket using a temporary URL. This URL includes a signature for the request, which embeds the HTTP verb. That means only GET requests are allowed, and HEAD requests would fail verification, leading to 403 erros. The same is observed when using `curl -LI ...`
|
|
|
|
|
|
|
|
Co-authored-by: Peter Thompson <thompson81@llnl.gov>
Co-authored-by: Tamara Dahlgren <35777542+tldahlgren@users.noreply.github.com>
|
|
* ffmpeg: add version 5.1.2 and switch to conditional variants
Also: py-torchvision: restrict ffmpeg dependency
|
|
|
|
|
|
|
|
|
|
|
|
|
|
v0.5 does not build due to a change in setting `arch` introduced in v0.5.2, compatibility with which was not kept in `arbor/package.py`. Since v0.5.2 is compatible with `arbor/package.py`, and is API compatible with v0.5, any users relying on v0.5 can rely on v0.5.2.
|
|
|
|
|
|
* first build of keras-tuner with dataset kt-legacy
* [py-kt-legacy] fixed homepage
* [py-kt-legacy] depends on setuptools
* [py-kt-legacy] fixed import
* [@spackbot] updating style on behalf of qwertos
Co-authored-by: Sid Pendelberry <sid@rit.edu>
Co-authored-by: qwertos <qwertos@users.noreply.github.com>
|
|
|
|
|
|
* Add py-urwid@2.1.2
* [@spackbot] updating style on behalf of meyersbs
|
|
|
|
|
|
|
|
|
|
|
|
Using `-Werror` is good practice for development and testing, but causes us a great
deal of heartburn supporting multiple compiler versions, especially as newer compiler
versions add warnings for released packages. This PR adds support for suppressing
`-Werror` through spack's compiler wrappers. There are currently three modes for
the `flags:keep_werror` setting:
* `none`: (default) cancel all `-Werror`, `-Werror=*` and `-Werror-*` flags by
converting them to `-Wno-error[=]*` flags
* `specific`: preserve explicitly selected warnings as errors, such as
`-Werror=format-truncation`, but reverse the blanket `-Werror`
* `all`: keeps all `-Werror` flags
These can be set globally in config.yaml, through the config command-line flags, or
overridden by a particular package (some packages use Werror as a proxy for determining
support for other compiler features). We chose to use this approach because:
1. removing `-Werror` flags entirely broke *many* build systems, especially autoconf
based ones, because of things like checking `-Werror=feature` and making the
assumption that if that did not error other flags related to that feature would also work
2. Attempting to preserve `-Werror` in some phases but not others caused similar issues
3. The per-package setting came about because some packages, even with all these
protections, still use `-Werror` unsafely. Currently there are roughly 3 such packages
known.
|
|
* Working updates to py-antlr4-python3-runtime and py-omegaconf
* [py-antlr4-python3-runtime] added version 4.9.3
* [@spackbot] updating style on behalf of qwertos
Co-authored-by: Benjamin Meyers <bsmits@rit.edu>
Co-authored-by: qwertos <qwertos@users.noreply.github.com>
|
|
For reasons beyond me Python thinks it's a great idea to upgrade HEAD
requests to GET requests when following redirects. So, this PR adds a
better `HTTPRedirectHandler`, and also moves some ad-hoc logic around
for dealing with disabling SSL certs verification.
Also, I'm stumped by the fact that Spack's `url_exists` does not use
HEAD requests at all, so in certain cases Spack awkwardly downloads
something first to see if it can download it, and then downloads it
again because it knows it can download it. So, this PR ensures that both
urllib and botocore use HEAD requests.
Finally, it also removes some things that were there to support currently
unsupported Python versions.
Notice that the HTTP spec [section 10.3.2](https://datatracker.ietf.org/doc/html/rfc2616.html#section-10.3.2) just talks about how to deal
with POST request on redirect (whether to follow or not):
> If the 301 status code is received in response to a request other
> than GET or HEAD, the user agent MUST NOT automatically redirect the
> request unless it can be confirmed by the user, since this might
> change the conditions under which the request was issued.
> Note: When automatically redirecting a POST request after
> receiving a 301 status code, some existing HTTP/1.0 user agents
> will erroneously change it into a GET request.
Python has a comment about this, they choose to go with the "erroneous change".
But they then mess up the HEAD request while following the redirect, probably
because they were too busy discussing how to deal with POST.
See https://github.com/python/cpython/pull/99731
|
|
* E4S: Conservatively add ecp-data-vis-sdk
* Remove ascent from CUDA SDK stack to stop hanging on Dray
* Adios2: Newer FindPython uses Python_EXECUTABLE
|
|
(#33746)" (#34087)
This reverts commit 5c4137baf19b9e271a2f13e886d6b875aab067dd.
|
|
* [libjpeg-turbo] Added version 2.1.3
* [imagecodecs] Added jpeg deependency commented outconglicting libraries
* [WIP]
* [py-imagecodecs] modifying setup.py to work with spack install locations
* [py-imagecodecs] Removed comments and unneeded dependencies
* [py-imagecodecs] removed some comments and fixed up some flake8 complaints
* [py-imagecodecs] flake8
* [py-imagecodecs] fixed import
* [@spackbot] updating style on behalf of qwertos
Co-authored-by: James A Zilberman <jazrc@rit.edu>
Co-authored-by: qwertos <qwertos@users.noreply.github.com>
|
|
|
|
|
|
|
|
|
|
The package.py assumed "+mpi" in many places, without checking for the variant.
This problem went undetected, as a hard dependency on scalapack pulled an mpi
implementation into the dependency chain (this is also fixed).
Also, the +mpi variant is used select between serial and parallel mode:
It has to enable MPI and ScaLAPACK: They are inter-dependent. Compile
fails because of checks for the other if the other is not enabled.
Co-authored-by: Bernhard Kaindl <contact@bernhard.kaindl.dev>
|
|
|
|
platforms (#34068)
|
|
|
|
|
|
|
|
Co-authored-by: Alexander Knieps <a.knieps@fz-juelich.de>
|
|
Reference: https://lists.boost.org/Archives/boost/2019/11/247380.php
As reported at the end of #33998 and this link, liblzma on older Xcode on
MacOSX 10 misses _lzma_cputhreads, so boost's can't use liblzma on those.
|
|
|
