internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: spack/spack

Issue:
py-matplotlib: multiple backend support
Can the `matplotlib` support multiple backends? 

```
[spack]$ spack install py-matplotlib backend=agg,tkagg
==> Error: multiple values are not allowed for variant "backend"
```


Discussion:
Hi @lrtfm, I wrote most of this package recipe. The `backend` variant is only which backend to enable by default, all backends will still be installed and functional as long as their dependencies are found at run-time. We could add another variant to control which backend deps are installed that allows multiple, but I don't think that's necessary. What do you think?
@adamjstewart, thanks, I got it.  If this is the case, adding more explanation for this option would be better, I think.
Where would you document that? In the spack info message? Or in the package?
In the space info message. Is this ok?

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/py-matplotlib/package.py b/var/spack/repos/builtin/packages/py-matplotlib/package.py
--- a/var/spack/repos/builtin/packages/py-matplotlib/package.py
+++ b/var/spack/repos/builtin/packages/py-matplotlib/package.py
@@ -65,7 +65,9 @@ class PyMatplotlib(PythonPackage):
     if sys.platform == 'darwin':
         default_backend = 'macosx'
 
-    variant('backend', default=default_backend, description='Default backend',
+    variant('backend', default=default_backend,
+            description='Default backend. All backends are installed and ' +
+            'functional as long as dependencies are found at run-time',
             values=all_backends, multi=False)
     variant('movies', default=False,
             description='Enable support for saving movies')


Test patch:
Repository: spack/spack

Issue:
Disable RPATH/RUNPATH forcing for mixed toolchains.
Compilers in mixed toolchains, e.g. NAG/GCC, might require different linker prefixes. Without this, it becomes impossible to build packages requiring both C and Fortran compilers at all.

Another solution would be to override `disable_new_dtags` and `enable_new_dtags` properties in the `Nag` class so they would return empty lines.


Discussion:
@alalazo does this make sense?
@alalazo I have moved the `Darwin` case from `compiler.py` to `build_environment.py` so the logic would be in one place. I have also added some tests but I am not sure whether the way I modified `lib/spack/spack/test/data/config/compilers.yaml` is acceptable.
Ping @alalazo 
@alalazo this is rather old. Could you, please, review it again?
Sure, I'll put it on my plate for tomorrow. Apologies for the delay.
I'm reading this again, and was wondering if:

> Another solution would be to override disable_new_dtags and enable_new_dtags properties in the Nag class so they would return empty lines.

would be a better solution. If the practical issue is with NAG only we can solve it with fewer lines like that, and wait some more for compiler as dependencies to be a thing. @skosukhin would that be fine with you?

EDIT: On top of that there's a failing test with clingo.

Resolving patch:
diff --git a/lib/spack/spack/compilers/nag.py b/lib/spack/spack/compilers/nag.py
--- a/lib/spack/spack/compilers/nag.py
+++ b/lib/spack/spack/compilers/nag.py
@@ -102,3 +102,13 @@ def fc_rpath_arg(self):
     @property
     def linker_arg(self):
         return '-Wl,-Wl,,'
+
+    @property
+    def disable_new_dtags(self):
+        # Disable RPATH/RUNPATH forcing for NAG/GCC mixed toolchains:
+        return ''
+
+    @property
+    def enable_new_dtags(self):
+        # Disable RPATH/RUNPATH forcing for NAG/GCC mixed toolchains:
+        return ''


Test patch:
Repository: spack/spack

Issue:
spack create -t r gives wrong signature for configure_args in template
This is related to issue #21760
The template for a new RPackage package generated from spack create -t r
includes a templated dummy definition
<configure_args(self, spec, prefix)>

However, the lib/spack/spack/build_systems/r.py file defines configure_args to only
accept <self> as an argument.

### Steps to reproduce the issue
```console
$ spack create -t r r-testpackage
```
The new package.py for r-testpackage will include a definition for configure_args
with the wrong signature.

### Information on your system
```spack debug report
* **Spack:** 0.14.2
* **Python:** 3.6.8
* **Platform:** linux-rhel8-ivybridge
```
### Additional information

<!-- These boxes can be checked by replacing [ ] with [x] or by clicking them after submitting the issue. -->
- [x ] I have run `spack debug report` and reported the version of Spack/Python/Platform
- [x ] I have searched the issues of this repo and believe this is not a duplicate
- [ ] I have run the failing commands in debug mode and reported the output



Discussion:

Resolving patch:
diff --git a/lib/spack/spack/cmd/create.py b/lib/spack/spack/cmd/create.py
--- a/lib/spack/spack/cmd/create.py
+++ b/lib/spack/spack/cmd/create.py
@@ -322,7 +322,7 @@ class RPackageTemplate(PackageTemplate):
     # depends_on('r-foo', type=('build', 'run'))"""
 
     body_def = """\
-    def configure_args(self, spec, prefix):
+    def configure_args(self):
         # FIXME: Add arguments to pass to install via --configure-args
         # FIXME: If not needed delete this function
         args = []


Test patch:
Repository: spack/spack

Issue:
shell test kcov suggestion does not work
### Steps to reproduce the issue

```console
$ ./share/spack/qa/run-shell-tests 
ERROR: kcov is required to run this script.

To install with Spack, run:
    $ spack install kcov
Then add the bin directory to your PATH.
$ spack load kcov
$ ./share/spack/qa/run-shell-tests 
ERROR: kcov is required to run this script.

To install with Spack, run:
    $ spack install kcov
Then add the bin directory to your PATH.
```

Seems like there is no kcov binary:

```
$ kcov

Command 'kcov' not found, but can be installed with:

sudo apt install kcov
```

* **Spack:** 0.16.0-1501-e8eb76c198
* **Python:** 3.8.7
* **Platform:** linux-ubuntu20.04-zen2
* **Concretizer:** clingo

### Additional information

- [x] I have run `spack debug report` and reported the version of Spack/Python/Platform
- [x] I have searched the issues of this repo and believe this is not a duplicate
- [x] I have run the failing commands in debug mode and reported the output





Discussion:
What do you get when you run:
```console
$ spack load kcov
$ which kcov
```
Spack builds a `kcov` executable for me.
```
$ ls /home/harmen/spack/opt/spack/linux-ubuntu20.04-zen2/gcc-10.2.0/kcov-38-ayzjybgqnlsbxr7bvwitlo4xzxop2vki/bin/
kcov-system-daemon
```
Oh wow, it's their cmake script. It's terrible :( https://github.com/SimonKagstrom/kcov/blob/master/src/CMakeLists.txt

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/kcov/package.py b/var/spack/repos/builtin/packages/kcov/package.py
--- a/var/spack/repos/builtin/packages/kcov/package.py
+++ b/var/spack/repos/builtin/packages/kcov/package.py
@@ -19,6 +19,8 @@ class Kcov(CMakePackage):
     depends_on('cmake@2.8.4:', type='build')
     depends_on('zlib')
     depends_on('curl')
+    depends_on('elfutils')
+    depends_on('binutils +libiberty', type='link')
 
     def cmake_args(self):
         # Necessary at least on macOS, fixes linking error to LLDB


Test patch:
Repository: spack/spack

Issue:
hwloc: added missing ncurses dependency



Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/hwloc/package.py b/var/spack/repos/builtin/packages/hwloc/package.py
--- a/var/spack/repos/builtin/packages/hwloc/package.py
+++ b/var/spack/repos/builtin/packages/hwloc/package.py
@@ -91,6 +91,10 @@ class Hwloc(AutotoolsPackage):
     depends_on('cairo', when='+cairo')
     depends_on('numactl', when='@:1.11.11 platform=linux')
 
+    # see https://github.com/open-mpi/hwloc/pull/417
+    depends_on('ncurses ~termlib', when='@:2.2')
+    depends_on('ncurses')
+
     # When mpi=openmpi, this introduces an unresolvable dependency.
     # See https://github.com/spack/spack/issues/15836 for details
     depends_on('mpi', when='+netloc')


Test patch:
Repository: spack/spack

Issue:
Variant issue for mpich
### Steps to reproduce the issue

Building and installing mpich with `--with-device=ch4:ucx` outside of Spack then running:

```console
spack external find 
```

### Error Message

```console
==> Error: invalid values for variant "device" in package "mpich": ['ch4:ucx']
```

### Information on your system

<!-- Please include the output of `spack debug report` -->

```
* **Spack:** 0.16.1-1764-3305a39c55
* **Python:** 3.8.5
* **Platform:** linux-ubuntu20.04-skylake
* **Concretizer:** original
```

<!-- If you have any relevant configuration detail (custom `packages.yaml` or `modules.yaml`, etc.) you can add that here as well. -->

### Additional information

<!-- These boxes can be checked by replacing [ ] with [x] or by clicking them after submitting the issue. -->
- [x] I have run `spack debug report` and reported the version of Spack/Python/Platform
- [x] I have searched the issues of this repo and believe this is not a duplicate
- [ ] I have run the failing commands in debug mode and reported the output

<!-- We encourage you to try, as much as possible, to reduce your problem to the minimal example that still reproduces the issue. That would help us a lot in fixing it quickly and effectively!

If you want to ask a question about the tool (how to use it, what it can currently do, etc.), try the `#general` channel on our Slack first. We have a welcoming community and chances are you'll get your reply faster and without opening an issue.

Other than that, thanks for taking the time to contribute to Spack! -->



Discussion:
@raffenet @yfguo should we change `multi=False` to `multi=True` for this variant?
For the device variant? You can only build one device configuration (ch3 or ch4), so I suspect not. `--with-device=ch4:ucx` specifies the ch4 device with ucx netmod.
In that case it sounds like the bug is in the automatic detection.
do you guys know of any way to avoid the problem from user command as a temporary fix that I could use?
If you don't care about mpich and only want to load a add a specific package, you can do `spack external find <package>`. Otherwise I think the fix is pretty simple. I'll push a PR and let you test it.

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/mpich/package.py b/var/spack/repos/builtin/packages/mpich/package.py
--- a/var/spack/repos/builtin/packages/mpich/package.py
+++ b/var/spack/repos/builtin/packages/mpich/package.py
@@ -274,12 +274,9 @@ def is_disabled(text):
             elif re.search(r'--with-pmix', output):
                 variants += ' pmi=pmix'
 
-            match = re.search(r'MPICH Device:\s+(\S+)', output)
+            match = re.search(r'MPICH Device:\s+(ch3|ch4)', output)
             if match:
-                if match.group(1) == 'ch3:nemesis':
-                    variants += ' device=ch3'
-                else:
-                    variants += ' device=' + match.group(1)
+                variants += ' device=' + match.group(1)
 
             match = re.search(r'--with-device=ch.\S+(ucx|ofi|mxm|tcp)', output)
             if match:


Test patch:
Repository: spack/spack

Issue:
Installation issue: mesa with gcc10.1.0
<!-- Thanks for taking the time to report this build failure. To proceed with the report please:

1. Title the issue "Installation issue: <name-of-the-package>".
2. Provide the information required below.

We encourage you to try, as much as possible, to reduce your problem to the minimal example that still reproduces the issue. That would help us a lot in fixing it quickly and effectively! -->

### Steps to reproduce the issue

<!-- Fill in the exact spec you are trying to build and the relevant part of the error message -->

gcc version 10.1.0 installed and set as default compiler.

```console
$ spack env create mesa
$ spack env activate mesa
$ spack add mesa
$ spack install
```

### Information on your system
```console
$ spack debug report
* **Spack:** 0.16.1-1850-c2a9b7aa08
* **Python:** 3.8.8
* **Platform:** linux-ubuntu18.04-skylake
* **Concretizer:** original
```

<!-- If you have any relevant configuration detail (custom `packages.yaml` or `modules.yaml`, etc.) you can add that here as well. -->

### Additional information

<!-- Please upload the following files. They should be present in the stage directory of the failing build. Also upload any config.log or similar file if one exists. -->

* [spack-build-out.txt](https://github.com/spack/spack/files/6197341/spack-build-out.txt)
* [spack-build-env.txt](https://github.com/spack/spack/files/6197343/spack-build-env.txt)

@chuckatkins  @v-dobrev

Known issue in gcc 10.1.0, fixed in gcc 10.2.0:
* [gcc bug report](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96130)
* [Ubuntu bug report](https://bugs.launchpad.net/ubuntu/+source/gcc-10/+bug/1887557)

### General information

<!-- These boxes can be checked by replacing [ ] with [x] or by clicking them after submitting the issue. -->
- [x] I have run `spack debug report` and reported the version of Spack/Python/Platform
- [x] I have run `spack maintainers <name-of-the-package>` and @mentioned any maintainers
- [x] I have uploaded the build log and environment files
- [x] I have searched the issues of this repo and believe this is not a duplicate



Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/mesa/package.py b/var/spack/repos/builtin/packages/mesa/package.py
--- a/var/spack/repos/builtin/packages/mesa/package.py
+++ b/var/spack/repos/builtin/packages/mesa/package.py
@@ -75,6 +75,10 @@ class Mesa(MesonPackage):
     depends_on('xrandr', when='+glx')
     depends_on('glproto@1.4.14:', when='+glx')
 
+    # version specific issue
+    # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96130
+    conflicts('%gcc@10.1.0', msg='GCC 10.1.0 has a bug')
+
     # Require at least 1 front-end
     # TODO: Add egl to this conflict once made available
     conflicts('~osmesa ~glx')


Test patch:
Repository: spack/spack

Issue:
Installation issue: gdrcopy
When I try to install gdrcopy it builds but tries to install in /usr/local/lib as opposed to my spack sandbox.  I modified gdrcopy/package.py to fix the problem.

I get the following error:

==> Installing gdrcopy-master-gn4oaromvgzkq72ld66jpynzutojejw6
==> No binary for gdrcopy-master-gn4oaromvgzkq72ld66jpynzutojejw6 found: installing from source
==> gdrcopy: Executing phase: 'edit'
==> gdrcopy: Executing phase: 'build'
==> gdrcopy: Executing phase: 'install'
==> Error: ProcessError: Command exited with status 2:
    'make' '-j16' 'lib_install' 'PREFIX=/home/mjleven/local/spatse/install/spack/opt/spack/linux-rhel8-thunderx2/gcc-10.2.0/gdrcopy-master-gn4oaromvgzkq72ld66jpynzutojejw6'
 
3 errors found in build log:
     18    make LIB_MAJOR_VER=2 LIB_MINOR_VER=2
     19    make[1]: Entering directory '/tmp/mjleven/spack-stage/spack-stage-gdrcopy-master-gn4oaromvgzkq72ld66jpynzutojejw6/spack-src/src'
     20    GDRAPI_ARCH=ARM64
     21    make[1]: Leaving directory '/tmp/mjleven/spack-stage/spack-stage-gdrcopy-master-gn4oaromvgzkq72ld66jpynzutojejw6/spack-src/src'
     22    installing in /usr/local/lib /usr/local/include...
     23    'src/libgdrapi.so.2.2' -> '/usr/local/lib/libgdrapi.so.2.2'
  >> 24    install: cannot create regular file '/usr/local/lib/libgdrapi.so.2.2': Permission denied
  >> 25    ln: failed to create symbolic link 'libgdrapi.so.2': Permission denied
  >> 26    ln: failed to create symbolic link 'libgdrapi.so': Permission denied
     27    make: *** [Makefile:68: lib_install] Error 1

I fixed the problem with a change to gdrcopy/package.py:

[mjleven@stnv1 spack]$ git diff
diff --git a/var/spack/repos/builtin/packages/gdrcopy/package.py b/var/spack/repos/builtin/packages/gdrcopy/package.py
index 88cf814e40..14ba4bb31b 100644
--- a/var/spack/repos/builtin/packages/gdrcopy/package.py
+++ b/var/spack/repos/builtin/packages/gdrcopy/package.py
@@ -32,4 +32,4 @@ def build(self, spec, prefix):
     def install(self, spec, prefix):
         mkdir(prefix.include)
         mkdir(prefix.lib64)
-        make('lib_install', 'PREFIX={0}'.format(self.prefix))
+        make('lib_install', 'prefix={0}'.format(self.prefix))
[mjleven@stnv1 spack]$
 


Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/gdrcopy/package.py b/var/spack/repos/builtin/packages/gdrcopy/package.py
--- a/var/spack/repos/builtin/packages/gdrcopy/package.py
+++ b/var/spack/repos/builtin/packages/gdrcopy/package.py
@@ -26,4 +26,9 @@ def build(self, spec, prefix):
     def install(self, spec, prefix):
         mkdir(prefix.include)
         mkdir(prefix.lib64)
-        make('lib_install', 'PREFIX={0}'.format(self.prefix))
+        if spec.satisfies('@2.2:'):
+            make('lib_install',
+                 'prefix={0}'.format(self.prefix))
+        else:
+            make('lib_install',
+                 'PREFIX={0}'.format(self.prefix))


Test patch:
Repository: spack/spack

Issue:
spack concretize issue
When i do spack concretize -f it started showing up with this error.

==> Error: variant "header_only" not found in package "cgal"

I have not seen this error before but only today. I thought of removing cgal but it is one of the dependencies of openfoam. So i will be able to remove it as openfoam install is painfully and takes really longtime . So is there a workaround for this issue. I even tried to install cgal with header on and i get the same error. Is there a way to fix this ?

thanks


Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/cgal/package.py b/var/spack/repos/builtin/packages/cgal/package.py
--- a/var/spack/repos/builtin/packages/cgal/package.py
+++ b/var/spack/repos/builtin/packages/cgal/package.py
@@ -31,7 +31,7 @@ class Cgal(CMakePackage):
     variant('build_type', default='Release',
             description='The build type to build',
             values=('Debug', 'Release'))
-    variant('header-only', default=False,
+    variant('header_only', default=False,
             description='Install in header only mode')
 
     # ---- See "7 CGAL Libraries" at:


Test patch:
Repository: spack/spack

Issue:
Installation issue with openjdk:  "Error: NameError: name 'Prefix' is not defined"
### Steps to reproduce the issue

Latest spack develop on OS X gives:

```console
 → spack install -v hpcviewer
==> Warning: Missing a source id for openjdk@11.0.10_9
[+] /usr (external openjdk-11.0.10_9-eoscwsxi5erdz5htmnixttlxjzhogare)
==> Installing hpcviewer-2021.03-a4q2ajczhy6u5dxcdszfx3lelqbf7tmd
==> No binary for hpcviewer-2021.03-a4q2ajczhy6u5dxcdszfx3lelqbf7tmd found: installing from source
==> Warning: Missing a source id for openjdk@11.0.10_9
==> Warning: microarchitecture specific optimizations are not supported yet on mixed compiler toolchains [check apple-clang@12.0.0 for further details]
==> Error: NameError: name 'Prefix' is not defined
```

### Information on your system

* Mac OS 10.15.5
* Spack cloned today


Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/openjdk/package.py b/var/spack/repos/builtin/packages/openjdk/package.py
--- a/var/spack/repos/builtin/packages/openjdk/package.py
+++ b/var/spack/repos/builtin/packages/openjdk/package.py
@@ -7,6 +7,7 @@
 import platform
 import re
 
+from spack.util.prefix import Prefix
 
 # If you need to add a new version, please be aware that:
 #  - versions in the following dict are automatically added to the package


Test patch:
Repository: spack/spack

Issue:
Installation issue: root
Spec: `root@6.22.00 +python` does not correctly build pyroot bindings

### Steps to reproduce the issue

```shell
spack install root@6.22.00 +python
spack load root@6.22.00 +python
python -c "import ROOT"
```
produces the error message:
```
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'ROOT'
```

I do not get this problem building `root@6.16.00`.

### Information on your system

<!-- Please include the output of `spack debug report` -->
* **Spack:** 0.16.1-2167-982d3ab
* **Python:** 3.6.8
* **Platform:** linux-centos7-skylake
* **Concretizer:** original
<!-- If you have any relevant configuration detail (custom `packages.yaml` or `modules.yaml`, etc.) you can add that here as well. -->

### Additional information

I believe that the issue is caused by the lines:
```
        # Some special features
        if self.spec.satisfies('@6.20:'):
            options.append(define_from_variant('pyroot', 'python'))
```

ROOT recently changed the build option from `python` to `pyroot`.
These lines implement that change for `>=6.20`.
However, examining the ROOT source code I see the new pyroot build command was introduced inbetween:
[v6-20-00](https://github.com/root-project/root/blob/v6-20-00/cmake/modules/RootBuildOptions.cmake) and
[v6-20-02](https://github.com/root-project/root/blob/v6-20-02/cmake/modules/RootBuildOptions.cmake)

Thus I believe that these lines should be something like:
```
        # Some special features
        if self.spec.satisfies('@6.20.02:'):
            options.append(define_from_variant('pyroot', 'python'))
```

spack maintainers: @chissg, @HadrienG2 @drbenmorgan @vvolkl

### General information

<!-- These boxes can be checked by replacing [ ] with [x] or by clicking them after submitting the issue. -->
- [x] I have run `spack debug report` and reported the version of Spack/Python/Platform
- [x] I have run `spack maintainers <name-of-the-package>` and @mentioned any maintainers
- [ ] I have uploaded the build log and environment files
- [x] I have searched the issues of this repo and believe this is not a duplicate



Discussion:
Thanks @davehadley for the report, and providing the fix already! Your proposed change looks reasonable to me. If you can open a PR with the changed line, I'd say, just go ahead.
Yes I can put in a PR once I test that this fix builds successfully.

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/root/package.py b/var/spack/repos/builtin/packages/root/package.py
--- a/var/spack/repos/builtin/packages/root/package.py
+++ b/var/spack/repos/builtin/packages/root/package.py
@@ -430,7 +430,7 @@ def cmake_args(self):
         ]
 
         # Some special features
-        if self.spec.satisfies('@6.20:'):
+        if self.spec.satisfies('@6.20.02:'):
             options.append(define_from_variant('pyroot', 'python'))
         else:
             options.append(define_from_variant('python'))


Test patch: