Change:
<ins> {lib, python, buildPythonPackage, isPyPy, gfortran, nose, blas}: args: let inherit (args) version; in buildPythonPackage (args // rec { name = "numpy-${version}"; disabled = isPyPy; buildInputs = args.buildInputs or [ gfortran nose ]; propagatedBuildInputs = args.propagatedBuildInputs or [ passthru.blas ]; preConfigure = '' sed -i 's/-faltivec//' numpy/distutils/system_info.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 numpy; numpy.test("fast", verbose=10)' popd runHook postCheck ''; passthru = { blas = blas; }; # The large file support test is disabled because it takes forever # and can cause the machine to run out of disk space when run. prePatch = '' sed -i 's/test_large_file_support/donttest/' numpy/lib/tests/test_format.py ''; meta = { description = "Scientific tools for Python"; homepage = "http://numpy.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: