This is less brittle and breaks loud if the code changes.
Also remove the /usr/bin/file patch. It is not really required
for the build to work, the generated warning is harmless.
* Replace LD_LIBRARY_PATH with OS-specific name (e.g. DYLD_LIBRARY_PATH
on macOS).
* Disable Python tests on macOS, because they use gpg, which fails due
to a very long socket path (https://github.com/NixOS/nix/pull/1085).
The former should be fixed upstream. The latter is a Nix-specific issue,
but it can be worked-around upstream by making Python tests respect
--disable-gpg-test.
* pythonPackages.matplotlib: add veprbl to maintainers
* pythonPackages.matplotlib: remove an old darwin hack
* pythonPackages.matplotlib: remove python and stdenv from buildInputs
* python3Packages.matplotlib: remove a hack for python33
* pythonPackages.matplotlib: remove outdated checkPhase
Downloading the baseline_images is not a real issue, building against
older freetype (local_freetype = True) is, perhaps, not what we
want. The good news is that the tests would pass (tested on 3.2.1) if
we were to enable them:
========== 6684 passed, 1332 skipped, 10 xfailed in 228.64s (0:03:48) ==========
* pythonPackages.matplotlib: provide setup.cfg from a file instead of a patch
* python3Packages.matplotlib: 3.1.3 -> 3.2.1
This is a better name since we have multiple 64-bit things that could
be referred to.
LP64 : integer=32, long=64, pointer=64
ILP64 : integer=64, long=64, pointer=64
Only the actual shared libraries are required to be installed, and they
are imported directly by path via ctypes. The package's patchPhase
already takes care of embedding the Nix store paths of the required
libraries into pyopengl.
This reduces the transitive closure size of PyOpenGL: 622M -> 136M.
Context: discussion in https://github.com/NixOS/nixpkgs/pull/82630
Mesa has been supporting S3TC natively without requiring these libraries
since the S3TC patent expired in December 2017.
This partially reverts commit cc03fb4210.
The libtorrentRasterbar update broke deluge 1.x, the hash was not
updated and obsolete dependencies and flags were not removed.
This makes packages use lapack and blas, which can wrap different
BLAS/LAPACK implementations.
treewide: cleanup from blas/lapack changes
A few issues in the original treewide:
- can’t assume blas64 is a bool
- unused commented code
This is based on previous work for switching between BLAS and LAPACK
implementation in Debian[1] and Gentoo[2]. The goal is to have one way
to depend on the BLAS/LAPACK libraries that all packages must use. The
attrs “blas” and “lapack” are used to represent a wrapped BLAS/LAPACK
provider. Derivations that don’t care how BLAS and LAPACK are
implemented can just use blas and lapack directly. If you do care what
you get (perhaps for some CPP), you should verify that blas and lapack
match what you expect with an assertion.
The “blas” package collides with the old “blas” reference
implementation. This has been renamed to “blas-reference”. In
addition, “lapack-reference” is also included, corresponding to
“liblapack” from Netlib.org.
Currently, there are 3 providers of the BLAS and LAPACK interfaces:
- lapack-reference: the BLAS/LAPACK implementation maintained by netlib.org
- OpenBLAS: an optimized version of BLAS and LAPACK
- MKL: Intel’s unfree but highly optimized BLAS/LAPACK implementation
By default, the above implementations all use the “LP64” BLAS and
LAPACK ABI. This corresponds to “openblasCompat” and is the safest way
to use BLAS/LAPACK. You may received some benefits from “ILP64” or
8-byte integer BLAS at the expense of breaking compatibility with some
packages.
This can be switched at build time with an override like:
import <nixpkgs> {
config.allowUnfree = true;
overlays = [(self: super: {
lapack = super.lapack.override {
lapackProvider = super.lapack-reference;
};
blas = super.blas.override {
blasProvider = super.lapack-reference;
};
})];
}
or, switched at runtime via LD_LIBRARY_PATH like:
$ LD_LIBRARY_PATH=$(nix-build -E '(with import <nixpkgs> {}).lapack.override { lapackProvider = pkgs.mkl; is64bit = true; })')/lib:$(nix-build -E '(with import <nixpkgs> {}).blas.override { blasProvider = pkgs.mkl; is64bit = true; })')/lib ./your-blas-linked-binary
By default, we use OpenBLAS LP64 also known in Nixpkgs as
openblasCompat.
[1]: https://wiki.debian.org/DebianScience/LinearAlgebraLibraries
[2]: https://wiki.gentoo.org/wiki/Blas-lapack-switch
This closes#79441.
ghcWithPackages is using `ghc-pkg recache` to build its package
database. By doing so, it overrides the `package.cache[.lock]` files.
Details are unclear, but GHC 8.10 changed a bit the behavior.
Previously, it was unconditionally replacing the files by new ones. Now
it tries to open (for modification) the files. These files are symlinks
to another nix derivation, which is hence read-only.
This commit removes the files before running `ghc-pkg recache`, hence it
will just write the new files.
Tested with `haskellPackages.ghcWithPackages` (i.e. GHC 8.8) and
`haskell.packages.ghc8101.ghcWithPackages` (i.e GHC 8.10) with the
following nix file, at the root of the nixpkgs repository:
```
with import ./. {
overlays = [
(
self: super: {
haskellPackages = super.haskell.packages.ghc8101.override {
overrides = selfh: superh: {
th-lift-instances = super.haskell.lib.doJailbreak superh.th-lift-instances;
th-expand-syns = super.haskell.lib.doJailbreak superh.th-expand-syns;
th-reify-many = super.haskell.lib.doJailbreak superh.th-reify-many;
th-orphans = super.haskell.lib.doJailbreak superh.th-orphans;
haskell-src-meta = super.haskell.lib.doJailbreak superh.haskell-src-meta;
};
};
}
)
];
};
haskellPackages.ghcWithPackages(p:[p.PyF])
```
This will test with GHC 8.10. Comment out the `overlays` to test with
GHC 8.8.
* ghcHEAD: bump to 8.11.20200403
* ghcHead: reduce diff vs. 8.10.1
dontAddExtraLibs was removed by accident (IMO) in ea19a8ed1e
* ghcHEAD: add ability to use system libffi
- enable nixpkgs' libffi
- minimise diffs against 8.10.1
- remove patching
* remove configure warning about --with-curses-includes
configure: WARNING: unrecognized options: --with-curses-includes
This is to fix a regression in upstream Racket packaging, the upstream
bug tracking this is here:
https://github.com/racket/racket/issues/3046
When the bug is fixed this workaround will be unnecessary.
