README.source

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-all' 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