Hi,
your subject suggests that you are looking for a solution for huge upstream
packages in general but reading your mail I get the feeling that you are
looking for a solution for src:linux specifically? I'm asking because the way
that src:linux is packaged in Debian contains a *lot* of custom code (a bit
more than 4000 lines of Python) which afaik is only used there and nowhere else
in Debian. So any solution you get for src:linux will probably only be
applicable there and at the same time because src:linux does contain so much
custom tooling, any general purpose solution will probably not work for it..
Quoting Marc Haber (2025-07-18 22:16:25)
> I would like to re-work my linux kernel building process and would like to do
> it right this time: Build a clean source package that dak and sbuild will
> accept. I do not plan to upload this to Debian, but I think that we all can
> learn from some discussion.
The Debian packaging of src:linux contains a lot of Python code which
re-generates the control files and Makefile code that you tell it to generate.
So it is that Python code that you would have to learn how to interact with so
that it can generate the source package you want for you.
I'm maintaining a downstream "fork" or patch-stack against the Debian Linux
packaging from Debian to build the custom kernel packages for the MNT Reform
open hardware laptops. We publish these kernels on the official Debian
repositories by MNT and I use the same tooling to build them against Debian
Trixie (and Trixie-backports in the future) and publish them on
reform.debian.net.
I met with Ben Hutchings at MiniDebConf in Berlin last year and received a lot
of tips on how to better use the Debian Linux kernel packaging in the MNT
downstream derivative. One essential tip was that what I want should probably
become its own "flavour". The Debian kernel packaging is able to build the
kernel for multiple flavours, each with their own configuration and they end up
in differently named binary packages. This is how we now produce kernel
packages for the MNT laptops which are named linux-image-mnt-reform-arm64 or
linux-headers-mnt-reform-arm64 where "mnt-reform-arm64" is the flavour name.
To create our own flavour, we create a file in debian/config.local which will
override files that the official packaging is putting into debian/config.
Specifically, our debian/config.local/arm64/defines.toml looks like this:
--%<-----------------------------------------------
[[flavour]]
name = 'mnt-reform-arm64'
[flavour.defs]
is_default = true
[flavour.packages]
installer = false
docs = false
[flavour.description]
hardware = '64-bit ARMv8 machines (MNT Reform)'
hardware_long = 'MNT Reform 2, MNT Pocket Reform and Reform Next'
[[featureset]]
name = 'none'
[[featureset.flavour]]
name = 'mnt-reform-arm64'
[build]
enable_signed = false
-->%-----------------------------------------------
As for the kernel config, we just dump all the custom kernel config settings
which are not part of the Debian packaging into debian/config/arm64/config
(that should probably also go into debian/config.local?)
After you edit these things you have to run a bunch of scripts like
kernel-team/utils/kconfigeditor2/process.py which will clean up your kernel
config, which I think is optional?
Non-optional is running debian/rules targets like "source" which ends up running
"make -f debian/rules.gen source" to regenerate the dsc and this:
make -f debian/rules debian/control-real
This will regenerate the control files and Makefile snippets given the new
information that you configured using toml configs like the one above.
> I would like to build differnt "flavors", lets call them linux-server,
> linux-vm, linux-desktop and linux-notebook. But I'd like to have them
> from - at least - the same .orig.tar.gz, just for the reason that this file
> is about 150 MB large.
I think you used the right term when you called what you want to build
"flavours". I think what you might want to do might be to hack up your own
flavour in the respective toml file in debian/config.local, throw in your
custom kernel config, run the debian/rules target to regenerate debian/control
and the start sbuild. We throw in the following build profiles to vastly speed
up our builds: nodoc, pkg.linux.nokerneldbg, pkg.linux.nokerneldbginfo.
I also learned a lot reading the excellent handbook of the kernel team:
https://kernel-team.pages.debian.net/kernel-handbook/
I'd also like to mention that a lot of things have changed in this department
recently. For example, the toml config format was only introduced in kernel
version 6.7 and more and more things have recently become configurable via
toml. For example we used to patch the kernel team's Python code to do things
but two months ago, Ben submitted
https://salsa.debian.org/kernel-team/linux/-/merge_requests/1481 and now
instead of patching code, we can just edit the toml.
The kernel team has been very helpful with supporting me as their downstream
and has added more and more convenience features which make work for me as
their downstream easier over the past months. I'm sure you'll have a pleasant
time as well as their downstream. :)
Thanks!
cheers, joschAttachment:
signature.asc
Description: signature