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

Issue:
Patches and Package Namespace
I have another repo other than builtin.  There is a lulesh package in both my repo and the builtin repo.  The builtin spackage has a patch, the version in my repo does not.  Spack was looking for the patch in my repo and failing to find it.  My thought was that the way spack checks for patches ignores the namespace?  
However after installing the patch into my repo directory to work then removing it to recreate the error solved the issue.


Discussion:

Resolving patch:
diff --git a/lib/spack/spack/patch.py b/lib/spack/spack/patch.py
--- a/lib/spack/spack/patch.py
+++ b/lib/spack/spack/patch.py
@@ -23,16 +23,28 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
 ##############################################################################
 import os
+import os.path
+import inspect
 
 import spack
 import spack.error
-import spack.stage
 import spack.fetch_strategy as fs
-
+import spack.stage
 from llnl.util.filesystem import join_path
 from spack.util.executable import which
 
 
+def absolute_path_for_package(pkg):
+    """Returns the absolute path to the ``package.py`` file implementing
+    the recipe for the package passed as argument.
+
+    Args:
+        pkg: a valid package object
+    """
+    m = inspect.getmodule(pkg)
+    return os.path.abspath(m.__file__)
+
+
 class Patch(object):
     """Base class to describe a patch that needs to be applied to some
     expanded source code.
@@ -90,7 +102,7 @@ class FilePatch(Patch):
     def __init__(self, pkg, path_or_url, level):
         super(FilePatch, self).__init__(pkg, path_or_url, level)
 
-        pkg_dir = spack.repo.dirname_for_package_name(pkg.name)
+        pkg_dir = os.path.dirname(absolute_path_for_package(pkg))
         self.path = join_path(pkg_dir, path_or_url)
         if not os.path.isfile(self.path):
             raise NoSuchPatchFileError(pkg.name, self.path)


Test patch:
Repository: spack/spack

Issue:
openblas: Allow specifying CPU architecture



Discussion:
How do we deal with the fact that targets are moving? I mean, it's very likely that the upcoming versions of `openblas` will drop support for some architectures, and add support for other ones. I fear this will become a mess similar to the libraries in `boost`.
@alalazo We can make this a free-form variant where any string is allowed as argument, with respective build-time tests.
@eschnett This seems to me a good compromise between correctness and flexibility. :+1: 

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/openblas/package.py b/var/spack/repos/builtin/packages/openblas/package.py
--- a/var/spack/repos/builtin/packages/openblas/package.py
+++ b/var/spack/repos/builtin/packages/openblas/package.py
@@ -50,6 +50,10 @@ class Openblas(MakefilePackage):
     variant('openmp', default=False, description="Enable OpenMP support.")
     variant('pic', default=True, description='Build position independent code')
 
+    variant('cpu_target', default='',
+                    description='Set CPU target architecture (leave empty for '
+                        'autodetection; GENERIC, SSE_GENERIC, NEHALEM, ...)')
+
     # virtual dependency
     provides('blas')
     provides('lapack')
@@ -104,8 +108,12 @@ def make_defs(self):
             'FC={0}'.format(spack_f77),
             'MAKE_NO_J=1'
         ]
+        if self.spec.variants['cpu_target'].value:
+            make_defs += [
+                'TARGET={0}'.format(self.spec.variants['cpu_target'].value)
+            ]
         # invoke make with the correct TARGET for aarch64
-        if 'aarch64' in spack.architecture.sys_type():
+        elif 'aarch64' in spack.architecture.sys_type():
             make_defs += [
                 'TARGET=PILEDRIVER',
                 'TARGET=ARMV8'


Test patch:
Repository: spack/spack

Issue:
gitk cannot find tk's wish program
When running `gitk` generated by spack, I see the following error:
```
 % gitk
/scratch/vendors/spack.20170502/opt/spack/linux-rhel7-x86_64/gcc-4.8.5/git-2.12.2-cduatp5pegjyiwvv6rfmpdaagp2hlmct/bin/gitk: line 3: exec: wish: not found
```

This can be remedied by:
1.  Creating a symlink in the `tk` bin directory: 
```
cd `spack location -i tk`/bin; ln -s wish8.6 wish
```
2. Loading the `tk` module when `git` is loaded.

I'm not sure how to automate this in spack.



Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/tk/package.py b/var/spack/repos/builtin/packages/tk/package.py
--- a/var/spack/repos/builtin/packages/tk/package.py
+++ b/var/spack/repos/builtin/packages/tk/package.py
@@ -53,3 +53,8 @@ def setup_environment(self, spack_env, run_env):
     def configure_args(self):
         spec = self.spec
         return ['--with-tcl={0}'.format(spec['tcl'].prefix.lib)]
+
+    @run_after('install')
+    def symlink_wish(self):
+        with working_dir(self.prefix.bin):
+            symlink('wish{0}'.format(self.version.up_to(2)), 'wish')


Test patch:
Repository: spack/spack

Issue:
Unable to build LLVM on CentOS 7
I'm trying to build LLVM on CentOS 7 with GCC 7.1.0. I'm seeing the following error message:
```
In file included from /blues/gpfs/home/ajstewart/spack/var/spack/stage/llvm-4.0.0-iwr5xsmpa2scpclnuhevp4od7pa3j7mq/llvm-4.0.0.src/tools/lldb/source/Utility/TaskPool.cpp:10:0:
/blues/gpfs/home/ajstewart/spack/var/spack/stage/llvm-4.0.0-iwr5xsmpa2scpclnuhevp4od7pa3j7mq/llvm-4.0.0.src/tools/lldb/include/lldb/Utility/TaskPool.h: In static member function ‘static std::future<typename std::result_of<_Functor(_ArgTypes ...)>::type> TaskPool::AddTask(F&&, Args&& ...)’:
/blues/gpfs/home/ajstewart/spack/var/spack/stage/llvm-4.0.0-iwr5xsmpa2scpclnuhevp4od7pa3j7mq/llvm-4.0.0.src/tools/lldb/include/lldb/Utility/TaskPool.h:122:12: error: ‘bind’ is not a member of ‘std’
       std::bind(std::forward<F>(f), std::forward<Args>(args)...));
            ^~~~
/blues/gpfs/home/ajstewart/spack/var/spack/stage/llvm-4.0.0-iwr5xsmpa2scpclnuhevp4od7pa3j7mq/llvm-4.0.0.src/tools/lldb/include/lldb/Utility/TaskPool.h:122:12: note: suggested alternative: ‘end’
       std::bind(std::forward<F>(f), std::forward<Args>(args)...));
            ^~~~
            end
```
Full build log [here](https://github.com/LLNL/spack/files/1203298/spack-build.txt).


Discussion:
This looks like a bug in `TaskPool.h.`  [std::bind](http://en.cppreference.com/w/cpp/utility/functional/bind) is defined in the C++ header `<functional>` but this header isn't included by `TaskPool.h.`.  Interestingly, https://github.com/llvm-mirror/lldb/blob/master/include/lldb/Utility/TaskPool.h has this header added to the source.

My guess is that `<functional>` was unknowingly included via another C++ header prior to GCC 7.
Got hit by this too today. I guess a simple PR with a patch is in order. The condition is gcc >= 7.0, I guess. I wonder what are the restrictions on llvm versions, though. I've only tried to install LLVM 4.0.0.
Checked llvm-4.0.1, no cigar, still missing `<functional>`.
Would like to write something like this:
```python
    patch('llvm_gcc7.patch', when='@4.0.0+lldb ^gcc@7.0:')
    patch('llvm_gcc7.patch', when='@4.0.1+lldb ^gcc@7.0:')
```
Not sure if this works, though.

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/llvm/package.py b/var/spack/repos/builtin/packages/llvm/package.py
--- a/var/spack/repos/builtin/packages/llvm/package.py
+++ b/var/spack/repos/builtin/packages/llvm/package.py
@@ -324,6 +324,9 @@ class Llvm(CMakePackage):
     conflicts('+clang_extra', when='~clang')
     conflicts('+lldb',        when='~clang')
 
+    # Github issue #4986
+    patch('llvm_gcc7.patch', when='@4.0.0:4.0.1+lldb %gcc@7.0:')
+
     def setup_environment(self, spack_env, run_env):
         spack_env.append_flags('CXXFLAGS', self.compiler.cxx11_flag)
 


Test patch:
Repository: spack/spack

Issue:
Vague "==> Error: 'shared'" message when attempting to build cntk
I am getting a rather vague error message when attempting to build cntk with spack (gitrev: bb29ec1) on ORNL Titan. The following is the output that I am getting from spack:

> titan-ext2: ./bin/spack install cntk %gcc@4.9.3 
> titan-ext2: ==> Error: 'shared'

This error message appears irregardless of what node type I attempt to compile on (login, service, and compute all show the same error) and it only appears with cntk (other packages compile/install without issue). 

What exactly is this error message indicating and what would I need to do to sidestep this problem?


Discussion:
@bwelton : for such abstract errors `debug` flag is your friend i.e. try `spack -d install ...`
Ok, I can reproduce this locally. Culprit is : 

```
depends_on('protobuf~shared')
```

There is no `shared` variant in protobuf now. I will submit PR. It should be just `depends_on('protobuf')`

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/cntk/package.py b/var/spack/repos/builtin/packages/cntk/package.py
--- a/var/spack/repos/builtin/packages/cntk/package.py
+++ b/var/spack/repos/builtin/packages/cntk/package.py
@@ -47,7 +47,7 @@ class Cntk(Package):
     depends_on('openblas')
     depends_on('mpi')
     depends_on('boost')
-    depends_on('protobuf~shared')
+    depends_on('protobuf')
     # CNTK depends on kaldi@c02e8.
     # See https://github.com/Microsoft/CNTK/blob/master/Tools/docker/CNTK-CPUOnly-Image/Dockerfile#L105-L125
     depends_on('kaldi@c024e8', when='+kaldi')


Test patch:
Repository: spack/spack

Issue:
boost@1.56.0^gcc@5.4.0 complains about reversed patch.
When I build boost@1.56.0 with gcc@5.4.0 I get a complaint about the call_once_variadic patch already having been applied and etc....

#5691 fixes it by changing the patch's constraint from `:1.56.0` to `:1.55.0`, but I do not know if that is actually appropriate.




Discussion:

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
@@ -156,7 +156,7 @@ class Boost(Package):
     patch('xl_1_62_0_le.patch', when='@1.62.0%xl_r')
     patch('xl_1_62_0_le.patch', when='@1.62.0%xl')
 
-    patch('call_once_variadic.patch', when='@:1.56.0%gcc@5:')
+    patch('call_once_variadic.patch', when='@:1.55.9999%gcc@5:')
 
     # Patch fix for PGI compiler
     patch('boost_1.63.0_pgi.patch', when='@1.63.0%pgi')


Test patch:
Repository: spack/spack

Issue:
Non-boolean variant does not work in ADIOS
Recent updates to spack have introduced the with-or-without functionality. 
In the adios package, the `staging` variant was modified accordingly to have multiple values: flexpath and dataspaces.

Now `spack install adios staging=flexpath` does not install adios with flexpath. The staging variant seems to be ignored.


Discussion:
I am not sure, but it looks like there are other issues in `adios`: 

```
    depends_on('libevpath', when='+flexpath')
    depends_on('libevpath', when='+staging')
```
should probably be
```
    depends_on('libevpath', when='staging=flexpath')
    depends_on('libevpath', when='staging=???')
```

p.s. supposedly the relevant PR is https://github.com/LLNL/spack/pull/5020

@alalazo ping.

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/adios/package.py b/var/spack/repos/builtin/packages/adios/package.py
--- a/var/spack/repos/builtin/packages/adios/package.py
+++ b/var/spack/repos/builtin/packages/adios/package.py
@@ -95,12 +95,10 @@ class Adios(AutotoolsPackage):
     # optional transports & file converters
     depends_on('hdf5@1.8:+mpi', when='+hdf5')
     depends_on('netcdf', when='+netcdf')
-    depends_on('libevpath', when='+flexpath')
-    depends_on('libevpath', when='+staging')
-    depends_on('dataspaces+mpi', when='+dataspaces')
-    depends_on('dataspaces+mpi', when='+staging')
+    depends_on('libevpath', when='staging=flexpath')
+    depends_on('dataspaces+mpi', when='staging=dataspaces')
 
-    for p in ['+hdf5', '+netcdf', '+flexpath', '+dataspaces', '+staging']:
+    for p in ['+hdf5', '+netcdf', 'staging=flexpath', 'staging=dataspaces']:
         conflicts(p, when='~mpi')
 
     build_directory = 'spack-build'


Test patch:
Repository: spack/spack

Issue:
need to specify preferred variant for mpi
For my package I have the following:

    depends_on('mpi')

since it is not restricted to any particular mpi implementation, but if openmpi is being selected (automatically or otherwise), I'd like to have a particular variant *required*. Eg, as pseudo-code

    depend_on('openmpi+thread_multiple', when="(mpi is openmpi)")

Adding this into `~/.spack/packages.yaml` isn't really an option since this doesn't work very well when distributing the package and would be rather error-prone.

What solutions are available?

I've tagged the usual suspects: @adamjstewart  @tgamblin @alalazo 




Discussion:
```
conflicts('+mpi', when='^openmpi~thread_multiple')
```
is what you probably want. p.s. i have not tested, just rough direction.
Thanks, this looks promising but seems to get ignored.
I guess this might be because the mpi dependency is indirectly resolved by the package dependency on `fftw`.
maybe something like
```
conflicts('^openmpi~thread_multiple')
```
will do? Given that you have `depends_on('mpi')`, that shall work.
Unfortunately that just got me

    1. "^openmpi~thread_multiple" conflicts with "openfoam-com"

> Unfortunately that just got me 

but that's what you want, isn't it? You always want to use `openmpi+thread_multiple`, right?

EDIT: `spack spec foo ^openmpi+thread_multiple` shall concretize
What I want is an additional layer of safety and automation. When installing, the user should be free to specify whichever MPI is desired or just use the fallback value. If the specified or fallback value is `openmpi`, then I would like to insist that my package always wants openmpi with the `+thread_multiple` variant. If this needs to be resolved via an additional command-line option, this is IMO too fragile.
> What I want is an additional layer of safety

that's what you get with the `conflict` statement.

>  If the specified or fallback value is openmpi, then I would like to insist that my package always wants openmpi with the +thread_multiple variant. 

as far as I know, that's not possible. You need to ask users to enable `+thread_multiple` from the command line or set this in their `packages.yaml`.

> this is IMO too fragile.

i don't think it's fragile, you have a `conflict`, there is no way anyone will build your package with `openmpi~ thread_multiple`. Nothing is fragile here.
Users might not like it, though. If they are not careful, they will get error during concretization.

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
@@ -292,6 +292,10 @@ class OpenfoamCom(Package):
 
     provides('openfoam')
     depends_on('mpi')
+
+    # After 1712 require openmpi+thread_multiple for collated output
+    conflicts('^openmpi~thread_multiple', when='@1712:')
+
     depends_on('zlib')
     depends_on('fftw')
     depends_on('boost')


Test patch:
Repository: spack/spack

Issue:
New patch deps: AttributeError: 'str' object has no attribute 'parent'
Try to build #5459:
```
==> Error: AttributeError: 'str' object has no attribute 'parent'
AttributeError: AttributeError: 'str' object has no attribute 'parent'

/home/junghans/spack/lib/spack/spack/package.py:1042, in do_patch:
     9             has_patch_fun = hasattr(self, 'patch') and callable(self.patch)
     10
     11            # Get the patches from the spec (this is a shortcut for the MV-variant)
  >> 12            patches = self.spec.patches
     13
     14            # If there are no patches, note it.
     15            if not patches and not has_patch_fun:
```


Discussion:
Is this with the latest develop?
This is on top of 5fa1191d1736659f03b3e49bf35db42b576d2266.
I'm trying to find a smaller reproducer than something which depends on llvm. Could you tell me which package this fails on (e.g. does it get all the way to flang)?
Oh and including the `spack install...` line would also be helpful (if it's anything different from `spack install flang`) and mention if externals are set up in packages.yaml
It fails when building `llvm` for `flang` running:
```
spack install -j2 -v flang
```
(no `packages.yaml`).
OK I think I've got a sense of the problem. I should have a PR shortly (in an hour).

Thanks for the info!

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
@@ -2535,8 +2535,9 @@ def patches(self):
 
             # if not found in this package, check immediate dependents
             # for dependency patches
-            for dep in self._dependents:
-                patch = dep.parent.package.lookup_patch(sha256)
+            for dep_spec in self._dependents.values():
+                patch = dep_spec.parent.package.lookup_patch(sha256)
+
                 if patch:
                     patches.append(patch)
 


Test patch:
Repository: spack/spack

Issue:
Updating hypre package so that new v2.12.1 is supported and preferred.
A new version of hypre is out, v2.12.1.  This pull request adds this version to the hypre spack package and makes it preferred.



Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/hypre/package.py b/var/spack/repos/builtin/packages/hypre/package.py
--- a/var/spack/repos/builtin/packages/hypre/package.py
+++ b/var/spack/repos/builtin/packages/hypre/package.py
@@ -35,12 +35,13 @@ class Hypre(Package):
     homepage = "http://computation.llnl.gov/project/linear_solvers/software.php"
     url      = "http://computation.llnl.gov/project/linear_solvers/download/hypre-2.10.0b.tar.gz"
 
-    version('develop', git='https://github.com/LLNL/hypre', tag='master')
-    version('xsdk-0.2.0', git='https://github.com/LLNL/hypre', tag='xsdk-0.2.0')
+    version('2.12.1', 'c6fcb6d7e57cec1c7ce4a44da885068c', url='https://github.com/LLNL/hypre/archive/v2.12.1.tar.gz')
     version('2.11.2', 'd507943a1a3ce5681c3308e2f3a6dd34')
     version('2.11.1', '3f02ef8fd679239a6723f60b7f796519')
     version('2.10.1', 'dc048c4cabb3cd549af72591474ad674')
     version('2.10.0b', '768be38793a35bb5d055905b271f5b8e')
+    version('develop', git='https://github.com/LLNL/hypre', tag='master')
+    version('xsdk-0.2.0', git='https://github.com/LLNL/hypre', tag='xsdk-0.2.0')
 
     # hypre does not know how to build shared libraries on Darwin
     variant('shared', default=(sys.platform != 'darwin'),


Test patch:
Repository: spack/spack

Issue:
Spack GPG list doesn't return anything with no arguments specified
Running with the current tip of develop if I create a spack GPG key, I cannot view it with `spack gpg list`, nor is any meaningful error returned.

Example
```
# spack gpg create david david@example.com
gpg: keyring `/root/spack/opt/spack/gpg/secring.gpg' created
gpg: keyring `/root/spack/opt/spack/gpg/pubring.gpg' created
gpg: skipping control `%no-protection' ()
gpg: /root/spack/opt/spack/gpg/trustdb.gpg: trustdb created
gpg: key C276E78E marked as ultimately trusted
# spack gpg list
# spack gpg export  key.key C276E78E
# cat key.key
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2
...
```


Discussion:

Resolving patch:
diff --git a/lib/spack/spack/cmd/gpg.py b/lib/spack/spack/cmd/gpg.py
--- a/lib/spack/spack/cmd/gpg.py
+++ b/lib/spack/spack/cmd/gpg.py
@@ -82,7 +82,7 @@ def setup_parser(subparser):
 
     list = subparsers.add_parser('list')
     list.add_argument('--trusted', action='store_true',
-                      help='list trusted keys')
+                      default=True, help='list trusted keys')
     list.add_argument('--signing', action='store_true',
                       help='list keys which may be used for signing')
     list.set_defaults(func=gpg_list)


Test patch:
diff --git a/lib/spack/spack/test/cmd/gpg.py b/lib/spack/spack/test/cmd/gpg.py
--- a/lib/spack/spack/test/cmd/gpg.py
+++ b/lib/spack/spack/test/cmd/gpg.py
@@ -98,6 +98,7 @@ def test_gpg(gpg, tmpdir, testing_gpg_directory):
 
     # List the keys.
     # TODO: Test the output here.
+    gpg('list')
     gpg('list', '--trusted')
     gpg('list', '--signing')
Repository: spack/spack

Issue:
FileList (base class of HeaderList and LibraryList) is not shown in the documentation
subj. see https://github.com/LLNL/spack/issues/2617#issuecomment-336208244


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
@@ -42,6 +42,7 @@
 
 __all__ = [
     'FileFilter',
+    'FileList',
     'HeaderList',
     'LibraryList',
     'ancestor',


Test patch:
Repository: spack/spack

Issue:
module refresh gives Error: 'core_compilers' key not found in configuration file
```
$ spack module refresh
==> You are about to regenerate tcl, lmod, dotkit module files for:

-- darwin-highsierra-x86_64 / clang@9.0.0-apple -----------------
<blablabla>

==> Do you want to proceed? [y/n] y
==> Regenerating tcl module files
==> Warning: Could not write module file [/Users/davydden/spack/share/spack/modules/darwin-highsierra-x86_64/gettext-0.19.8.1-clang-9.0.0-apple-6gzxwhl]
==> Warning: 	--> global name 'prefix' is not defined <--
==> Error: 'core_compilers' key not found in configuration file
```
I have no idea what that is


Discussion:
I need to check the defaults (and remove `lmod` from them), in the meanwhile you can:
```
$ spack module refresh -m tcl
```
thanks, @alalazo ! Limiting it to `tcl` worked as expected.
Incidentally: the module system is also reporting a bug (due to a typo) in `builtin/gettext/package.py`. 
> the module system is also reporting a bug (due to a typo) in builtin/gettext/package.py.

where's the typo? 
I'll fix it, don't worry. It seems a `prefix` is used somewhere instead of `self.prefix`. It comes in a warning because the failure of writing a single module shouldn't prevent other modules to be written.

Resolving patch:
diff --git a/lib/spack/spack/cmd/common/arguments.py b/lib/spack/spack/cmd/common/arguments.py
--- a/lib/spack/spack/cmd/common/arguments.py
+++ b/lib/spack/spack/cmd/common/arguments.py
@@ -107,7 +107,7 @@ def __call__(self, parser, namespace, values, option_string=None):
     '-m', '--module-type',
     choices=spack.modules.module_types.keys(),
     action='append',
-    help='type of module file. More than one choice is allowed [default: all available module types]')  # NOQA: ignore=E501
+    help='type of module file. More than one choice is allowed [default: tcl]')  # NOQA: ignore=E501
 
 _arguments['yes_to_all'] = Args(
     '-y', '--yes-to-all', action='store_true', dest='yes_to_all',
diff --git a/lib/spack/spack/cmd/module.py b/lib/spack/spack/cmd/module.py
--- a/lib/spack/spack/cmd/module.py
+++ b/lib/spack/spack/cmd/module.py
@@ -332,7 +332,9 @@ def module(parser, args):
     module_types = args.module_type
     if module_types is None:
         # If no selection has been made select all of them
-        module_types = list(spack.modules.module_types.keys())
+        module_types = ['tcl']
+
+    module_types = list(set(module_types))
 
     try:
 


Test patch:
diff --git a/lib/spack/spack/test/cmd/module.py b/lib/spack/spack/test/cmd/module.py
--- a/lib/spack/spack/test/cmd/module.py
+++ b/lib/spack/spack/test/cmd/module.py
@@ -54,7 +54,8 @@ def parser():
         ['rm', 'doesnotexist'],  # Try to remove a non existing module
         ['find', 'mpileaks'],  # Try to find a module with multiple matches
         ['find', 'doesnotexist'],  # Try to find a module with no matches
-        ['find', 'libelf'],  # Try to find a module wo specifying the type
+        # Try to find a module specifying more than one type
+        ['find', '-m', 'tcl', '-m', 'lmod', 'libelf'],
     ]
 )
 def failure_args(request):