The first release in the 4.9 branch.
I've also migrated my update scripts to SHA-512 so that'll
be the hash of choice for grsec packages going forward.
The callCabal2nix function cannot reliably determine the appropriate "name" for
the package it's processing. Attempts to derive this information have led to
plenty of evaluation errors, and so I'd like to go for the obvious and reliable
solution now and let the caller specify that bit of information.
Here is an example that demonstrates how to use callCabal2nix.
let
pkgs = import <nixpkgs> {};
src = pkgs.fetchFromGitHub {
owner = "gtk2hs";
repo = "gtk2hs";
rev = "eee61d84edf1dd44f8d380d7d7cae2405de50124";
sha256 = "12i53grimni0dyjqjydl120z5amcn668w4pfhl8dxscjh4a0l5nb";
};
in
pkgs.haskellPackages.callCabal2nix "gtkhs-tools" "${src}/tools" {}
This fixes the "sliding window" principle:
0. Run packages: build = native; host = foreign; target = foreign;
1. Build packages: build = native; host = native; target = foreign;
2. Vanilla packages: build = native; host = native; target = native;
3. Vanilla packages: build = native; host = native; target = native;
n+3. ...
Each stage's build dependencies are resolved against the previous stage,
and the "foreigns" are shifted accordingly. Vanilla packages alone are
built against themsevles, since there are no more "foreign"s to shift away.
Before, build packages' build dependencies were resolved against
themselves:
0. Run packages: build = native; host = foreign; target = foreign;
1. Build packages: build = native; host = native; target = foreign;
2. Build packages: build = native; host = native; target = foreign;
n+2. ...
This is wrong because that principle is violated by the target
platform staying foreign.
This will change the hashes of many build packages and run packages, but
that is OK. This is an unavoidable cost of fixing cross compiling.
The cross compilation docs have been updated to reflect this fix.
