We are currently carrying a number of vala versions where each version
is essentially just a copy of the earlier version.
This PR gets rid of a ton of duplication and uses a standard builder.
Secondly, we add a definition for the latest vala 0.34.1.
Lastly, we add a generic "vala" that refers to the latest stable
version.
I have tried changing the definitions for "simple-scan" and "valum" to use
the latest vala version and they at least compile OK so I'll try a
massive sed job to replace all the definitions later to simply use the
latest version through "vala" instead of specifying a version directly.
According to upstream:
"Well-maintained packages are expected to always build with the latest
stable Vala version."
Maybe this means that my generic builder is then no longer necessary. Oh well...
I added myself to the maintainer array for vala although I have no
interest in the language - this was purely a nix exercise for me but I
thought it was reasonable to be the one to clean up the mess if this has
side effects...
Cc: @antono and @lethalman
This reinstates the libSystem selective symbol export machinery we used
to have, but locks it to the symbols that were present in 10.11 and skips
the actual compiled code we put into that library in favor of the system
initialization code. That should make it more stable and less likely to
do weird stuff than the last time we did this.
This makes it easy to specify kernel patches:
boot.kernelPatches = [ pkgs.kernelPatches.ubuntu_fan_4_4 ];
To make the `boot.kernelPatches` option possible, this also makes it
easy to extend and/or modify the kernel packages within a linuxPackages
set. For example:
pkgs.linuxPackages.extend (self: super: {
kernel = super.kernel.override {
kernelPatches = super.kernel.kernelPatches ++ [
pkgs.kernelPatches.ubuntu_fan_4_4
];
};
});
Closes #15095