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

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

TUXEDO getting involved with the Debian kernel team

Started byWerner Sembach <wse@tuxedocomputers.com>
First post2026-08-19 00:30 +0200
Last post2026-10-01 14:40 +0200
Articles 5 — 2 participants

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

Contents

  TUXEDO getting involved with the Debian kernel team Werner Sembach <wse@tuxedocomputers.com> - 2026-08-19 00:30 +0200
    Re: TUXEDO getting involved with the Debian kernel team Bastian Blank <waldi@debian.org> - 2026-09-04 13:40 +0200
      Re: TUXEDO getting involved with the Debian kernel team Werner Sembach <wse@tuxedocomputers.com> - 2026-09-04 21:10 +0200
      Re: TUXEDO getting involved with the Debian kernel team Werner Sembach <wse@tuxedocomputers.com> - 2026-10-01 14:40 +0200
        Re: TUXEDO getting involved with the Debian kernel team Werner Sembach <wse@tuxedocomputers.com> - 2026-10-01 14:40 +0200

#93783 — TUXEDO getting involved with the Debian kernel team

FromWerner Sembach <wse@tuxedocomputers.com>
Date2026-08-19 00:30 +0200
SubjectTUXEDO getting involved with the Debian kernel team
Message-ID<NtAtH-bLx6-1@gated-at.bofh.it>
Hello there,

I'm Werner from TUXEDO Computers and my colleague Max and I got to talk to 
Mechthilde at FrOSCon this weekend, who strongly advised me to to write the 
kernel team. I hope I found the right mailing list.

As you might already know: TUXEDO wants to use Debian as the base for our TUXEDO 
OS distro in the near future. Max did a Talk at FrOSCon explaining it in detail 
(sadly only in German): 
https://programm.froscon.org/froscon2026/talk/f467703e-39ea-41e0-bd66-f98efe4375d1/

I'm tasked with building packing the kernel.

To have full support for the newest devices we are selling, we currently need 
the newest Kernel 7.1.x + 2 Patches that are currently not upstream and TBH are 
somewhat dirty fixes that need more attention before they can go upstream. 
Besides my best efforts to upstream as soon as possible, this situation will 
always occur from time to time, so there is no way around it for us to build our 
own kernel fork where we can apply patches on our own.

My current effort to do this is based on the readme files in the Debian Linux 
repo and analyzing the config directory in there to build a "-tuxedo" featureset 
alongside the "-cloud" and "-rt" one with the patches added in there: 
https://gitlab.com/tuxedocomputers/development/packages/linux/-/tree/tuxedo-debian?ref_type=heads 
(relevant part is the patches-tuxedo folder and the new featureset in the 
defines.toml in the config folder)

But I'm not quite happy with the result yet:

- When I build this, I also always build the other featuresets including base 
featureset, which
- are then also included in the dsc and source tar and
- when I want to sign it for secure boot i also have to install these other 
featuresets and can not just sign the "-tuxedo" one.
- To sign the kernel with our self signed secure boot key (we not yet have our 
own shim bootloader, so we are using the MOK function of shim to include our 
self signed certificate) I patched USB-stick HSM support in the debian-test-sign 
script from the kernel-team repo.

I hope you could help me to find a recommended more "Debian way" to do all of this:

- How to I best add a new featureset with new patches ans slightly altered 
config and
- only build that to be installed alongside the not rebuild base, -rt, and 
-cloud featuresets.
- How do I properly sign that kernel using a HSM USB-stick?
- How can I best contribute back to Debian besides pushing TUXEDO developed 
patches as soon as possible to upstream so that all distros including Debian 
gain easy and automatic access to them?

Best regards

Werner

[toc] | [next] | [standalone]

#94007

FromBastian Blank <waldi@debian.org>
Date2026-09-04 13:40 +0200
Message-ID<NzAr0-f8ul-31@gated-at.bofh.it>
In reply to#93783
On Tue, Aug 18, 2026 at 11:57:52PM +0200, Werner Sembach wrote:
> My current effort to do this is based on the readme files in the Debian
> Linux repo and analyzing the config directory in there to build a "-tuxedo"
> featureset alongside the "-cloud" and "-rt" one with the patches added in
> there: https://gitlab.com/tuxedocomputers/development/packages/linux/-/tree/tuxedo-debian?ref_type=heads
> (relevant part is the patches-tuxedo folder and the new featureset in the
> defines.toml in the config folder)

-cloud and -rt are not featuresets, so they don't carry own patches and
are handled differently.

> But I'm not quite happy with the result yet:
> - When I build this, I also always build the other featuresets including
> base featureset, which
> - are then also included in the dsc and source tar and

| --- /dev/null
| +++ b/debian/config.local/amd64/defines.toml
| @@ -0,0 +1,3 @@
| +[[featureset]]
| +name = 'none'
| +enable = false

or so.

> I hope you could help me to find a recommended more "Debian way" to do all of this:
> - How to I best add a new featureset with new patches ans slightly altered
> config and

The easier way is to rename the source package:

| --- a/debian/changelog
| +++ b/debian/changelog
| @@ -1,4 +1,4 @@
| -linux (7.2.2-1~exp1) experimental; urgency=medium
| +linux-tuxedo (7.2.2-1~exp1) experimental; urgency=medium
|  
|     * New upstream stable update:
|      

There is one small fix needed to actually make that work right now:

| --- a/debian/bin/gencontrol.py
| +++ b/debian/bin/gencontrol.py
| @@ -557,7 +557,7 @@ class Gencontrol(Base):
|              'upstreamversion': self.version.linux_version_full,
|              'version': self.version.linux_version,
|              'version_complete': self.version.complete,
| -            'source_basename': re.sub(r'-[\d.]+$', '',
| +            'source_basename': re.sub(r'-\S+$', '',
|                                        self.changelog[0].source),
|              'source_upstream': self.version.upstream,
|              'source_package': self.changelog[0].source,

This then renames most of the packages to contain -tuxedo in the names,
so they can be easily identified.

> - only build that to be installed alongside the not rebuild base, -rt, and
> -cloud featuresets.

You still need to disable them, using properly placed "enable = false".
This should work:

| --- /dev/null
| +++ b/debian/config.local/amd64/defines.toml
| @@ -0,0 +1,6 @@
| +[[flavour]]
| +name = 'cloud-amd64'
| +enable = false
| +[[flavour]]
| +name = 'rt-amd64'
| +enable = false

> - How do I properly sign that kernel using a HSM USB-stick?

This depends on your setup.  Debian uses
https://salsa.debian.org/ftp-team/code-signing, which bolts into dak.

Bastian

-- 
Without freedom of choice there is no creativity.
		-- Kirk, "The return of the Archons", stardate 3157.4

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

#94008

FromWerner Sembach <wse@tuxedocomputers.com>
Date2026-09-04 21:10 +0200
Message-ID<NzHst-fcn4-11@gated-at.bofh.it>
In reply to#94007
Hi,

Am 04.09.26 um 13:17 schrieb Bastian Blank:
> On Tue, Aug 18, 2026 at 11:57:52PM +0200, Werner Sembach wrote:
>> My current effort to do this is based on the readme files in the Debian
>> Linux repo and analyzing the config directory in there to build a "-tuxedo"
>> featureset alongside the "-cloud" and "-rt" one with the patches added in
>> there: https://gitlab.com/tuxedocomputers/development/packages/linux/-/tree/tuxedo-debian?ref_type=heads
>> (relevant part is the patches-tuxedo folder and the new featureset in the
>> defines.toml in the config folder)
> -cloud and -rt are not featuresets, so they don't carry own patches and
> are handled differently.
>
>> But I'm not quite happy with the result yet:
>> - When I build this, I also always build the other featuresets including
>> base featureset, which
>> - are then also included in the dsc and source tar and
> | --- /dev/null
> | +++ b/debian/config.local/amd64/defines.toml
> | @@ -0,0 +1,3 @@
> | +[[featureset]]
> | +name = 'none'
> | +enable = false
>
> or so.

Did not think about setting the base package to false but works like a charm for 
less output.

But there are still the libc packages. Can i somehow also avoid of them being built?

>
>> I hope you could help me to find a recommended more "Debian way" to do all of this:
>> - How to I best add a new featureset with new patches ans slightly altered
>> config and
> The easier way is to rename the source package:
>
> | --- a/debian/changelog
> | +++ b/debian/changelog
> | @@ -1,4 +1,4 @@
> | -linux (7.2.2-1~exp1) experimental; urgency=medium
> | +linux-tuxedo (7.2.2-1~exp1) experimental; urgency=medium
> |
> |     * New upstream stable update:
> |
>
> There is one small fix needed to actually make that work right now:
>
> | --- a/debian/bin/gencontrol.py
> | +++ b/debian/bin/gencontrol.py
> | @@ -557,7 +557,7 @@ class Gencontrol(Base):
> |              'upstreamversion': self.version.linux_version_full,
> |              'version': self.version.linux_version,
> |              'version_complete': self.version.complete,
> | -            'source_basename': re.sub(r'-[\d.]+$', '',
> | +            'source_basename': re.sub(r'-\S+$', '',
> |                                        self.changelog[0].source),
> |              'source_upstream': self.version.upstream,
> |              'source_package': self.changelog[0].source,
>
> This then renames most of the packages to contain -tuxedo in the names,
> so they can be easily identified.

That actually sadly didn't fully work, the source package got renamed, but not 
the other ones, and running the kernel-team/scripts/debian-test-sign script now 
throws an error:

$ ./kernel-team/scripts/debian-test-sign ./linux-tuxedo_*_amd64.changes
I: Found signed-template package linux-image-tuxedo-amd64-signed-template:amd64
.....+.+...+...........+.......+...+..+....+...+........+....+........+...+++++++++++++++++++++++++++++++++++++++*..+........................+.......+++++++++++++++++++++++++++++++++++++++*........+.+...........+.+.........+.....+.+...+.........+...+..+......+....+........+.......+..+...+.......+...+...............+...+...+............+..............+.........+.+...+..+...+..........+...............+.....................+..+....+........+.......+...+......+.....+......+.+..+..........+...+.....+....+...........+.............+..+....+...........+...+....++++++
...+....+..+......+...+............+............+.+......+...+.....+.+......+.........+..+..........+...+.....+.+.....+......+....+...........+....+......+............+......+.........+..+...+.......+......+...+...........+...+......+.........+.............+.....+...+.......+.....+...................+...+.....+......+++++++++++++++++++++++++++++++++++++++*...+.......+......+...+..+...+++++++++++++++++++++++++++++++++++++++*......+......+...+...+.....+....+.....+...+.+......+.....+......+....+...........+...+..........+.....+......+.+............+......+......+...............+.....+.+........+.+.....+...+.+.....+....+.....+......+......+....+.....+.......+.....+.......+...........+.+.........+.........+..+.+........+......+......+...+................+...+......+.....+....+..+....+......+.....+....+..............+.............+..+.+......+......+..+............+...++++++
-----
I: Processing signed-template package linux-image-tuxedo-amd64-signed-template:amd64
I: Processing code package linux-binary-unsigned-7.1.13.1-tuxedo-amd64:amd64
Signing Unsigned original image
dpkg-source: error: source package has two conflicting values - 
linux-signed-tuxedo-amd64 and linux-signed-amd64
Traceback (most recent call last):
   File "/home/wse/Projekte/linux/./kernel-team/scripts/debian-test-sign", line 
261, in <module>
     main(*sys.argv[1:])
     ~~~~^^^^^^^^^^^^^^^
   File "/home/wse/Projekte/linux/./kernel-team/scripts/debian-test-sign", line 
212, in main
     subprocess.check_call(
     ~~~~~~~~~~~~~~~~~~~~~^
         ['dpkg-source', '-b', '.'],
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^
         cwd=template_source_dir)
         ^^^^^^^^^^^^^^^^^^^^^^^^
   File "/usr/lib/python3.14/subprocess.py", line 420, in check_call
     raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['dpkg-source', '-b', '.']' returned 
non-zero exit status 255.

>
>> - only build that to be installed alongside the not rebuild base, -rt, and
>> -cloud featuresets.
> You still need to disable them, using properly placed "enable = false".
> This should work:
>
> | --- /dev/null
> | +++ b/debian/config.local/amd64/defines.toml
> | @@ -0,0 +1,6 @@
> | +[[flavour]]
> | +name = 'cloud-amd64'
> | +enable = false
> | +[[flavour]]
> | +name = 'rt-amd64'
> | +enable = false

I actually did it a little bit different, but with the same result:

+[[featureset]]
+name = 'tuxedo'
+# Override available flavours in tuxedo featureset
+[[featureset.flavour]]
+name = 'amd64'
+[featureset.flavour.build]
+config = ['amd64/config.tuxedo']

>
>> - How do I properly sign that kernel using a HSM USB-stick?
> This depends on your setup.  Debian uses
> https://salsa.debian.org/ftp-team/code-signing, which bolts into dak.

Thanks. I will look into it.

Best regards,

Werner Sembach

>
> Bastian
>

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

#94306

FromWerner Sembach <wse@tuxedocomputers.com>
Date2026-10-01 14:40 +0200
Message-ID<NJoeR-2Uzu-5@gated-at.bofh.it>
In reply to#94007
Am 04.09.26 um 13:17 schrieb Bastian Blank:
> On Tue, Aug 18, 2026 at 11:57:52PM +0200, Werner Sembach wrote:
>> My current effort to do this is based on the readme files in the Debian
>> Linux repo and analyzing the config directory in there to build a "-tuxedo"
>> featureset alongside the "-cloud" and "-rt" one with the patches added in
>> there: https://gitlab.com/tuxedocomputers/development/packages/linux/-/tree/tuxedo-debian?ref_type=heads
>> (relevant part is the patches-tuxedo folder and the new featureset in the
>> defines.toml in the config folder)
> -cloud and -rt are not featuresets, so they don't carry own patches and
> are handled differently.
>
>> But I'm not quite happy with the result yet:
>> - When I build this, I also always build the other featuresets including
>> base featureset, which
>> - are then also included in the dsc and source tar and
> | --- /dev/null
> | +++ b/debian/config.local/amd64/defines.toml
> | @@ -0,0 +1,3 @@
> | +[[featureset]]
> | +name = 'none'
> | +enable = false
>
> or so.
>
>> I hope you could help me to find a recommended more "Debian way" to do all of this:
>> - How to I best add a new featureset with new patches ans slightly altered
>> config and
> The easier way is to rename the source package:
>
> | --- a/debian/changelog
> | +++ b/debian/changelog
> | @@ -1,4 +1,4 @@
> | -linux (7.2.2-1~exp1) experimental; urgency=medium
> | +linux-tuxedo (7.2.2-1~exp1) experimental; urgency=medium
> |
> |     * New upstream stable update:
> |
>
> There is one small fix needed to actually make that work right now:
>
> | --- a/debian/bin/gencontrol.py
> | +++ b/debian/bin/gencontrol.py
> | @@ -557,7 +557,7 @@ class Gencontrol(Base):
> |              'upstreamversion': self.version.linux_version_full,
> |              'version': self.version.linux_version,
> |              'version_complete': self.version.complete,
> | -            'source_basename': re.sub(r'-[\d.]+$', '',
> | +            'source_basename': re.sub(r'-\S+$', '',
> |                                        self.changelog[0].source),
> |              'source_upstream': self.version.upstream,
> |              'source_package': self.changelog[0].source,
>
> This then renames most of the packages to contain -tuxedo in the names,
> so they can be easily identified.
>
>> - only build that to be installed alongside the not rebuild base, -rt, and
>> -cloud featuresets.
> You still need to disable them, using properly placed "enable = false".
> This should work:
>
> | --- /dev/null
> | +++ b/debian/config.local/amd64/defines.toml
> | @@ -0,0 +1,6 @@
> | +[[flavour]]
> | +name = 'cloud-amd64'
> | +enable = false
> | +[[flavour]]
> | +name = 'rt-amd64'
> | +enable = false
>
>> - How do I properly sign that kernel using a HSM USB-stick?
> This depends on your setup.  Debian uses
> https://salsa.debian.org/ftp-team/code-signing, which bolts into dak.
Short question: What is dak?
>
> Bastian
>

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

#94307

FromWerner Sembach <wse@tuxedocomputers.com>
Date2026-10-01 14:40 +0200
Message-ID<NJoeR-2Uzu-9@gated-at.bofh.it>
In reply to#94306
Am 01.10.26 um 14:07 schrieb Werner Sembach:
>
> Am 04.09.26 um 13:17 schrieb Bastian Blank:
>> On Tue, Aug 18, 2026 at 11:57:52PM +0200, Werner Sembach wrote:
>>> My current effort to do this is based on the readme files in the Debian
>>> Linux repo and analyzing the config directory in there to build a "-tuxedo"
>>> featureset alongside the "-cloud" and "-rt" one with the patches added in
>>> there: 
>>> https://gitlab.com/tuxedocomputers/development/packages/linux/-/tree/tuxedo-debian?ref_type=heads
>>> (relevant part is the patches-tuxedo folder and the new featureset in the
>>> defines.toml in the config folder)
>> -cloud and -rt are not featuresets, so they don't carry own patches and
>> are handled differently.
>>
>>> But I'm not quite happy with the result yet:
>>> - When I build this, I also always build the other featuresets including
>>> base featureset, which
>>> - are then also included in the dsc and source tar and
>> | --- /dev/null
>> | +++ b/debian/config.local/amd64/defines.toml
>> | @@ -0,0 +1,3 @@
>> | +[[featureset]]
>> | +name = 'none'
>> | +enable = false
>>
>> or so.
>>
>>> I hope you could help me to find a recommended more "Debian way" to do all 
>>> of this:
>>> - How to I best add a new featureset with new patches ans slightly altered
>>> config and
>> The easier way is to rename the source package:
>>
>> | --- a/debian/changelog
>> | +++ b/debian/changelog
>> | @@ -1,4 +1,4 @@
>> | -linux (7.2.2-1~exp1) experimental; urgency=medium
>> | +linux-tuxedo (7.2.2-1~exp1) experimental; urgency=medium
>> |
>> |     * New upstream stable update:
>> |
>>
>> There is one small fix needed to actually make that work right now:
>>
>> | --- a/debian/bin/gencontrol.py
>> | +++ b/debian/bin/gencontrol.py
>> | @@ -557,7 +557,7 @@ class Gencontrol(Base):
>> |              'upstreamversion': self.version.linux_version_full,
>> |              'version': self.version.linux_version,
>> |              'version_complete': self.version.complete,
>> | -            'source_basename': re.sub(r'-[\d.]+$', '',
>> | +            'source_basename': re.sub(r'-\S+$', '',
>> | self.changelog[0].source),
>> |              'source_upstream': self.version.upstream,
>> |              'source_package': self.changelog[0].source,
>>
>> This then renames most of the packages to contain -tuxedo in the names,
>> so they can be easily identified.
>>
>>> - only build that to be installed alongside the not rebuild base, -rt, and
>>> -cloud featuresets.
>> You still need to disable them, using properly placed "enable = false".
>> This should work:
>>
>> | --- /dev/null
>> | +++ b/debian/config.local/amd64/defines.toml
>> | @@ -0,0 +1,6 @@
>> | +[[flavour]]
>> | +name = 'cloud-amd64'
>> | +enable = false
>> | +[[flavour]]
>> | +name = 'rt-amd64'
>> | +enable = false
>>
>>> - How do I properly sign that kernel using a HSM USB-stick?
>> This depends on your setup.  Debian uses
>> https://salsa.debian.org/ftp-team/code-signing, which bolts into dak.
> Short question: What is dak?
Never mind, found it: https://salsa.debian.org/ftp-team/dak
>>
>> Bastian
>>

[toc] | [prev] | [standalone]

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

csiph-web