Thanks for your reply! :) (almost missed it as you replied only to the list ;-) )
> On Thu, 2026-04-09 at 00:12 +0200, Piotr Morgwai Kotarbinski wrote: >> Hello Debian Kernel Team, >> >> Recently I needed to build packages for the latest mainline kernel to post >> some logs to kernel.org bugzilla >> (https://bugzilla.kernel.org/show_bug.cgi?id=221319). I followed the kernel >> handbook (chapter 4 mainly) and it generally went pretty smoothly and I >> posted a mini-howTo on Debian Forums: >> https://forums.debian.net/viewtopic.php?t=166381 > > It is much easier to use "make bindeb-pkg" for this, instead of the > Debian official packaging (section 4.2 in the handbook). For the latest mainline version I needed to go through combination of 4.6+4.7 anyway and then 4.5.4/4.5.5 way spared me messing with the config and personally I found it much simpler this way. >> The only bit that I'm missing is generating `linux-image-${VERSION}-amd64`, >> so to work-around this, after installing the built packages, I manually call >> `linux-run-hooks image postinst`. From what I understand, `linux-signed` / >> `linux-image-${VERSION}-amd64` is generated by Debusine based on >> `linux-image-amd64-signed-template`, so I was wondering if: >> >> a) ...I can fake this process somewhat and generate >> `linux-image-${VERSION}-amd64` locally using some scripts and ideally also >> sign the kernel for example with my dkms MOK, or... >> >> b) ...if the above is over-complicated or not feasible, is it sufficient >> (for the purpose of setting-up / cleaning-up of kernel images) to create a >> dummy package that depends on `linux-binary` (and others) with >> maintainer-scripts generated from `debian/templates/image.p*` templates? If >> so, is there an easy to use script or a `make` rule to generate these >> maintainer-scripts from these templates? > > I have used this workaround myself recently, but this will likely stop > working in the near future. In the mean time I've written a small script for this, but editing debian/config/amd64/defines.toml seems like a much better way. > If you actually want to sign the kernel images yourself, you can see how > to do that in done in debian/salsa-ci.yml. Otherwise you should disable > signing of the image by editing debian/config/amd64/defines.toml and > regnerate debian/control before starting the build. Editing debian/config/amd64/defines.toml works great: thanks! :) I'll have a look at debian/salsa-ci.yml later, but signing is not critical for me. > On Fri, 2026-04-10 at 14:58 +0200, Ben Hutchings wrote: > [...] >> I will try to update the instructions in the kernel handbook soon. > > I opened > <https://salsa.debian.org/kernel-team/kernel-handbook/-/merge_requests/11> > for this (and one other change). Could you review the new text there? I've left a few minor comments. Many thanks for explaining all this! :)
