gcc 9.3.0 and glibc 2.31 (found in the base install of Ubuntu 20.04)
cause the gcc package to error during build with the error:
"size of array 'assertion_failed__####' is negative"
Previous to this fix, the error was resolved for v8.1.0 <= gcc <= v9.2.0
via two patches.
This fix backports those patches for v5.3.0 <= gcc <= v7.4.0
Potentially these patches need to be backported to versions of gcc
before v5.3.0, but other compile issues need to be resolved for earlier
versions of gcc first.
Fixes#16968
* intel-tbb: Fix for #16938 add custom libs method
Override the libs method to look for libraries of form libtbb*
(instead of inherited which looks for libintel-tbb*)
* Fixing pre-existing flake8 issues
* py-flake8: add version 3.8.2
* This version depends on different versions of py-pycodestyle
and py-pyflakes
* When built for python@:3.7, this depends on the
py-importlib-metadata backport library
* py-pycodestyle: add version 2.6.0
* py-pyflakes: add version 2.2.0
Builds can be stopped before the final install phase due to user requests. Those builds
should not be registered as installed in the database.
We had code intended to handle this but:
1. It caught the wrong type of exception
2. We were catching these exceptions to suppress them at a lower level in the stack
This PR allows the StopIteration to propagate through a ChildError, and catches it
properly. Also added to an existing test to prevent regression.
This fixes a fork bomb in `spack versions`. Recursive generation of pools
to scrape URLs in `_spider` was creating large numbers of processes.
Instead of recursively creating process pools, we now use a single
`ThreadPool` with a concurrency limit.
More on the issue: having ~10 users running at the same time spack
versions on front-end nodes caused kernel lockup due to the high number
of sockets opened (sys-admin reports ~210k distributed over 3 nodes).
Users were internal, so they had ulimit -n set to ~70k.
The forking behavior could be observed by just running:
$ spack versions boost
and checking the number of processes spawned. Number of processes
per se was not the issue, but each one of them opens a socket
which can stress `iptables`.
In the original issue the kernel watchdog was reporting:
Message from syslogd@login03 at May 19 12:01:30 ...
kernel:Watchdog CPU:110 Hard LOCKUP
Message from syslogd@login03 at May 19 12:01:31 ...
kernel:watchdog: BUG: soft lockup - CPU#110 stuck for 23s! [python3:2756]
Message from syslogd@login03 at May 19 12:01:31 ...
kernel:watchdog: BUG: soft lockup - CPU#94 stuck for 22s! [iptables:5603]
Stratimikos is an optional dependency for our project. It depends on
Thyra, and thyra has subpackages that should be enabled based on
tpetra/epetra/epetraext.
* gnuplot: Fix for #16928
Dependency for --with-wx flag mistyped (should be wxwidgets)
* Revert "gnuplot: Fix for #16928"
This reverts commit 2b85814e5ccf5c9b2c70c7959994e89c18fdc3d8.
* gnuplot: Fix for #16928
Dependency spec for --with-wx flag mistyped (should be wxwidgets, not
wx)
* add an --exclude-file option to 'spack mirror create' which allows a user to specify a file of specs to exclude when creating a mirror. this is anticipated to be useful especially when using the '--all' option
* allow specifying number of versions when mirroring all packages
* when mirroring all specs within an environment, include dependencies of root specs
* add '--exclude-specs' option to allow user to specify that specs should be excluded on the command line
* add test for excluding specs
fixes#12527
Mention that specs can be uninstalled by hash also in
the help message. Reference `spack gc` in case people
are looking for ways to clean the store from build time
dependencies.
Use "spec" instead of "package" to avoid ambiguity in
the error message.
