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.
- special case linux-testing fetching
- use hash instead of sha256 everywhere
- respect COMMIT envvar
This causes rebuilds, so should go in with the next bump probably.
