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

Issue:
opencv@3.4.6 fails to build with error "dynlink_nvcuvid.h: No such file or directory'
### Steps to reproduce the issue

```console
spack install opencv@3.4.6+cuda ^hdf5+hl
```
### Platform and user environment

Please report your OS here:
```commandline
$ uname -a 
Linux compute-101 3.10.0-957.12.2.el7.x86_64 #1 SMP Tue May 14 21:24:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -d
Description:    CentOS Linux release 7.6.1810 (Core)
``` 

### Additional information

Cuda version is `cuda@10.1.243`

[spack-build-out.txt_opencv.txt](https://github.com/spack/spack/files/4017893/spack-build-out.txt_opencv.txt)



Discussion:
The following discussion seems to be relevant: https://github.com/opencv/opencv_contrib/issues/1786
Same build error also showed up for v3.4.9, it seems this bug is not fixed yet.
As discussed in the above link, as of cuda@10, the above header file is not provided by cuda rather by nvidia gpu drivers. Hence for now it makes sense to make opencv_cudacodec module a variant and disable it if cuda version is 10 until this is sorted out. Once that is disabled as shown below, opencv compiles just fine:
```python
            '-DBUILD_opencv_cudacodec={0}'.format((
                'ON' if '+cudacodec' in spec else 'OFF')),
```
ideally opencv cmake setup should have check if this header exists, if not cmake should automatically disable this feature.

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/opencv/package.py b/var/spack/repos/builtin/packages/opencv/package.py
--- a/var/spack/repos/builtin/packages/opencv/package.py
+++ b/var/spack/repos/builtin/packages/opencv/package.py
@@ -60,6 +60,7 @@ class Opencv(CMakePackage, CudaPackage):
     # OpenCV modules
     variant('calib3d', default=True, description='calib3d module')
     variant('core', default=True, description='Include opencv_core module into the OpenCV build')
+    variant('cudacodec', default=False, description='Enable video encoding/decoding with CUDA')
     variant('dnn', default=True, description='Build DNN support')
     variant('features2d', default=True, description='features2d module')
     variant('flann', default=True, description='flann module')
@@ -121,6 +122,11 @@ class Opencv(CMakePackage, CudaPackage):
     depends_on('ffmpeg', when='+videoio')
     depends_on('mpi', when='+videoio')
 
+    # TODO For Cuda >= 10, make sure 'dynlink_nvcuvid.h' or 'nvcuvid.h'
+    # exists, otherwise build will fail
+    # See https://github.com/opencv/opencv_contrib/issues/1786
+    conflicts('cuda@10:', when='+cudacodec')
+
     extends('python', when='+python')
 
     def cmake_args(self):
@@ -147,6 +153,8 @@ def cmake_args(self):
                 'ON' if '+calib3d' in spec else 'OFF')),
             '-DBUILD_opencv_core:BOOL={0}'.format((
                 'ON' if '+core' in spec else 'OFF')),
+            '-DBUILD_opencv_cudacodec={0}'.format((
+                'ON' if '+cudacodec' in spec else 'OFF')),
             '-DBUILD_opencv_dnn:BOOL={0}'.format((
                 'ON' if '+dnn' in spec else 'OFF')),
             '-DBUILD_opencv_features2d={0}'.format((


Test patch:
Repository: spack/spack

Issue:
Spack is building a non-optimized CMake?
It would seem that the Spack cmake/package.py file is set up to build a **no optimized** version of CMake by default.  I noticed this a few months ago when we were almost going to try to use the Spack-installed env but then noticed this that the Spack-installed cmake was about 2.5x slower than correctly built CMake.  Here are the configure times for the Primary Tested Trilinos suite on my super fast Linux machine:

Install Method | CMake version | Runtime
-- | -- | --
SEMS | 3.12.2 | 2m30.498s
TriBITS | 3.11.1 | 2m29.507s
Spack | 3.14.5 | 7m47.042s

Until we can fix this, CMake as installed by spack is unusable for SNL ATDM :-(

The proper way to build an optimized CMake is shown in:

* https://github.com/TriBITSPub/TriBITS/blob/master/tribits/devtools_install/install-cmake.py#L172

and that shows how to do a fast parallel configure too.






Discussion:
While the default build does seem to be unoptimized, just adding `O3` to the flags as the referenced implementation does is not universally safe across all the compliers we need to bootstrap with.  However, we should be able to make sure a release build gets built, which in most cases will use `O2` and should address the performance issues as well as be a universally safe.  I'll get a pr up today for it.
@chuckatkins, that would be great!   Please let me know when you have a commit that you think works and I will cherry-pick it and test it out on our side.

@robertmaynard, @bradking, what is the best way to build and install CMake on linux systems?  The instructions at:

* https://cmake.org/install/

say to use "bootstrap" but at SNL we have been using `configure` with `--parallel` as shown at:

* https://github.com/TriBITSPub/TriBITS/blob/master/tribits/devtools_install/install-cmake.py#L172

which seems to build a very nicely optimized version of CMake.



Resolving patch:
diff --git a/var/spack/repos/builtin/packages/cmake/package.py b/var/spack/repos/builtin/packages/cmake/package.py
--- a/var/spack/repos/builtin/packages/cmake/package.py
+++ b/var/spack/repos/builtin/packages/cmake/package.py
@@ -168,8 +168,15 @@ def bootstrap_args(self):
             args.append('--sphinx-html')
             args.append('--sphinx-man')
 
+        # Now for CMake arguments to pass after the initial bootstrap
+        args.append('--')
+
+        # Make sure to create an optimized release build
+        args.append('-DCMAKE_BUILD_TYPE=Release')
+
+        # When building our own private copy of curl then we need to properly
+        # enable / disable oepnssl
         if '+ownlibs' in spec:
-            args.append('--')
             args.append('-DCMAKE_USE_OPENSSL=%s' % str('+openssl' in spec))
 
         return args


Test patch:
Repository: spack/spack

Issue:
Installation issue: magma (review gcc/cuda conflicts)
I think the "conflicts" in the magma/package.py should be reviewed, afaik cuda 9 works fine with gcc 7? And what about cuda 10? And - isn't this kind of stuff handled by the CudaPackage?


Discussion:
@Sinan81 can you take a look at this? Sounds like the exact same fix as you did in #13959.
Sure!

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/magma/package.py b/var/spack/repos/builtin/packages/magma/package.py
--- a/var/spack/repos/builtin/packages/magma/package.py
+++ b/var/spack/repos/builtin/packages/magma/package.py
@@ -7,10 +7,10 @@
 from spack import *
 
 
-class Magma(CMakePackage):
-    """The MAGMA project aims to develop a dense linear algebra library similar to
-       LAPACK but for heterogeneous/hybrid architectures, starting with current
-       "Multicore+GPU" systems.
+class Magma(CMakePackage, CudaPackage):
+    """The MAGMA project aims to develop a dense linear algebra library similar
+       to LAPACK but for heterogeneous/hybrid architectures, starting with
+       current "Multicore+GPU" systems.
     """
 
     homepage = "http://icl.cs.utk.edu/magma/"
@@ -27,13 +27,15 @@ class Magma(CMakePackage):
             description='Enable Fortran bindings support')
     variant('shared', default=True,
             description='Enable shared library')
+    variant('cuda', default=True, description='Build with CUDA')
 
     depends_on('blas')
     depends_on('lapack')
-    depends_on('cuda')
+    depends_on('cuda@8:', when='@2.5.1:')  # See PR #14471
 
-    conflicts('%gcc@6:', when='^cuda@:8')
-    conflicts('%gcc@7:', when='^cuda@:9')
+    conflicts('~cuda', msg='Magma requires cuda')
+    conflicts('cuda_arch=none',
+              msg='Please indicate a CUDA arch value or values')
 
     patch('ibm-xl.patch', when='@2.2:2.5.0%xl')
     patch('ibm-xl.patch', when='@2.2:2.5.0%xl_r')
@@ -68,11 +70,14 @@ def cmake_args(self):
                     '-DCMAKE_Fortran_COMPILER=%s' % self.compiler.f77
                 ])
 
-        if spec.satisfies('^cuda@9.0:'):
+        if spec.satisfies('^cuda'):
+            cuda_arch = self.spec.variants['cuda_arch'].value
             if '@:2.2.0' in spec:
-                options.extend(['-DGPU_TARGET=sm30'])
+                capabilities = ' '.join('sm{0}'.format(i) for i in cuda_arch)
+                options.extend(['-DGPU_TARGET=' + capabilities])
             else:
-                options.extend(['-DGPU_TARGET=sm_30'])
+                capabilities = ' '.join('sm_{0}'.format(i) for i in cuda_arch)
+                options.extend(['-DGPU_TARGET=' + capabilities])
 
         if '@2.5.0' in spec:
             options.extend(['-DMAGMA_SPARSE=OFF'])


Test patch:
Repository: spack/spack

Issue:
spack extensions behavior when no extendable package is specified
If you run `spack extensions` with no extendable package, it prints an error message telling you that a package spec is required. It would be nice if Spack also printed a list of installed extendable packages to choose from.



Discussion:
I am having a look at this command, which I never used. In some sense, it seems quite similar to `spack providers`. Would it make sense to show by default all the possible extensions, and have a flag to restrict to installed packages?
That would make sense. I also have a similar issue open for `spack providers`.

Resolving patch:
diff --git a/lib/spack/spack/cmd/extensions.py b/lib/spack/spack/cmd/extensions.py
--- a/lib/spack/spack/cmd/extensions.py
+++ b/lib/spack/spack/cmd/extensions.py
@@ -4,6 +4,7 @@
 # SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
 import argparse
+import sys
 
 import llnl.util.tty as tty
 from llnl.util.tty.colify import colify
@@ -21,6 +22,8 @@
 
 
 def setup_parser(subparser):
+    subparser.epilog = 'If called without argument returns ' \
+                       'the list of all valid extendable packages'
     arguments.add_common_arguments(subparser, ['long', 'very_long'])
     subparser.add_argument('-d', '--deps', action='store_true',
                            help='output dependencies along with found specs')
@@ -42,7 +45,19 @@ def setup_parser(subparser):
 
 def extensions(parser, args):
     if not args.spec:
-        tty.die("extensions requires a package spec.")
+        # If called without arguments, list all the extendable packages
+        isatty = sys.stdout.isatty()
+        if isatty:
+            tty.info('Extendable packages:')
+
+        extendable_pkgs = []
+        for name in spack.repo.all_package_names():
+            pkg = spack.repo.get(name)
+            if pkg.extendable:
+                extendable_pkgs.append(name)
+
+        colify(extendable_pkgs, indent=4)
+        return
 
     # Checks
     spec = cmd.parse_specs(args.spec)


Test patch:
diff --git a/lib/spack/spack/test/cmd/extensions.py b/lib/spack/spack/test/cmd/extensions.py
--- a/lib/spack/spack/test/cmd/extensions.py
+++ b/lib/spack/spack/test/cmd/extensions.py
@@ -69,6 +69,11 @@ def check_output(ni, na):
     check_output(1, 1)
 
 
+def test_extensions_no_arguments(mock_packages):
+    out = extensions()
+    assert 'python' in out
+
+
 def test_extensions_raises_if_not_extendable(mock_packages):
     with pytest.raises(SpackCommandError):
         extensions("flake8")
Repository: spack/spack

Issue:
headers of python packages not listed in CPATH
When installed, Python packages have the typical structure with `include`, `lib`, and `bin` folders. When loaded by spack, their `include` directory is added to the CPATH environment  variable. Most python packages do not expose C headers. However, python packages that do have headers will often install them in `include/pythonX` (where X is the python version), rather than in `include` (for instance on my machine with Python 3.6.8 they are installed in `include/python3.6m`). Hence any code that requires these headers will need to `#include <python3.6m/path/to/the/header.h>` (so we should know ahead of time the python version) instead of simply `#include <path/to/the/header.h>`, OR it should figure out the header path by a means other than simply relying on CPATH.

It would be good, when loading a Python package, that its `include/pythonX` also be added to CPATH (with X being replaced appropriately).


Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/python/package.py b/var/spack/repos/builtin/packages/python/package.py
--- a/var/spack/repos/builtin/packages/python/package.py
+++ b/var/spack/repos/builtin/packages/python/package.py
@@ -678,14 +678,20 @@ def libs(self):
 
     @property
     def headers(self):
-        config_h = self.get_config_h_filename()
+        try:
+            config_h = self.get_config_h_filename()
+
+            if not os.path.exists(config_h):
+                includepy = self.get_config_var('INCLUDEPY')
+                msg = 'Unable to locate {0} headers in {1}'
+                raise RuntimeError(msg.format(self.name, includepy))
 
-        if not os.path.exists(config_h):
-            includepy = self.get_config_var('INCLUDEPY')
-            msg = 'Unable to locate {0} headers in {1}'
-            raise RuntimeError(msg.format(self.name, includepy))
+            headers = HeaderList(config_h)
+        except ProcessError:
+            headers = find_headers(
+                'pyconfig', self.prefix.include, recursive=True)
+            config_h = headers[0]
 
-        headers = HeaderList(config_h)
         headers.directories = [os.path.dirname(config_h)]
         return headers
 
@@ -705,6 +711,9 @@ def site_packages_dir(self):
     def easy_install_file(self):
         return join_path(self.site_packages_dir, "easy-install.pth")
 
+    def setup_run_environment(self, env):
+        env.prepend_path('CPATH', os.pathsep.join(self.headers.directories))
+
     def setup_dependent_build_environment(self, env, dependent_spec):
         """Set PYTHONPATH to include the site-packages directory for the
         extension and any other python extensions it depends on."""


Test patch:
Repository: spack/spack

Issue:
Installation issue: hdf5@1.10.6 +mpi
Builds of of `hdf5@1.10.6`  on `linux-centos7-skylake_avx512` with `gcc@8.3.0` and on `linux-ubuntu16.04-broadwell` with `gcc@7.4.0`  fails with following `patch` error

```
==> Created stage in /tmp/yangw/spack-stage/spack-stage-hdf5-1.10.6-wn3d32vilbvopkvr352yk5osjjjax4ng
1 out of 1 hunk FAILED -- saving rejects to file src/H5public.h.rej
==> Patch PATH_TO_SPACK/spack/var/spack/repos/builtin/packages/hdf5/h5public-skip-mpicxx.patch failed.
==> Error: ProcessError: Command exited with status 1:
    'PATH_TO_SPACK/spack/opt/spack/linux-ubuntu16.04-broadwell/gcc-7.4.0/patch-2.7.6-l7j5o3em3cznptfompr6djszvwly5mfk/bin/patch' '-s' '-p' '1' '-i' 'PATH_TO_SPACK/spack/var/spack/repos/builtin/packages/hdf5/h5public-skip-mpicxx.patch' '-d' '.'
```

The previous version `hdf5@1.10.5` builds with no problems.


Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/hdf5/package.py b/var/spack/repos/builtin/packages/hdf5/package.py
--- a/var/spack/repos/builtin/packages/hdf5/package.py
+++ b/var/spack/repos/builtin/packages/hdf5/package.py
@@ -114,7 +114,7 @@ class Hdf5(AutotoolsPackage):
 
     # Disable MPI C++ interface when C++ is disabled, otherwise downstream
     # libraries fail to link; see https://github.com/spack/spack/issues/12586
-    patch('h5public-skip-mpicxx.patch', when='+mpi~cxx',
+    patch('h5public-skip-mpicxx.patch', when='@:1.8.21,1.10.0:1.10.5+mpi~cxx',
           sha256='b61e2f058964ad85be6ee5ecea10080bf79e73f83ff88d1fa4b602d00209da9c')
 
     filter_compiler_wrappers('h5cc', 'h5c++', 'h5fc', relative_root='bin')


Test patch:
Repository: spack/spack

Issue:
Installation issue: pdt
### Steps to reproduce the issue

```console
$ spack install pdt%gcc@7.3.0
```
PDT will install fine, but later TAU will fail to build because PDT defaulted to XL compliers on ppc64le.

### Platform and user environment

Please report your OS here:
```commandline
$ uname -a 
Linux cyclops 4.14.0-115.10.1.el7a.ppc64le #1 SMP Wed Jun 26 09:32:17 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux
$ lsb_release -d
Description:	Red Hat Enterprise Linux Server release 7.6 (Maipo)
``` 

### Additional information

I have a patch for this issue, will submit a PR subsequently...


Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/pdt/package.py b/var/spack/repos/builtin/packages/pdt/package.py
--- a/var/spack/repos/builtin/packages/pdt/package.py
+++ b/var/spack/repos/builtin/packages/pdt/package.py
@@ -43,6 +43,10 @@ def configure(self, spec, prefix):
             options.append('-icpc')
         elif self.compiler.name == 'pgi':
             options.append('-pgCC')
+        elif self.compiler.name == 'gcc':
+            options.append('-GNU')
+        else:
+            raise InstallError('Unknown/unsupported compiler family')
 
         configure(*options)
 


Test patch:
Repository: spack/spack

Issue:
Fix dependency of py-pygdal



Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/py-pygdal/package.py b/var/spack/repos/builtin/packages/py-pygdal/package.py
--- a/var/spack/repos/builtin/packages/py-pygdal/package.py
+++ b/var/spack/repos/builtin/packages/py-pygdal/package.py
@@ -22,6 +22,8 @@ class PyPygdal(PythonPackage):
 
     version('3.0.1.5', sha256='1222f69fe5e6b632d0d2a42d3acb8fac80fb4577c05e01969d8cd5548192ccaa')
     version('2.4.2.5', sha256='73386683c0b10ab43b6d64257fca2ba812f53ec61b268de8811565fd9ae9bacd')
+    version('2.4.1.6', sha256='5d1af98ad09f59e34e3b332cf20630b532b33c7120295aaaabbccebf58a11aa4')
+    version('2.4.0.6', sha256='728d11f3ecae0cd3493cd27dab599a0b6184f5504cc172d49400d88ea2b24a9c')
     version('1.11.5.3', sha256='746d13b73a284446a1b604772f869789eabfe6e69dee463f537da27845b29fa7')
     version('1.11.4.3', sha256='99d4b0c94d57ae50592924faaa65cc6a0c0892d83764e9f24ef9270c3a4b111a')
 
@@ -29,6 +31,7 @@ class PyPygdal(PythonPackage):
     depends_on('py-numpy@1.0.0:', type=('build', 'run'))
     depends_on('gdal@3.0.1', type=('build', 'link', 'run'), when='@3.0.1.5')
     depends_on('gdal@2.4.2', type=('build', 'link', 'run'), when='@2.4.2.5')
-    depends_on('gdal@2.4.1', type=('build', 'link', 'run'), when='@2.4.0')
+    depends_on('gdal@2.4.1', type=('build', 'link', 'run'), when='@2.4.1.6')
+    depends_on('gdal@2.4.0', type=('build', 'link', 'run'), when='@2.4.0.6')
     depends_on('gdal@1.11.5', type=('build', 'link', 'run'), when='@1.11.5.3')
     depends_on('gdal@1.11.4', type=('build', 'link', 'run'), when='@1.11.4.3')


Test patch:
Repository: spack/spack

Issue:
Installation issue: tau
---

### Steps to reproduce the issue

```console
$ spack install tau
...
ERROR: Command line switch `-sqlite3=DIR' not recognized
```
Unfortunately, I added a new feature in the develop branch of TAU that isn't in any of the released version, and shouldn't be enabled by default.  See #15189.

Will submit a PR fix in a few seconds...


Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/tau/package.py b/var/spack/repos/builtin/packages/tau/package.py
--- a/var/spack/repos/builtin/packages/tau/package.py
+++ b/var/spack/repos/builtin/packages/tau/package.py
@@ -68,7 +68,7 @@ class Tau(Package):
     variant('fortran', default=darwin_default, description='Activates Fortran support')
     variant('io', default=True, description='Activates POSIX I/O support')
     variant('adios2', default=False, description='Activates ADIOS2 output support')
-    variant('sqlite', default=True, description='Activates SQLite3 output support')
+    variant('sqlite', default=False, description='Activates SQLite3 output support')
 
     # Support cross compiling.
     # This is a _reasonable_ subset of the full set of TAU
@@ -100,6 +100,10 @@ class Tau(Package):
     conflicts('+libelf', when='@:2.28.0')
     conflicts('+libdwarf', when='@:2.28.0')
 
+    # ADIOS2, SQLite only available from 2.29.1 on
+    conflicts('+adios2', when='@:2.29.1')
+    conflicts('+sqlite', when='@:2.29.1')
+
     filter_compiler_wrappers('tau_cc.sh', 'Makefile.tau', relative_root='bin')
 
     def set_compiler_options(self, spec):


Test patch:
Repository: spack/spack

Issue:
gromacs-2020 fails to build with cmake>3.15.2 and openmpi
Gromacs version 2020 fails to build with cmake>3.15.2 and openmpi.
The error message is ``g++: error: unrecognized command line option '-fexceptions -pthread'; did you mean '-fexceptions'`` and is due to cmake adding compiler arguments with quotes.
A similar issue has been reported in #15097.

### Spack version
0.14.0-165-146589e

### Additional information

There seem to be three options to deal with the issue:

1. ignore as the Gromacs developers fixed the issue in version 2020.1; #15399 is the PR to upgrade the Gromacs version in Spack
2. include the upstream fix (https://github.com/gromacs/gromacs/commit/7d0829a3cbc3d3bbb8e0bb7e6d104e2d2165336f) in Spack for Gromacs-2020 as patch
3. add ``conflicts('cmake@3.15.3:' when='@2020')`` or similarly ``depends_on('cmake@:3.15.2', when='@2020')``

@junghans, @marvinbernhardt: what do you prefer? In case of 2. or 3. I could provide a PR.


Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/gromacs/package.py b/var/spack/repos/builtin/packages/gromacs/package.py
--- a/var/spack/repos/builtin/packages/gromacs/package.py
+++ b/var/spack/repos/builtin/packages/gromacs/package.py
@@ -25,6 +25,7 @@ class Gromacs(CMakePackage):
     maintainers = ['junghans', 'marvinbernhardt']
 
     version('master', branch='master')
+    version('2020.1', sha256='e1666558831a3951c02b81000842223698016922806a8ce152e8f616e29899cf')
     version('2020', sha256='477e56142b3dcd9cb61b8f67b24a55760b04d1655e8684f979a75a5eec40ba01')
     version('2019.6', sha256='bebe396dc0db11a9d4cc205abc13b50d88225617642508168a2195324f06a358')
     version('2019.5', sha256='438061a4a2d45bbb5cf5c3aadd6c6df32d2d77ce8c715f1c8ffe56156994083a')


Test patch:
Repository: spack/spack

Issue:
cuda@10.2.89 conflicts for Intel 19.0 are incorrect
@psychocoderHPC This commit https://github.com/spack/spack/commit/9c10b80591fec2cf391c97f8f53040c3429dbdec#diff-25617eab209908525fc69e80febde144

broke support for the Intel 19.0 compiler.

CUDA 10.2.89 does in fact work with the Intel 19.0 compiler.
https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html

Intel 19.0 compiler support started with CUDA 10.1.x
https://docs.nvidia.com/cuda/archive/10.1/cuda-installation-guide-linux/index.html 

The conflicts statement are inclusive with the arguments which at times makes it difficult to express the CUDA conflicts. But basically this line:
https://github.com/spack/spack/blob/develop/lib/spack/spack/build_systems/cuda.py#L143

say Intel Compiler 19.0 does not work with the CUDA 10.2.89.

One easy fix is to change the line to:
```
conflicts('%intel@19.0:', when='+cuda ^cuda@:10.0.130')
```

or even less verbose:
```
conflicts('%intel@19.0:', when='+cuda ^cuda@:10.0')
```
https://docs.nvidia.com/cuda/archive/10.0/cuda-installation-guide-linux/index.html


Discussion:
@naromero77 Coud you please provide the second solution as pull request.

CC-ing: @ax3l 
will take care of it over the weekend
Also pinging @svenevs in case he has anything to add
This looks correct to me, I currently use 19.0 with CUDA 10.2. Thanks @naromero77!

Resolving patch:
diff --git a/lib/spack/spack/build_systems/cuda.py b/lib/spack/spack/build_systems/cuda.py
--- a/lib/spack/spack/build_systems/cuda.py
+++ b/lib/spack/spack/build_systems/cuda.py
@@ -140,12 +140,12 @@ def cuda_flags(arch_list):
     conflicts('%intel@16.0:', when='+cuda ^cuda@:8.0.43')
     conflicts('%intel@17.0:', when='+cuda ^cuda@:8.0.60')
     conflicts('%intel@18.0:', when='+cuda ^cuda@:9.9')
-    conflicts('%intel@19.0:', when='+cuda ^cuda@:10.2.89')
+    conflicts('%intel@19.0:', when='+cuda ^cuda@:10.0')
 
     # XL is mostly relevant for ppc64le Linux
     conflicts('%xl@:12,14:', when='+cuda ^cuda@:9.1')
     conflicts('%xl@:12,14:15,17:', when='+cuda ^cuda@9.2')
-    conflicts('%xl@17:', when='+cuda ^cuda@10.0.130:10.2.89')
+    conflicts('%xl@17:', when='+cuda ^cuda@:10.2.89')
 
     # Mac OS X
     # platform = ' platform=darwin'


Test patch: