The "recommends" field set in the [image] section for these
configurations overrode the field at the top level. We want
gencontrol.py to concatenate the relations in this section at all
levels.
The ConfigCore.get_merge method supports doing this, but only with
list fields So we need to specify in the config schema that these
fields are comma-separated lists.
It is no longer possible to run the "setup" rules without a compiler,
because Kconfig symbols can depend on compiler properties. Add a way
to invoke just the first step of setup, which merges the kconfig files
and overrides together.
With the recent refactor, setting source: false in debian/config/defines
is no longer enough to disable the linux-source-$ver package build, as
dh_listpackages is used to determine what is built.
Do not add linux-source-$ver to d/control if it is disabled.
The packages we should build are restricted by:
* Package configuration in debian/config (limits which binary packages are
included in debian/control)
* Architecture (specified per package in debian/templates/control.* and
then in debian/control)
* Build profile (specified per package in debian/templates/control.* and
then in debian/control)
The logic for these restrictions is currently repeated in
debian/rules.real, but sometimes it becomes inconsistent with
debian/control (as with my recent changes for libbpf).
dh_listpackages reads debian/control and filters it by the current
host architecture and build profiles, so that it reliably reports
which packages we should build.
Therefore:
* Replace the logic in debian/rules.real with checks for package names
in the output of dh_listpackages
* Remove the redundant flag variables passed by debian/rules and
debian/rules.gen
* Remove the special-casing of stage1 in debian/rules and
debian/rules.gen
CONFIG_DEBUG_INFO and CONFIG_MODULE_SIG are added in gencontrol.py,
so be consistent with that.
This unfortunately requires some ugly escaping of quotes.
Gencontrol.parse_changelog() makes a list of all Debian versions with
the same upstream version, but doesn't use it. This is left over from
the old multiple-series patch system which was removed in 2012.
- Add explicit imports for all needed modules, rather than indirectly
(accidentally!) importing them with "from ... import *"
- Replace all "from ... import *" statements, which inhibit static
checking, with explicit lists of names to import
- Delete the remaining unneeded imports reported by pyflakes
Fix coding style violations reported by pycodestyle. This is
mostly a matter of reformatting code, particularly to eliminate
over-long lines. I also rename one variable ("l" is considered
visually ambiguous) and change a bare "except" to explicitly
catch all exceptions.
There are three types of error or warning remaining:
- debian/bin/...: E402 module level import not at top of file
Scripts in debian/bin need to modify the import path before
importing from debian/lib/python.
- E127 continuation line over-indented for visual indent
This seems to be a false positive. pycodestyle doesn't seem to be
happy with any level of indent (including 0) on a continuation line
in a "with" statement.
- debian/lib/python/debian_linux/debian.py:15:2: W291 trailing whitespace
This is a false positive. The trailing spaces are in a long
string and are intentional.
Merge the configuration and default-configuration directories,
using per-architecture overrides in package-list.
This requires a newer version of kernel-wedge to support
Depends_<arch> properly.
The only immediate change to debian/control is to remove the
different description for nic-modules on sparc64.
In Linux 4.18, various compiler version and feature tests are invoked
via kconfig rather than via kbuild. This means that we generally
cannot generate kconfig files for foreign architectures.
Move the config files to a new linux-config-<version> package which is
arch-dependent (and also M-A: same).
Make linux-config-<version> and linux-source-<version> recommend each
other.
Add a new "pkg.linux.nosource" to let users disable building the
linux-source-* package, and allow to set "source: false" to modify
the default behaviour when no rofile is used.
When doing development builds this can save up to 15 minutes of build
time, especially on IO-strapped build workers.
We don't want to include "-4.9" in them twice. Add a "source_basename"
template variable that excludes any version suffix in the source package
name.
(cherry picked from commit f3c51efdd6e9d0ce32ee5a0f998fdcda930a715c)
For master, nothing is immediately broken without this. Also we have
no longer build a linux-manual package. Change the changelog text
accordingly.
We already had support for disabling the tools build, used by
src:linux-grsec. However in this case, where we're using a different
based version to src:linux, we do still need to build the versioned
tools packages (linux-kbuild-4.9 and linux-perf-4.9). Split the
control template, config setting and rules accordingly.
(cherry picked from commit cb62c945f27ddee476631fa85c6aa67e50ed3bee)
The obvious way to do this is to edit the PATH in .kernelvariables.
But this obvious way doesn't work due to a bug in make (#895835).
(cherry picked from commit 4c6213fbbbff44710dda2091a7b26e0f0ea0a610)
debhelper no longer fully trusts the package list specified with -p,
but only processes packages that are listed in debian/control and
enabled in the current build profile. This breaks the test build of
udebs that we build for real after code signing.
Work around this by adding the udebs to the control file, conditional
on a new build profile (pkg.linux.udeb-unsigned-test-build). Override
the build profile during the test build.
I just made this change for firmware-nonfree, for which I wrote:
We open some, but not all, files with an explicit UTF-8 encoding. One
of the open calls that I missed has just caused gencontrol.py to fail
instead a pbuilder environment. Instead of continuing to set an
explicit encoding for each open call, use locale.setlocale to set it
globally.
I haven't hit such a problem here, but let's do it anyway.
Keep using explicit encodings in debian/lib for now, since we can't
assume all calling programs will set the locale.
dak currently allows a binary upload to include debug symbol packages
that don't appear in the overrides file or the Binary field of the
changes file, so long as they have the appropriate
'Auto-Built-Package' field and their name matches another binary
package in the upload plus the '-dbgsym' suffix.
For architectures with code signing enabled, our binary uploads never
match this condition as the corresponding binary package has the
'-unsigned' suffix and the debug symbols package does not. Since we
do list the debug symbol packages in the Binary field, they do get
added to the overrides file when accepted through the NEW queue, but
they are automatically pruned from there some time later. Later
uploads then have to go through NEW even though they are not
introducing new binary packages. This would be a big problem for
stable security updates.
For now, move debug symbols back to the main archive with the old
'-dbg' suffix. Keep them enabled for all architectures.
This reverts commit 99d37f9b16, which
caused most binary uploads to be rejected. dak's allows upload of
debug symbol packages not listed in the Binary field only if there is
a corresponding binary package without the -dbgsym suffix, which is
not the case on architectures where we use a -unsigned suffix.
Any packages listed in debian/control that are not installed in the
main archive will always be seen as NEW. This might be fixable by
archive configuration changes, but for now we'll generate them in a
similar way to debhelper.
Include headers for all architectures that we build a kernel for.
This allows co-installation of per-flavour header packages for
multiple Debian architectures, and fixes the problem of arm64 headers
depending on arm headers that we did not include.
By default dpkg-architecture lets the current environment override the
architecture specified by the -a option. We mustn't let that happen
here as we are considering all architectures. Use the -f option to
force use of our specified architecture.
The current cross-compiler packages don't set the Multi-Arch field, so
specify that the cross-compiler package must be native, rather than any
architecture.
flex doesn't support multi-arch, and this would require splitting it
(#611230, #761449). Force use of the native package for now.
openssl doesn't support multi-arch but probably easily could (#827028).
Force use of the native package for now.
We need the native libssl-dev while building the kernel itself and the
host libssl-dev while building tools for linux-kbuild.
Document the state of cross-building in README.source.
These packages will be taken over by src:linux-signed. Still do
everything but building the packages so we find configuration
errors before building linux-signed.
Bastian Blank
Ben Hutchings
Luca Boccassi
Roger Shimizu