* Add latest release 3.0.2
https://www.open-mpi.org/software/ompi/v3.0/:x

Signed-off-by: Daniel Topa <[email protected]>

* Add in library version in comment

…pack#8537)

- All now have both 'ecp' and 'ecp-apps' tags.
- ECP ST projects will eventually also have ecp and ecp-software tags.

* elpa: add 2018.05.001.rc1 and 2017.11.001

* elpa: shift preferred

…k#8449)

* Added minuit package

* Removed default method and template

* Different URLs for old versions

* Patches for versions down to 1.5.0

* Reverted ROOT package changes

* Removed print statement

* Added checksums for older versions

* Consistent version names

To benefit from updates to config.guess for newer architectures.

More info: spack#2063

* ncbi-magicblast: new package

* updated package.py

* updated ncbi-magicblast

…8547)

* Add the grass74 GIS system.

* Correct flake8 errors

* Made requested changes

* added correct types to python

cd /tmp/balay/spack-stage/spack-stage-joxtpr/omega_h-9.13.4/spack-build/src && /home/balay/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/openmpi-3.1.0-7ws4tgx4z3o
ru5g5skjrxs5sobpeiyef/bin/mpic++   -Domega_h_EXPORTS -I/home/balay/spack/var/spack/stage/omega-h-9.13.4-th4b67fz5es6cbgcar742jxamjt3tqjb/omega_h-9.13.4/src -I/tmp/bala
y/spack-stage/spack-stage-joxtpr/omega_h-9.13.4/spack-build/src -I/home/balay/spack/var/spack/stage/omega-h-9.13.4-th4b67fz5es6cbgcar742jxamjt3tqjb/omega_h-9.13.4/tpl
-I/home/balay/spack/opt/spack/linux-ubuntu16.04-x86_64/gcc-5.4.0/zlib-1.2.11-5nus6knzumx4ik2yl44jxtgtsl7d54xb/include  -O2 -g -DNDEBUG -fPIC   -o CMakeFiles/omega_h.di
r/Omega_h_map.cpp.o -c /home/balay/spack/var/spack/stage/omega-h-9.13.4-th4b67fz5es6cbgcar742jxamjt3tqjb/omega_h-9.13.4/src/Omega_h_map.cpp
In file included from /usr/include/c++/5/chrono:35:0,
                 from /home/balay/spack/var/spack/stage/omega-h-9.13.4-th4b67fz5es6cbgcar742jxamjt3tqjb/omega_h-9.13.4/src/Omega_h_timer.hpp:4,
                 from /home/balay/spack/var/spack/stage/omega-h-9.13.4-th4b67fz5es6cbgcar742jxamjt3tqjb/omega_h-9.13.4/src/Omega_h_timer.cpp:1:
/usr/include/c++/5/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
 #error This file requires compiler and library support \
  ^

* Fix [email protected] on OS X 10.13.5

[email protected] failed to build on my OS X 10.13.5 box.

I found/modified a patch in the MacPorts world that traced back to
Homebrewy, https://trac.macports.org/ticket/56502#no1

The issue has also been reported to gcc,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83531

I eventually discovered a nearly identical version of the patch at
Homebrew.

https://github.com/Homebrew/formula-patches/blob/master/gcc%405/10.13_headers.patch

gcc builds with this and I can compile many things, but e.g. curl and
cmake both fail.  As @davydden and others observed in spack#1847, it seems
to be an apple thing.

* Fix mistaken change to patch when clause (added :)

I mistakenly deleted a colon from the
'darwin/gcc-7.1.0-headerpad.patch'.

m4 exited immediately (causing the nettle build to fail).

```
(alice)[11:09:46]spack>>/Users/hartzell/tmp/spack-mac/spack/opt/spack/darwin-highsierra-x86_64/clang-9.1.0-apple/m4-1.4.18-caxsf7l5yd7qbq2bown6bzi5el3ltfwf/bin/m4
Abort trap: 6
(alice)[11:10:18]spack>>fg
```

Tracked down a fix via the Homebrew recipe.  I'll send a note to the
`[email protected]` list to ensure that upstream knows about it.

plasma@develop has another flag 'DHAVE_MKL' that needs to be disabled [for non-mkl build]

add dependency on gcc-6.0

add in new dependency on readline

plasma: requires both LIBS in make.inc and command line?

If cmd line is missing -some internal values from plasma makefile gets used - causing link errors [on Mac]

tools/lua-5.3.4/src/Makefile:   $(MAKE) $(ALL) SYSCFLAGS="-DLUA_USE_LINUX" SYSLIBS="-Wl,-E -lreadline"

if make.inc is missing - I get:

/usr/bin/ld: cannot find -lmkl_intel_lp64
/usr/bin/ld: cannot find -lmkl_sequential
/usr/bin/ld: cannot find -lmkl_core
collect2: error: ld returned 1 exit status

Also add a new dependency -ldl

* petsc: remove dependency on boost - its required only as a dependency on trilinos

Also set COPTFLAGS='' etc - this way CFLAGS is the primary way optimization flags are set by spack

* petsc: update pkgs with petsc~boost dependency

* fix flake8

* boost is optional for trilinos - so adjust petsc dependency on boost [via trilinos] accordingly

* do not add boost dependency on petsc [due to trilinos requirement]. Trilinos adds this dependency anyway.

- I keep typing this based on `spack test -h` and `spack test -H`
- This finally makes my fingers happy

- make list test use SpackCommand
- convert to pytest
- add a test for HTML output

…#8561)

- This complies with the unix directory hierarchy standard (which Spack
  attempts to follow)
- Also unclutters the repo root directory.

…k/test

- removes two files from root of repository
- `spack test` still works fine to run tests

* Add Dockerfile for Scientific Linux 7 (RHEL7 recompile)

- Spack was assuming that a group with gid == current uid would always exist.
- This was breaking the travis build for macos.

- also fix issue with the DB tarball test finding coverage filesx

* Add Dockerfile for Scientific Linux 7 (RHEL7 recompile)

* revert version change

* remove duplicate docker-related files

* 	new file:   var/spack/repos/builtin/packages/py-imageio/package.py

* 	modified:   var/spack/repos/builtin/packages/py-imageio/package.py

* Update package.py

* Add specific version to package verilator

Change-Id: If7645410ec192f92a5eed83ee9b317b569576b4a

* fix dependency types

Change-Id: Ib36c72257c1fa6678c8553225ca21a010d7ae6d1

Functional updates:

- `python` now creates a copy of the `python` binaries when it is added
  to a view

- Python extensions (packages which subclass `PythonPackage`) rewrite
  their shebang lines to refer to python in the view

- Python packages in the same namespace will not generate conflicts if
  both have `...lib/site-packages/namespace-example/__init__.py`

  - These `__init__` files will also remain when removing any package in
    the namespace until the last package in the namespace is removed


Generally (Updated 2/16):

- Any package can define `add_files_to_view` to customize how it is added
  to a view (and at the moment custom definitions are included for
  `python` and `PythonPackage`)

  - Likewise any package can define `remove_files_from_view` to customize
    which files are removed (e.g. you don't always want to remove the
    namespace `__init__`)

- Any package can define `view_file_conflicts` to customize what it
  considers a merge conflict

- Global activations are handled like views (where the view root is the
  spec prefix of the extendee)

  - Benefit: filesystem-management aspects of activating extensions are
    now placed in views (e.g. now one can hardlink a global activation)

  - Benefit: overriding `Package.activate` is more straightforward (see
    `Python.activate`)

  - Complication: extension packages which have special-purpose logic
    *only* when activated outside of the extendee prefix must check for
    this in their `add_files_to_view` method (see `PythonPackage`)

- `LinkTree` is refactored to have separate methods for copying a
  directory structure and for copying files (since it was found that
  generally packages may want to alter how files are copied but still
  wanted to copy directories in the same way)


TODOs (updated 2/20):

- [x] additional testing (there is some unit testing added at this point
  but more would be useful)

- [x] refactor or reorganize `LinkTree` methods: currently there is a
  separate set of methods for replicating just the directory structure
  without the files, and a set for replicating everything

- [x] Right now external views (i.e. those not used for global
  activations) call `view.add_extension`, but global activations do not
  to avoid some extra work that goes into maintaining external views. I'm
  not sure if addressing that needs to be done here but I'd like to
  clarify it in the comments (UPDATE: for now I have added a TODO and in
  my opinion this can be merged now and the refactor handled later)

- [x] Several method descriptions (e.g. for `Package.activate`) are out
  of date and reference a distinction between global activations and
  views, they need to be updated

- [x] Update aspell package activations

the parmetis build system does not install metis.h and libmetis

* Add package tcl-itcl

Change-Id: I0eeaefe0554d0b62614f56204d635e3d8d216e4a

* fix naming

Change-Id: Id8adc7299f41b217b48999304a74827525533598

* and fix name of file accordingly

Change-Id: I0f32f8b66f2695fd99eee4a326353cd5af4aa334

…ike spack will links against system-like spack.

- compiles with newer LLVM.

  The older mesa-17 versions balk at the changes in the llvm::FastMath
  class, where a member function has been removed.

* Update Gotcha and Caliper versions

* caliper: Use spack-built gotcha

* caliper: Enable sampling support on Linux

* More robust check for Linux