linux/poky.git/meta/classes, branch 1.4_M6.rc1

ptest bug fixes

2013-04-11T11:20:38+00:00

Move ${PN}-ptest to start of PACKAGES to ensure all ptest files are packaged in the -ptest package. Add QA exclusions to insane.bbclass to ensure -ptest packages can contain any files they need. Disable ptest for native packages. Don't emit errors on missing _ptest functions. (From OE-Core rev: 01bea4ef932e46eb2fcc8b4be7ff5e2b5b2a0978) Signed-off-by: Björn Stenberg Signed-off-by: Anders Roxell Signed-off-by: Josep Puigdemont Signed-off-by: Richard Purdie

kernel.bbclass: do_strip: allow recipes to strip the kernel

2013-04-11T08:03:24+00:00

Allow recipes to specify sections to be stripped from the kernel output using KERNEL_IMAGE_STRIP_EXTRA_SECTIONS. For example: KERNEL_IMAGE_STRIP_EXTRA_SECTIONS = ".comment .unwanted" The kernel output is stripped in place. Since the toolchain does not give indication when the specified sections are absent, we read the sections first and make this report by issuing a warning to the developer. The toolchain by default strips the image with the -s option (even when -s is not specified): -s --strip-all Remove all symbol and relocation information For example, these sections are always removed: .debug_aranges .debug_info .debug_abbrev .debug_line .debug_frame .debug_str .debug_loc .debug_ranges .symtab .strtab In addition to these, the sections listed in KERNEL_IMAGE_STRIP_EXTRA_SECTIONS will also be removed. Only stripping of vmlinux (elf) is supported at this time. A warning will be given if the image type is not vmlinux. Stripping the image could also be done in the kernel, but that would only work for linux-yocto based kernels, so it's not the route we decided to go. [YOCTO 3515] (From OE-Core rev: 5f6d33b05b4e7883f2728ca812cb5386d1e36989) Signed-off-by: Bruce Ashfield Signed-off-by: Michel Thebeau Signed-off-by: Richard Purdie

postinst-intercepts, qemu.bbclass: fix segfaults in postinstalls

2013-04-10T11:56:52+00:00

Postinstalls that use qemu are throwing a segmentation fault when building for qemux86-64 on a 64bit host (it might also happen for qemux86 if building on a 32bit host but I didn't test). It looks like qemu looks for ld.so.cache which is not found because it is generated after rootfs_(rpm|ipk|deb)_do_rootfs is called and then it tries to load libraries from the default paths (which are the host's). In order to avoid this, pass the LD_LIBRARY_PATH explicitly to the target's dynamic loader. (From OE-Core rev: 48e8b613b3f5c7b1d917bf3147606d44072ce49e) Signed-off-by: Laurentiu Palcu Signed-off-by: Richard Purdie

update-rc.d: correctly look up the initscript params with overrides

2013-04-10T11:56:52+00:00

The creation of a clone of d with extra OVERRIDES was removed in 72c1fd72d3b479c728e249eaa763116d352e945b but some of the lookups are essential so that variables such as ${INITSCRIPT_PARAMS} get overriden and resolved correctly on a per-package basis. [ YOCTO #3960 ] (From OE-Core rev: b016bc9aaabc90fe4dc98af8c5e73dfcb4526ef4) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

classes/license: remove outdated comment

2013-04-10T08:23:18+00:00

Package listing was implemented in the deb backend some time ago. (From OE-Core rev: e2915b6e1d2088d3a791bf629dabc58f38940961) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

systemd.bbclass: restart service in postinst, not start

2013-04-09T17:09:14+00:00

When upgrading packages it's possible that the service is already running because opkg doesn't actually execute the prerm hooks on upgrades, which is where the service should be stopped. Handle this case by restarting in postinst instead of starting. If the service isn't already running then this doesn't make a difference, but if it is running then the service will be restarted. [ YOCTO #4213 ] (From OE-Core rev: 319ef0df4ae7ed0372eff90e11244123eccb023c) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

base.bbclass: Fix matching of MACHINEOVERRIDES in COMPATIBLE_MACHINE

2013-04-09T12:19:43+00:00

The use of SOC_FAMILY here is old code and SOC_FAMILY is now implemented by MACHINEOVERRIDES behind the scenes. It therefore makes more sense to use the replacement value in this code. Just like SOC_FAMILY, this is a ":" delimited variable so we should iterate over the components, not use the value directly. Finally, MACHINEOVERRIDES contains MACHINE so we don't need to check that directly. This makes the functionality match what most users would expect it to do and is also compatible with the way things previously worked. (From OE-Core rev: 8ceef74dd4f662b4c7e3c170ce486e966ebebeff) Signed-off-by: Otavio Salvador Signed-off-by: Richard Purdie

classes/buildhistory: fix interaction with rm_work

2013-04-09T12:16:52+00:00

Change do_write_srcrevs to a postfunc of do_fetch, avoiding a dependency being created that causes large numbers of setscene tasks being executed on every build with both buildhistory and rm_work being enabled. (From OE-Core rev: a751e9042dfffcc5c4701634a1f1f598012d609c) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

kernel.bbclass: do_sizecheck: update path to build image and do not delete

2013-04-08T21:26:24+00:00

do_sizecheck has a few issues especially with vmlinux image type. It breaks because KERNEL_OUTPUT is a path relative to ${B}. When do_sizecheck runs it does not find the file (because the working directory is elsewhere) and does not fail. Also, the image file referenced by KERNEL_OUTPUT may be a link. Finally, when do_sizecheck deletes the oversized kernel image it leaves the previously run do_compile task with inaccurate status. So, do the following: - specify that the working directory should be ${B} - use ls -L to reference to the real file, and ensure that the link file is created - keep the oversized image file so the status of do_compile is valid [YOCTO #3514] (From OE-Core rev: f0b19ddce3c92c5d06976cf73d4c4c480e053dff) Signed-off-by: Bruce Ashfield Signed-off-by: Michel Thebeau Signed-off-by: Richard Purdie

image.bbclass: fix postinstall intercepts fallback

2013-04-08T15:56:46+00:00

The wrong type of paranthesis was used so 'continue' did nothing (was in another context) and the packages were marked as installed. (From OE-Core rev: 0bdde53e885aae3506c7b070b6e21f64a7cd4115) Signed-off-by: Laurentiu Palcu Signed-off-by: Richard Purdie