Right now, hashes for 4.14 are kept (and thus also maintained by the
hardened updater) even though we don't support that anymore, the oldest
supported branch is 4.19.
To avoid having to remember too many places where to drop a kernel when
dropping an old one (next will be 4.19), the oldest kernel branch will
be determined by the lowest version number in the keys of
`kernels-org.json`. That way, it's sufficient to drop an old branch
from this file and it will be ignored on the upcoming update runs.
Yes, the code to read from that file is duplicated, but I'd expect the
min version to change way more often than 3 lines of code reading a
version from a JSON file[1].
The logic is fairly simple though: if the branch (i.e. MAJOR.MINOR) of a
kernel that's listed on kernel.org[2] is older than the oldest version
in `kernels-org.json`, it's omitted on update and a message is printed
like this:
[...]
linux_5_4: 5.4.265 is latest, skipping...
linux_4_19: 4.19.303 is latest, skipping...
4.14 is too old and not supported anymore, skipping...
Kernels that have the branch `testing` are excluded from that check and
always allowed.
[1] Also, I'm unhappy already that I can't just do a relative import in
here to deduplicate the function and for 3 lines of code it seems
like unnecessarily much effort to create a python package structure
here.
[2] Kernels that got unlisted there are too old to be added/kept here
anyways.
This one isn't 4.14 anymore and that should've been updated while
removing 4.14, but is easy to miss.
Since it's not expected that we have versions older than the oldest
mainline version from `kernels-org.json`, determine the minimum
supported version by reading it from there.
Also, this means lesser places to update when dropping old kernels.
This needs an additional change for the mainline updater to make sure
that no older versions appear there[1]. This will be implemented in
the next commit.
[1] At the time of implementing this, the oldest supported kernel was
4.19, however 4.14 wasn't EOL yet and thus still picked up by the
mainline updater.
Before the change there was no way to poll for presence of
`vendorSha256` attribute:
$ nix-instantiate --strict --eval --expr 'with import ./. {}; _3mux.vendorSha256 or "no hash"'
error: attribute 'vendorSha256' missing
292| passthru = passthru // { inherit go goModules vendorHash; } // { inherit (args') vendorSha256; };
| ^
After the change the poll happens as expected:
$ nix-instantiate --strict --eval --expr 'with import ./. {}; _3mux.vendorSha256 or "no hash"'
"no hash"
