building some kernels is broken by latest busybox/hexdump

A recent regression in busybox's hexdump applet causes some(?) kernel builds create a truncated kernel image. abuild reports the package as a success, but the image in the package will be something super small, I was seeing 57KB. It was a pain to debug, and it was ultimately ncopa who was able to blame hexdump. It's not super clear to me if this issue only affects a specific CPU arch (I'm using aarch64 everywhere).

It was reported upstream to busybox, and as of now a fix hasn't been identified/merged upstream. I think we basically have two choices:

1. Do nothing / wait for Alpine to package a fix for this (either from a new BB release or a backported patch). This seems like a bad option, unless upstream is verrrry close to fixing this. If pmaports kernel packages are built before this is fixed, the packages may install or upgrade to a totally broken kernel image on a device, and apk won't indicate any problem with this!

2. Install the full version of hexdump, this is what Alpine did temporarily in linux-virt package to work around this issue. Also, the full hexdump is like 80KB... maybe we should just always install it in build chroots so we can completely avoid this specific problem in the future?

The 2nd option seems kinda hard to deploy. Alpine added hexdump to the list of makedepends for the aports/linux-virt kernel. I don't think we want to do this for all 300+ kernels since it'll force bpo to rebuild them all. A kernel rebuild isn't necessary to work around/prevent this issue... OTOH almost all kernels in pmaports depend on postmarketos-installkernel, so we could add depends=hexdump to that package. The question is, what to do about the group (~100) of kernels that don't depend on pmos-installkernel?

Also see:

• Bug reported to upstream busybox: https://lists.busybox.net/pipermail/busybox/2024-October/090982.html
• Busybox bug bisected: https://lists.busybox.net/pipermail/busybox/2024-October/090983.html