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.)
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.
The list is getting hard to read as we add build profiles. It's also easier
to merge and cherry-pick changes when each dependency is on a separate line.
* 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
Karsten did a test-build on armhf and found failures due to missing modules
and directories.
* The wireless drivers from staging need to be optional; this requires
support for wildcards in optional-inclusion lines
* The check for a containing directory must only be done for non-optional
inclusion lines
Bump the kernel-wedge version requirement and add the optional-include
suffixes.
Currently we have xz-utils in build-depends-indep as we explicitly
use xz to compress files in linux-source. We also have a build-
dependency on lzma (now a virtual package provided by xz-utils),
but only on armel which was the first architecture for which we
set CONFIG_KERNEL_XZ=y.
However, since 3.7 we've set CONFIG_KERNEL_XZ for all architectures so
xz-utils is needed everywhere. Currently we get away with this
because dpkg-dev depends on xz-utils, but this could change in future.
Build-depend on xz-utils without qualification.
- genorig: Include new directory for usbip UAPI header
- debian/control: Update Build-Depends for usbip switching from libsysfs to libudev
svn path=/dists/trunk/linux-tools/; revision=21641
- Remove versions for debhelper, python, kernel-wedge that are satisfied by stable
- Remove module-init-tools as alternative to kmod, which is in stable
svn path=/dists/sid/linux/; revision=21117
debian/lib/python/debian_linux/debian.py,
debian/lib/python/debian_linux/patches.py,
- Support Python 3.
- Use six if necessary.
* debian/templates/control.main.in, debian/templates/control.source.in:
Depend on python-six.
svn path=/dists/trunk/linux/; revision=20946
The transition from libunwind soversion 7 to 8 is blocked and will
likely remain blocked for some time because libunwind7 is linked into
all ia64 binaries.
For amd64 and i386, downgrade the build-dependency to libunwind7-dev.
For architectures that are supported by libunwind8-dev, remove the
build-dependency and ensure we don't accidentally link with libunwind8
by setting NO_LIBUNWIND=1 when building perf.
svn path=/dists/sid/linux-tools/; revision=20755
libunwind8-dev is available but practically uninstallable on ia64, as
the default compiler version is still gcc-4.6 which depends on
libunwind7-dev and thus conflicts with it.
We could use libunwind7-dev instead, but then we only want it for perf
which we can't build for ia64 anyway!
svn path=/dists/sid/linux-tools/; revision=20741