26fa60ac55
Nota bene: this probably does not work! Caveat emptor, etc.
This inverts the grsecurity builder, making it much simpler. Instead,
users just give a full description of the type of kernel they want to
build, and the result is an attribute set containing kernel and
kernelPackages results.
Now, in order to build a custom grsecurity kernel, you do something more
like:
let
kver = "4.0.4";
grver = "3.1-${kver}-201505222222";
kernel = rec
{ version = kver;
localver = "-grsec";
src = fetchurl rec {
name = "linux-${kver}.tar.xz";
url = "mirror://kernel/linux/kernel/v4.x/${name}.tar.xz";
sha256 = "1j5l87z6gd05cqzg680id0x1nk38kd6sjffd2lifl0fz5k6iqr9h";
};
};
patches =
[ fetchurl rec {
name = "grsecurity-${grver}.patch";
url = "https://grsecurity.net/test/grsecurity-${grver}.patch";
sha256 = "0ampby10y3kr36f7rvzm5fdk9f2gcfmcdgkzf67b5kj78y52ypfz";
}
];
customGrsecKern = customGrsecKernelPackages { inherit kernel patches; };
in
{
...
boot.kernelPackages = customGrsecKern.kernelPackages;
}
Which is far more flexible and easier to think about; plus, it gives
full control over the kernel localver and modDirVer, as well as support
for other patches (because you may have other patches to apply on-top of
grsec, or you may bundle grsec with some other distribution, and still
need the builder support.) It also gives you full control of the kernel
tarball, in case you want to use e.g. libre-linux.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
||
|---|---|---|
| .. | ||
| applications | ||
| build-support | ||
| data | ||
| desktops | ||
| development | ||
| games | ||
| misc | ||
| os-specific | ||
| servers | ||
| shells | ||
| stdenv | ||
| test | ||
| tools | ||
| top-level | ||