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

Issue:
spack require GitHub account and password
Dear spack developers and users,

recently I am trying to install a software using spack to install a software (https://github.com/votca/csg/wiki/Installing#spack), when downloading the packages from GitHub, it asks me to give the GitHub account and password containing the source code. I am wondering if anyone knows what is the problem and how to solve it?

Thank you very much!
With best regards,
Shiyun


Discussion:
```
git clone https://github.com/llnl/spack.git
```
shall not ask for any password. Can you copy-paste the terminal commands you are doing and the output, preferably from a fresh start? 
Yeah, I haven't seen this issue before either, especially because `https://github.com/...` is usally working anonymously. 
Dear Davydden and Junghans,

Thank you very much for your help. 
git clone https://github.com/llnl/spack has no problem. But after downloaded the spack, I used the spack to install votca by the command:
spack install votca-csg@develop votca-tools@develop
During this step, it asked me GitHub account and passphase when cloning the votca-csg source. The full output is attached.
Thanks a lot
With best regards,
Shiyun
[spack_out.txt](https://github.com/LLNL/spack/files/1082525/spack_out.txt)

The URL in Spack's votca-csg is wrong. It uses the correct `https://github.com/votca/csg/tarball/v1.4` for the tarball, but a wrong one `https://github.com/csg/tools` for version. Because that repository does not exist, github asks for password (probably, assuming that's a private one).

Just need to fix an URL.

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/votca-csg/package.py b/var/spack/repos/builtin/packages/votca-csg/package.py
--- a/var/spack/repos/builtin/packages/votca-csg/package.py
+++ b/var/spack/repos/builtin/packages/votca-csg/package.py
@@ -36,7 +36,7 @@ class VotcaCsg(CMakePackage):
     homepage = "http://www.votca.org"
     url      = "https://github.com/votca/csg/tarball/v1.4"
 
-    version('develop', git='https://github.com/csg/tools', branch='master')
+    version('develop', git='https://github.com/votca/csg', branch='master')
     version('1.4', 'd009e761e5e3afd51eed89c420610a67')
 
     variant('debug', default=False, description='Build debug version')


Test patch:
Repository: spack/spack

Issue:
building flex with +lex variant fails
Using an older system (suse 13 with python 2.7.6) and the symlink code in the package fails entirely.
@mjwoods 



Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/flex/package.py b/var/spack/repos/builtin/packages/flex/package.py
--- a/var/spack/repos/builtin/packages/flex/package.py
+++ b/var/spack/repos/builtin/packages/flex/package.py
@@ -32,6 +32,7 @@ class Flex(AutotoolsPackage):
     homepage = "https://github.com/westes/flex"
     url = "https://github.com/westes/flex/releases/download/v2.6.1/flex-2.6.1.tar.gz"
 
+    version('2.6.4', '2882e3179748cc9f9c23ec593d6adc8d')
     version('2.6.3', 'a5f65570cd9107ec8a8ec88f17b31bb1')
     # Problematic version:
     # See issue #2554; https://github.com/westes/flex/issues/113
@@ -68,13 +69,17 @@ def url_for_version(self, version):
 
     @run_after('install')
     def symlink_lex(self):
+        """Install symlinks for lex compatibility."""
         if self.spec.satisfies('+lex'):
             dso = dso_suffix
             for dir, flex, lex in \
-                    ((self.prefix.bin, 'flex', 'lex'),
-                     (self.prefix.lib, 'libfl.a', 'libl.a'),
-                     (self.prefix.lib, 'libfl.' + dso, 'libl.' + dso)):
-                with working_dir(dir):
-                    if (os.path.isfile(flex) and not
-                            os.path.lexists(lex)):
-                        symlink(flex, lex)
+                    ((self.prefix.bin,   'flex', 'lex'),
+                     (self.prefix.lib,   'libfl.a', 'libl.a'),
+                     (self.prefix.lib,   'libfl.' + dso, 'libl.' + dso),
+                     (self.prefix.lib64, 'libfl.a', 'libl.a'),
+                     (self.prefix.lib64, 'libfl.' + dso, 'libl.' + dso)):
+
+                if os.path.isdir(dir):
+                    with working_dir(dir):
+                        if (os.path.isfile(flex) and not os.path.lexists(lex)):
+                            symlink(flex, lex)


Test patch:
Repository: spack/spack

Issue:
Default Editor in Non-Interactive Mode
Hi,

with the latest updates in `develop` (tested: 790b06e0c363ce1598deb3bde217c4685701b61d) spack seems to require to know my `default editor` when installing software, even in non-interactive mode.

On the first call to `spack install` it now fails if *no editor is installed* on a system (which is quite often the case in docker images #4480):
```
Traceback (most recent call last):
  File "/home/src/spack/bin/spack", line 80, in <module>
    import spack.main  # noqa
  File "/home/src/spack/lib/spack/spack/__init__.py", line 227, in <module>
    default = default_editors[0]
NameError: name 'default_editors' is not defined
```

This was not required earlier this week, so it might have been introduced quite recently. IMHO, spack should not need to know my editor for such a task :) (only for `spack create`-like commands)
Don't immediately raise an error when an editor is not found.
Fixes #4526.

@ax3l 


Discussion:

Resolving patch:
diff --git a/lib/spack/spack/__init__.py b/lib/spack/spack/__init__.py
--- a/lib/spack/spack/__init__.py
+++ b/lib/spack/spack/__init__.py
@@ -223,12 +223,13 @@
 else:
     editor = which('vim', 'vi', 'emacs', 'nano')
 
+# If there is no editor, only raise an error if we actually try to use it.
 if not editor:
-    default = default_editors[0]
-    msg  = 'Default text editor, {0}, not found.\n'.format(default)
-    msg += 'Please set the EDITOR environment variable to your preferred '
-    msg += 'text editor, or install {0}.'.format(default)
-    raise EnvironmentError(msg)
+    def editor_not_found(*args, **kwargs):
+        raise EnvironmentError(
+            'No text editor found! Please set the EDITOR environment variable '
+            'to your preferred text editor.')
+    editor = editor_not_found
 
 from spack.package import \
     install_dependency_symlinks, flatten_dependencies, \


Test patch:
Repository: spack/spack

Issue:
BUG: mxml / adios link error
This seems to be related to the pull request https://github.com/LLNL/spack/pull/3696 that I abandoned a few months back, but which has now come back to haunt me.
If I use the current spack setup for adios and mxml, I receive the following error when I try to link against the adios library:

    ld: /home/mol/Software/spack/opt/spack/linux-opensuse42-x86_64/gcc-4.8/mxml-2.10-zxpuyumt66b7ehrlidmcax7li5ekhr6x/lib64/libmxml.a(mxml-attr.o):
    relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
    /home/mol/Software/spack/opt/spack/linux-opensuse42-x86_64/gcc-4.8/mxml-2.10-zxpuyumt66b7ehrlidmcax7li5ekhr6x/lib64/libmxml.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status

Interestingly enough, the adios library is always being built as a `.a`, regardless of +shared, ~shared, whatever.

If I avoid the external mxml library for ADIOS - relying instead on adios' own internal copy - I don't see this issue.
I'll post a commit and pull-request and see if someone can tell me why.
BUG: mxml / adios link error
This seems to be related to the pull request https://github.com/LLNL/spack/pull/3696 that I abandoned a few months back, but which has now come back to haunt me.
If I use the current spack setup for adios and mxml, I receive the following error when I try to link against the adios library:

    ld: /home/mol/Software/spack/opt/spack/linux-opensuse42-x86_64/gcc-4.8/mxml-2.10-zxpuyumt66b7ehrlidmcax7li5ekhr6x/lib64/libmxml.a(mxml-attr.o):
    relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
    /home/mol/Software/spack/opt/spack/linux-opensuse42-x86_64/gcc-4.8/mxml-2.10-zxpuyumt66b7ehrlidmcax7li5ekhr6x/lib64/libmxml.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status

Interestingly enough, the adios library is always being built as a `.a`, regardless of +shared, ~shared, whatever.

If I avoid the external mxml library for ADIOS - relying instead on adios' own internal copy - I don't see this issue.
I'll post a commit and pull-request and see if someone can tell me why.


Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/mxml/package.py b/var/spack/repos/builtin/packages/mxml/package.py
--- a/var/spack/repos/builtin/packages/mxml/package.py
+++ b/var/spack/repos/builtin/packages/mxml/package.py
@@ -48,5 +48,9 @@ def url_for_version(self, version):
             return 'https://github.com/michaelrsweet/mxml/releases/download/release-{0}/mxml-{0}.tar.gz'.format(version)
 
     def configure_args(self):
-        # Default is non-shared, but avoid any future surprises
-        return ['--disable-shared']
+        return [
+            # ADIOS build with -fPIC, so we need it too (avoid linkage issue)
+            'CFLAGS=-fPIC',
+            # Default is non-shared, but avoid any future surprises
+            '--disable-shared',
+        ]


Test patch:
Repository: spack/spack

Issue:
update libdrm version



Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/libdrm/package.py b/var/spack/repos/builtin/packages/libdrm/package.py
--- a/var/spack/repos/builtin/packages/libdrm/package.py
+++ b/var/spack/repos/builtin/packages/libdrm/package.py
@@ -27,13 +27,13 @@
 
 
 class Libdrm(Package):
-    """A userspace  library for  accessing the  DRM, direct
-    rendering  manager, on  Linux,  BSD and  other  operating
-    systems that support the  ioctl interface."""
+    """A userspace library for accessing the DRM, direct rendering manager,
+    on Linux, BSD and other systems supporting the ioctl interface."""
 
     homepage = "http://dri.freedesktop.org/libdrm/"
     url      = "http://dri.freedesktop.org/libdrm/libdrm-2.4.59.tar.gz"
 
+    version('2.4.81', 'dc575dd661a082390e9f1366ca5734b0')
     version('2.4.75', '743c16109d91a2539dfc9cc56130d695')
     version('2.4.70', 'a8c275bce5f3d71a5ca25e8fb60df084')
     version('2.4.59', '105ac7af1afcd742d402ca7b4eb168b6')


Test patch:
Repository: spack/spack

Issue:
New package: quinoa
Fixes quinoacomputing/quinoa#129


Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/quinoa/package.py b/var/spack/repos/builtin/packages/quinoa/package.py
new file mode 100644
--- /dev/null
+++ b/var/spack/repos/builtin/packages/quinoa/package.py
@@ -0,0 +1,65 @@
+##############################################################################
+# Copyright (c) 2017, Los Alamos National Security, LLC
+# Produced at the Los Alamos National Laboratory.
+#
+# This file is part of Spack.
+# Created by Todd Gamblin, tgamblin@llnl.gov, All rights reserved.
+# LLNL-CODE-647188
+#
+# For details, see https://github.com/llnl/spack
+# Please also see the LICENSE file for our notice and the LGPL.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU Lesser General Public License (as
+# published by the Free Software Foundation) version 2.1, February 1999.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the IMPLIED WARRANTY OF
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the terms and
+# conditions of the GNU Lesser General Public License for more details.
+#
+# You should have received a copy of the GNU Lesser General Public
+# License along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+##############################################################################
+
+from spack import *
+
+
+class Quinoa(CMakePackage):
+    """Quinoa is a set of computational tools that enables research and
+       numerical analysis in fluid dynamics. At this time it is a test-bed
+       to experiment with various algorithms using fully asynchronous runtime
+       systems.
+    """
+
+    homepage = "http://quinoacomputing.org"
+    url      = "https://github.com/quinoacomputing/quinoa/tarball/quinoa_v0.1"
+
+    version('develop', git='https://github.com/quinoacomputing/quinoa', branch='master')
+
+    variant('debug', default=False, description='Build debug version')
+
+    depends_on('hdf5+mpi')
+    depends_on("charm backend=mpi")
+    depends_on("trilinos+exodus")
+    depends_on("boost")
+    depends_on("hypre~internal-superlu")
+    depends_on("random123")
+    depends_on("netlib-lapack+lapacke")
+    depends_on("mad-numdiff")
+    depends_on("h5part")
+    depends_on("boostmplcartesianproduct")
+    depends_on("tut")
+    depends_on("pugixml")
+    depends_on("pstreams")
+    depends_on("pegtl")
+
+    root_cmakelists_dir = '../src'
+
+    def build_type(self):
+        spec = self.spec
+        if '+debug' in spec:
+            return 'Debug'
+        else:
+            return 'Release'


Test patch:
Repository: spack/spack

Issue:
problem with xproto
the xproto could be compile properly but while installing, i come across the following problem

```
==> 'make' '-j8'
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-recursive
Making all in specs
Making all in SIAddresses
make[3]: Nothing to be done for `all'.
make[3]: Nothing to be done for `all-am'.
make[2]: Nothing to be done for `all-am'.
==> 'make' '-j8' 'install'
Making install in specs
Making install in SIAddresses
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
make[3]: Nothing to be done for `install-exec-am'.
 /spack/var/spack/stage/xproto-7.0.31-rgclwhmbundqudnhjaavmnvuzceqlgsh/xproto-7.0.31/install-sh -c -d '/spack/opt/spack/darwin-sierra-x86_64/clang-3.9.0/xproto-7.0.31-rgclwhmbundqudnhjaavmnvuzceqlgsh/share/doc/xproto'
 /spack/var/spack/stage/xproto-7.0.31-rgclwhmbundqudnhjaavmnvuzceqlgsh/xproto-7.0.31/install-sh -c -d '/spack/opt/spack/darwin-sierra-x86_64/clang-3.9.0/xproto-7.0.31-rgclwhmbundqudnhjaavmnvuzceqlgsh/share/doc/xproto'
mkdir: /spack/opt/spack/darwin-sierra-x86_64/clang-3.9.0/xproto-7.0.31-rgclwhmbundqudnhjaavmnvuzceqlgsh/share: File exists
mkdir: /spack/opt/spack/darwin-sierra-x86_64/clang-3.9.0/xproto-7.0.31-rgclwhmbundqudnhjaavmnvuzceqlgsh/share/doc: File exists
mkdir: /spack/opt/spack/darwin-sierra-x86_64/clang-3.9.0/xproto-7.0.31-rgclwhmbundqudnhjaavmnvuzceqlgsh/share/doc/xproto: File exists
make[3]: *** [install-dist_shelfDATA] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [install-am] Error 2
make[1]: *** [install-recursive] Error 1
make: *** [install-recursive] Error 1
```


Discussion:
Can you try `spack install -j1 xproto` and see if that works for you?
If that doesn't work, maybe the previous installation left behind some files in the installation prefix and you need to clear them out first.
ah, it worked with `spack install -j1 xproto` 
thanks a lot
I was able to reproduce this as well on macOS, although I couldn't reproduce it on Linux. I'll modify the package to make this more permanent.

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/xproto/package.py b/var/spack/repos/builtin/packages/xproto/package.py
--- a/var/spack/repos/builtin/packages/xproto/package.py
+++ b/var/spack/repos/builtin/packages/xproto/package.py
@@ -43,3 +43,8 @@ class Xproto(AutotoolsPackage):
 
     depends_on('pkg-config@0.9.0:', type='build')
     depends_on('util-macros', type='build')
+
+    def install(self, spec, prefix):
+        # Installation fails in parallel
+        # See https://github.com/LLNL/spack/issues/4805
+        make('install', parallel=False)


Test patch:
Repository: spack/spack

Issue:
m4 does not build with clang
``` bash
spack install m4%clang
```
produces a linker error
```
make[2]: Entering directory `/spack-stage/spack-stage-1tj6uI/m4-1.4.18/spack-build/src'
  CC       m4.o
  CC       builtin.o
  CC       debug.o
  CC       eval.o
  CC       format.o
  CC       freeze.o
  CC       macro.o
  CC       input.o
  CC       output.o
  CC       path.o
  CC       symtab.o
  CCLD     m4
../lib/libm4.a(xmalloc.o): In function `xnmalloc':
spack/var/spack/stage/m4-1.4.18-tdbq4h34ahmclwg3cyzlpg4rnzcefsoz/m4-1.4.18/lib/xmalloc.c:(.text+0x71): undefined reference to `__muloti4'
```

I suspect the build fails to find symbols that otherwise come from libgcc. I tried setting ```LIBS=-lcompiler-rt``` without success.


Discussion:
I've also run into this problem.  My work around is to use the system provided m4 via a `packages.yaml` entry. 
It would probably be best to contact the `m4` developers on this one, I don't think it's a Spack bug.
KineticTheory has a good workaround, however I try to avoid including external packages because it tends to leak other environment information into builds (Python will get confused IIRC)

I found two other workable solutions:
1. In packages, ```depends_on('m4%gcc', type='build')```
2. From CLI, ```spack install software%clang ^m4%gcc```
> 1. In packages, `depends_on('m4%gcc', type='build')`

We definitely don't want to do this. Just because one compiler doesn't work doesn't mean GCC is the only compiler that works.

> 2. From CLI, `spack install software%clang ^m4%gcc`

This is a perfectly fine workaround until someone reports the bug to the `m4` developers and we get it fixed with a patch or new release.
I [reported](https://lists.gnu.org/archive/html/bug-m4/2017-07/msg00003.html) this issue to the m4 development team.  Apparently, the issue is with gnulib (not m4) and the gnulib folks claim that this particular m4@clang compile failure can be resolved by proper installation and use of clang.  See this [LLVM bug report](https://bugs.llvm.org/show_bug.cgi?id=16404), particularly comment 12.

Does anyone want to give their solution a try?


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
@@ -48,6 +48,9 @@ def configure_args(self):
         spec = self.spec
         args = ['--enable-c++']
 
+        if spec.satisfies('%clang') and not spec.satisfies('platform=darwin'):
+            args.append('CFLAGS=-rtlib=compiler-rt')
+
         if '+sigsegv' in spec:
             args.append('--with-libsigsegv-prefix={0}'.format(
                 spec['libsigsegv'].prefix))


Test patch:
Repository: spack/spack

Issue:
Running spack with nohup fails with "...'input_stream' referenced before assignment"
I'm introducing one of my co-workers to Spack.  He uses `nohup` (I'm a tmux-er) and found that my build scripts fail (:scream:) under nohup.

We trimmed it down to a simple test case of creating a one line bash script that runs `spack install ...` and then running that script under `nohup`.

```
[hartzelg@lb097hmdev ~]$ cd tmp
[hartzelg@lb097hmdev tmp]$ git clone git@github.com:llnl/spack   spack-nohup
Cloning into 'spack-nohup'...
remote: Counting objects: 74384, done.
remote: Compressing objects: 100% (83/83), done.
remote: Total 74384 (delta 42), reused 42 (delta 10), pack-reused 74281
Receiving objects: 100% (74384/74384), 26.18 MiB | 9.48 MiB/s, done.
Resolving deltas: 100% (35361/35361), done.
Checking out files: 100% (2538/2538), done.
[hartzelg@lb097hmdev tmp]$ cd spack-nohup/
[hartzelg@lb097hmdev spack-nohup]$ export PATH=`pwd`/bin:$PATH
[hartzelg@lb097hmdev spack-nohup]$ cat > nohup-test.sh
#!/bin/bash
spack install gcc@5.4.0
[hartzelg@lb097hmdev spack-nohup]$ module purge
[hartzelg@lb097hmdev spack-nohup]$ chmod +x ./nohup-test.sh
[hartzelg@lb097hmdev spack-nohup]$ nohup ./nohup-test.sh
nohup: ignoring input and appending output to ‘nohup.out’
[hartzelg@lb097hmdev spack-nohup]$ cat nohup.out
==> Error: local variable 'input_stream' referenced before assignment
==> Installing libsigsegv
[hartzelg@lb097hmdev spack-nohup]$
```

I doubt that this is what *should* be happening.

Is it expected given what Spack's doing to redirect IO and etc?

Can someone sketch a fix?

**Thanks!**


Discussion:
FWIW, this works:

```
nohup ./nohup-test.sh < /dev/null
```


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
@@ -54,6 +54,7 @@
 import inspect
 import multiprocessing
 import os
+import errno
 import shutil
 import sys
 import traceback
@@ -577,8 +578,15 @@ def child_execution(child_connection, input_stream):
     parent_connection, child_connection = multiprocessing.Pipe()
     try:
         # Forward sys.stdin to be able to activate / deactivate
-        # verbosity pressing a key at run-time
-        input_stream = lang.duplicate_stream(sys.stdin)
+        # verbosity pressing a key at run-time.  When sys.stdin can't
+        # be duplicated (e.g. running under nohup, which results in an
+        # '[Errno 22] Invalid argument') then just use os.devnull
+        try:
+            input_stream = lang.duplicate_stream(sys.stdin)
+        except OSError as e:
+            if e.errno == errno.EINVAL:
+                tty.debug("Using devnull as input_stream")
+                input_stream = open(os.devnull)
         p = multiprocessing.Process(
             target=child_execution,
             args=(child_connection, input_stream)


Test patch:
Repository: spack/spack

Issue:
Trouble with variants and hyphens?
Previously, I was able to build *trilinos* against a specific version of *superlu-dist* like this:

```
spack install trilinos+superlu-dist ^superlu-dist@4.3 ^netlib-lapack
```

However, with the current _develop_ branch, I get this error:

```
==> Error: trilinos does not depend on superlu-dist
```

Using `spack info` and reviewing `trilinos/package.py` it is clear that the `+superlu-dist` variant should be available.  I'm wondering if this is broken due to the hyphen in the name.  (I should note that `spack install trilinos+boost ^boost@1.63.0` seems to work.)

Any ideas on why this doesn't work any longer?


Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/trilinos/package.py b/var/spack/repos/builtin/packages/trilinos/package.py
--- a/var/spack/repos/builtin/packages/trilinos/package.py
+++ b/var/spack/repos/builtin/packages/trilinos/package.py
@@ -203,8 +203,8 @@ class Trilinos(CMakePackage):
     # work at the end. But let's avoid all this by simply using shared libs
     depends_on('mumps@5.0:+mpi+shared', when='+mumps')
     depends_on('scalapack', when='+mumps')
+    depends_on('superlu-dist', when='+superlu-dist')
     depends_on('superlu-dist@:4.3', when='@:12.6.1+superlu-dist')
-    depends_on('superlu-dist', when='@12.6.2:+superlu-dist')
     depends_on('superlu-dist@develop', when='@develop+superlu-dist')
     depends_on('superlu-dist@xsdk-0.2.0', when='@xsdk-0.2.0+superlu-dist')
     depends_on('superlu+fpic@4.3', when='+superlu')


Test patch:
Repository: spack/spack

Issue:
Adios2 missing zeromq dependency
@ax3l : I did a normal build without specifying any variants

    Call Stack (most recent call first):
    ..../cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:377 (_FPHSA_FAILURE_MESSAGE)
    cmake/FindZeroMQ.cmake:44 (find_package_handle_standard_args)
    source/dataman/CMakeLists.txt:51 (find_package)




Discussion:
ah, I accidentally removed that in the last rebase!
will add it again asap. (testing...)

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/adios2/package.py b/var/spack/repos/builtin/packages/adios2/package.py
--- a/var/spack/repos/builtin/packages/adios2/package.py
+++ b/var/spack/repos/builtin/packages/adios2/package.py
@@ -77,6 +77,7 @@ class Adios2(CMakePackage):
     # depends_on('pybind11@2.1.1:', when='+python')
 
     depends_on('mpi', when='+mpi')
+    depends_on('zeromq', when='+dataman')
 
     depends_on('hdf5', when='+hdf5')
     depends_on('hdf5+mpi', when='+hdf5+mpi')


Test patch: