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

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

Adding Linux 6.12 udebs for bookworm LTS

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

Contents

  Adding Linux 6.12 udebs for bookworm LTS Ben Hutchings <ben@decadent.org.uk> - 2026-06-05 12:30 +0200
    Re: Adding Linux 6.12 udebs for bookworm LTS Ben Hutchings <ben@decadent.org.uk> - 2026-06-12 22:00 +0200
      Re: Adding Linux 6.12 udebs for bookworm LTS Jose R Rodriguez <jose.r.r@metztli.com> - 2026-06-13 01:20 +0200
        Re: Adding Linux 6.12 udebs for bookworm LTS Ben Hutchings <ben@decadent.org.uk> - 2026-06-13 12:20 +0200
      Re: Adding Linux 6.12 udebs for bookworm LTS Cyril Brulebois <kibi@debian.org> - 2026-06-13 14:40 +0200
        Re: Adding Linux 6.12 udebs for bookworm LTS Ben Hutchings <ben@decadent.org.uk> - 2026-06-27 13:50 +0200
          Re: Adding Linux 6.12 udebs for bookworm LTS Cyril Brulebois <kibi@debian.org> - 2026-06-27 18:00 +0200

#92898 — Adding Linux 6.12 udebs for bookworm LTS

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

Currently backports of src:linux in the backports suites include udebs,
which may be used in unofficial installer builds.  I'm proposing to also
do this for a backport in the bookworm(-security) suites.  This was
previously requested for bullseye (#1117674) and I would llke to do this
for bookworm when LTS maintenance starts.

Since the backports suites are not supported for a full 5 years, I add a
backported kernel to the -security suite at the start of LTS
maintenance.  Until now, I have conservatively disabled building udebs
in these backports.

For bookworm specifically, this will require either updating kernel-
wedge or disabling compressed kernel modules, because bookworm's version
does not support them.  I verified that updating kernel-wedge from 2.104
to 2.106 did not change (1) the debian/control file generated for
src:linux (2) the contents of the udebs produced after a
build/sign/build of src:linux.  (The udebs were not bit-identical due to
modules being signed with an ephemeral key, but otherwise the packages
were the same.)  So I think this is quite safe to do.

I have *not* tested whether having these additional udebs available will
affect the inclusion of packages in official installer builds for the
final point release.  To test this, would it be sufficient to put them
in localudebs/, or should I put them in a local APT archive and add a
sources.list.udeb.local pointing at them?

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
                                                           - Bill Gates

[toc] | [next] | [standalone]

#92972

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

On Fri, 2026-06-05 at 12:27 +0200, Ben Hutchings wrote:
[...]
> I have *not* tested whether having these additional udebs available will
> affect the inclusion of packages in official installer builds for the
> final point release.  To test this, would it be sufficient to put them
> in localudebs/, or should I put them in a local APT archive and add a
> sources.list.udeb.local pointing at them?

I tested a netinst build with the additional udebs available in
localudebs/, and as intended and expected they were *not* included.

But I also wanted to test "CD" builds.  Unfortunately setting LOCAL +
LOCALDEBS + UPDATE_LOCAL changes the behaviour of various scripts in
debian-cd so all the extra packages get copied into a separate directory
in the image.  To test the behaviour of an official build with new
packages present, it appears that I would need to somehow merge the new
packages into my mirror.  And I can't see how to do that.

Unless someone can help me to create that merged archive, I'm afraid I
will have to test this after linux-6.12 is in bookworm-proposed-updates,
and fix any breakage then.

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source

[toc] | [prev] | [next] | [standalone]

#92977

On 2026-06-12 12:53, Ben Hutchings wrote:
> On Fri, 2026-06-05 at 12:27 +0200, Ben Hutchings wrote:
> [...]
>> I have *not* tested whether having these additional udebs available 
>> will
>> affect the inclusion of packages in official installer builds for the
>> final point release.  To test this, would it be sufficient to put them
>> in localudebs/, or should I put them in a local APT archive and add a
>> sources.list.udeb.local pointing at them?
> 
> I tested a netinst build with the additional udebs available in
> localudebs/, and as intended and expected they were *not* included.
Just an experienced -based observation, Ben:
When I build reiser4 udebs for AMD64 architecture, after placing them 
under localudebs/, I still have to reference those in file:
build/pkg-lists/netboot/amd64.cfg
otherwise, those unofficial udebs are not included in the final netinst 
build image.

Accordingly, if your intention is to include in the final netinst image 
those unofficial UDEB packages under localudebs/, you would reference 
them in their respective file:
build/pkg-lists/netboot/[architecture].cfg
for the architecture you are targeting the d-i netinst image build.
> 
> But I also wanted to test "CD" builds.  Unfortunately setting LOCAL +
> LOCALDEBS + UPDATE_LOCAL changes the behaviour of various scripts in
> debian-cd so all the extra packages get copied into a separate 
> directory
> in the image.  To test the behaviour of an official build with new
> packages present, it appears that I would need to somehow merge the new
> packages into my mirror.  And I can't see how to do that.
> 
> Unless someone can help me to create that merged archive, I'm afraid I
> will have to test this after linux-6.12 is in 
> bookworm-proposed-updates,
> and fix any breakage then.
> 
> Ben.

-- 
Best Professional Regards.

--
Jose R R
http://metztli.it
---------------------------------------------------------------------------------------------
Download Metztli Reiser4: Debian Trixie w/ Linux 5.17.15-2 AMD64
---------------------------------------------------------------------------------------------
feats ZSTD compression https://sf.net/projects/metztli-reiser4/
-------------------------------------------------------------------------------------------
Official current Reiser4 resources: https://reiser4.wiki.kernel.org/

[toc] | [prev] | [next] | [standalone]

#92987

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

On Fri, 2026-06-12 at 16:08 -0700, Jose R Rodriguez wrote:
> On 2026-06-12 12:53, Ben Hutchings wrote:
> > On Fri, 2026-06-05 at 12:27 +0200, Ben Hutchings wrote:
> > [...]
> > > I have *not* tested whether having these additional udebs available 
> > > will
> > > affect the inclusion of packages in official installer builds for the
> > > final point release.  To test this, would it be sufficient to put them
> > > in localudebs/, or should I put them in a local APT archive and add a
> > > sources.list.udeb.local pointing at them?
> > 
> > I tested a netinst build with the additional udebs available in
> > localudebs/, and as intended and expected they were *not* included.
> Just an experienced -based observation, Ben:
> When I build reiser4 udebs for AMD64 architecture, after placing them 
> under localudebs/, I still have to reference those in file:
> build/pkg-lists/netboot/amd64.cfg
> otherwise, those unofficial udebs are not included in the final netinst 
> build image.
> 
> Accordingly, if your intention is to include in the final netinst image 
> those unofficial UDEB packages under localudebs/,
[...]

No, that is precisely what I *don't* want to happen.  My intent is that
users who need Linux 6.12 on bookworm will still have that with security
support, but the standard install media should be unaffected.

Ben.

-- 
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot

[toc] | [prev] | [next] | [standalone]

#92989

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

Hi,

And sorry for the delay…

Ben Hutchings <ben@decadent.org.uk> (2026-06-12):
> On Fri, 2026-06-05 at 12:27 +0200, Ben Hutchings wrote:
> [...]
> > I have *not* tested whether having these additional udebs available
> > will affect the inclusion of packages in official installer builds
> > for the final point release.  To test this, would it be sufficient
> > to put them in localudebs/, or should I put them in a local APT
> > archive and add a sources.list.udeb.local pointing at them?
> 
> I tested a netinst build with the additional udebs available in
> localudebs/, and as intended and expected they were *not* included.

Right, things would only be pulled from there if there were listed in
package lists.

> But I also wanted to test "CD" builds.  Unfortunately setting LOCAL +
> LOCALDEBS + UPDATE_LOCAL changes the behaviour of various scripts in
> debian-cd so all the extra packages get copied into a separate directory
> in the image.  To test the behaviour of an official build with new
> packages present, it appears that I would need to somehow merge the new
> packages into my mirror.  And I can't see how to do that.

Right, using those variables is tricky, can be useful to get local tests
that are somewhat useful to make progress with debian-cd features/fixes,
but depending on the exact topic it can create enough divergences from
official builds that one can't draw accurate conclusions.

> Unless someone can help me to create that merged archive, I'm afraid I
> will have to test this after linux-6.12 is in bookworm-proposed-updates,
> and fix any breakage then.

I have a local amd64 mirror handy, I can probably merge things manually
there to give this a try, and let ftpsync clean things up afterwards.

Reading your initial mail again, it looks to me we're looking at having
extra udebs getting included into the official images, since all udebs
are included by default. Unless their size is noticeable, they shouldn't
push packages out of the first image; if they do, and/or if we don't
want those udebs included, we could just exclude them at the debian-cd
level (see data/*/exclude-udebs).

If we want to be safe, patching debian-cd to exclude them in advance
would make sense to me, advising the images team to double check what
happens on release day.


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [next] | [standalone]

#93121

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

On Sat, 2026-06-13 at 14:31 +0200, Cyril Brulebois wrote:
[...]
> > Unless someone can help me to create that merged archive, I'm afraid I
> > will have to test this after linux-6.12 is in bookworm-proposed-updates,
> > and fix any breakage then.
> 
> I have a local amd64 mirror handy, I can probably merge things manually
> there to give this a try, and let ftpsync clean things up afterwards.
> 
> Reading your initial mail again, it looks to me we're looking at having
> extra udebs getting included into the official images, since all udebs
> are included by default. Unless their size is noticeable, they shouldn't
> push packages out of the first image; if they do, and/or if we don't
> want those udebs included, we could just exclude them at the debian-cd
> level (see data/*/exclude-udebs).

Thank you.

> If we want to be safe, patching debian-cd to exclude them in advance
> would make sense to me, advising the images team to double check what
> happens on release day.

I have since had confirmation that the bookworm-backport suite will
remain open until the final point release.  So I won't need to add
src:linux-6.12 until after the point release, and no work will be needed
to exclude or re-prioritise it in installation media.

Ben.

-- 
Ben Hutchings
Lowery's Law:
        If it jams, force it. If it breaks, it needed replacing anyway.

[toc] | [prev] | [next] | [standalone]

#93129

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

Ben Hutchings <ben@decadent.org.uk> (2026-06-27):
> I have since had confirmation that the bookworm-backport suite will
> remain open until the final point release.  So I won't need to add
> src:linux-6.12 until after the point release, and no work will be needed
> to exclude or re-prioritise it in installation media.

Alright, thanks for the heads-up.


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [standalone]

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

csiph-web