On Fri, 2026-01-02 at 22:20 +0000, Micha Lenk wrote: > Hi Ben, > > looking through the debdiff output of the linux-signed-amd64 and > linux-signed-arm64 packages currently sitting in BACKPORTS-NEW, I wonder > how to read the changes in the debian/changelog file. The usual pattern > I see (in non-kernel packages) is a new changelog entry being added to > describe the changes necessary to prepare the backport. Sometimes the > previous backport's changelog entries are carried over from previous > uploads to trixie-backports (which is a bit cumbersome to read, but > still acceptable). [...] > 1.) Is this change in debian/changelog expected in the debdiff output? Yes. The changelog is a copy of that in src:linux, with the top entry changed to have the correct package name and "Sign kernel from ..." as an additional item. Originally I added an entirely new changelog entry but that was changed in <https://salsa.debian.org/kernel-team/linux/-/merge_requests/31>. The discussion of the *reasons* for this is unfortunately not there and probably took place on IRC. But I think the reasoning was that some tools wold only show the top changelog entry, or maybe they would not show entries with a different source package name. If the problem was that tools only showing the top changelog entry, that would still be a problem for -backports since the top entry will still only describe backporting changes, but hopefully you can see that this made sense for other suites. > 2.) As I expect this changelog entry to be generated by some > semi-automated tooling, do you have any documentation how the handling > of the linux-signed-* packages is done, especially in the context of > backports? In summary: 1. The src:linux build process produces some binary packages that contain unpacked "template" source packages that need detached signatures added to them. 2. dak generates information about these somewhere the code signing service can see it. It is configured to do this for specific source packages and suites. 3. The code signing service downloads and unpacks each of those binary packages along with the binary packages containing the code. 4. The code signing service creates detached signatures for the code and adds them to the source package template. It then builds, signs, and uploads the complete source package (linux-signed-*). The design for this is described further in <https://wiki.debian.org/SecureBoot/Discussion#Agreed_design>. src:linux makes heavy use of generating dpkg and debhelper configuration files from templates. This is a combination of home-grown stuff in debian/bin and debian/lib, Jinja2, and kernel-wedge for the udebs. The entry point is debian/bin/gencontrol.py. This is unfortunately not well-documented and I'm not going to start writing the documentation here, sorry. > 3.) Given the somewhat special situation for the linux kernel, is there > anything you want me to focus on when reviewing such changes in the > linux-signed-* packages in the BACKPORTS-NEW queue? If you can find a way to s/\+deb14/+deb13/ on both file names and contents before comparing them, you should then be able to see any actually interesting changes. (But there should not be any after that.) Unfortunately I don't think debdiff can do that. > I try to not block other maintainer's work as much as possible. So, I > will accept both uploads for now. Yet I feel curious and would like to > learn more about the backports needs of the linux Kernel developers in > Debian. Thank you. Ben. -- Ben Hutchings - Debian developer, member of kernel, installer and LTS teams
Attachment:
signature.asc
Description: This is a digitally signed message part