With the new host tools path filtering, aufs-utils-native fails to build
as follows:
| ERROR: oe_runmake failed
| cc
| -isystem/build/tmp/work/x86_64-linux/aufs-util-native/3.14+gitAUTOINC+b59a2167a1-r0/recipe-sysroot-native/usr/include
| -O2 -pipe -O -Wall
| -I/build/tmp/work/x86_64-linux/aufs-util-native/3.14+gitAUTOINC
+b59a2167a1-r0/git/include
| -I/build/tmp/work/x86_64-linux/aufs-util-native/3.14+gitAUTOINC+b59a2167a1-r0/git/libau
| -D_GNU_SOURCE -I./libau -DAUFHSM_CMD=\"/usr/bin/aufhsm\"
| -DMOUNT_CMD=\"/bin/mount\" -DUMOUNT_CMD=\"/bin/um
ount\"
| -L/build/tmp/work/x86_64-linux/aufs-util-native/3.14+gitAUTOINC+b59a2167a1-r0/recipe-sysroot-native/usr/lib
| -L/build/tmp/work/x86_64-linux/aufs-util-native/3.14+gitAUTOINC+b59a2167a1-r0/recipe-sysro
ot-native/lib
| -Wl,-rpath-link,/build/tmp/work/x86_64-linux/aufs-util-native/3.14+gitAUTOINC+b59a2167a1-r0/recipe-sysroot-native/usr/lib
| -Wl,-rpath-link,/build/tmp/work/x86_64-linux/aufs-util-native/3.14+gi
tAUTOINC+b59a2167a1-r0/recipe-sysroot-native/lib
| -Wl,-rpath,/build/tmp/work/x86_64-linux/aufs-util-native/3.14+gitAUTOINC+b59a2167a1-r0/recipe-sysroot-native/usr/lib
| -Wl,-rpath,/build/tmp/work/x86_64-linux
/aufs-util-native/3.14+gitAUTOINC+b59a2167a1-r0/recipe-sysroot-native/lib
| -Wl,-O1 c2sh.c -o c2sh
| make: cc: Command not found
| <builtin>: recipe for target 'c2sh' failed
While we could get 'cc' added to the tools whitelist, it is just as easy
to redefine CC to be gcc, which is already passed through.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
During runtime testing of meta-cloud-services several python scripts were
continunously segfaulting the interpreter. corefiles and gdb pointed at
the greenlet implementation.
Moving to 0.4.1 fixed the segfaults, and showed no regressions.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
A minimum dnsmasq version of 2.5.9 is required deal with IPv6 link local
addresses. So instead of just going to the minimum version, we can go
all the way to 2.6.3.
As part of this update, the following changes have been made in addition to
the pure version update:
- PR is dropped in favour of PRSERVER functionality
- dhcp_release is added to the default build, since it is used in the
cleanup phase for virtual machines.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Joe MacDonald <joe@deserted.net>
netcf was orginally introduced in meta-virtualization, since it provides
functionality required by libvirt, but it is otherwise not bound to
virtualization.
So we can move it to meta-networking, and in the process uprev to the
the latest 0.2.3 functinality.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Joe MacDonald <joe@deserted.net>
The compilation routine for the kernel has an explicit call to
build version.h, which works fine for most kernels, but the
location of it has recently changes.
commit d183e6f5 [UAPI: Move linux/version.h]
commit 10b63956 [UAPI: Plumb the UAPI Kbuilds into the user
header installation and checking]
moves the file to include/generated/linux/version.h and then to
include/generated/uapi/linux/version.h.
As a result kernel builds of 3.7 or bisection builds of intermediate
kernel commits will fail with:
make[2]: *** No rule to make target `include/linux/version.h'. Stop.
Making the explicit version.h build conditional on the version, or
via a file test would fix the problem, but it introduces some complexity
to the build.
Even without an explicit call to build version.h, it is always produced
by the kernel build, so it can simply be removed.
This extra make line was originally so that the kernel version could be
determined, so that then different instructions could be executed depending
on whether it was a 2.4 or 2.6 kernel. Since we no longer support 2.4, this
code is no longer needed.
[YOCTO: #3293]
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the kernel version string uses characters or symbols that
need to be santized for the package name, we can end up with a
mismatch between module requirements and what the kernel
provides.
The kernel version is pulled from utsrelease.h, which contains
the exact string that was passed to the kernel build, not
one that is santized, this can result in:
echo "CONFIG_LOCALVERSION="\"MYVER+snapshot_standard\" >> ${B}/.config
<build>
% rpm -qp kernel-module-uvesafb-3.4-r0.qemux86.rpm --requires
update-modules
kernel-3.4.3-MYVER+snapshot_standard
% rpm -qp kernel-3.4.3-myver+snapshot-standard-3.4-r0.qemux86.rpm --provides
kernel-3.4.3-myver+snapshot-standard = 3.4-r0
At rootfs assembly time, we'll have a dependency issue with the kernel
providing the santizied string and the modules requiring the utsrelease.h
string.
To not break existing use cases, we can add a second provides to the
kernel packaging with the unsantized version string, and allowing the
kernel module packaging to be unchanged.
RPROVIDES_kernel-base += "kernel-${KERNEL_VERSION}"
% rpm -qp kernel-3.4.3-myver+snapshot-standard-3.4-r0.qemux86.rpm --provides
kernel-3.4.3-MYVER+snapshot_standard
kernel-3.4.3-myver+snapshot-standard = 3.4-r0
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
The kernel source tree in the sysroot has all unecessary source
code removed. The existing use case is to support module building
out of the sysroot, but as more toolsa are moved into the kernel
tree itself there are new use cases for the kernel sysroot source.
To avoid putting dependencies on the kernel, and to be able to
individually build and package these tools out of the source tree,
we can save $kerndir/tools and $kernddir/lib from being removed.
This enables tools like perf to be built our of the kernel source
in the sysroot, without significantly increasing the amount of
source in the sysroot.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
For kernel's that use a split source/object build the copy
of defconfig to {S} in the base kernel class is problematic.
The previous solution for this was to override the do_configure
of the base kernel class in a subclass. While this is still
a viable/valid option, it does mean that changes to the base
do_configure will be missed.
The solution to this is to copy a defconfig to {B} which is
typically the same as {S}, so most kernel recipes won't see or
care about this change.
With this change in place, linux-yocto.bbclass can drop its
override of do_configure.
Tested with linux-yocto and oe linux recipes.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Bruce Ashfield