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.
For userland we already got this through dpkg-buildflags, but it uses
the current directory rather than the source package's top directory
as the default 'old' path. Set DEB_BUILD_PATH to fix this.
- Add python-sphinx and python-sphinx-rtd-theme to Build-Depends-Indep
- Install files from both HTML output directories into the package
- Exclude RST sources from the package
usbip has its own version number which we combine with the source
package version, which is assigned to VERSION for the install-usbip
target (only). We find the version number by processing the config.h
file created by autoconf. The file always exists before the
install-usbip rule is invoked, but the target-specific definition of
VERSION is still evaluated whenever debian/rules.real is used,
resulting in confusing (though harmless) error messages about a
missing file.
We could change VERSION to be a recursively-expanded variable, but
then it would still be evaulated multiple times. Instead, move the
definition of VERSION into the target's commands.
Pass $(CROSS_COMPILE) or host GNU type through to upstream build rules.
debian/rules.real: Filter tools packages by host arch, not build arch
debian/rules.d/Makefile: Build the tools needed for headers_install in
a separate subdirectory
Currently we build-depend on the native python (via asciidoc), and on
the host python (via python-dev). As these are not coinstallable it
is impossible to perform a complete cross-build. Until that's resolved,
this will allow cross-building of most of the package with the
combination of the 'cross' and 'nopython' profiles.
(This also sidesteps the issue of perf wanting a multilib compiler.)
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.
Where we include the 'version' in paths, it needs to be what
debian/rules.real calls UPSTREAMVERSION (no -rcN, no Debian revision).
(We should really make the naming of version variables consistent
across all our makefiles.)
Our signing certificate isn't included in the source tarball and would
be pointless to include in custom kernels. Custom kernels also won't
have a separate signing stage. So remove our settings for
CONFIG_MODULE_SIG_ALL, CONFIG_MODULE_SIG_KEY and
CONFIG_SYSTEM_TRUSTED_KEYS. This should cause custom kernels based on
the included configs to follow the upstream default for signing, which
is to use a new key pair for each build.
* Rename the make macro from submake to make-tools
* Rename debian/stamps/build to debian/stamps/build-tools
* Build them all under debian/build/build-tools/
* Drop redundant gitignore.patch from linux-tools
* Rename linux-tools' debian/templates/control.main.in to
debian/templates/control.tools.in
* Combine changelogs, putting all entries for each upstream release
cycle in chronological order
* Combine rules and gencontrol.py code
Ben Hutchings
Mattia Dongili