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

Issue:
Installation issue: gcc@7.2.0
### Steps to reproduce the issue

```console
$ spack install gcc@7.2.0
...
>> 29760    /apps/spack/var/spack/stage/gcc-7.2.0-bcsmtl56t3etoswkauritld6bzfnjfzx/gcc-7.2.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:157:10: fatal error: sys/ustat.h: No such file or directory
     29761     #include <sys/ustat.h>
     29762              ^~~~~~~~~~~~~
     29763    compilation terminated.
...
```

### Platform and user environment

Please report your OS here:
```commandline
$ uname -a 
Linux glados 4.18.16-300.fc29.x86_64 #1 SMP Sat Oct 20 23:24:08 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -d
Description:    Fedora release 29 (Twenty Nine)
``` 

### Additional information

This issue is with the system glibc (2.28).
Broken versions are releases before 7.4.0 (Except 6.5.0 where I believe the fix was backported)

I have attached the patched used in the GCC 6.4.0 Arch Linux user repo package.

[glibc2.28-ustat.patch.txt](https://github.com/spack/spack/files/2652903/glibc2.28-ustat.patch.txt)

I'm not sure if **all** the releases are broken, I think the required addition to the `package.py` is:
```
patch('glibc2.28-ustat.patch', when='@4:6.4,7:7.3')
```

I can submit a pull request if this looks correct



Discussion:
> I can submit a pull request if this looks correct

Please do. We've been seeing a lot of GCC 7 build errors lately.

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/gcc/package.py b/var/spack/repos/builtin/packages/gcc/package.py
--- a/var/spack/repos/builtin/packages/gcc/package.py
+++ b/var/spack/repos/builtin/packages/gcc/package.py
@@ -168,6 +168,8 @@ class Gcc(AutotoolsPackage):
     patch('stack_t.patch', when='@5.1:5.4,6.1:6.4,7.1')
     # https://bugs.busybox.net/show_bug.cgi?id=10061
     patch('signal.patch', when='@4.9,5.1:5.4')
+    # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85835
+    patch('sys_ustat.h.patch', when='@4:6.4,7:7.3')
 
     build_directory = 'spack-build'
 


Test patch:
Repository: spack/spack

Issue:
Freetype tries to include windows.h resulting in an error
I am seeing this error with Freetype 2.9.1 and I'm using binutils 2.29.1:
```
freetype-2.9.1/src/base/ftver.rc:19:20: fatal error: windows.h: No such file or directory
 #include<windows.h>
                    ^
compilation terminated.
windres: preprocessing failed.
```

I see this error reported in https://mail-index.netbsd.org/pkgsrc-users/2018/08/10/msg027329.html and https://github.com/Linuxbrew/homebrew-core/issues/7625 so I reported it to Freetype here https://savannah.nongnu.org/bugs/index.php?54967 . Posting this as an issue here in case anyone else runs into this error. Why does Freetype always have so many problems?

Edit: For me the solution has been to use freetype 2.7.1.


Discussion:
I just encountered this issue as well. It looks like they wrote a [patch](http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=3b6e65f7bf674601b9419d02ce0aa633e2e882fb) to fix this. Let me see if I can regenerate `configure` and patch that directly so we don't have to run `autoreconf` on installation.

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/freetype/package.py b/var/spack/repos/builtin/packages/freetype/package.py
--- a/var/spack/repos/builtin/packages/freetype/package.py
+++ b/var/spack/repos/builtin/packages/freetype/package.py
@@ -13,9 +13,9 @@ class Freetype(AutotoolsPackage):
     of most vector and bitmap font formats."""
 
     homepage = "https://www.freetype.org/index.html"
-    url      = "http://download.savannah.gnu.org/releases/freetype/freetype-2.7.1.tar.gz"
+    url      = "https://download.savannah.gnu.org/releases/freetype/freetype-2.9.1.tar.gz"
 
-    version('2.9.1', 'ec391504e55498adceb30baceebd147a6e963f636eb617424bcfc47a169898ce')
+    version('2.9.1', sha256='ec391504e55498adceb30baceebd147a6e963f636eb617424bcfc47a169898ce')
     version('2.7.1', '78701bee8d249578d83bb9a2f3aa3616')
     version('2.7',   '337139e5c7c5bd645fe130608e0fa8b5')
     version('2.5.3', 'cafe9f210e45360279c730d27bf071e9')
@@ -24,6 +24,8 @@ class Freetype(AutotoolsPackage):
     depends_on('bzip2')
     depends_on('pkgconfig', type='build')
 
+    patch('windows.patch', when='@2.9.1')
+
     def configure_args(self):
         args = ['--with-harfbuzz=no']
         if self.spec.satisfies('@2.9.1:'):


Test patch:
Repository: spack/spack

Issue:
installation issue: xgboost (the wrong stuff is installed under prefix)
### Steps to reproduce the issue
installation seemingly works fine:
```console
$ spack install xgboost
```
until I check what is under the prefix directory: apparently the folder ".../xgboost/dmlc-core/include" from the source files was put under prefix/include and ".../xgboost/dmlc-core/libdmlc.a" was put in prefix/lib as opposed to the target file "libxgboost.so"

### Platform and user environment

```commandline
$ uname -a
Linux storm 4.15.0-38-generic #41-Ubuntu SMP Wed Oct 10 10:59:38 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
 $ lsb_release -d
Description:	Linux Mint 19 Tara (same as Ubuntu bionic (18.04.1))
``` 
### Additional information
I will be creating a PR shortly to fix the problem.



Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/xgboost/package.py b/var/spack/repos/builtin/packages/xgboost/package.py
--- a/var/spack/repos/builtin/packages/xgboost/package.py
+++ b/var/spack/repos/builtin/packages/xgboost/package.py
@@ -20,3 +20,10 @@ def cmake_args(self):
         return [
             '-DUSE_CUDA={0}'.format('YES' if '+cuda' in self.spec else 'NO')
         ]
+
+    def install(self, spec, prefix):
+        install_tree(str(self.stage.source_path), prefix)
+        # create a bin directory for executable "xgboost" which is possibly
+        # used in functional testing of the compilation target "libxgboost"
+        mkdirp(prefix.bin)
+        install('xgboost', prefix.bin)


Test patch:
Repository: spack/spack

Issue:
m4 Doesn't Build With ARM Compiler
The m4 package fails to build with the ARM compiler with the error:
```
undefined reference to `__muloti4`
```

This is essentially the same error as mentioned in #4883, and the same fix will also work here.  (The ARM compiler is based on LLVM, so this isn't too surprising.)  Pull request will be coming shortly.



Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/m4/package.py b/var/spack/repos/builtin/packages/m4/package.py
--- a/var/spack/repos/builtin/packages/m4/package.py
+++ b/var/spack/repos/builtin/packages/m4/package.py
@@ -34,7 +34,8 @@ def configure_args(self):
         spec = self.spec
         args = ['--enable-c++']
 
-        if spec.satisfies('%clang') and not spec.satisfies('platform=darwin'):
+        if (spec.satisfies('%clang') or spec.satisfies('%arm')) and not \
+           spec.satisfies('platform=darwin'):
             args.append('CFLAGS=-rtlib=compiler-rt')
 
         if spec.satisfies('%intel'):


Test patch:
Repository: spack/spack

Issue:
Mac clone problem
```
$ git clone --depth 1 https://github.com/spack/spack.git

Cloning into 'spack'...
remote: Enumerating objects: 7553, done.
remote: Counting objects: 100% (7553/7553), done.
remote: Compressing objects: 100% (3961/3961), done.
remote: Total 7553 (delta 730), reused 4489 (delta 623), pack-reused 0
Receiving objects: 100% (7553/7553), 4.13 MiB | 7.28 MiB/s, done.
Resolving deltas: 100% (730/730), done.
Checking out files: 100% (4351/4351), done.
warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:

  'lib/spack/env/cray/CC'
  'lib/spack/env/cray/cc'
  'lib/spack/env/craype/CC'
  'lib/spack/env/craype/cc'
```

It doesn't matter whether I do --depth 1 or not, it barfs like that. I'm on 10.13.6.  My HD is `APFS (encrypted)`


Discussion:

Resolving patch:
diff --git a/lib/spack/spack/build_environment.py b/lib/spack/spack/build_environment.py
--- a/lib/spack/spack/build_environment.py
+++ b/lib/spack/spack/build_environment.py
@@ -342,7 +342,7 @@ def set_build_environment_variables(pkg, env, dirty):
         if os.path.isdir(ci):
             env_paths.append(ci)
 
-    for item in reversed(env_paths):
+    for item in env_paths:
         env.prepend_path('PATH', item)
     env.set_path(SPACK_ENV_PATH, env_paths)
 
diff --git a/lib/spack/spack/compilers/cce.py b/lib/spack/spack/compilers/cce.py
--- a/lib/spack/spack/compilers/cce.py
+++ b/lib/spack/spack/compilers/cce.py
@@ -26,10 +26,10 @@ class Cce(Compiler):
     PrgEnv = 'PrgEnv-cray'
     PrgEnv_compiler = 'cce'
 
-    link_paths = {'cc': 'cc',
-                  'cxx': 'c++',
-                  'f77': 'f77',
-                  'fc': 'fc'}
+    link_paths = {'cc': 'cce/cc',
+                  'cxx': 'cce/case-insensitive/CC',
+                  'f77': 'cce/ftn',
+                  'fc': 'cce/ftn'}
 
     @classmethod
     def default_version(cls, comp):


Test patch:
Repository: spack/spack

Issue:
PackageBase._has_make_target fails if not English locale 
For a package based on Makefiles or autotools, "spack install --test ..." searches for targets "test", then "check", respectively, after the build. This uses PackageBase._has_make_target which checks for error messages from "make -n <target>" on stderr. However, if LANG is e.g. set to "de_DE.UTF-8", the error is "make: *** No rule to make target 'test'.  Schluss.". This results in _has_make_target wrongly returning True.

With "unset LANG", it works as expected. But I think spack should unset LANG by itself as it does not check for the language specific error message of make.

### Steps to reproduce the issue

With German translations for make installed:

```console
$ export LANG=de_DE
$ spack install --test root valgrind
...
```

### Error Message

==> RUN-TESTS: build-time tests [check]
==> 'make' '-j24' '-n' 'test'
==> 'make' '-j24' 'test'
make: *** No rule to make target 'test'.  Schluss.
==> Error: ProcessError: Command exited with status 2:
    'make' '-j24' 'test'

Stack runs "make -j24 test" because it assumes that this target exists.
Due to that, it does not go on to test for target "check".

BTW: the correct target for running the test suite in Valgrind is "make regtests". I will to a PR to fix this in the upstream Valgrind spec file.

### Information on your system

SLES12SP3



Discussion:

Resolving patch:
diff --git a/lib/spack/spack/package.py b/lib/spack/spack/package.py
--- a/lib/spack/spack/package.py
+++ b/lib/spack/spack/package.py
@@ -1139,7 +1139,11 @@ def _has_make_target(self, target):
         Returns:
             bool: True if 'target' is found, else False
         """
-        make = inspect.getmodule(self).make
+        # Prevent altering LC_ALL for 'make' outside this function
+        make = copy.deepcopy(inspect.getmodule(self).make)
+
+        # Use English locale for missing target message comparison
+        make.add_default_env('LC_ALL', 'C')
 
         # Check if we have a Makefile
         for makefile in ['GNUmakefile', 'Makefile', 'makefile']:


Test patch:
Repository: spack/spack

Issue:
spack help --spec doesn't include /hash
`spack help --spec` is a useful shortcut whenever you forget the spec syntax that Spack allows. However, it looks like the `/hash` shortcut isn't included in this shortcut. We should add it.


Discussion:

Resolving patch:
diff --git a/lib/spack/spack/cmd/help.py b/lib/spack/spack/cmd/help.py
--- a/lib/spack/spack/cmd/help.py
+++ b/lib/spack/spack/cmd/help.py
@@ -19,7 +19,9 @@
 
   package [constraints] [^dependency [constraints] ...]
 
-  package                           any package from 'spack list'
+  package                           any package from 'spack list', or
+  @K{/hash}                             unique prefix or full hash of
+                                    installed package
 
   constraints:
     versions:
@@ -51,6 +53,8 @@
 
     dependencies:
       ^dependency [constraints]     specify constraints on dependencies
+      ^@K{/hash}                        build with a specific installed
+                                    dependency
 
   examples:
       hdf5                          any hdf5 configuration


Test patch:
Repository: spack/spack

Issue:
Error SPACK_DEPENDENCIES when running spack setup
I am following the developer workflow to install my product dependencies and before generating spconfig.py, I got this error : ==> Error: 'SPACK_DEPENDENCIES'

### Steps to reproduce the issue

```console
$ spack setup parmetis
...
```

### Origin

It seems this bug is related to 8ca384875efffbcee1881db9fdef4399e74add50.


Discussion:

Resolving patch:
diff --git a/lib/spack/spack/cmd/setup.py b/lib/spack/spack/cmd/setup.py
--- a/lib/spack/spack/cmd/setup.py
+++ b/lib/spack/spack/cmd/setup.py
@@ -39,13 +39,6 @@ def setup_parser(subparser):
     arguments.add_common_arguments(cd_group, ['clean', 'dirty'])
 
 
-def spack_transitive_include_path():
-    return ';'.join(
-        os.path.join(dep, 'include')
-        for dep in os.environ['SPACK_DEPENDENCIES'].split(os.pathsep)
-    )
-
-
 def write_spconfig(package, dirty):
     # Set-up the environment
     spack.build_environment.setup_package(package, dirty)
@@ -57,8 +50,8 @@ def write_spconfig(package, dirty):
     paths = os.environ['PATH'].split(':')
     paths = [item for item in paths if 'spack/env' not in item]
     env['PATH'] = ':'.join(paths)
-    env['SPACK_TRANSITIVE_INCLUDE_PATH'] = spack_transitive_include_path()
     env['CMAKE_PREFIX_PATH'] = os.environ['CMAKE_PREFIX_PATH']
+    env['SPACK_INCLUDE_DIRS'] = os.environ['SPACK_INCLUDE_DIRS']
     env['CC'] = os.environ['SPACK_CC']
     env['CXX'] = os.environ['SPACK_CXX']
     env['FC'] = os.environ['SPACK_FC']
@@ -84,7 +77,7 @@ def cmdlist(str):
             if name.find('PATH') < 0:
                 fout.write('env[%s] = %s\n' % (repr(name), repr(val)))
             else:
-                if name == 'SPACK_TRANSITIVE_INCLUDE_PATH':
+                if name == 'SPACK_INCLUDE_DIRS':
                     sep = ';'
                 else:
                     sep = ':'


Test patch:
Repository: spack/spack

Issue:
git-lfs aborts (sometimes), fix in progress upstream
This is mostly an FYI.

Starting with `git-lfs@2.7.0` we frequently had `git-lfs` aborting.  In some situations it ran successfully, in others it didn't.  It seemed to depend on what other modules were loaded, but...

Between `git-lfs@2.6.1` and `git-lfs@2.7.0` the Makefile started unconditionally adding a `-extldflags` bit to the `go` command line, setting it to the value of `LDFLAGS`.  If `LDFLAGS` isn't set to anything (our case) then it wasn't given an argument, even though it needs one.  I'm not sure why this doesn't provide an error from the compiler, it seems to be grabbing something out of whatever comes next in memory.

I've changed the Makefile only set `-extldflags` if `LDFLAGS` is defined and made a Pull Request upstream:  https://github.com/git-lfs/git-lfs/pull/3545

Depending what Upstream has to say, perhaps we'll want to patch `git-lfs@2.7.0`, or forbid it, or ...

I'll keep this updated as the `git-lfs` PR progresses.




Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/git-lfs/package.py b/var/spack/repos/builtin/packages/git-lfs/package.py
--- a/var/spack/repos/builtin/packages/git-lfs/package.py
+++ b/var/spack/repos/builtin/packages/git-lfs/package.py
@@ -22,6 +22,8 @@ class GitLfs(MakefilePackage):
     depends_on('go@1.5:', type='build')
     depends_on('git@1.8.2:', type='run')
 
+    patch('patches/issue-10702.patch', when='@2.7.0')
+
     parallel = False
 
     # Git-lfs does not provide an 'install' target in the Makefile


Test patch:
Repository: spack/spack

Issue:
Permit Spack shell integration with Modules v4
As a user of Spack I want `environment-modules` v4.X to be supported as a module command so that I can use Spack shell integration with the latest version available.

### Rationale

Users that want to use Spack's shell integration should be able to employ the latest major version of `environment-modules`.

### Description

There's a PR that is mostly done to permit this integration, see #7536.


Discussion:

Resolving patch:
diff --git a/lib/spack/spack/cmd/bootstrap.py b/lib/spack/spack/cmd/bootstrap.py
--- a/lib/spack/spack/cmd/bootstrap.py
+++ b/lib/spack/spack/cmd/bootstrap.py
@@ -46,7 +46,7 @@ def bootstrap(parser, args, **kwargs):
     # Define requirement dictionary defining general specs which need
     # to be satisfied, and the specs to install when the general spec
     # isn't satisfied.
-    requirement_dict = {'environment-modules': 'environment-modules@3.2.10~X'}
+    requirement_dict = {'environment-modules': 'environment-modules~X'}
 
     for requirement in requirement_dict:
         installed_specs = spack.store.db.query(requirement)


Test patch:
Repository: spack/spack

Issue:
util-linux installs to system
On Linux systems, `util-linux`, although having a `--prefix` set, tries to install to a system path.

Yes, I actually only need it on OSX platforms but still...

### Expected Result

Install into the prefix inside spack.

### Actual Result

```bash
$ spack install util-linux

# [...]
  >> 1155    /usr/bin/install: cannot remove '/usr/share/bash-completion/completions/b
             lkid': Permission denied
  >> 1156    /usr/bin/install: cannot remove '/usr/share/bash-completion/completions/c
             al': Permission denied
  >> 1157    /usr/bin/install: cannot create regular file '/usr/share/bash-completion/
             completions/col': Permission denied
  >> 1158    /usr/bin/install: cannot create regular file '/usr/share/bash-completion/
             completions/colcrt': Permission denied
[...]
```

### Steps to reproduce the issue

```console
$ spack install util-linux
```

### Information on your system

Platforms:
- Debian GNU/Linux 9.4 (stretch)
- Ubuntu 16.04


Discussion:
Ha, lol: https://stackoverflow.com/a/44140457/2719194

Ok, so it requires the very obvious option `prefix=` and `DESTDIR=` *at make install time* as well... :D

We can otherwise disable or place the bash completion scripts in the right paths (are there any common places for `expand`-ing those in spack? [pkgconfig completionsdir](https://github.com/scop/bash-completion/blob/master/README.md#faq)?)

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/util-linux/package.py b/var/spack/repos/builtin/packages/util-linux/package.py
--- a/var/spack/repos/builtin/packages/util-linux/package.py
+++ b/var/spack/repos/builtin/packages/util-linux/package.py
@@ -19,16 +19,11 @@ class UtilLinux(AutotoolsPackage):
     version('2.25',   'f6d7fc6952ec69c4dc62c8d7c59c1d57')
 
     depends_on('python@2.7:')
+    depends_on('pkgconfig')
 
     def url_for_version(self, version):
         url = "https://www.kernel.org/pub/linux/utils/util-linux/v{0}/util-linux-{1}.tar.gz"
         return url.format(version.up_to(2), version)
 
     def configure_args(self):
-        spec = self.spec
-
-        return [
-            'PKG_CONFIG_PATH={0}'.format(
-                join_path(spec['python'].prefix.lib, 'pkgconfig')),
-            '--disable-use-tty-group',
-        ]
+        return ['--disable-use-tty-group']


Test patch:
Repository: spack/spack

Issue:
Installation issue: <netgen>
Installation issue: <netgen>

The install breaks down when trying to fetch netgen:
Installing netgen

==> No binary for netgen found: installing from source
==> Fetching http://gigenet.dl.sourceforge.net/project/netgen-mesher/netgen-mesher/5.3/netgen-5.3.1.tar.gz

curl: (7) Failed to connect to gigenet.dl.sourceforge.net port 80: Connection refused
==> Fetching from http://gigenet.dl.sourceforge.net/project/netgen-mesher/netgen-mesher/5.3/netgen-5.3.1.tar.gz failed.
==> Error: FetchError: All fetchers failed for netgen-5.3.1-fxostpbpelllydkeut3m3uvvmzwjdae6

/home/..../spack/package.py:961, in do_fetch:
        958                raise FetchError("Will not fetch %s" %
        959                                 self.spec.format('$_$@'), ck_msg)
        960
  >>    961        self.stage.create()
        962        self.stage.fetch(mirror_only)
        963        self._fetch_time = time.time() - start_time
        964

I know the correct URL, I mean I am able to download it from  sourceforge.net manually.
I don't know how to tell Spack (if that's a solution!) where to find the package.
What can I do about it?
Thanks



Discussion:
I can confirm this error. Is there any workaround?
Yes it is solved.
command: spack edit netgent
provides access to the file where the URL could be modified.
We entered a new URL to fetching netgen and it worked.  


Resolving patch:
diff --git a/var/spack/repos/builtin/packages/netgen/package.py b/var/spack/repos/builtin/packages/netgen/package.py
--- a/var/spack/repos/builtin/packages/netgen/package.py
+++ b/var/spack/repos/builtin/packages/netgen/package.py
@@ -15,7 +15,7 @@ class Netgen(AutotoolsPackage):
        mesh refinement. """
 
     homepage = "https://ngsolve.org/"
-    url = "https://gigenet.dl.sourceforge.net/project/netgen-mesher/netgen-mesher/5.3/netgen-5.3.1.tar.gz"
+    url = "https://sourceforge.net/projects/netgen-mesher/files/netgen-mesher/5.3/netgen-5.3.1.tar.gz"
 
     version('5.3.1', 'afd5a9b0b1296c242a9c554f06af6510')
 
@@ -30,7 +30,7 @@ class Netgen(AutotoolsPackage):
     depends_on('metis', when='+metis')
 
     def url_for_version(self, version):
-        url = "http://gigenet.dl.sourceforge.net/project/netgen-mesher/netgen-mesher/{0}/netgen-{1}.tar.gz"
+        url = "https://sourceforge.net/projects/netgen-mesher/files/netgen-mesher/{0}/netgen-{1}.tar.gz"
         return url.format(version.up_to(2), version)
 
     def configure_args(self):


Test patch: