Currently the linux-source-<version> package may or may not include
these files, depending on the order things are built in.
As autotools always modifies the source directory, copy (rsync) the
source to the build directory and build in-place there.
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