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>
This patch does a lot of cleanup on the kernel expressions to make them
easier to maintain and streamline them for the future.
Really, we shouldn't have 30 different kernels under the sun with 20
various versions of each and random patches for them all. We should
officially have, like, a handful of versions, at best, with supported
configurations and guidelines. Ideally, simply the latest
mainline/testing as well as the most recent -stable branch - which is
exactly what this patch does. Including any needed patches.
The writing was pretty much on the wall for this one, honestly. Post
kernel 4.1, we're likely to move to kdbus, which will quickly mean
dropping support for older kernels in systemd. Plus, there really
*isn't* a need for things like the 3.2 or 3.4 kernel, even if they're
technically still mainline. These were part of old NixOS releases months
ago; there's little reason to hang on.
Finally, random experiments in the tree (MIPS FPU patches, TuxOnIce,
xsave, etc) are fun to commit, but ultimately not very fun to maintain
as very few people are going to test them at all, they're probably
broken with newer kernels (several of these were commited 2-3 years
ago), and it's unclear what benefit we get from building them when
nobody (or like 2 people, which is below epsilon) uses it.
Now, if we include our own patches that *users are likely to use*, *are
on by default* and *broadly useful*, that's probably a different story.
For example, I have a WIP patch to add a switch to randomize MAC
addresses via a kernel patch when an interface goes online, without the
need for macchanger. You can simply flip it on and off. This patch isn't
upstream, and its value in the default build is arguable - but is still
probably more useful to NixOS users than what we have now. Another
example is the BFQ scheduler patches, which could be broadly useful.
This dramatically simplifies keeping the kernels up to date, relieves
Hydra of a lot of packages it otherwise needed to build, and makes the
world a more pleasurable place to live.
In detail:
- Get rid of all old -stable kernels, including 3.{2,4,10,12,14}.
- Remove apparmor patches, as they're no longer needed post 3.6+.
- Remove xsave, crc-regression, TuxOnIce and MIPS patches.
- Tighten up patches.nix, and put patches back under a ./patches dir.
- Drop old perf patches, and old linux.upstream.template
If anyone wants to recover these features, they can do so: by adding
them to their own system derivations or forks, which is where a lot of
this belonged in the first place.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This was untested and didn't function without a dbus patch which wasn't
applied to the system dbus package, so it wasn't used at all.
Also, it creates a weird cyclic dependency if we want systemd to depend
on libapparmor (for AppArmorProfiles= support), because libapparmor then
wants dbus, and dbus wants systemd. Oof.
Luckily, this feature and whatnot will probably all be irrelevant in the
glorious kdbus-based future, and the dbus patches aren't even upstream I
think. So we can just drop it.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
