Updating the upstream source
============================
1) You can use either:
a) a git repository of the kernel source
b) a kernel tarball from kernel.org (e.g. linux-3.4.tar.bz2)
and, optionally, a patch (e.g. patch-3.5-rc1.bz2).
2) Run ./debian/bin/genorig.py <repository>
or ./debian/bin/genorig.py <tarball> [patch]
This will produce ../orig/linux_<version>.orig.tar.gz
(e.g. linux_3.5~rc1.orig.tar.gz).
(genorig.py requires the python and unifdef packages to be
installed)
3) Unpack linux_<version>.orig.tar.gz, cd into the new directory,
and do a 'svn export' to get the debian/ subdirectory.
Alternatively unpack using "make -f debian/rules orig".
(the orig target of the Makefiles requires rsync)
Applying patches to the Debian kernel tree
==========================================
The Debian kernel packaging uses the quilt patch system, but with
multiple series to allow for featuresets.
Patches are stored below debian/patches, loosely sorted in bugfix/,
features/ and debian/. Patches are in the standard kernel patch
format (unified diff to be applied with patch -p1) and generally have
DEP-3 headers.
The series file 'series' is used for all configurations and a series
file 'series-<featureset>' is used for each optional featureset.
If you want to generate a source tree with all patches applied, run
make -f debian/rules source
The resulting source can be found below debian/build.
Kernel config files
===================
Configuration files are constructed dynamically from a number of config
files, as listed in debian/config/<arch>/defines.
Control file
============
The master control file debian/control must be generated before
the package is uploaded. debian/rules contains the debian/control
target, which generates the control file by invoking the
debian/bin/gencontrol.py script, which combines the templates from
the templates directory and architecture-specific defines file to
produce the debian/control file. Note that this target is intentionally
made to fail with a non-zero exit code to make sure that it is never
run during an automatic build. The following variables are substituted
into the templates:
@version@ Upstream kernel version, for example 2.6.11.
@arch@ The Debian arch name, such as powerpc or i386.
@flavour@ The build flavour, such as 686 or k7-smp.
@class@ The CPU/architecture class; displayed in synopsis. It should
be fairly short, as the synopsis is supposed to be <80 chars.
It should be in the form "foo class", and will show up in the
description as "foo class machines".
@longclass@ The CPU/architecture class; displayed in the extended
description. The same rules apply as in @class@. If
this is unset, it will default to @class@.
@desc@ (Potentially) multi-line verbiage that's appended to
-image descriptions.
@abiname@ Current abiname, a single digit.
Normally, the arch-specific contents should be controlled by
adjusting the corresponding defines file.
TODO:
- Patches applied to the upstream source
- How to define a flavour
- More detail on generation of debian/control and configs
ef9299159e