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).
The v7 series is very different.
This commit introduces the 3 packages: fahclient, fahcontrol and
fahviewer. It also rebuilds the NixOS module to map better with the new
client.
* source-han-sans: 1.004R -> 2.001
* source-han-serif: switch to Super OTC
* source-han-mono: init at 1.002
The Source Han fonts now use shared package infrastructure, and the
Super OTC distributions, which unify the various scripts into a single
bundle file, improving automatic font selection and reducing overall
disk space usage. This also means that the Traditional
Chinese—Hong Kong language variant is now included.
The old package names including language are aliased to the Super OTC
bundle packages.
According to https://endoflife.software/programming-languages/server-side-scripting/ruby
ruby 2.4 will go end-of-life in march, where the new release of nixpkgs
will be cut. We won't be able to support it for security updates.
Remove all references to ruby_2_4 and add ruby_2_7 instead where
missing.
Mark packages that depend on ruby 2.4 as broken:
* chefdk
* sonic-pi
Package is marked as broken for >2 years and used a fairly old
snapshot from the gcc7-branch, so I fairly doubt that this is
somewhere used (and is also pretty misleading as you don't expect a
random snapshot from gcc7 at `pkgs.gcc-snapshot`).
There are no new releases of sqldeveloper v17/v18 and I don't think that
we should keep obviously unmaintained software that interacts with
database systems.
I removed `sqldeveloper_18` and `pkgs.sqldeveloper` now points to
version 19.4. Unfortunately I had to drop darwin support as JavaFX is
required for 19.4 which is part of the `oraclejdk` which isn't packaged
for darwin yet.
For further information please refer to the release notes:
https://www.oracle.com/technetwork/developer-tools/sql-developer/downloads/sqldev-relnotes-194-5908846.html
See u-boot@8fa7f65dd02c176ee6021eaf40114560b8954ba2
> configs: Remove am335x_boneblack_defconfig
>
> The am335x_evm_defconfig supports all am335x_boneblack variants. Remove
> the redundant am335x_boneblack_defconfig.
On numerous occasions I have seen users mistake this
module as libinput because it being called "multitouch"
and them being unaware that the actually module they want
is libinput. They then run into several decrepit bugs due
to the completely out-of-date nature of the underlying package.
The underlying package hasn't been changed to an up-to-date
fork in a period of 8 years. I don't consider this to be production quality.
However, I'm not opposed for the module being readded to NixOS
with new packaging, and a better name.
These are all based on firefox versions with known vulnerabilities
exploited in the wild.
We seriously shouldn't ship this in nixpkgs, especially not for
sensitive applications as the Tor Browser.
`tor-browser-bundle` is just a wrapper around
`firefoxPackages.tor-browser`, so let's remove it too.
`tor-browser-bundle-bin` is the much safer bet, which is individually
downloaded from `dist.torproject.org` and just `patchelf`-ed locally to
work on NixOS.
Co-Authored-By: Alyssa Ross <hi@alyssa.is>
Co-Authored-By: Andreas Rammhold <andreas@rammhold.de>
Co-Authored-By: Graham Christensen <graham@grahamc.com>
make unstable use kicad-libraries
still using a link in $out..., not sure that's a bad thing
this allows setting that path in makeWrapperArgs
can't use $out there
kicad-with-packages3d -> kicad and kicad-small
default to OCCT, OCE is outdated
enforce OCCT on aarch64, where OCE is broken
withOCE flag allows using OCE on non-aarch64
People have only been using this for the spell-entry widget, i.e even
hexchat just has the code vendored and are maintaining it themselves.
There is a continuation that could be packaged if anyone needs it
* https://github.com/TingPing/libsexy3
but currently no package within nixpkgs has a use for this.
This package actually uses the old abandoned code base.
However the code base has been revieved by new maintainers
* https://github.com/projecthamster/
if there is a request for it could be re-added to nixpkgs.
