Change:
}; }; <del> numpy = let support = import ../development/python-modules/numpy-scipy-support.nix { inherit python; openblas = pkgs.openblasCompat; pkgName = "numpy"; }; in buildPythonPackage ( rec { name = "numpy-${version}"; version = "1.10.4"; </del> <ins> buildNumpyPackage = callPackage ../development/python-modules/numpy.nix { gfortran = pkgs.gfortran; blas = pkgs.openblasCompat_2_14; }; numpy = self.numpy_1_10; numpy_1_10 = self.buildNumpyPackage rec { version = "1.10.4"; </ins> src = pkgs.fetchurl { <del> url = "https://pypi.python.org/packages/source/n/numpy/${name}.tar.gz"; </del> <ins> url = "https://pypi.python.org/packages/source/n/numpy/numpy-${version}.tar.gz"; </ins> sha256 = "7356e98fbcc529e8d540666f5a919912752e569150e9a4f8d869c686f14c720b"; }; <del> disabled = isPyPy;  # WIP preConfigure = '' sed -i 's/-faltivec//' numpy/distutils/system_info.py ''; inherit (support) preBuild checkPhase; buildInputs = [ pkgs.gfortran self.nose ]; propagatedBuildInputs = [ support.openblas ]; # Disable failing test_f2py test. # f2py couldn't be found by test, # even though it was used successfully to build numpy # 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_f2py/donttest/' numpy/tests/test_scripts.py 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/"; }; }); </del> <ins> }; </ins> numpydoc = buildPythonPackage rec { name = "numpydoc-${version}";

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: