Change:
<ins> { stdenv, fetchurl, gfortran, perl, which, config, coreutils # Most packages depending on openblas expect integer width to match pointer width, # but some expect to use 32-bit integers always (for compatibility with reference BLAS). , blas64 ? null }: with stdenv.lib; let blas64_ = blas64; in let local = config.openblas.preferLocalBuild or false; binary = { i686-linux = "32"; x86_64-linux = "64"; x86_64-darwin = "64"; }."${stdenv.system}" or (throw "unsupported system: ${stdenv.system}"); genericFlags = [ "DYNAMIC_ARCH=1" "NUM_THREADS=64" ]; localFlags = config.openblas.flags or optionals (hasAttr "target" config.openblas) [ "TARGET=${config.openblas.target}" ]; blas64 = if blas64_ != null then blas64_ else hasPrefix "x86_64" stdenv.system; version = "0.2.14"; in stdenv.mkDerivation { name = "openblas-${version}"; src = fetchurl { url = "https://github.com/xianyi/OpenBLAS/archive/v${version}.tar.gz"; sha256 = "2411c4f56f477b42dff54db2b7ffc0b7cf53bb9778d54982595c64cc69c40fc1"; name = "openblas-${version}.tar.gz"; }; inherit blas64; nativeBuildInputs = optionals stdenv.isDarwin [coreutils] ++ [gfortran perl which]; makeFlags = (if local then localFlags else genericFlags) ++ optionals stdenv.isDarwin ["MACOSX_DEPLOYMENT_TARGET=10.9"] ++ [ "FC=gfortran" # Note that clang is available through the stdenv on OSX and # thus is not an explicit dependency. "CC=${if stdenv.isDarwin then "clang" else "gcc"}" ''PREFIX="''$(out)"'' "BINARY=${binary}" "USE_OPENMP=${if stdenv.isDarwin then "0" else "1"}" "INTERFACE64=${if blas64 then "1" else "0"}" ]; doCheck = true; checkTarget = "tests"; meta = with stdenv.lib; { description = "Basic Linear Algebra Subprograms"; license = licenses.bsd3; homepage = "https://github.com/xianyi/OpenBLAS"; platforms = platforms.unix; maintainers = with maintainers; [ ttuegel ]; }; } </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: