View source for HowTo build latest mainline kernel packages for Trixie

In essence, this HowTo summarizes the invaluable insights from @Aki (from [https://forums.debian.net/viewtopic.php?p=841404#p841404 this thread]) and  @stevepusser (from [https://forums.debian.net/viewtopic.php?p=838594#p838594 this thread]) and the general info from [https://kernel-team.pages.debian.net/kernel-handbook the kernel handbook] (mainly chapter 4).

'''NOTE:''' A given moment's latest mainline kernel is usually not ready for a general use, especially during "rcX" versions as their names clearly suggest ("release candidate"). This HowTo is intended mostly for folks that need to post logs to LKML or bugzilla.kernel.org where discussions/questions/bug-reports regarding anything older than the latest mainline will almost always be ignored.
If you want to try the very latest stable release, check Debian's official [https://wiki.debian.org/Backports trixie-backports], [https://wiki.debian.org/DebianUnstable sid] and [https://wiki.debian.org/DebianExperimental experimental] suites (in that order) : the Kernel Team usually publishes packages just a few days after a tag is created in kernel.org's stable repo. In case of Sid and Experimental packages, it's usually more recommended to rebuild them with Trixie's <code>gcc-14</code> (see point 2) rather than pulling half of a system of dependencies from Sid.

The examples below are based on 7.0~rcX versions, the instructions were also tested on 7.1 and should be mostly applicable to later mainline versions as well, at least in the near future.
The env var <code>ARCH</code> used in some commands below refers to the primary architecture of your system (like <code>amd64</code> or <code>arm64</code>), it can be exported for convenience with
<pre>
export ARCH="$(dpkg --print-architecture)"
</pre> 

<ol><li> Clone <code>debian/latest</code> branch of the Linux kernel debianization from [https://salsa.debian.org/kernel-team/linux the Kernel Team's Salsa] (consider limiting history depth with <code>--depth</code> to reduce the transfer size from hundreds of MB even down to ~2MB in case of <code>--depth=1</code>). Next, <code>cd</code> into the cloned repo's folder: all commands from the remaining points are supposed to be issued in that folder.

</li><li> Replace <code>c_compiler</code> in <code>debian/config/defines.toml</code> from Sid's and Forky's <code>gcc-15</code> to Trixie's <code>gcc-14</code>.

</li><li> Starting with v6.19, the build process by default does not produce <code>linux-image-${ABI}-*</code>, which is generated by Debusine when signing a given kernel. The easiest way to produce all the usual packages, is to turn off <code>enable_signed</code> in <code>debian/config/${ARCH}/defines.toml</code> file (keeping it enabled won't sign your kernel automagically anyway: it only causes templates for Debusine to be produced).

</li><li> Decide for your suffix of Debian-release part of the package version. The suffix must be of the form <code>[a-z]+${SEQUENTIAL_NUMBER}</code> and the <code>SEQUENTIAL_NUMBER</code> must be increased each time you build the packages for a given upstream version. For example I use <code>morgwai1</code>, then <code>morgwai2</code> and so on.
Export your suffix for example as <code>VERSION_SUFFIX</code> and then create a new entry in <code>debian/changelog</code> for the desired upstream kernel version with the target suite set to <code>UNRELEASED</code>. For example in case of <code>7.0~rc7</code>:
<pre>
cat - debian/changelog >changelog-new <<EOF
linux (7.0~rc7-1~${VERSION_SUFFIX}) UNRELEASED; urgency=medium

  * New upstream release candidate.
  * Packaging changes for Trixie.

 -- $(getent passwd ${USER} |cut -d : -f 5 |cut -d , -f 1) <${USER}@$(hostname)>  $(date -R)

EOF
mv changelog-new debian/changelog
</pre>
''(at this stage, <code>dch</code> usually cannot be used as <code>debian/control</code> has not been generated yet)''

</li><li> ABI name management:
<ul><li> For new features testing purposes, it is often useful to be able to install several "rcX" kernel packages along each other, but by default, <code>~rcX</code> part is not included in the ABI name (and as a consequence neither in package names) of packages built for <code>UNRELEASED</code> suite. To include it, remove <code>abi_version_full = false</code> line from the <code>[<nowiki/>[debianrelease]]</code> section for <code>UNRELEASED</code> suite in <code>debian/config/defines.toml</code> file.
</li><li> If you also want to be able to install along each other packages for several builds of the same upstream version, include your <code>VERSION_SUFFIX</code> in <code>abi_suffix</code> in the same section, for example:
<pre>
sed -e "s#abi_suffix = '+unreleased'#abi_suffix = '+${VERSION_SUFFIX}'#" debian/config/defines.toml >defines-new.toml
mv defines-new.toml debian/config/defines.toml
</pre>
Unfortunately, you need to update it each time you change your <code>VERSION_SUFFIX</code>.
</li></ul>

</li><li> By default, packages for all feature-sets (the default and <code>rt</code> and <code>cloud</code>) and flavors (like <code>arm64-16k</code>) are built, which is rarely needed, probably only by the maintainers when publishing the official packages. Of course it also causes the build to take n times longer. To disable unneeded feature-sets / flavors, edit <code>debian/config/${ARCH}/defines.toml</code> and remove their corresponding <code>[<nowiki/>[flavour]]</code> sections (usually at the top of a given file).

</li><li> Starting with 7.1, <code>debian/watch</code> uses a new format not supported by tools in Trixie, so replace it with the version from 7.0.x:
<pre>
git checkout debian/7.0/trixie-backports -- debian/watch
</pre>
If you cloned the repo with <code>--depth</code>, then get it using <code>curl</code> or <code>wget</code> instead:
<pre>
wget -O debian/watch https://salsa.debian.org/kernel-team/linux/-/raw/debian/7.0/trixie-backports/debian/watch
</pre>
Next, fetch the kernel sources from the kernel.org repo and create a corresponding <code>orig.tar.xz</code> file in the parent folder:
<pre>
uscan --download-current-version --vcs-export-uncompressed
</pre>
Note that the stable kernel tree sometimes lags with syncing "-rcX" tags from Linus, so soon after a creation of a such, you may need to use [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git his tree] instead in <code>debian/watch</code>.

Finally, extract the kernel source form the <code>orig.tar.xz</code> and "merge" it into the debianization:
<pre>
debian/rules orig
</pre>
This will generate <code>debian/control</code> and apply all the patches from <code>debian/patches</code>. It may happen that some of the patches cannot be applied cleanly due to changes in the involved parts of the source code. Sometimes a patch may be already applied in the latest upstream version (this is common situation for security patches), in which case you can simply remove it from <code>debian/patches</code>. Otherwise you need decide whether to rework such patch or if it concerns features you don't use, in which case you can remove it also.

</li><li> Several build profiles are defined, described in <code>debian/README.source</code>. You almost certainly don't need "udeb" packages and most probably don't need packages with documentation, so consider at least <code>export DEB_BUILD_PROFILES="nodoc noudeb"</code>. Note that applying some of the profiles may modify your kernel config (for example <code>pkg.linux.nokerneldbg</code> and <code>pkg.linux.nokerneldbginfo</code>).

</li><li> At this point you are ready to start the build process using 1 of the standard Debian ways. ''Either'':
<ul><li> install all the build deps and build binary packages directly on your system:
<pre>
sudo apt-get build-dep .
MAKEFLAGS="-j$(nproc)" dpkg-buildpackage -b -nc -uc
</pre>
(Also check [https://forums.debian.net/viewtopic.php?t=165708 Aki's ccache guide])

...''OR'':
</li><li> build a source package first with
<pre>
dpkg-source --build .
</pre>
...and then use for example [https://wiki.debian.org/sbuild sbuild] to build binary packages in a clean chroot-ed environment or build and publish them on [https://wiki.debian.org/OpenSuseBuildService OBS].

Note: if <code>dpkg-source</code>  complains about leftover Python caches, just remove the <code> __pycache__</code> folder it will point.
</li></ul>
The build process may take from 10 minutes to several hours depending on your hardware. A fresh build (empty ccache) of the default amd64 feature-set of 7.1 takes about 1.5h on OBS.

If for whatever reason you want to restart the build/configuration process from scratch, the command <code>debian/rules maintainerclean</code> will delete all generated files and the kernel sources, leaving only the Salsa debianization (so you will need to re-run <code>debian/rules orig</code>: useful when you want to build a new upstream version).

</li><li> Install the packages built in the parent folder, usually at least the below:<pre>
sudo apt install \
  ../linux-base-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
  ../linux-binary-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
  ../linux-image-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
  ../linux-modules-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb
</pre>
If you intend to build any modules with <code>dkms</code> (for example Nvidia drivers), then also these:
<pre>
sudo apt install \
  ../linux-headers-7.*+"${VERSION_SUFFIX}-${FLAVOR}"_*.deb \
  ../linux-headers-7.*+"${VERSION_SUFFIX}-common"_*.deb \
  ../linux-kbuild-7.*+"${VERSION_SUFFIX}"_*.deb
</pre>
<code>FLAVOR</code> on x86_64 machines is the same as <code>ARCH</code> (<code>amd64</code>), in case of ARM  it may be either <code>arm64</code> or <code>arm64-16k</code>, depending on what was left in <code>debian/config/arm64/defines.toml</code> in point 6.
</li></ol>

'''Remember that the kernel is unsigned so you need to either disable secure-boot or sign it for example using <code>sbsign</code>.'''

At this point your system should be ready to reboot to the new kernel.