Update header common package name in prompt from binary-indep_none_real
to binary-indep_none_headers-common. which can find in debian/rules.gen:
$ grep binary-indep debian/rules.gen
Signed-off-by: Yunseong Kim <ysk@kzalloc.com>
In unstable, genorig.py has been removed since uscan can now do its
job. Since this section is about switching to a new upstream version,
it doesn't need to cover older releases, so replace the old text about
genorig.py with instructions for using uscan.
In order to build a kernel without debug information, it is not sufficient to
just disable DEBUG_INFO. The setting DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT needs
to be disabled as well, or `make oldconfig` will re-enable DEBUG_INFO.
In the header, drop the Prev/Next links and put:
- Debian logo
- Link to kernel team page
- "Breadcrumbs" for the handbook
all with the appropriate classes for the Debian stylesheet.
In the footer:
- Keep the Prev / Home / Next links in the footer
- Since there isn't any provision in the Debian stylesheet for navigation
across multiple chapters, add our own rules for them
- Use flexbox instead of a table for layout
I will need to override some rules here to fully implement the Debian
style, which requires writing (X)HTML without a namespace. Assign
the XSL DTD to the "xsl" namespace instead of the default namespace
and change tags accordingly.
This turns into a web page so it's fairly silly to suggest the other
options. We will need to mention some other licenses and I want to
keep this brief.
For parallel builds, fakeroot limits actual concurrency a lot. In
other cases it's still an unnecessary complication that slows things
down.
- Where appropriate, use dpkg-buildpackage instead.
- Otherwise, since src:linux has had "Rules-Requires-Root: no" since
before buster, use DEB_RULES_REQUIRES_ROOT=no instead. (Without
either this or fakeroot, some debhelper commands would complain.)
- Remove fakeroot from lists of packages to be installed.
dpkg-buildpackage will set DEB_BUILD_OPTIONS=parallel=<#cpus> but
all our example commands call debian/rules or debian/rules.gen
without using dpkg-buildpackage.
Add setting of MAKEFLAGS to the preparation section.
When building kernel packages with experimental changes, it is
undesirable that these packages will replace or conflict with the
current kernel packages. Aside from any run-time bugs, if Secure Boot
is still enabled then the unsigned linux-image package will not be
bootable. Recommend changing the ABI name so the new binary packages
are co-installable.
Give straightforward instructions for changing the ABI name for
a custom package, and given an example name of "0.local".
The current version has important bugs and limitations that make it
not nearly as easy to use as it should be. This is now fixed in
unstable and will soon be fixed for bookworm, but older releases may
remain broken. Expand the warning about debug info to add 2 other big
problems.
The generation of debug info and -dbg packages is now controlled
through build profiles and not through debian/config/defines.
These instructions still don't work for some versions of test-patches,
but a fix for that is in unstable and the next commit will add a
warning about the problem.
When test-patches was introduced, src:linux was still using source
format 1.0 which did not support setting executable bits on files in
the debian/ directory (except debian/rules). Thus it was necessary to
include the script interpreter in these command lines.
This hasn't been the case for many years, and putting "bash" in front
will cause problems if we ever want to change the script's
interpreter.
Before 2011, kernel udebs were built from separate source packages,
and dak didn't support Built-Using. This meant there was no guarantee
that the exact source version for the kernel udebs in a suite would be
present in the same suite.
To ensure that we could comply with the GPL's requirements for source
availability, the kernel patch system supported multiple series files
that could each add and remove patch files. Each Debian revision
based on the same upstream version would add a new series file, and
the source could be patched to the current or an older "patchlevel".
This became obsolete once we started building kernel udebs directly,
and the patch system has since been entirely replaced with quilt.
The sections currently go:
- 4.1. Obtaining the Debian kernel source
- 4.2. Rebuilding official Debian kernel packages
- 4.3. Building a development version of the Debian kernel package
- 4.4. Generating orig tarball from newer upstream
- 4.5. Building a custom kernel from Debian kernel source
- 4.6. Building a custom kernel from the "pristine" kernel source
- 4.7. Out-of-tree kernel modules
It's easy to read 4.1 (which says to install linux-source-<version>)
as preparation for 4.2, which it is not.
Move sections 4.2-4.4, all relating to the official packages, after
all the other sections, which really are more likely to be common
tasks.
The Japanese string translations haven't been updated since 2015,
except where I updated untranslated text such as URLs. As a result,
the Japanese version of the manual currently contains a lot of text in
English. Until this is fixed, stop building the translated manual and
package.
The kernel team has been encouraging use of DKMS since the "squeeze"
release, and far more modules are now packaged for use with it. So
list DKMS first.
Since "m-a a-i" covers the entire process, it doesn't seem very
helpful to give the long explanation as well. We already refer to the
module-assistant documentation for details.
These binary module packages were built from the
linux-modules-{extra,contrib,nonfree}-2.6 source package, which were
dropped before the squeeze release(!).
nvidia-graphics-modules carried on building binary module packages
for a while, but was dropped before the stretch release.
We currently only talk about asking submitters to report to an
upstream bug tracker. However, in most cases bugs should be reported
to a mailing list, and this can be done by a maintainer.
- Generalise the "Analysis by maintainer" and "Testing by submitter"
headings to "Responsibility of the {maintainer,submitter}"
- Add a subsection explaining how to find the right place, including
the stable mailing list
- Add forwarding to a mailing list under "Responsibility of the
maintainer"
- Change the text about reporting to an upstream bug tracker to
refer to the new subsection
bugzilla.kernel.org is not that popular with upstream maintainers and
shouldn't be assumed as the default bug tracker. The MAINTAINERS file
now has B: entries identifying where bugs should be sent.
The current instructions, mentioning only build-essential, are long
outdated. Add all the possible build-dependencies in the current
upstream version. Also put the package installation in a separate
paragraph rather than combining it with fetching sources.
I removed support for tarballs and patches in genorig.py, because it
was no longer being tested and didn't include signature verification.
While it will still work in existing stable releases, it shouldn't be
recommended here.
While doing this, also mention that remote Git URLs will work in
bookworm onward.
