[OE-core] [PATCH 16/22] chrpath.bbclass: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 17/22] testsdk.bbclass: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 21/22] testimage.bbclass: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 18/22] libc-package.bbclass: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 14/22] useradd.bbclass: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 20/22] utility-tasks.bbclass: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 22/22] cmake: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 19/22] package.bbclass: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 15/22] sstate.bbclass: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 13/22] gtk-immodules-cache.bbclass: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 12/22] systemd.bbclass: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 09/22] gummiboot.bbclass: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 11/22] license.bbclass: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 10/22] update-rc.d.bbclass: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 07/22] syslinux.bbclass: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 08/22] systemd-boot.bbclass: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 05/22] useradd-staticids.bbclass: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 06/22] grub-efi.bbclass: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 04/22] package_rpm.bbclass: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 02/22] package_ipk.bbclass: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 03/22] package_deb.bbclass: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 01/22] base.bbclass: Use bb.fatal() instead of raising FuncFailed

This sets a good example and avoids unnecessarily contributing to perceived complexity and cargo culting. Motivating quote below: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what

[OE-core] [PATCH 00/22] Use bb.fatal() instead of raising FuncFailed

Motiving quote: < kergoth> the *original* intent was for the function/task to error via whatever appropriate means, bb.fatal, whatever, and funcfailed was what you'd catch if you were calling exec_func/exec_task. that is, it's what those functions

[OE-core] [PATCH 1/1] parselogs.py: Add disabling eDP error to x86_common whitelist

The NUC6 firmware tells the kernel to try and initialize an embedded DisplayPort it does not have, causing this warning. Its harmless, so just whitelist it. Fixes [YOCTO #9434]. Signed-off-by: California Sullivan --- meta/lib/oeqa/runtime/parselogs.py | 1 + 1

Re: [OE-core] [PATCH 1/2] classes/uboot-extlinux-config: Add class

On Sat, Oct 1, 2016 at 12:54 AM, Ulf Magnusson wrote: > On Fri, Sep 30, 2016 at 10:33 PM, Fabio Berton > wrote: >> This class allow the extlinux.conf generation for U-Boot use. >> The U-Boot support for it is given to allow the Generic

Re: [OE-core] [PATCH 1/2] classes/uboot-extlinux-config: Add class

On Fri, Sep 30, 2016 at 10:33 PM, Fabio Berton wrote: > This class allow the extlinux.conf generation for U-Boot use. > The U-Boot support for it is given to allow the Generic Distribution > Configuration specification use by OpenEmbedded-based products. > > This

Re: [OE-core] [PATCH] gmock: fixed installing pkgconfig file and libraries on x86_64 architecture

On 30 September 2016 at 23:18, Mateusz Nowakowski < mateusz.cz.nowakow...@gmail.com> wrote: > Signed-off-by: Mateusz Nowakowski > As this is for meta-oe, the patch should go to openembedded-de...@lists.openembedded.org. Thanks, Ross --

[OE-core] [PATCH 2/2] u-boot: Add support to use uboot-extlinux-config class

Use uboot-extlinux-config class to create extlinux.conf file and then install inside /boot/extlinux directory and also put file to deploy dir. This file will be only create if UBOOT_EXTLINUX is set to 1. You can use DEPLOYDIR/extlinux.conf file to install into final image using wic setting:

[OE-core] [PATCH 1/2] classes/uboot-extlinux-config: Add class

This class allow the extlinux.conf generation for U-Boot use. The U-Boot support for it is given to allow the Generic Distribution Configuration specification use by OpenEmbedded-based products. This class can be inherited by u-boot recipes to create extlinux.conf and boot using menu options.

[OE-core] [PATCH] gmock: fixed installing pkgconfig file and libraries on x86_64 architecture

Signed-off-by: Mateusz Nowakowski --- .../gmock/cmake-Add-install-command-for-libraries-and-headers.patch | 4 ++-- .../gmock/gmock/cmake-gmock.pc.in-Add-pkg-config-support.patch | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git

[OE-core] [PATCH 0/1] Avoid unnecessary dependency on awk in devtool deploy-target

After updating to Krogoth, our developers were faced with the following error message when using devtool deploy-target: /tmp/devtool_deploy.sh: line 23: awk: not found This is of course due to the fact that we do not have awk installed in our products. However, the use of awk in devtool

[OE-core] [PATCH 1/1] devtool: deploy-target: Avoid unnecessary dependency on awk on the target

Relying on that awk is installed on the target just to extract the fourth column (i.e., the free volume size) from `df -P` is an unnecessary dependency for devtool deploy-target. As it is already using sed to mangle the output from `df -P`, this can easily be modified to only extract the free

Re: [OE-core] [PATCH][jethro] rootfs: Modify RPM installation

On 07/08/2016 02:57 AM, David Vincent wrote: When using a custom RPM data directory instead of the default dir '/var/lib/rpm', the final image did not contain any of the database files in the expected location. This commit takes into account the 'rpmlibdir' variable set into

Re: [OE-core] -c menuconfig stopped working in master

Nevermind, the bug I'm experiencing is different, but also related to python 3. I'll submit a patch. 2016-09-30 20:47 GMT+01:00 Renato Caldas : > Hi Leonardo, > > Sorry for yet another ping, but do you have the patch at hand? > > 2016-09-22 17:50 GMT+01:00 Renato

Re: [OE-core] -c menuconfig stopped working in master

Hi Leonardo, Sorry for yet another ping, but do you have the patch at hand? 2016-09-22 17:50 GMT+01:00 Renato Caldas : > 2016-06-09 20:58 GMT+01:00 Leonardo Sandoval > : >> Yes, this is related to the python3 change. I have

[OE-core] [PATCH] linux-yocto/4.8: mmc configuration for x86*

Updating the common-pc* configuration to have the following mmc configs available by default: meta/common-pc-64: use mmc-sdhci feature meta/common-pc: use mmc-sdhci feature meta: add mmc/mmc-sdhci feature meta: add mmc/mmc-block feature meta: add mmc/base feature Signed-off-by: Bruce

[OE-core] [PATCH 2/7] allarch: Fixes to stop rebuilds when change multilibs

When changing multilibs, allarch recipes should not be rebuilding. This adds enough variable exclusions to make this work properly. Future regressions will be prevented with new testing. Signed-off-by: Richard Purdie --- meta/classes/allarch.bbclass | 5 +

[OE-core] [PATCH 3/7] multilib.conf: Ensure sstate checksums don't change when using this include

When enabling multilib.conf, the world was rebuilding due to changes in the pkg-config search path. This doesn't matter so exclude it from the checksums. Signed-off-by: Richard Purdie --- meta/conf/multilib.conf | 3 ++- 1 file changed, 2 insertions(+), 1

[OE-core] [PATCH 5/7] boost: Ensure native recipes have consistent checksums

When building boost-native on i686, the x86 override isn't applied unless the target also happens to be x86. Similarly the x86_64 override is only applied on 64 bit target machines. Avoid various problems by removing the new problematic configure options in the native case. Signed-off-by:

[OE-core] [PATCH 1/7] nativesdk: Don't enable MULTILIBS

package_write_rpm references the MULTILIBS variable and the checksums of nativesdk recipes were changing as a result of this. We don't need/want MULTILIBS values for nativesdk so disable this. Signed-off-by: Richard Purdie --- meta/classes/nativesdk.bbclass

[OE-core] [PATCH 6/7] oeqa/sstatetests: Add test for multilib allarch checksums

Switching between multilib configurations should not change allarch recipe or nativesdk checksums. Add a new sstate test for this based on the standard allarch test. Signed-off-by: Richard Purdie --- meta/lib/oeqa/selftest/sstatetests.py | 45

[OE-core] [PATCH 4/7] gcc-cross: Stop target recipes depending on SDK_SYS

gcc-cross target recipes should not depend on SDK_SYS but started to after recent changes. Remove the dependency to stop this (its caused by shared code in do_install). The compiler names contain SDK_SYS so changes would be correctly handled via other means. Signed-off-by: Richard Purdie

[OE-core] [PATCH 7/7] machine-sdk: Clear ABIEXTENSION to avoid sstate checksum mismatch issues

When switching MACHINE, nativeksdk recipes could end up being rebuilt. Clear ABIEXTENSION to avoid this problem and ensure sstate checksum consistency. Signed-off-by: Richard Purdie --- meta/conf/machine-sdk/i586.conf | 1 + meta/conf/machine-sdk/i686.conf

Re: [OE-core] [PATCH 1/3] subprocess: remove strings and migrate to direct arrays

On 29 September 2016 at 22:34, Stephano Cetola < stephano.cet...@linux.intel.com> wrote: > -cmd = "%s %s query --output %s" % \ > - (self.smart_cmd, self.smart_opt, available_manifest) > +cmd = [self.smart_cmd, self.smart_opt, 'query', '--output', >

Re: [OE-core] [PATCH] multilib_header: avoid sstate checksum issues for -nativesdk recipes

On Fri, 2016-09-30 at 08:29 -0700, akuster808 wrote: > > On 09/30/2016 02:09 AM, Joshua Lock wrote: > > > > Much as with -native recipes, as addressed in commit > > b15730caf0d4c40271796887505507f2501958bb, arch specific variables > > like MIPSPKGSFX_ABI were affecting -nativesdk sstate

[OE-core] [wic][PATCH] mkefidisk.wks: use partition UUID and GPT partition table

This is a preparation to use mkefidisk as a default wks for genericx86* BSPs. This change enables usage of partition UUID instead of device name to specify root partition in kernel command line. It should make images to boot on devices with boot device names that differ from what's mentioned in

Re: [OE-core] [PATCH] multilib_header: avoid sstate checksum issues for -nativesdk recipes

On 09/30/2016 02:09 AM, Joshua Lock wrote: Much as with -native recipes, as addressed in commit b15730caf0d4c40271796887505507f2501958bb, arch specific variables like MIPSPKGSFX_ABI were affecting -nativesdk sstate checksums for recipes like nativesdk-glibc-initial. Since commit

[OE-core] Yocto Project Status WW40

Current Dev Position: YP 2.2 M4 Next Deadline: YP 2.2 M4 which will be Oct. 3rd (5:00pm GMT) SWAT team rotation: Joshua -> Armin https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: *We're seeing a lot of good bug fixing on master, we still have quite

[OE-core] [PATCH v2] scripts: add new script 'native'

Added 'native' convenience shell script to run native tools. Example of usage: > bitbake bmap-tools-native > native bmaptool --version Signed-off-by: Ed Bartosh --- scripts/native | 48 1 file changed, 48

[OE-core] [PATCH 1/2] oe-build-perf-test: return 2 if some tests failed

Add a new return value '2' that indicates that some tests failed but there were no fatal errors (i.e. configuration mistakes or bugs in the tests themselves). Signed-off-by: Markus Lehtonen --- scripts/oe-build-perf-test | 2 +- 1 file changed, 1 insertion(+), 1

[OE-core] [PATCH 2/2] build-perf-test-wrapper.sh: accept test case failures

Utilize the new return value (2) from oe-build-perf-test. Do not exit with an error in case some individual tests fail. Even if some tests fail we still want to complete successfully, that is, display and archive the results and do cleanup. The individual tests do not depend on each other anymore

[OE-core] [PATCH 0/2] build-perf-test: improve handling of test case failures

This patchset makes build-perf-test wrapper script behave more reasonably if some build perf test cases fail. Previously, there was no distinction between failed test cases or more serious errors, e.g. runtime failures of oe-build-perf-test itself. In both cases the wrapper script just exited

[OE-core] [PATCH] multilib_header: avoid sstate checksum issues for -nativesdk recipes

Much as with -native recipes, as addressed in commit b15730caf0d4c40271796887505507f2501958bb, arch specific variables like MIPSPKGSFX_ABI were affecting -nativesdk sstate checksums for recipes like nativesdk-glibc-initial. Disable multilib_header for nativesdk as we don't use multilibs in this

[OE-core] [PATCH 1/1] grub-efi.bbclass: Add a space between root and append parameter

Add a space between the root and append parameter, similar to syslinux.bbclass, in creating the final grub.cfg. Without this, the final kernel boot parameters will concatenate into strings like root=/dev/ram0console=ttyS0... Signed-off-by: Raymond Tan ---

[OE-core] [PATCH 0/1] grub-efi.bbclass: Add a space between root and append parameter

Patch to add the missing space between root and append kernel boot parameter Raymond Tan (1): grub-efi.bbclass: Add a space between root and append parameter meta/classes/grub-efi.bbclass | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 2.9.3 --

[OE-core] [PATCH 0/1] kbd: create ptest sub-package

From: Kai Kang The following changes since commit 5d8a968ecdf40babe452b0ac63d94a7a163710ae: dev-manual: Applied review changes to GNU debugging section. (2016-09-28 15:02:33 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib

[OE-core] [PATCH 1/1] kbd: create ptest sub-package

From: Kai Kang Create kbd-ptest sub-package: * add file run-ptest and runtime dependency make * modify installed Makefile to disable remake Makefile and the test cases when run the ptest * add patch to set proper path for test cases to get resource files

Re: [OE-core] [wic][PATCH] wic: selftest: add test for mksystemd-bootdisk

On Thu, Sep 29, 2016 at 03:48:59PM +0100, Burton, Ross wrote: > On 29 September 2016 at 09:38, Ed Bartosh > wrote: > > > +def test_mksystemd_bootdisk(self): > > +"""Test creation of mksystemd-bootdisk image""" > > +image = "mksystemd-bootdisk" > >

[OE-core] [PATCH] boost: add python to default PACKAGECONFIG options

From: Jackie Huang We want to provide python libs by default, and some other popular Linux distributions like redhat/fedora does the same. Signed-off-by: Jackie Huang --- meta/recipes-support/boost/boost.inc | 2 +- 1 file changed, 1