Since the exposure of the version attribute done in
892a0e8ff4, the OpenBLAS build fails for
i686-linux:
https://nix-cache.s3.amazonaws.com/log/wi79zyfmwdpwx7bm29dzqh4vglx3x550-openblas-0.3.0.drv
According to @edolstra the build slaves of Hydra updated to a new
kernel, which seems to be the real cause for this issue. The latter is
already tracked upstream[1] and a fix[2] is already included in version
0.3.1.
This very update cases 4795 rebuilds across all architectures we
support, so it's still not significant enough to go through staging. In
addition the number of rebuilds doesn't include the amount of builds
that are currently failing.
My original idea was to add a patch just for fixing this on i686-linux
and do the real update via staging, but the amount of rebuilds still is
in an acceptable range IMO and @edolstra agreed on that on IRC.
[1]: https://github.com/xianyi/OpenBLAS/issues/1575
[2]: https://github.com/xianyi/OpenBLAS/pull/1583
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @ttuegel
* pkgs: refactor needless quoting of homepage meta attribute
A lot of packages are needlessly quoting the homepage meta attribute
(about 1400, 22%), this commit refactors all of those instances.
* pkgs: Fixing some links that were wrongfully unquoted in the previous
commit
* Fixed some instances
Attempting to build openblas on ARM resulted in the error "unsopported system: armv7l_linux". This PR resolves that issue and some other issues that pop up when trying to build openblas for ARM.
Without this one gets a lot of build time warnings like:
ld: warning: object file (/tmp/strip.2OzFn8) was built for newer OSX
version (10.9) than being linked (10.7)
The `f_check` script uses `which` to check that the Fortran compiler is
available. `which` is a shell built-in on NixOS, but not on Darwin or
other Linuxes.
Upstream began shipping OpenBLAS with LAPACK 3.4.1. This is the version
we were using in Nixpkgs anyway, so there is no reason to continue
copying the LAPACK sources into the build tree.
