`spack style` tests were annoyingly brittle because we could not easily be
specific about which tools to run (we had to use `--no-black`, `--no-isort`,
`--no-flake8`, and `--no-mypy`). We should be able to specify what to run OR
what to skip.

Now you can run, e.g.:

    spack style --tool black,flake8

or:

    spack style --skip black,isort

- [x] Remove  `--no-black`, `--no-isort`, `--no-flake8`, and `--no-mypy` args.
- [x] Add `--tool TOOL` argument.
- [x] Add `--skip TOOL` argument.
- [x] Allow either `--tool black --tool flake8` or `--tool black,flake8` syntax.

A GitHub rebase merge seems to rewrite commits even if it would be a
fast-forward, which means that the commit merged from spack#24718 is wrong.

- [x] update `.git-blame-ignore-revs` with real commit from `develop`

This test relied on an old version of the `flake8_package` fixture that modified
the spack repository, but it doesn't do that anymore. There are other tests for
`changed_files()` that do a better job of mocking up a git repository with
changes, so we can just delete this one.

* wi4mpi: New version 3.6.0

libunwind is supported on Linux only

…spack#31828)

ROOT also needs updating for downstream macOS packages

…31841)

* kokkos@develop: set CMAKE_CXX_STANDARD instead of Kokkos_CXX_STANDARD

* use CMAKE_CXX_STANDARD regardless of kokkos version

…aml (spack#31864)

Resurrect Known issues, since users ask frequently about that.

)

Spack doesn't have an easy way to say something like "If I build
package X, then I *need* version Y":

* If you specify something on the command line, then you ensure
  that the constraints are applied, but the package is always built
* Likewise if you `spack add X...`` to your environment, the
  constraints are guaranteed to hold, but the environment always
  builds the package
* You can add preferences to packages.yaml, but these are not
  guaranteed to hold (Spack can choose other settings)

This commit adds a 'require' subsection to packages.yaml: the
specs added there are guaranteed to hold. The commit includes
documentation for the feature.

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

`requirement_policy/3` is generated and may not be in Spack's inputs to Clingo.
Currently this is causing warnings like:

```
$ spack spec zlib
/global/u2/t/tgamblin/src/spack/lib/spack/spack/solver/concretize.lp:510:3-43: info: atom does not occur in any rule head:
  requirement_policy(Package,X,"one_of")

/global/u2/t/tgamblin/src/spack/lib/spack/spack/solver/concretize.lp:517:3-43: info: atom does not occur in any rule head:
  requirement_policy(Package,X,"one_of")

/global/u2/t/tgamblin/src/spack/lib/spack/spack/solver/concretize.lp:523:3-43: info: atom does not occur in any rule head:
  requirement_policy(Package,X,"any_of")

/global/u2/t/tgamblin/src/spack/lib/spack/spack/solver/concretize.lp:534:3-43: info: atom does not occur in any rule head:
  requirement_policy(Package,X,"any_of")

Input spec
--------------------------------
zlib

Concretized
--------------------------------
[email protected]%[email protected]+optimize+pic+shared arch=cray-sles15-haswell
```

- [x] Silence warning with `#defined requirement_policy/3`

)

* filesystem: use lstat in recursive mtime

When a `develop` path contains a dead symlink, the `os.stat` in the recursive `mtime` determination trips up over it.

Closes spack#32165.

We're seeing errors pop up with older versions of Kokkos and newer versions of
`oneapi`, specifically:

    error: no member named 'ONEAPI' in namespace 'sycl'

This hapens because `sycl::ONEAPI` is `sycl::ext::oneapi` since oneapi `2022.0.0`.
`[email protected]:` uses the new namespace. A conflict was present for this, but it was too
specific -- both to `dpcpp` and to the `2022.0.0` version.

- [x] Expand version ranges in `kokkos` conflict
- [x] Add conflict for `oneapi` in addition to `dpcpp`

…#32179)

* CI: reduce the amount of tests run in the original concretizer
* Don't test Python 3.6 on the original concretizer

…31841)

* kokkos@develop: set CMAKE_CXX_STANDARD instead of Kokkos_CXX_STANDARD

* use CMAKE_CXX_STANDARD regardless of kokkos version

…cies. (spack#32182)

* Adding 36.3.8h_2020-05-04

* [@spackbot] updating style on behalf of mikerenfro

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

* Add version 1.4.0

- override build variant with explicit variant instead of __init__ workaround

* Update package.py

* [py-bitshuffle] New package

* [py-bitshuffle] compiling against spack hdf5

* [py-bitshuffle] flake8

* [py-bitshuffle] update import ine

* [@spackbot] updating style on behalf of qwertos

Co-authored-by: James A Zilberman <[email protected]>
Co-authored-by: qwertos <[email protected]>

- [x] Rework `headers` to search a sequence of directories and to display all searched
      locations on error, as opposed to handling each directory with a variable

- [x] Make `headers` and `libs` do the same type of search and raise the same sort of
      errors.

Co-authored-by: Todd Gamblin <[email protected]>

The Python that comes with XCode command line tools is a bit weird.

This fixes two issues that were preventing it from bootstrapping:

- [x] CommandLineTools python does not come with a `python-config` executable. If you
      don't have one of these, CMake's FindPython will, for some reason, assume that you
      want Python 2, so you need to set `CLINGO_PYTHON_VERSION` to ensure that clingo
      tells `find_package(Python <VERSION>)` the right thing.

- [x] We weren't setting `PYTHONHOME` correctly in Python's `package.py`. We were
      setting it to the `prefix` from Python `sysconfig`, but `prefix` tells you where
      the executable lives. CommandLineTools python reports its prefix as

          /Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8

      but that doesn't exist. It looks like Apple builds the full python and just copies
      pieces of it into command line tools. PYTHONHOME is supposed to tell you where the
      default python library location is. So you have to look at the `base`, which
      `sysconfig` reports as

          /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8

      On most systems this is probably the same as `prefix`, but not with
      CommandLineTools, which has its system library in a different place.

The second change here was cherry-picked to 0d981a0 before merging and doesn't show
up here.

Co-authored-by: Adam J. Stewart <[email protected]>

Create a package for riscv-gnu-toolchain, a cross-compilation tool.