summaryrefslogtreecommitdiffstats
path: root/debian/README.source
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-07 18:49:59 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-07 18:49:59 +0000
commit01997497f915e8f79871f3f2acb55ac465051d24 (patch)
tree1ce1afd7246e1014199e15cbf854bf7924458e5d /debian/README.source
parentAdding upstream version 6.1.76. (diff)
downloadlinux-01997497f915e8f79871f3f2acb55ac465051d24.tar.xz
linux-01997497f915e8f79871f3f2acb55ac465051d24.zip
Adding debian version 6.1.76-1.debian/6.1.76-1
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'debian/README.source')
-rw-r--r--debian/README.source297
1 files changed, 297 insertions, 0 deletions
diff --git a/debian/README.source b/debian/README.source
new file mode 100644
index 000000000..2248ac9ae
--- /dev/null
+++ b/debian/README.source
@@ -0,0 +1,297 @@
+Checklist for uploaders
+=======================
+
+There is a checklist in the kernel-team.git repository; see
+<https://salsa.debian.org/kernel-team/kernel-team/-/blob/master/docs/kernel-upload-checklist.md>.
+
+Updating the upstream source
+============================
+
+In addition to the build-dependencies, you will need the rsync package
+installed.
+
+1) Run: ./debian/bin/genorig.py <repository>
+
+ where <repository> is a local or remote git repository with the
+ upstream release tag in it.
+
+ If you do not have a local repository, use the appropriate one of:
+
+ * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
+ * https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+ * git://kernel.ubuntu.com/ubuntu/linux.git
+
+ This will produce ../orig/linux_<version>.orig.tar.xz
+ (e.g. linux_3.5~rc1.orig.tar.xz).
+
+ It involves deleting files for DFSG compliance, as listed in the
+ Files-Excluded field in debian/copyright.
+
+2) Run: make -f debian/rules orig
+
+ This will apply the main quilt series to the upstream source, which
+ will usually fail due to conflicts with upstream changes. You need
+ to resolve those by dropping or refreshing patches.
+
+Recording updates in the changelog
+----------------------------------
+
+Upstream commits that we already cherry-picked and included in a
+previous package upload should not be mentioned, since they don't make
+any difference to the package. Any other commits that fix a Debian
+bug report and/or a security issue with a CVE ID should always be
+listed, along with the (Closes: #nnnnnn) and/or (CVE-yyyy-nnnn)
+reference.
+
+Aside from those general rules:
+
+* For an upstream release candidate, don't attempt to list the changes
+
+* For a stable release by Linus, refer to the summary at
+ kernelnewbies.org, e.g. https://kernelnewbies.org/Linux_4.5
+
+* For a stable update, refer to the changelog on kernel.org, e.g.
+ https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.5.1, and
+ list all changes that are relevant to our package and that fix bugs
+ that we would consider 'important' or higher severity
+
+ - The script debian/bin/stable-update updates the changelog
+ version and inserts the list of changes. It doesn't attempt to
+ filter out irrelevant or unimportant changes.
+
+ - If you have time, please delete irrelevant changes such as:
+ + Fixes for architectures not supported by the package
+ + Fixes for drivers that aren't enabled in any of our configurations
+ + Build fixes for configurations that we don't use
+ + Fixes for lockdep false positives
+
+If you have time, please add bracketted prefixes to the upstream
+change list as described below under "Changelog conventions".
+
+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.
+
+For each optional featureset there is an additional patch directory
+debian/patches-<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.
+
+Changelog conventions
+=====================
+
+If a change only affects some architectures, flavours or featuresets,
+this should be noted with a bracketted prefix on the changelog line:
+
+* [<fset>] Change to featureset <fset>
+* [<arch>] Change that affects Debian architecture <arch>
+* [<arch1>,<arch2>...] Change that affects Debian architectures
+ <arch1>, <arch2>, ...
+* [<arch>/<flavour>] Change that affects kernel flavour <flavour>
+ on Debian architecture <arch>
+* [<arch>/{<flavour1>,<flavour2>...}] Change that affects kernel
+ flavours <flavour1>, <flavour2>, ... on Debian architecture <arch>
+
+You can use wildcards to cover multiple values, e.g. 'arm*' for armel,
+armhf and arm64 architectures. Also 'x86' is used to cover the Debian
+architectures amd64, i386 and x32.
+
+Kernel config files
+===================
+
+Each kernel configuration file is constructed dynamically from a
+number of files under debian/config and (if it exists)
+debian/config.local. They are read in the following order, such that
+files later on the list can override settings from earlier files.
+Files in debian/config.local can also override settings from the
+corresponding file in debian/config. Most of the files are optional
+and the filenames can generally be overridden by explicit lists
+(possibly empty) specified in the 'defines' files.
+
+1. Common:
+ - Default filename: config
+ - Filename list: [image]configs in defines
+2. Per kernel architecture:
+ - Filename: kernelarch-<karch>/config (optional)
+3. Per architecture:
+ - Default filename: <arch>/config
+ - Filename list: [image]configs in <arch>/defines
+4. Per architecture and flavour:
+ - Default filename: <arch>/config.<flavour> (optional)
+ - Filename list: [<flavour>_image]configs in <arch>/defines
+5. Per featureset:
+ - Default filename: featureset-<fset>/config (optional)
+ - Filename list: [image]configs in featureset-<fset>/defines
+6. Per architecture and featureset:
+ - Default filename: <arch>/<fset>/config (optional)
+ - Filename list: [image]configs in <arch>/<fset>/defines
+7. Per architecture, featureset, and flavour:
+ - Default filename: <arch>/<fset>/config.<flavour> (optional)
+ - Filename list: [<flavour>_image]configs in <arch>/<fset>/defines
+
+You can check the final list of configuration files by reading
+debian/rules.gen. Each binary-arch_<arch>_<fset>_<flavour>_real
+rule passes the list to debian/rules.real as the KCONFIG variable.
+
+These files should be kept in order using the kconfigeditor2
+utility from <https://salsa.debian.org/kernel-team/kernel-team>.
+With this source package as your working directory, run:
+
+ debian/rules source
+ .../kernel-team/utils/kconfigeditor2/process.py .
+
+This will also warn about any symbols that no longer exist, or
+cannot be explicitly configured.
+
+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.
+
+Build-dependencies that relate to specific binary packages can be
+specified in a Build-Depends field in the template for that binary
+package. gencontrol.py will append the value to the source package's
+Build-Depends-Arch or Build-Depends-Indep field, as appropriate. It
+will also use the binary package's Architecture and Build-Profile as
+the architecture-qualification and/or restriction for each build-
+dependency that doesn't already have them.
+
+TODO:
+- Patches applied to the upstream source
+- How to define a flavour
+- More detail on generation of debian/control and configs
+
+Running tests
+=============
+
+linux supports autopkgtest and should be able to run most of the
+kernel's self-tests on any architecture where kexec is supported,
+but it has higher resource requirements than most packages:
+
+- A VM with plenty of disk space (10GB is enough), RAM (1GB is
+ probably enough) and at least 2 CPUs
+- The temporary directory for adt-virt-qemu (-o option) will need
+ several GB of space, so a tmpfs may not be suitable
+
+Note that if you tell adt-run to use an 'unbuilt tree' (i.e. an
+unpacked source package) it does not exclude VCS directories such as
+.git. Either use a packed source package or copy the working tree
+elsewhere excluding .git.
+
+Example invocation:
+
+ adt-run -B ../linux-image-4.2.0-rc6-amd64_4.2~rc6-1~exp2_amd64.deb \
+ ../linux_4.2~rc6-1~exp2.dsc \
+ --timeout-test=1200 \
+ --- adt-virt-qemu /var/cache/autopkgtest/adt-sid.img -o /var/tmp -c 2
+
+Build profiles
+==============
+
+Several build profiles are understood and supported:
+
+- stage1: Needed when bootstrapping an architecture. A stage1 build
+ produces only the linux-libc-dev package and has no host
+ build-dependencies.
+- nodoc: Exclude most documentation
+- noudeb: Exclude installer udeb packages
+- pkg.linux.notools: Exclude userland tool packages (linux-kbuild-<version>,
+ linux-perf, etc.)
+- pkg.linux.mintools: Build minimal set of userland tool packages
+ (linux-kbuild-<version>, linux-bootwrapper-<abiname> on powerpc/ppc64)
+- pkg.linux.nokernel: Exclude kernel image and header packages
+- pkg.linux.nokerneldbg: Exclude kernel debug packages
+- pkg.linux.nokerneldbginfo: Build kernel without debug symbols (also disables
+ BTF)
+- pkg.linux.nosource: Exclude source binary package (linux-source-<version>)
+- cross: Needed when cross-building.
+- nopython: Disable Python bindings. This currently disables building the
+ linux-perf-<version> package, as the perf program embeds Python.
+- pkg.linux.nometa: Exclude most meta-packages. The linux-compiler-* and
+ linux-headers-*-all* packages can still be built.
+- pkg.linux.quick: Perform a limited build that should provide good
+ coverage yet be quick enough for use in CI.
+
+Build rules
+===========
+
+The Debian build rules are split across multiple makefiles:
+
+- debian/rules: Standard top-level makefile for Debian package build.
+- debian/rules.gen: Intermediate makefile between debian/rules and
+ debian/rules.real. This is generated by gencontrol.py based on
+ the configuration under debian/config.
+- debian/rules.real: Makefile for building a single kernel flavour
+ or other group of binary packages.
+- debian/rules.d: Makefiles for building userland code from specific
+ source directories. The directory structure mirrors the kernel
+ source directories. debian/rules.real uses the "make-tools" to
+ invoke these makefiles.
+
+All builds *must* be done out-of-tree in a subdirectory of
+debian/build, so that the output files do not end up in the
+linux-source-<version> binary package. Currently kernel builds use
+debian/build/build_<arch>_<featureset>_<flavour>, userland code uses
+debian/build/build-tools/<source-dir> and documentation uses
+debian/build/build-doc.
+
+Code signing
+============
+
+The kernel image and modules may be signed after building, to support
+a Secure Boot or Trusted Boot policy. In Debian, this is performed by
+a "code signing service" that is separate from the normal package
+build process.
+
+The initial package build generates binary packages named
+linux-image-<arch>-signed-template, that contain a source package
+template and metadata about the files to be signed. The code signing
+service will download this and the linux-image packages to be signed.
+It will add detached signatures to the source package, then upload it
+(without ever running debian/rules).
+
+The source package template is generated by
+debian/bin/gencontrol_signed.py and debian/rules.real with files from
+debian/signing_templates and debian/templates. To test changes to
+these:
+
+1. Build the linux source package.
+2. Generate the signed source package by running the script
+ "debian-test-sign" from the kernel-team.git repository. It is
+ also possible to set up a development configuration of the
+ official code signing service, but this is more complicated.
+3. Build the signed source package.