This includes several enhancements in the underlying compiler, including
codegen improvements for AVX-512, Ice Lake CPU definitions,
cross-{arch,os} compilation (currently unsupported due to multilib
issues), and more.
This also bumps the LLVM backend to the 10.0 release. Note that ispc
itself requires a few extra stability patches on top of 10.0 for AVX-512
support, but these aren't applied for us. Therefore AVX-512 still has
some extra, rough edges.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
The package was marked as broken for 3 years, there were no
upstream updates for 8 years, and the program requires third
party services that don't provide APIs to work. I think it's
safe to say that this program is not going to work.
This implements the override pattern for builds done with buildEnv, so
that we can, for example, write
php.override { fpmSupport = false; }
and get a PHP package with the default extensions enabled, but PHP
compiled without fpm support.
This will avoid breaking the build whenever a non-major kernel update
happens. In the update script, we map each kernel version to the latest
patch for the latest kernel version less than or equal to what we
have packaged.
Previously, callPackage would try and fill the arguments such as `name`
and `src` which would cause problems if those existed as top-level
attributes. This also makes it clearer what part is the function
signature.
Then document the derivation inline in the code to explain the ellipsis
and various use-cases.
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.
* let's try 2.0 version now, no time better than the present! Maybe!
* bz2 -> xz
* maybe python3
* disable pyGtkGlade for deps, maybe not needed?
* fix gtk/etc deps, deluge-gtk works! \o/
* restore installation of images and such
The old version is kept available as some torrent trackers have not
updated their whitelists yet.
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 is an updated version of the former upstream,
https://github.com/AndroidHardeningArchive/linux-hardened, and provides
a minimal set of additional hardening patches on top of upstream.
The patch already incorporates many of our hardened profile defaults,
and releases are timely (Linux 5.5.15 and 5.6.2 were released on
2020-04-02; linux-hardened patches for them came out on 2020-04-03 and
2020-04-04 respectively).
