Change:
<ins> {lib, python, buildPythonPackage, isPyPy, gfortran, nose}: args: let inherit (args) version; inherit (args) numpy; in buildPythonPackage (args // rec { name = "scipy-${version}"; buildInputs = (args.buildInputs or [ gfortran nose ]); propagatedBuildInputs = (args.propagatedBuildInputs or [ passthru.blas numpy]); preConfigure = '' sed -i '0,/from numpy.distutils.core/s//import setuptools;from numpy.distutils.core/' setup.py ''; preBuild = '' echo "Creating site.cfg file..." cat << EOF > site.cfg [openblas] include_dirs = ${passthru.blas}/include library_dirs = ${passthru.blas}/lib EOF ''; checkPhase = '' runHook preCheck pushd dist ${python.interpreter} -c 'import scipy; scipy.test("fast", verbose=10)' popd runHook postCheck ''; passthru = { blas = numpy.blas; }; setupPyBuildFlags = [ "--fcompiler='gnu95'" ]; meta = { description = "SciPy (pronounced 'Sigh Pie') is open-source software for mathematics, science, and engineering. "; homepage = http://www.scipy.org/; maintainers = with lib.maintainers; [ fridh ]; } // (args.meta or {}); }) </ins>

Discussion:
But we cannot upgrade to openblas 0.2.15 either, due to runtime issues (segfault?). Possible fix is to package the openblas 'develop' branch. See discussions: CC
Did you try with 2.15 yourself? We could also go back to Atlast + Lapack. It would mean changing and the same line in . And of course
I just built numpy with openblas 0.2.15 and did . Nothing more. (numpy is just being pulled in as a dependency on my system, I don't really have any specific use for it at the moment.) If upstream makes a new release in a week, I can wait for that.
Good. I think we do need to have a solution for the new stable.
They put out an RC:
I'm now testing the RC. , do you know whether would hide processor information?
I'm pretty sure it doesn't.
Evaluation with openblas 0.2.15: Evaluation with openblas 0.2.16.rc1: We get a segfault with scikitlearn when using 0.2.15, but not anymore with 0.2.16.rc1. , could you try building the current PR?
That is, this one
I've evaluated numpy/scipy/scikitlearn without issues using openblas 0.2.17. See
Because we use openblas 0.2.17 now I am closing this.

When I try to install openblas I get following failure:
Are you building with chroot environments enabled or disabled?
I'm not sure if I'm building with chroot environments enabled or disabled, how could I figure out? I've installed the nix package manager on an ubuntu install to manage packages with nix.
What does your file say?
I don't have an My is here:
If you don't have it, then the builds should be non-chrooted. Anyway, that's the most likely explanation why it succeeds on Hydra and not for you (we could still fix it, but it's not a high priority for me as chrooting solves many problems).
'Detecting CPU failed' happened to me as well, on a machine with intel broadwell CPU. I made an upstream issue and was told to build from their 'develop' branch (I don't think they use 'master'). The develop branch worked. We should prod them to make a new release.
This is not currently affecting me.
This is still an issue for nix installations outside of /nix (which seem unchrootable). Explicitly adding TARGET=NEHALEM just like in the travis build seems to work: