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.
Fully disable building and installing any documentation when the nodoc
build-profile is used.
Among other things this will help reducing build times when doing
development builds, especially on IO-limited build workers.
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)
If building with CONFIG_MODULE_SIG_ALL and CONFIG_DEBUG_INFO the
objcopy call that adds the debuglink has the side-effect of removing
the signature added to the kernel module. Let's explicitly sign the
installed modules again in that case.
Closes: #852715
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.
It has a lintian error (non-empty-dependency_libs-in-la-file) and it
also seems to be missing a header (the newly added
usbip_host_common.h) since Linux 4.7. No-one seems to have noticed,
and it has nothing build-depending on it, so get rid of it.
The upstream doc build system still implements the old mandocs target,
but it's now a no-op. Stop using it, as it will presumably be removed
at some point.
Revert to running dh_installdocs unconditionally, although that
currently installs more than we want (which is permitted by policy).
When we upgrade to debhelper compat level 11, dh_installdocs will
become sensitive to the profile and will install only the copyright
file in this case. But we shouldn't do that until development of
this level is complete and supported in stretch-backports.
This reverts commit 85b468262e "Remove unused liblockdep packaging"
and 87d08943da "liblockdep: Stop trying to build packages, as it
failed to build again", but doesn't restore the patches. All our
patches, and further build fixes, were applied upstream as of
v4.13-rc1.
It has finally been removed after all docs were converted to ReST format.
As there is no longer a way to build manpages, remove the linux-manual
package.
dh_install used to treat each given filename/pattern as space-separated
(bug #198507), and we accidentally depended on that. This was recently
fixed, leading to FTBFS.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAlkI0/kACgkQ57/I7JWG
EQkutQ/9EsYdnQXf4HaC1YTqQW0Nu5+swZzyosOcdtMfJrj+PWXQMgmY4WWav8I/
DipRGhfXXMnqlBg1vOR5cEdqPznRm/cwcuPqZpw7H0fA7LvyCibg/7yERJYv7i1U
BIy8s29NCpVVRhDhY9Nl5t0WLGQT4Rg9JW6iKNRDq2y91etahSxzOBxB2B3k04Ys
9vFPpuKq5QAskCBGEucinYYKTy7/ciIXsaSij2m/G7/ly/Qaqt0pIgjqi4QhuJs3
yWidIm1aBvE4MHXH8WQkg1aF20vfdGXz3CZNT6BWFn/6hNesS+tEQpF/nYLBqnfS
2GghqeWO1+xzxlXWNZU/SD0JhkB6gAeZ+4MP7eYz8BAtpUz7H/zZfZNsOBWb6YJY
Pc8AjqG6mBd/1B2O8yXUda/j/xazEtg0c7uxQjyOEqh2nPeHn9FVLuJsSP74wxdx
zjGmOjJzKUmhBGxLdJZAFL5N7YbLR+qNQfV2UGz4+zVIJge9R7HwWwR9+Um8AHq0
qrnjRf6iAla1phYlgHnPx4r6A9kactDuFsNMfUN8nsUrV+KX15k+dt02CpFSWw0B
lXGPf2MNXTEp+CsuAVBAWFP55JCOwD6yYoLfEfErXvchc7qqIKHgmIrLSyexro7O
F1+HBfu6t1M4tRz0xNu8sGL4uzsjockMW8RL1HFgboUluMgTFPQ=
=k/sj
-----END PGP SIGNATURE-----
Merge tag 'debian/4.9.25-1'
Drop the added patches, which are already in 4.11.
CONFIG_NFP_NETVF is replaced by CONFIG_NFP in 4.11.
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 is necessary to avoid creating files in source directory, which
makes the linux-source package unclean (and unreproducible).
Firstly, Python creates bytecode files alongside the module sources.
We can and do exclude those, though.
Secondly, starting with 4.10, Documentation/media/Makefile converts
from dot to SVG and from SVG to PDF in the source directory. These
can't easily be excluded, as SVG is also used as a source format.
Some files are moving around under Documentation and being replaced
with symlinks.
gzip -r doesn't even check for symlinks, and fails when they're broken
(which happens if the destination was found first). So use find and
xargs instead, and deal with the symlinks separately.
REPORTING-BUGS moved to Documentation/admin-guide/reporting-bugs.rst
and doesn't need to be listed separately.
Many of the ReST files in Documentation used to be plain-text and
users may want to continue reading them as such, so don't prune
*.rst.
Listing usr/sbin in linux-cpupower.install caused FTBFS on !x86 as
cpupower itself doesn't install anything there. Do the architecture
filtering in the debhelper lists instead of complicating
debian/rules.real further.
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.
Since jessie's diff returns 2 when it finds a binary (#737180) we need
to do this to avoid FTBFS in jessie-backports. Besides which, those
aren't part of the source.
(cherry picked from commit 62cce57936757e7492b082b2845e04be00cda5d2)
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.
Fixes FTBFS on sparc64:
dpkg-shlibdeps: error: no dependency information found for /usr/lib32/libc.so.6 (used by debian/linux-perf-4.9/usr/lib/perf_4.9-core/perf-read-vdso32)
Hint: check if the library actually comes from a package.
dh_shlibdeps: dpkg-shlibdeps -Tdebian/linux-perf-4.9.substvars debian/linux-perf-4.9/usr/bin/perf_4.9 debian/linux-perf-4.9/usr/lib/traceevent_4.9/plugins/plugin_xen.so debian/linux-perf-4.9/usr/lib/traceevent_4.9/plugins/plugin_hrtimer.so debian/linux-perf-4.9/usr/lib/traceevent_4.9/plugins/plugin_jbd2.so debian/linux-perf-4.9/usr/lib/traceevent_4.9/plugins/plugin_function.so debian/linux-perf-4.9/usr/lib/traceevent_4.9/plugins/plugin_mac80211.so debian/linux-perf-4.9/usr/lib/traceevent_4.9/plugins/plugin_sched_switch.so debian/linux-perf-4.9/usr/lib/traceevent_4.9/plugins/plugin_kvm.so debian/linux-perf-4.9/usr/lib/traceevent_4.9/plugins/plugin_cfg80211.so debian/linux-perf-4.9/usr/lib/traceevent_4.9/plugins/plugin_scsi.so debian/linux-perf-4.9/usr/lib/traceevent_4.9/plugins/plugin_kmem.so debian/linux-perf-4.9/usr/lib/perf_4.9-core/perf-read-vdso32 returned exit code 2
I can't see when or why this changed, but the HTML (and related) files
are now being generated in Documentation/output and not an html
subdirectory of that.
Currently on powerpc, powerpcspe and ppc64 we get an automatic dbgsym
package with symbols for the bootwrapper tools (addnote, hack-coff,
mktree). We should either put them in linux-image-*-dbgsym or
nowhere. For now, opt for nowhere.
Move the dh_strip invocation from the install-base rule to the
install-image_... rule. None of the other packages using install-base
should contain any executables.
Ben Hutchings
YunQiang Su
Bastian Blank
Luca Boccassi
Jan Blunck
Salvatore Bonaccorso