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

Issue:
new package: redis
Spack package for Redis (https://redis.io)


Discussion:
Seems to work for me. It is worth noting that redis seems to depend on (and bundle) jemalloc, lua, hiredis and linenoise. I am not sure whether it makes sense to try to unbundle some of those. Even Fedora only seems to unbundle jemalloc: https://src.fedoraproject.org/rpms/redis/blob/master/f/redis.spec
This looks good but can you update the license according to https://github.com/spack/spack/pull/9450#issue-221027331? The new license header comment looks like:

```
# Copyright 2013-2018 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)
```

Spack changed its licensing recently.
@scheibelp @tgamblin Just asking out of sheer legal ignorance: can we update the license header in cases like this or is it on the poster to actively change the license of the PR?
@bhatiaharsh Can this be updated with the newest stable version 5 release?
version('5.0.3', 'aee2e1d0e50f87d6c21abef1c45f9767')




Resolving patch:
diff --git a/var/spack/repos/builtin/packages/redis/package.py b/var/spack/repos/builtin/packages/redis/package.py
new file mode 100644
--- /dev/null
+++ b/var/spack/repos/builtin/packages/redis/package.py
@@ -0,0 +1,35 @@
+# Copyright 2013-2019 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 Redis(MakefilePackage):
+    """Redis is an open source (BSD licensed), in-memory data structure store,
+    used as a database, cache and message broker.
+
+    It supports data structures such as strings, hashes, lists, sets, sorted
+    sets with range queries, bitmaps, hyperloglogs, geospatial indexes with
+    radius queries and streams. Redis has built-in replication, Lua scripting,
+    LRU eviction, transactions and different levels of on-disk persistence,
+    and provides high availability via Redis Sentinel and automatic
+    partitioning with Redis Cluster
+    """
+
+    homepage = "https://redis.io"
+    url = "http://download.redis.io/releases/redis-5.0.3.tar.gz"
+
+    version('5.0.3',   sha256='e290b4ddf817b26254a74d5d564095b11f9cd20d8f165459efa53eb63cd93e02')
+    version('5.0.2',   sha256='937dde6164001c083e87316aa20dad2f8542af089dfcb1cbb64f9c8300cd00ed')
+    version('5.0.1',   sha256='82a67c0eec97f9ad379384c30ec391b269e17a3e4596393c808f02db7595abcb')
+    version('5.0.0',   sha256='70c98b2d0640b2b73c9d8adb4df63bcb62bad34b788fe46d1634b6cf87dc99a4')
+    version('4.0.13',  sha256='17d955227966dcd68590be6139e5fe7f2d19fc4fb7334248a904ea9cdd30c1d4')
+    version('4.0.12',  sha256='6447259d2eed426a949c9c13f8fdb2d91fb66d9dc915dd50db13b87f46d93162')
+    version('4.0.11',  sha256='fc53e73ae7586bcdacb4b63875d1ff04f68c5474c1ddeda78f00e5ae2eed1bbb')
+
+    @property
+    def install_targets(self):
+        return [
+            'PREFIX={0}'.format(self.spec.prefix),
+            'install'
+        ]


Test patch:
Repository: spack/spack

Issue:
openfoam-com finds wrong flex
Installing openfoam-com with Spack fails if an old flex version is in the system path:
```
error: declaration is incompatible with "void yySTLFlexLexer::switch_streams(std::istream *, std::ostream *)" (declared at line 129 of "/usr/include/FlexLexer.h")
```
However, spack reports that the installation completed successfully. That's not the case.

I am not familiar with the build system of OpenFOAM. @olesenm is there a possibility to make the build system finding the Spack version of Flex?


Discussion:
This isn't something that I'd worried about before, but I can see where it would be an issue, especially since some systems are likely to have an old flex etc. Could you please add as an issue under develop.openfoam.com? This would be easier for me to track there.
For completeness, I should also mention that the OpenFOAM will currently not deal well (ie no provision) with libz that is not from the system. 

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/openfoam-com/package.py b/var/spack/repos/builtin/packages/openfoam-com/package.py
--- a/var/spack/repos/builtin/packages/openfoam-com/package.py
+++ b/var/spack/repos/builtin/packages/openfoam-com/package.py
@@ -307,7 +307,7 @@ class OpenfoamCom(Package):
     depends_on('cgal')
     # The flex restriction is ONLY to deal with a spec resolution clash
     # introduced by the restriction within scotch!
-    depends_on('flex@:2.6.1,2.6.4:', type='build')
+    depends_on('flex@:2.6.1,2.6.4:')
     depends_on('cmake', type='build')
 
     # Require scotch with ptscotch - corresponds to standard OpenFOAM setup


Test patch:
Repository: spack/spack

Issue:
Installation Issue: bowtie build error
### Steps to reproduce the issue

```console
[centos] ~: spack install bowtie
==> Installing bowtie
==> Searching for binary cache of bowtie
==> Warning: No Spack mirrors are currently configured
==> No binary for bowtie found: installing from source
==> Fetching https://github.com/BenLangmead/bowtie/archive/v1.2.2_p1.tar.gz
######################################################################## 100.0%
==> Staging archive: /spack/var/spack/stage/bowtie-1.2.2_p1-se66bd5p6mfiop65vwqpr4jh6uwvpxsr/v1.2.2_p1.tar.gz
==> Created stage in /spack/var/spack/stage/bowtie-1.2.2_p1-se66bd5p6mfiop65vwqpr4jh6uwvpxsr
==> No patches needed for bowtie
==> Building bowtie [MakefilePackage]
==> Executing phase: 'edit'
==> Executing phase: 'build'
==> Error: ProcessError: Command exited with status 2:
    'make' '-j2' 'NO_TBB=1'

4 errors found in build log:
     18    In file included from sequence_io.h:12:0,
     19                     from multikey_qsort.h:8,
     20                     from diff_sample.h:13,
     21                     from blockwise_sa.h:19,
     22                     from ebwt.h:27,
     23                     from ebwt_build.cpp:11:
  >> 24    pat.h:6:18: fatal error: zlib.h: No such file or directory
     25     #include <zlib.h>
     26                      ^

     27    compilation terminated.
     28    In file included from sequence_io.h:12:0,
     29                     from multikey_qsort.h:8,
     30                     from diff_sample.h:13,
     31                     from blockwise_sa.h:19,
     32                     from ebwt.h:27,
     33                     from ebwt_build.cpp:11:
  >> 34    pat.h:6:18: fatal error: zlib.h: No such file or directory
     35     #include <zlib.h>
     36                      ^
     37    compilation terminated.
  >> 38    make: *** [bowtie-build-l] Error 1
     39    make: *** Waiting for unfinished jobs....
  >> 40    make: *** [bowtie-build-s] Error 1

See build log for details:
  /spack/var/spack/stage/bowtie-1.2.2_p1-se66bd5p6mfiop65vwqpr4jh6uwvpxsr/bowtie-1.2.2_p1/spack-build.out
```

### Platform and user environment

Please report your OS here:
```commandline
$ uname -a
Linux 4b5226354c71 4.9.125-linuxkit #1 SMP Fri Sep 7 08:20:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
``` 
Bowtie installation fails with missing zlib dependency. 




Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/bowtie/package.py b/var/spack/repos/builtin/packages/bowtie/package.py
--- a/var/spack/repos/builtin/packages/bowtie/package.py
+++ b/var/spack/repos/builtin/packages/bowtie/package.py
@@ -38,6 +38,7 @@ class Bowtie(MakefilePackage):
     variant('tbb', default=False, description='Use Intel thread building block')
 
     depends_on('tbb', when='+tbb')
+    depends_on('zlib')
 
     # See: https://github.com/BenLangmead/bowtie/issues/87, a
     # different fix is in the FreeBSD ports/package tree


Test patch:
Repository: spack/spack

Issue:
No develop version available for `leveldb`
Two versions of `leveldb` are available: 1.18 and 1.20 . There is no `develop` version available in spack.

### Rationale

Some packages (e.g FAODEL #11268 ) search for `leveldb` using `CMake` function `find_package()` which expects to find a file called `leveldb-config.cmake`. However, this file is not available for the versions of this package available in `spack` but it is available in its `master` branch.

### Description

The solution is a add a `develop` version of `leveldb` that points to its GitHub `master` branch.


Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/leveldb/package.py b/var/spack/repos/builtin/packages/leveldb/package.py
--- a/var/spack/repos/builtin/packages/leveldb/package.py
+++ b/var/spack/repos/builtin/packages/leveldb/package.py
@@ -13,7 +13,9 @@ class Leveldb(MakefilePackage):
 
     homepage = "https://github.com/google/leveldb"
     url      = "https://github.com/google/leveldb/archive/v1.20.tar.gz"
+    git      = "https://github.com/google/leveldb.git"
 
+    version('master', branch='master')
     version('1.20', '298b5bddf12c675d6345784261302252')
     version('1.18', '73770de34a2a5ab34498d2e05b2b7fa0')
 


Test patch:
Repository: spack/spack

Issue:
packages.yaml: ninja and ninja-fortran are now virtual packages
### Description

On my macOS machines, I maintain a `packages.yaml` file I use to expose Homebrew- or system-installed software to Spack. As part of that file, I have an entry for `ninja`, but it appears that `ninja` has been made a virtual package as of merging PR #11347 (commit `251f3f5058beb60f65d420a03f1ee77998ddbc87`), and `ninja` provides, in some cases, `ninja-fortran` and vice versa. The name of a virtual package cannot be used as a package entry under the `packages:` field in a `package.yaml` file. Thus, a user who has installed Ninja on their system through some means other than Spack and wants to expose that installation to Spack cannot do so.

### Steps to reproduce the issue

1. Install `ninja` by some other means than through Spack.

2. Add an entry for `ninja` in a `packages.yaml` file discoverable by Spack (e.g., `~/.spack/packages.yaml`). For instance:

```yaml
packages:
  # other packages may go before this entry
   ninja:
     paths:
       ninja@1.9.0 %clang@10.0.1-apple: /usr/local/opt/ninja
  # other packages may go after this entry
```
3. Attempt to install or uninstall something.

```console
$ spack install cmake curl
```

### Error Message

```console
==> Error: packages.yaml entries cannot be virtual packages:
  in "/Users/oxberry1/.spack/packages.yaml", line 207, column 3: ninja
```

### Information on your system

My system is running macOS 10.14.5 and uses a custom `packages.yaml` file. An excerpted version is listed above to reproduce the error. This bug should be insensitive to OS, so it should be reproducible on Linux as well.


Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/ninja-fortran/package.py b/var/spack/repos/builtin/packages/ninja-fortran/package.py
--- a/var/spack/repos/builtin/packages/ninja-fortran/package.py
+++ b/var/spack/repos/builtin/packages/ninja-fortran/package.py
@@ -27,8 +27,6 @@ class NinjaFortran(Package):
 
     depends_on('python', type='build')
 
-    provides('ninja')
-
     phases = ['configure', 'install']
 
     def url_for_version(self, version):
diff --git a/var/spack/repos/builtin/packages/ninja/package.py b/var/spack/repos/builtin/packages/ninja/package.py
--- a/var/spack/repos/builtin/packages/ninja/package.py
+++ b/var/spack/repos/builtin/packages/ninja/package.py
@@ -24,8 +24,6 @@ class Ninja(Package):
 
     depends_on('python', type='build')
 
-    provides('ninja-fortran', when='@kitware')
-
     phases = ['configure', 'install']
 
     def configure(self, spec, prefix):


Test patch:
Repository: spack/spack

Issue:
Installing rclone leaves a go folder outside spack root
Spack version: commit a45c4ef33de (if no change on relevant part, it is basically the head).
OS distribution: Ubuntu server 18.04.

After `spack install rclone`, there is a folder named go outside spack installation root as `~/go/` (the spack root is `~/spack/`). I have no idea about go lang, but it seems to be the go packages directory, denoted as `$GOPATH`.

I wonder whether it is necessary to leave something outside spack root or should it be simple to move such GOPATH within spack root by hacking some repos (such as go or rclone).

BTW, 
```bash
module show go-1.11.5-gcc-7.4.0-gm
--------------------------------------------------------------------------------------------------------------------------------
   /home/ubuntu/spack/share/spack/modules/linux-ubuntu18.04-x86_64/go-1.11.5-gcc-7.4.0-gm:
--------------------------------------------------------------------------------------------------------------------------------
whatis("The golang compiler and build environment ")
prepend_path("PATH","/home/ubuntu/spack/opt/spack/linux-ubuntu18.04-x86_64/gcc-7.4.0/go-1.11.5-gmcvqdwr6az4hxbicr375if5fttk6sna/bin")
prepend_path("LD_LIBRARY_PATH","/home/ubuntu/spack/opt/spack/linux-ubuntu18.04-x86_64/gcc-7.4.0/go-1.11.5-gmcvqdwr6az4hxbicr375if5fttk6sna/lib")
prepend_path("LIBRARY_PATH","/home/ubuntu/spack/opt/spack/linux-ubuntu18.04-x86_64/gcc-7.4.0/go-1.11.5-gmcvqdwr6az4hxbicr375if5fttk6sna/lib")
prepend_path("CMAKE_PREFIX_PATH","/home/ubuntu/spack/opt/spack/linux-ubuntu18.04-x86_64/gcc-7.4.0/go-1.11.5-gmcvqdwr6az4hxbicr375if5fttk6sna/")
help([[The golang compiler and build environment
]])
```
The auto generated module file for go by spack has no modification on `$GOPATH`.

Correct me if I have any misunderstanding on go or its way of doing things, since literally I know nothing about it.


Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/rclone/package.py b/var/spack/repos/builtin/packages/rclone/package.py
--- a/var/spack/repos/builtin/packages/rclone/package.py
+++ b/var/spack/repos/builtin/packages/rclone/package.py
@@ -17,6 +17,10 @@ class Rclone(Package):
 
     depends_on("go", type='build')
 
+    def setup_environment(self, spack_env, run_env):
+        # Point GOPATH at the top of the staging dir for the build step.
+        spack_env.prepend_path('GOPATH', self.stage.path)
+
     def install(self, spec, prefix):
         go('build')
         mkdirp(prefix.bin)


Test patch:
Repository: spack/spack

Issue:
projections naming convention not working properly in spack stacks
The projections are not doing the naming convention properly:
 
[lee218@ulna2:delete]$ ls usr-2/tce-ulna/packages/fftw/
fftw-3.3.8-fftw-3.3.8-gcc-4.8.5
 
Note the double {name}-{version}. My specification is:
 
      projections:
        ^mpi: '{name}/{name}-{version}-{^mpi.name}-{^mpi.version}-{compiler.name}-{compiler.version}'
        '%gcc@4.8.5': '{name}/{name}-{version}'
        all: '{name}/{name}-{version}-{compiler.name}-{compiler.version}'



Discussion:

Resolving patch:
diff --git a/lib/spack/spack/spec.py b/lib/spack/spack/spec.py
--- a/lib/spack/spack/spec.py
+++ b/lib/spack/spack/spec.py
@@ -3130,6 +3130,7 @@ def write(s, c=None):
             cwrite(f, stream=out, color=color)
 
         def write_attribute(spec, attribute, color):
+            current = spec
             if attribute.startswith('^'):
                 attribute = attribute[1:]
                 dep, attribute = attribute.split('.', 1)
@@ -3140,7 +3141,6 @@ def write_attribute(spec, attribute, color):
                     'Format string attributes must be non-empty')
             attribute = attribute.lower()
 
-            current = spec
             sig = ''
             if attribute[0] in '@%/':
                 # color sigils that are inside braces


Test patch:
Repository: spack/spack

Issue:
spack compiler add uses relative path
If fed a relative path, `spack compiler add` will write the relative path to compilers.yaml rather than dereference it to the absolute path. This behavior began with commit 6d56d4545472ddff1cdc0e8fd49d8260428a141e according to `git bisect`.



### Steps to reproduce the issue

```console
$ spack compiler add --scope=site ../apps/linux-centos7-x86_64/gcc-4.8.5/intel-19.0.3-4vf3wugrvromolotwrco5vuzydnts3bv/
==> Added 1 new compiler to /opt/packages/gpjohnsn/opt/ssoft/spack/etc/spack/compilers.yaml
    intel@19.0.3.199
==> Compilers are defined in the following files:
    /opt/packages/gpjohnsn/opt/ssoft/spack/etc/spack/compilers.yaml
$ cat etc/spack/compilers
...
- compiler:
    environment: {}
    extra_rpaths: []
    flags: {}
    modules: []
    operating_system: centos7
    paths:
      cc: ../apps/linux-centos7-x86_64/gcc-4.8.5/intel-19.0.3-4vf3wugrvromolotwrco5vuzydnts3bv/bin/icc
      cxx: ../apps/linux-centos7-x86_64/gcc-4.8.5/intel-19.0.3-4vf3wugrvromolotwrco5vuzydnts3bv/bin/icpc
      f77: ../apps/linux-centos7-x86_64/gcc-4.8.5/intel-19.0.3-4vf3wugrvromolotwrco5vuzydnts3bv/bin/ifort
      fc: ../apps/linux-centos7-x86_64/gcc-4.8.5/intel-19.0.3-4vf3wugrvromolotwrco5vuzydnts3bv/bin/ifort
    spec: intel@19.0.3.199
    target: x86_64
...
```
```console
Previous, and expected, output:
- compiler:
    environment: {}
    extra_rpaths: []
    flags: {}
    modules: []
    operating_system: centos7
    paths:
      cc: /opt/packages/gpjohnsn/opt/ssoft/apps/linux-centos7-x86_64/gcc-4.8.5/intel-19.0.3-4vf3wugrvromolotwrco5vuzydnts3bv/bin/icc
      cxx: /opt/packages/gpjohnsn/opt/ssoft/apps/linux-centos7-x86_64/gcc-4.8.5/intel-19.0.3-4vf3wugrvromolotwrco5vuzydnts3bv/bin/icpc
      f77: /opt/packages/gpjohnsn/opt/ssoft/apps/linux-centos7-x86_64/gcc-4.8.5/intel-19.0.3-4vf3wugrvromolotwrco5vuzydnts3bv/bin/ifort
      fc: /opt/packages/gpjohnsn/opt/ssoft/apps/linux-centos7-x86_64/gcc-4.8.5/intel-19.0.3-4vf3wugrvromolotwrco5vuzydnts3bv/bin/ifort
    spec: intel@19.0.3.199
    target: x86_64
...

```
Loading the respective module first will do the right thing but using a relative path in the `spack compiler` command used to work. Also, it seems that a relative path should never be written to compilers.yaml.


Discussion:

Resolving patch:
diff --git a/lib/spack/llnl/util/filesystem.py b/lib/spack/llnl/util/filesystem.py
--- a/lib/spack/llnl/util/filesystem.py
+++ b/lib/spack/llnl/util/filesystem.py
@@ -1443,6 +1443,7 @@ def search_paths_for_executables(*path_hints):
         if not os.path.isdir(path):
             continue
 
+        path = os.path.abspath(path)
         executable_paths.append(path)
 
         bin_dir = os.path.join(path, 'bin')


Test patch:
Repository: spack/spack

Issue:
User scope override settings not working as expected for compilers.yaml

I'm attempting to override system settings with per-user settings. In particular, I am unable to override a compiler specification, and observe the following collision when attempting to spec any package using the compiler definition:

```
willmore@thetalogin1:~$ spack spec tmux%intel@18.0.0.128
Input spec
--------------------------------
tmux%intel@18.0.0.128

Concretized
--------------------------------
==> Error: Compiler configuration contains entries with duplicate specification (intel@18.0.0.128, cray-cnl8-mic_knl) in the following files:
        /lus/theta-fs0/software/spack/spack-dev/etc/spack/compilers.yaml: 1 time
        /home/willmore/.spack/cray/compilers.yaml: 1 time

The intent is to be able to use a user-defined compiler to override a system version as described in the spack documentation here: 
https://spack.readthedocs.io/en/latest/configuration.html#configuration-scopes
```

### Information on your system

Cray XC-40 (ALCF-theta)
```
~/.spack/compilers.yaml
$spack/etc/spack/compilers.yaml
```




Discussion:

Resolving patch:
diff --git a/lib/spack/spack/compilers/__init__.py b/lib/spack/spack/compilers/__init__.py
--- a/lib/spack/spack/compilers/__init__.py
+++ b/lib/spack/spack/compilers/__init__.py
@@ -383,7 +383,9 @@ def compiler_for_spec(compiler_spec, arch_spec):
     if len(compilers) < 1:
         raise NoCompilerForSpecError(compiler_spec, arch_spec.os)
     if len(compilers) > 1:
-        raise CompilerDuplicateError(compiler_spec, arch_spec)
+        msg = 'Multiple definitions of compiler %s' % compiler_spec
+        msg += 'for architecture %s:\n %s' % (arch_spec, compilers)
+        tty.debug(msg)
     return compilers[0]
 
 


Test patch:
diff --git a/lib/spack/spack/test/compilers.py b/lib/spack/spack/test/compilers.py
--- a/lib/spack/spack/test/compilers.py
+++ b/lib/spack/spack/test/compilers.py
@@ -50,6 +50,32 @@ class MockOs(object):
     return _factory
 
 
+def test_multiple_conflicting_compiler_definitions(mutable_config):
+    compiler_def = {
+        'compiler': {
+            'flags': {},
+            'modules': [],
+            'paths': {
+                'cc': 'cc',
+                'cxx': 'cxx',
+                'f77': 'null',
+                'fc': 'null'},
+            'extra_rpaths': [],
+            'operating_system': 'test',
+            'target': 'test',
+            'environment': {},
+            'spec': 'clang@0.0.0'}}
+
+    compiler_config = [compiler_def, compiler_def]
+    compiler_config[0]['compiler']['paths']['f77'] = 'f77'
+    mutable_config.update_config('compilers', compiler_config)
+
+    arch_spec = spack.spec.ArchSpec('test', 'test', 'test')
+    cspec = compiler_config[0]['compiler']['spec']
+    cmp = compilers.compiler_for_spec(cspec, arch_spec)
+    assert cmp.f77 == 'f77'
+
+
 def test_get_compiler_duplicates(config):
     # In this case there is only one instance of the specified compiler in
     # the test configuration (so it is not actually a duplicate), but the
Repository: spack/spack

Issue:
Spack doesn't print stack traces on SystemExit
Spack fails to give a stacktrace for some kinds of errors, even with the `--debug` flag.  For example:
```
$ spack --debug install --hello
==> Error: unrecognized arguments: --hello
```



Discussion:

Resolving patch:
diff --git a/lib/spack/spack/main.py b/lib/spack/spack/main.py
--- a/lib/spack/spack/main.py
+++ b/lib/spack/spack/main.py
@@ -16,6 +16,7 @@
 import inspect
 import pstats
 import argparse
+import traceback
 from six import StringIO
 
 import llnl.util.tty as tty
@@ -705,10 +706,14 @@ def main(argv=None):
         tty.die(e)
 
     except KeyboardInterrupt:
+        if spack.config.get('config:debug'):
+            raise
         sys.stderr.write('\n')
         tty.die("Keyboard interrupt.")
 
     except SystemExit as e:
+        if spack.config.get('config:debug'):
+            traceback.print_exc()
         return e.code
 
 


Test patch:
Repository: spack/spack

Issue:
Installation issue: py-jsonchema (No checksum provided for @2.6.0 requested by nrm)
The nrm package specifically requests py-jsonschema@2.6.0. Attempting to install this package results in the following error:

==> Warning: There is no checksum on file to fetch py-jsonschema@2.6.0 safely.
==> Error: Will not fetch py-jsonschema@2.6.0
Add a checksum or use --no-checksum to skip this check.



Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/py-jsonschema/package.py b/var/spack/repos/builtin/packages/py-jsonschema/package.py
--- a/var/spack/repos/builtin/packages/py-jsonschema/package.py
+++ b/var/spack/repos/builtin/packages/py-jsonschema/package.py
@@ -10,8 +10,9 @@ class PyJsonschema(PythonPackage):
     """Jsonschema: An(other) implementation of JSON Schema for Python."""
 
     homepage = "http://github.com/Julian/jsonschema"
-    url      = "https://pypi.io/packages/source/j/jsonschema/jsonschema-2.5.1.tar.gz"
+    url      = "https://pypi.io/packages/source/j/jsonschema/jsonschema-2.6.0.tar.gz"
 
+    version('2.6.0', sha256='6ff5f3180870836cae40f06fa10419f557208175f13ad7bc26caa77beb1f6e02')
     version('2.5.1', '374e848fdb69a3ce8b7e778b47c30640')
 
     depends_on('py-setuptools', type='build')


Test patch: