Move icoutils from buildInputs to nativeBuildInputs because it is a
compile time dependency.

https://git.sr.ht/~sircmpwn/core.sr.ht/commit/61c730191c5387d42e2f9910ec5422a236d81121

https://git.sr.ht/~sircmpwn/sr.ht-pkgbuilds/commit/73600466cc9c3911643961c559d1047d137602b2

FTP is often blocked by firewalls and is generally slower and less secure than HTTPS.

No change to `src` hash.

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 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

Add some ability to test the different BLAS/LAPACK implementations
together.

Add a simple hook that makes sure blas and lapack are linked to the
right place.

This is unfree.

systemfd: init at 0.3.0

Add BLAS/LAPACK switching mechanism

mesa-glu: use HTTPS instead of FTP

https://github.com/mikefarah/yq/releases/tag/3.3.0

fwupdate: Clean up -I flags

…2.1 -> 4.2.2"

This partially reverts commit cc03fb4.
The libtorrentRasterbar update broke deluge 1.x, the hash was not
updated and obsolete dependencies and flags were not removed.

https://raw.githubusercontent.com/arvidn/libtorrent/libtorrent-1_2_5/ChangeLog

The old release is kept available as libtorrentRasterbar-1_1_x for deluge 1.x.

* 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.

yq-go: 3.2.1 -> 3.3.0

Signed-off-by: Markus S. Wamser <github-dev@mail2013.wamser.eu>

packet-cli: init at 0.0.6

blas: fix build

ghidra: 9.1 -> 9.1.2

sourcehut: 2020.04.16

treewide: Get rid of -dumpmachine in favor of static info

NixOS/nixpkgs@16a4332#diff-43de86228df91216c5cfc9446cb041feL249