Add kernel builds based on Debian kernels (V2)

[dimkr]

Now that woof-CE supports kernels without aufs, we don't have to maintain our own kernels really, because Puppy kernels are no longer special.

Instead, we can just take Debian kernels and apply the Puppy<>Debian delta, i.e. things like CONFIG_USB_STORAGE=y instead of CONFIG_USB_STORAGE=m. The Debian kernel team has more expertise, and Debian kernel configurations are more battle-tested in terms of stability and security compared to Puppy ones, so we can take everything minus the Puppy stuff from the Debian kernel and maintain just the delta.

This PR adds 5 kernel builds to the weekly rotation:

1. bullseye, x86_64 and x86, without aufs, with /usr symlinks
2. bookworm, x86_64 and x86, without aufs, with /usr symlinks
3. sid, x86_64 only, without aufs, with /usr symlinks

They're built from the Debian kernel source and not the latest officially released bugfix version from kernel.org, making them extremely Debian-compatible and less likely to break.

Debian Bookworm is still not frozen, and currently uses 5.19.x, so that's what the bookworm job builds at the moment. If and when Bookworm or Sid switches to 6.0.x, we'll have a ready-made 6.0.x kernel with the Puppy secret sauce, without a maintenance burden and without any manual intervention during this upgrade. 🎉

These kernels live alongside the current selection of 4.19.x, 5.4.x, 5.10.x and 5.15.x, and anyone who wants to "rinse and repeat" by adding a .config and a build job for 6.0.x, etc', is free to do so; dpup will now track Debian kernels in the name of easy maintenance, wide hardware support and close compatibility with Debian.

[dimkr]

bookworm = bullseye + ntfs3

[dimkr]

sid = bookworm, until the sid kernel needs some adjustment the bookworm one doesn't

[peabee]

I have no problem if these are additions only used by dpups.....

however I do worry that the kernel-kit output is now offering a mind-blowing number of different kernel versions and wonder whether it should be divided up more explicitly into the various categories

also, if these new kernels are only going to be used by dpups perhaps they should be "less public"? i.e. specific to the dpup builds.

and will the inevitable conclusion be that Slackware and Ubuntu and Void specific kernels also be needed? Slippery slope.

[dimkr]

however I do worry that the kernel-kit output is now offering a mind-blowing number of different kernel versions and wonder whether it should be divided up more explicitly into the various categories

GitHub actions doesn't provide a way to customize the job output page.

However, I do think that some builds can be disabled - 5.4.x is unused since 8e02c72 and Slacko 7.x can be migrated to 5.10.x instead of 4.19.x, greatly reducing the number of build configurations.

also, if these new kernels are only going to be used by dpups perhaps they should be "less public"? i.e. specific to the dpup builds.

1. They can be used by other Puppy builds as well - they're Debian-based but not incompatible with anything else
2. They must be public, because GPL

I can move them to a separate job, if that matters.

EDIT: moved

Slippery slope.

If you want a Void-compatible kernel you can do so, but if you don't, it won't happen on its own. I'm working on dpup and that's where the slope ends. Once I have a reliable stream of Debian-compatible kernels, I no longer need any of the other kernel builds.

[peabee]

5.4.x should continue to be built until proven to be unusable

[dimkr]

Tested in a VM with #3419, works brilliantly. Merging, the size of these kernels can be reduced later and there shouldn't be missing drivers, but I'll do more testing.