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

Issue:
Broken builds as of last night
I have an automated build for dyninst - you can see the Dockerfile here:  https://github.com/dyninst/dyninst/tree/master/docker built as follows from that directory

```bash
$ docker build -t dyninst -f Dockerfile ../
```

And it hasn't had an issue building nightly... until last night. It fails to apply a patch and then chokes and dies.

![image](https://user-images.githubusercontent.com/814322/149677381-bacc8569-b71d-4972-8c63-408d9600f2b1.png)

https://github.com/dyninst/dyninst/runs/4833782666?check_suite_focus=true

I tried pinning to the last spack release, that produced a different error:

https://github.com/dyninst/dyninst/pull/1185

![image](https://user-images.githubusercontent.com/814322/149677443-1bcef7d4-6b0a-4aca-8ec3-7c0789927ff5.png)

I'm not sure what I can do here - I'd like the build to keep working. Thanks!


Discussion:
Note that the PR link I'm a bit desperate so I'm going to try to pin to an early version of spack. But this was working two days ago so... no ideas here.
@pbrady @tgamblin @hainest 
I can reproduce the same failure. 
See:  https://github.com/spack/spack/pull/28322

Maybe the range `when="@1.69.0:1.73.0"` needs to be adjusted.
That was my thoughts too (just copy pasta-d this in slack). For my container I'm trying to do 1.73.0. Perhaps the range should be adjusted to 1.72.0? If we want to decide on something to test I can make a branch for it and redo my build.
I'll test 1.72.0 on my build now and see if it still happens.
And thank you @mwkrentel !
The version range comes from https://github.com/spack/spack/issues/28273#issuecomment-1007694749. The open interval version test would then be [1.69.0, 1.73.0), no? Did I muck that up?
1.72 has reached way beyond the original error point so (although the full dyninst container might not build) I think this fixes the issue here! https://github.com/dyninst/dyninst/runs/4835044296?check_suite_focus=true
@hainest I found an example in the docs by grepping for when, and it looks like that syntax is <= so 1.73.0 would be included (highlighted in gray because I'm making good decisions about colors here lol).

![image](https://user-images.githubusercontent.com/814322/149688967-51f6c2e2-7c10-4f19-9580-611ea1eca098.png)


Resolving patch:
diff --git a/var/spack/repos/builtin/packages/boost/package.py b/var/spack/repos/builtin/packages/boost/package.py
--- a/var/spack/repos/builtin/packages/boost/package.py
+++ b/var/spack/repos/builtin/packages/boost/package.py
@@ -311,8 +311,8 @@ def libs(self):
           working_dir="tools/build")
 
     # Fix issues with PTHREAD_STACK_MIN not being a DEFINED constant in newer glibc
-    # See https:://github.com/spack/spack/issues/28273
-    patch("pthread-stack-min-fix.patch", when="@1.69.0:1.73.0")
+    # See https://github.com/spack/spack/issues/28273
+    patch("pthread-stack-min-fix.patch", when="@1.69.0:1.72.0")
 
     def patch(self):
         # Disable SSSE3 and AVX2 when using the NVIDIA compiler


Test patch:
Repository: spack/spack

Issue:
`spack compiler info` returns 0 when not found
### Steps to reproduce

`spack compiler info` returns 0 when an error is hit.

```console
[rocky-8][~]> spack compiler info foo
==> Error: No compilers match spec foo
[rocky-8][~]> echo $?
0
```

### Error message

Error message is valid (see above). Return code is inconsistent.

### Information on your system

* **Spack:** 0.17.1
* **Python:** 3.6.8
* **Platform:** linux-rocky8-zen2
* **Concretizer:** clingo

### General 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:

Resolving patch:
diff --git a/lib/spack/spack/cmd/compiler.py b/lib/spack/spack/cmd/compiler.py
--- a/lib/spack/spack/cmd/compiler.py
+++ b/lib/spack/spack/cmd/compiler.py
@@ -120,7 +120,7 @@ def compiler_info(args):
     compilers = spack.compilers.compilers_for_spec(cspec, scope=args.scope)
 
     if not compilers:
-        tty.error("No compilers match spec %s" % cspec)
+        tty.die("No compilers match spec %s" % cspec)
     else:
         for c in compilers:
             print(str(c.spec) + ":")


Test patch:
Repository: spack/spack

Issue:
librsb update to 1.2.0.11/ 1.3.0.0
### Summary

Hi!
librsb-1.2.0.11 and 1.3.0.0 are out, at https://sourceforge.net/projects/librsb/files/
Time to update its package.py.

### Rationale

_No response_

### Description

_No response_

### Additional information

_No response_

### General information

- [X] I have run `spack --version` and reported the version of Spack
- [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/librsb/package.py b/var/spack/repos/builtin/packages/librsb/package.py
--- a/var/spack/repos/builtin/packages/librsb/package.py
+++ b/var/spack/repos/builtin/packages/librsb/package.py
@@ -11,9 +11,11 @@ class Librsb(AutotoolsPackage):
     library for the Recursive Sparse Blocks format"""
 
     homepage = "http://librsb.sourceforge.net/"
-    url      = "http://download.sourceforge.net/librsb/librsb-1.2.0.10.tar.gz"
+    url      = "http://download.sourceforge.net/librsb/librsb-1.3.0.0.tar.gz"
     list_url = "https://sourceforge.net/projects/librsb/files/"
 
+    version('1.3.0.0',   '2ac8725d1f988f57df9383ae6b0bb2ed221ec935187d31ebb62ea95ee868a790')
+    version('1.2.0.11',  '0686be29bbe277e227c6021de6bd0564e4fc83f996b787886437d28048057bc8')
     version('1.2.0.10',  'ec49f3f78a7c43fc9e10976593d100aa49b1863309ed8fa3ccbb7aad52d2f7b8')
     version('1.2.0.9',   'f421f5d572461601120933e3c1cfee2ca69e6ecc92cbb11baa4e86bdedd3d9fa')
     version('1.2.0.8',   '8bebd19a1866d80ade13eabfdd0f07ae7e8a485c0b975b5d15f531ac204d80cb')
@@ -29,6 +31,7 @@ def configure_args(self):
             '--enable-fortran-module-install',
             'CPPFLAGS={0}'.format(self.spec['zlib'].headers.include_flags),
             'CFLAGS=-O3',
+            'CXXFLAGS=-O3',
             'LDFLAGS={0}'.format(self.spec['zlib'].libs.search_flags)
         ]
         return args


Test patch:
Repository: spack/spack

Issue:
Spack-Trilinos needs dialing UVM option for CUDA
### Summary

Since 13.2.0, Trilinos is removing UVM options for CUDA build because of the performance issues.  


See line 736-:
```
            if '+cuda' in spec:
                options.extend([
                    define_kok_enable('CUDA_UVM', True),
                    define_kok_enable('CUDA_LAMBDA', True),
                    define_kok_enable('CUDA_RELOCATABLE_DEVICE_CODE', 'cuda_rdc')
                ])
                arch_map = Kokkos.spack_cuda_arch_map
                options.extend(
                    define("Kokkos_ARCH_" + arch_map[arch].upper(), True)
                    for arch in spec.variants['cuda_arch'].value
                )
```

I suggest disabling UVM option for 13.2 or later.

### Rationale

_No response_

### Description

_No response_

### Additional information

_No response_

### General information

- [X] I have run `spack --version` and reported the version of Spack
- [X] I have searched the issues of this repo and believe this is not a duplicate


Discussion:
@sethrj I cannot assign the task to myself and other people.
@jrood-nrel we should track this change for exawind.

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/trilinos/package.py b/var/spack/repos/builtin/packages/trilinos/package.py
--- a/var/spack/repos/builtin/packages/trilinos/package.py
+++ b/var/spack/repos/builtin/packages/trilinos/package.py
@@ -736,8 +736,10 @@ def define_tpl(trilinos_name, spack_name, have_dep):
                                   else 'OpenMP'),
             ])
             if '+cuda' in spec:
+                # See https://github.com/spack/spack/issues/28869
+                use_uvm = (spec.version < Version(13.2))
                 options.extend([
-                    define_kok_enable('CUDA_UVM', True),
+                    define_kok_enable('CUDA_UVM', use_uvm),
                     define_kok_enable('CUDA_LAMBDA', True),
                     define_kok_enable('CUDA_RELOCATABLE_DEVICE_CODE', 'cuda_rdc')
                 ])


Test patch:
Repository: spack/spack

Issue:
"unalias: despacktivate: not found" error in setup-env.sh 
### Steps to reproduce

So far I've only seen this in job batch scripts and not in interactive terminals, but I don't know what the difference is yet.

These scripts have a line that looks something like `. /ccs/home/carns/working/src/spack/share/spack/setup-env.sh`, with the path varying depending on where spack is located.

This command reports a failure, though spack appears to work correctly afterwards if you script is not too picky about checking return codes.


### Error message

```
/ccs/home/carns/working/src/spack/share/spack/setup-env.sh: line 143: unalias: despacktivate: not found
```

### Information on your system

```
$ spack debug report
* **Spack:** 0.17.1-915-c11ce3bd1f
* **Python:** 3.6.8
* **Platform:** linux-rhel8-power9le
* **Concretizer:** clingo
```
This is from the Summit system at the OLCF, but we have seen the same error on at least two entirely different systems at ANL.

### General 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:
I'd like to see this addressed soon.  This is bash error that is confusing to a lot of the users in my project.  
I'll also throw on another fun one for the deactivate. Can't deactivate if there is a syntax error in a `spack.yaml` because deactivating tried to load the environment to deactivate. 
> Can't deactivate if there is a syntax error

Deactivate should also undo changes from packages (setup_run_environment), so if the environment is invalid, you can't deactivate.

Resolving patch:
diff --git a/lib/spack/spack/environment/shell.py b/lib/spack/spack/environment/shell.py
--- a/lib/spack/spack/environment/shell.py
+++ b/lib/spack/spack/environment/shell.py
@@ -73,7 +73,7 @@ def deactivate_header(shell):
         cmds += 'if [ ! -z ${SPACK_ENV+x} ]; then\n'
         cmds += 'unset SPACK_ENV; export SPACK_ENV;\n'
         cmds += 'fi;\n'
-        cmds += 'unalias despacktivate;\n'
+        cmds += 'alias despacktivate > /dev/null 2>&1 && unalias despacktivate;\n'
         cmds += 'if [ ! -z ${SPACK_OLD_PS1+x} ]; then\n'
         cmds += '    if [ "$SPACK_OLD_PS1" = \'$$$$\' ]; then\n'
         cmds += '        unset PS1; export PS1;\n'


Test patch:
Repository: spack/spack

Issue:
bmi versions
@carns please have a version for bmi its tied to `main` branch for time being and this causes issues when trying to put specs in buildcache since it cant find version. See https://github.com/spack/spack/blob/9e2d78cffc1beaec2c6e4c3a379c17f25a35b31f/var/spack/repos/builtin/packages/bmi/package.py#L17. 

spack will give a warning because its not a version. 

```
==> Warning: Missing a source id for bmi@main
```

Please consider having a release i dont see any in https://github.com/radix-io/bmi/releases. 


Discussion:
Sure thing @shahzebsiddiqui .  I'm on vacation through the end of this week but I'll get on it shortly after that.  It's not difficult (the code hasn't changed in years) but I want to make sure to get the naming etc. right.
Thanks @carns. Yeah this also causes an issue for us when we ttrying to update buildcache because there is no version in addition to fact that building of `main` branch is not good practice as spack builds will be affected if main branch is changed over time.

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/bmi/package.py b/var/spack/repos/builtin/packages/bmi/package.py
--- a/var/spack/repos/builtin/packages/bmi/package.py
+++ b/var/spack/repos/builtin/packages/bmi/package.py
@@ -11,10 +11,12 @@ class Bmi(AutotoolsPackage):
 
     homepage = 'https://github.com/radix-io/bmi/'
     git = 'https://github.com/radix-io/bmi.git'
+    url = 'https://github.com/radix-io/bmi/archive/v2.8.1.tar.gz'
 
     maintainers = ['carns']
 
     version('main', branch='main')
+    version('2.8.1', sha256='28aa4341f0456cf20ee762f712d7c749ab8f864003329f9327c18ea03fc7ffdb')
 
     depends_on('autoconf', type='build')
     depends_on('automake', type='build')


Test patch:
Repository: spack/spack

Issue:
Installation issue: llvm-amdgpu
### Steps to reproduce the issue

```console
spack install llvm-amdgpu
```

### Information on your system

```
$ spack debug report
* **Spack:** 0.17.1-1167-d4394d502f
* **Python:** 3.9.7
* **Platform:** linux-pop21-icelake
* **Concretizer:** clingo
```


### Additional information

[spack-build-out.txt](https://github.com/spack/spack/files/8054545/spack-build-out.txt)
[spack-build-env.txt](https://github.com/spack/spack/files/8054546/spack-build-env.txt)

@arjun-raj-kuppala 
@haampie 
@srekolam 

This issue appears to be related to the removal of `cyclades.h` from the Linux kernel headers and is more of an issue with the llvm-amdgpu source code. [This ticket on GCC](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100379) suggests the includes for cyclades.h can be simply removed and perhaps a spack patch may help resolve this issue. It looks like https://github.com/ROCm-Developer-Tools/llvm-project hasn't had any major activity for some time, so a patch may be the only route forward unless the llvm-project sees an update.

### General information

- [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:
this was reported sometime ago #26861
Here the LLVM commit that fixes the issue: https://github.com/llvm/llvm-project/commit/68d5235cb58f988c71b403334cd9482d663841ab
You could try to C-P this fix or wait for ROCm 5.0 which i am currently working to update now.

@srekolam if older versions of llvm-amdgpu are offered through spack, we really ought to put in patches for those versions so they can be installed on OS's that removed cyclades. Otherwise, this error will still afflict some users. 

Alternatively, OS version requirements need to be strictly enforced for older versions of ROCm that are incompatible with newer OS

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/llvm-amdgpu/package.py b/var/spack/repos/builtin/packages/llvm-amdgpu/package.py
--- a/var/spack/repos/builtin/packages/llvm-amdgpu/package.py
+++ b/var/spack/repos/builtin/packages/llvm-amdgpu/package.py
@@ -70,8 +70,9 @@ class LlvmAmdgpu(CMakePackage):
     patch('fix-ncurses-3.9.0.patch', when='@3.9.0:4.0.0')
 
     # This is already fixed in upstream but not in 4.2.0 rocm release
-    patch('fix-spack-detection-4.2.0.patch', when='@4.2.0:')
+    patch('fix-spack-detection-4.2.0.patch', when='@4.2.0:4.5.2')
 
+    patch('remove-cyclades-inclusion-in-sanitizer.patch', when='@4.2.0:4.5.2')
     conflicts('^cmake@3.19.0')
 
     root_cmakelists_dir = 'llvm'


Test patch:
Repository: spack/spack

Issue:
Build issue: diffutils@3.8%nvhpc
### Steps to reproduce the issue

```console
$ spack install diffutils@3.8%nvhpc@22.1
```

### Error message

<details><summary>Error message</summary><pre>
"/tmp/ryan.krattiger/spack-stage/spack-stage-diffutils-3.8-zwu4ukysjtqv7k43y2c5z2aplogu5deu/spack-src/lib/malloca.c", line 52: error: 64 bits operations with signed and unsigned operands are currently unsupporte
d by __builtin_add_overflow
    if (!INT_ADD_WRAPV (n, plus, &nplus) && !xalloc_oversized (nplus, 1))
</pre></details>


### Information on your system

```
* **Spack:** 0.17.1-1264-2e86260c89
* **Python:** 3.8.10
* **Platform:** linux-ubuntu20.04-zen2
* **Concretizer:** clingo
```

### Additional information

[diffutils-spack-build-out.txt](https://github.com/spack/spack/files/8100655/diffutils-spack-build-out.txt)
[diffutils-spack-build-env.txt](https://github.com/spack/spack/files/8100656/diffutils-spack-build-env.txt)


### General information

- [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:
I see the same error and have wandered here with the help of Google. Apparently, this is a bug in NVHPC:
https://lists.nongnu.org/archive/html/bug-diffutils/2022-01/msg00002.html

What worked for me is to use diffutils@3.7 instead.

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/diffutils/package.py b/var/spack/repos/builtin/packages/diffutils/package.py
--- a/var/spack/repos/builtin/packages/diffutils/package.py
+++ b/var/spack/repos/builtin/packages/diffutils/package.py
@@ -27,6 +27,8 @@ class Diffutils(AutotoolsPackage, GNUMirrorPackage):
 
     patch('nvhpc.patch', when='@3.7 %nvhpc')
 
+    conflicts('%nvhpc', when='@:3.6,3.8:')
+
     depends_on('iconv')
 
     def setup_build_environment(self, env):


Test patch:
Repository: spack/spack

Issue:
#27021 broke GitHub SSH urls
### Steps to reproduce

```console
spack install rkt-base
```

### Error message

Empty error message
```console
==> Error: 
```

In debug mode, this leads to an assertion error originating here (code introduced in #27021):

https://github.com/spack/spack/blob/872d29e20168d1ff133fc25cad5932e5949c9c6e/lib/spack/spack/util/url.py#L345-L347

### Information on your system

* **Spack:** 0.18.0.dev0 (c8f1b8c95c4feaa36577d33344c7639f0799bc93)
* **Python:** 3.8.10
* **Platform:** linux-ubuntu20.04-skylake_avx512
* **Concretizer:** clingo

### General 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:
I'm also seeing this issue (different package).  Adding `ssh://|` to the regex on line 346 fixes the issue for me.
and then presumably also adding `ssh://` to the affected packages? This isn't typically specified for git clients.

Resolving patch:
diff --git a/lib/spack/spack/util/url.py b/lib/spack/spack/util/url.py
--- a/lib/spack/spack/util/url.py
+++ b/lib/spack/spack/util/url.py
@@ -343,7 +343,7 @@ def parse_git_url(url):
 
 
 def require_url_format(url):
-    ut = re.search(r'^(file://|http://|https://|ftp://|s3://|gs://|/)', url)
+    ut = re.search(r'^(file://|http://|https://|ftp://|s3://|gs://|ssh://|/)', url)
     assert ut is not None
 
 


Test patch:
Repository: spack/spack

Issue:
[Q] Modify the existing py-or-tools package or create a new or-tools package?
Hi,

  I'd like to improve Google OR-Tools support by either modifying [py-or-tools](https://github.com/spack/spack/tree/develop/var/spack/repos/builtin/packages/py-or-tools)  package or creating a new one called [or-tools](https://github.com/hyoklee/spack/tree/develop/var/spack/repos/builtin/packages/or-tools). However, I don't know what's  the best for Spack maintainers and users so I'd appreciate if someone can recommend the right approach.

  My goal is to provide the ability to
  
  * turn off Python support via variant.
  * add more CMake build options that OR-tools provide.

  The package name py-or-tools already suggests that it's for Python   so I'm not sure if it is acceptable to add a variant that turns off Python  API to the existing py-or-tools package. Is there any other Spack package that starts with “py-”  but turns off the Python interface through a variant?

  I'd appreciate it if someone could give me a recommendation.  For example, Spack maintainer may want to rename py-or-tools to or-tools  and add `+python` as a variant to turn on Python.

  Best regards,




Discussion:
https://spack.readthedocs.io/en/latest/build_systems/pythonpackage.html#choosing-a-package-name has some guidance on this

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/or-tools/package.py b/var/spack/repos/builtin/packages/or-tools/package.py
new file mode 100644
--- /dev/null
+++ b/var/spack/repos/builtin/packages/or-tools/package.py
@@ -0,0 +1,37 @@
+# Copyright 2013-2022 Lawrence Livermore National Security, LLC and other
+# Spack Project Developers. See the top-level COPYRIGHT file for details.
+#
+# SPDX-License-Identifier: (Apache-2.0 OR MIT)
+
+
+class OrTools(CMakePackage):
+    """This project hosts operations research tools developed at
+    Google and made available as open source under the Apache 2.0
+    License."""
+
+    homepage = "https://developers.google.com/optimization/"
+    url      = "https://github.com/google/or-tools/archive/v7.8.tar.gz"
+    maintainers = ['hyoklee']
+
+    version('7.8', sha256='d93a9502b18af51902abd130ff5f23768fcf47e266e6d1f34b3586387aa2de68')
+    variant('coin', default=False, description='Enable COIN-OR solvers.')
+    depends_on('cmake@3.14:', type='build')
+    depends_on('gflags@2.2.2:')
+    depends_on('glog@0.4.0:')
+    depends_on('protobuf@3.12.2:')
+    depends_on('abseil-cpp@20200225.2:')
+    depends_on('cbc@2.10.5:')
+    depends_on('cgl@0.60.3:')
+    depends_on('clp@1.17.4:')
+    depends_on('osi@0.108.6:')
+    depends_on('coinutils@2.11.4:', when='+coin')
+
+    def cmake_args(self):
+        cmake_args = []
+        cmake_args.append('-DBUILD_DEPS=OFF')
+        cmake_args.append('-DBUILD_PYTHON=OFF')
+        cmake_args.append(self.define_from_variant('USE_COINOR', 'coin'))
+        cmake_args.append('-DUSE_SCIP=ON')
+        cmake_args.append('-DBUILD_SCIP=ON')
+        cmake_args.append('-DBUILD_TESTING=OFF')
+        return cmake_args


Test patch: