Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #90677 > unrolled thread

Re: Questions on debdiff for linux-signed-{amd64,arm64} in trixie-backports

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Questions on debdiff for linux-signed-{amd64,arm64} in  trixie-backports Ben Hutchings <benh@debian.org> - 2026-01-03 02:20 +0100
    Re: Questions on debdiff for linux-signed-{amd64,arm64} in  trixie-backports Ben Hutchings <benh@debian.org> - 2026-01-04 18:30 +0100

#90677 — Re: Questions on debdiff for linux-signed-{amd64,arm64} in trixie-backports

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#90698

[Multipart message — attachments visible in raw view] — view raw

Reminder to self, don't send emails at 2 a.m.  I now need to add a few
clarifications:

On Sat, 2026-01-03 at 02:16 +0100, Ben Hutchings wrote:
[...]
> 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-*).

Note that this "build" is a source-build.  The binary packages are later
built in the usual way.

[...]
> > 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.)

On some backports branches I have made minor changes to maintain
compatibility with stable user-space, dropping a Breaks, but this has
not yet happened for trixie-backports.

> Unfortunately I don't think debdiff can do that.
[...]

This will produce something closer to a reasonable diff:

   VERSION=6.17.13+1
   dpkg-source -x linux-signed-amd64_${VERSION}.dsc
   dpkg-source -x linux-signed-amd64_${VERSION}~bpo13+1.dsc
   find linux-signed-amd64-${VERSION} -type f -print0 | xargs -0 sed -i 's/+deb14/+deb13/g'
   find linux-signed-amd64-${VERSION} -depth -name '*+deb14*' -print0 | xargs -0 rename -d 's/\+deb14/+deb13/g'
   diff -urN linux-signed-amd64-${VERSION}{,~bpo13+1}

However I also see many instances of the linux source version and the
compiler version differing.  The linux source version doesn't really
need to be repeated multiple times in rules.gen and the compiler is not
needed at this point, so possibly we could eliminate some of that with
changes to the generation process.

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web