Re: [OE-core] gcc 5.2 failures
On 15-07-27 05:30 AM, Richard Purdie wrote: I've run a gcc 5.2 test build on the autobuilder: http://errors.yoctoproject.org/Errors/Search/?items=10query=3628c3c06fa4195003ac655bcc791acfac775173limit=50 41 errors (with a few more pending). The good news is that if we tweak the security flags, the poky-lsb gcc, elfutils, coreutils and iptables issues can be removed and I have a patch for this. This leaves: 3.14 kernel failures for edgerouter, genericx86-64, qemuarm, beaglebone, mpc8315e-rdb Gah. I had all these building with 5.1 .. chasing gcc is a pain with this older kernel. openssl issue for p1022ds u-boot on imx28evk, p1022ds, mpc8315e-rdb xf86-video-imxfb-vivante on imx6qsabresd linux-imx issue on imx53qsb Some kind of random qemu runtime issue (4 cases). At this point I think we likely need to enter bugs into the bugzilla for each of these. If we want to switch 1.9 to use this (which I think is desirable), we need to get this fixed as a priority. Bruce: How do you want to handle the 3.14 issues? Switch to 4.1? or fix 3.14? Now that 4.1 is in place, and I can't really see a large user base that needs gcc 5.x with the linux-yocto 3.14 kernel (other folks using master with their own kernel's will obviously have to deal with the issue in their trees) .. join that with the fact that we need to update all the reference boards to 4.1 anyway, my suggestion is that we open bugs for the h/w reference updates (and I'll get the appropriate Wind River eyes on them) and walk away from burning more cycles on gcc 5.x and the 3.14 kernel. Cheers, Bruce Otavio: The freescale machines are looking unwell, can you help us make sure the right people know about this? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] gcc 5.2 failures
using gcc 5.1, the boost statechart library compile fail. On Mon, Jul 27, 2015 at 9:20 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: On 15-07-27 05:30 AM, Richard Purdie wrote: I've run a gcc 5.2 test build on the autobuilder: http://errors.yoctoproject.org/Errors/Search/?items=10query=3628c3c06fa4195003ac655bcc791acfac775173limit=50 41 errors (with a few more pending). The good news is that if we tweak the security flags, the poky-lsb gcc, elfutils, coreutils and iptables issues can be removed and I have a patch for this. This leaves: 3.14 kernel failures for edgerouter, genericx86-64, qemuarm, beaglebone, mpc8315e-rdb Gah. I had all these building with 5.1 .. chasing gcc is a pain with this older kernel. openssl issue for p1022ds u-boot on imx28evk, p1022ds, mpc8315e-rdb xf86-video-imxfb-vivante on imx6qsabresd linux-imx issue on imx53qsb Some kind of random qemu runtime issue (4 cases). At this point I think we likely need to enter bugs into the bugzilla for each of these. If we want to switch 1.9 to use this (which I think is desirable), we need to get this fixed as a priority. Bruce: How do you want to handle the 3.14 issues? Switch to 4.1? or fix 3.14? Now that 4.1 is in place, and I can't really see a large user base that needs gcc 5.x with the linux-yocto 3.14 kernel (other folks using master with their own kernel's will obviously have to deal with the issue in their trees) .. join that with the fact that we need to update all the reference boards to 4.1 anyway, my suggestion is that we open bugs for the h/w reference updates (and I'll get the appropriate Wind River eyes on them) and walk away from burning more cycles on gcc 5.x and the 3.14 kernel. Cheers, Bruce Otavio: The freescale machines are looking unwell, can you help us make sure the right people know about this? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] gcc 5.2 failures
On Mon, 2015-07-27 at 09:20 -0400, Bruce Ashfield wrote: On 15-07-27 05:30 AM, Richard Purdie wrote: I've run a gcc 5.2 test build on the autobuilder: http://errors.yoctoproject.org/Errors/Search/?items=10query=3628c3c06fa4195003ac655bcc791acfac775173limit=50 41 errors (with a few more pending). The good news is that if we tweak the security flags, the poky-lsb gcc, elfutils, coreutils and iptables issues can be removed and I have a patch for this. This leaves: 3.14 kernel failures for edgerouter, genericx86-64, qemuarm, beaglebone, mpc8315e-rdb Gah. I had all these building with 5.1 .. chasing gcc is a pain with this older kernel. I'm not sure if this is a 5.1 verses 5.2 issue or not. I'm starting to wonder if the SRCREVs we're using pull in the gcc 5.x fixes? E.g. one of the failures was: /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm-lsb/build/build/tmp/work-shared/beaglebone/kernel-source/include/linux/compiler-gcc.h:106:30: fatal error: linux/compiler-gcc5.h: No such file or directory which doesn't look 5.2. Bruce: How do you want to handle the 3.14 issues? Switch to 4.1? or fix 3.14? Now that 4.1 is in place, and I can't really see a large user base that needs gcc 5.x with the linux-yocto 3.14 kernel (other folks using master with their own kernel's will obviously have to deal with the issue in their trees) .. join that with the fact that we need to update all the reference boards to 4.1 anyway, my suggestion is that we open bugs for the h/w reference updates (and I'll get the appropriate Wind River eyes on them) and walk away from burning more cycles on gcc 5.x and the 3.14 kernel. That seems reasonable to me, assuming we don't have an easy SRCREV fix we've just missed/lost somehow... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] recipes-connectivity: Add iw configuration for enabling Marvell 8897 WiFi feature
On Thu, 2015-07-09 at 13:10 +0800, wei.tee...@intel.com wrote: From: Ng Shui Lei shui.lei...@intel.com iw features was created in the recipes-connectivity layer to enable Marvell 8897 module in AP mode and STA mode. iw is a new nl80211 based CLI configuration utility for wireless devices. Signed-off-by: Ng Shui Lei shui.lei...@intel.com Signed-off-by: Ng Wei Tee wei.tee...@intel.com --- sh-don-t-use-git-describe-for-versioning.patch | 40 meta/recipes-connectivity/iw/iw_3.8.bb | 27 + 2 files changed, 67 insertions(+) create mode 100644 meta/recipes-connectivity/iw/iw-3.8/0001-iw-version.sh-don-t-use-git-describe-for-versioning.patch create mode 100644 meta/recipes-connectivity/iw/iw_3.8.bb 1. How is this patch specific to the Marvell 8897 chip? 2. Did this recipe come from another layer? If so, saying where it came from would be good. 3. Why do we want iw in OE-Core. I can see a case for it but you do need to explain that here in the commit message. 4. There are some cleanliness tweaks needed (see below). diff --git a/meta/recipes-connectivity/iw/iw-3.8/0001-iw-version.sh-don-t-use-git-describe-for-versioning.patch b/meta/recipes-connectivity/iw/iw-3.8/0001-iw-version.sh-don-t-use-git-describe-for-versioning.patch new file mode 100644 index 000..f4a7ee7 --- /dev/null +++ b/meta/recipes-connectivity/iw/iw-3.8/0001-iw-version.sh-don-t-use-git-describe-for-versioning.patch @@ -0,0 +1,40 @@ +From: Koen Kooi k...@dominion.thruhere.net +Date: Tue, 29 Nov 2011 17:03:27 +0100 +Subject: [PATCH] iw: version.sh: don't use git describe for versioning + +It will detect top-level git repositories like the Angstrom setup-scripts and break. + +Upstream-status: Unknown Pending perhaps? or Inappropriate looking at what the patch does. +Signed-off-by: Koen Kooi k...@dominion.thruhere.net +--- + version.sh | 16 +--- + 1 file changed, 1 insertion(+), 15 deletions(-) + +diff --git a/version.sh b/version.sh +index db02f0d..336ce2b 100755 +--- a/version.sh b/version.sh +@@ -3,21 +3,7 @@ + VERSION=3.8 + OUT=$1 + +-if head=`git rev-parse --verify HEAD 2/dev/null`; then +-git update-index --refresh --unmerged /dev/null +-descr=$(git describe) +- +-# on git builds check that the version number above +-# is correct... +-[ ${descr%%-*} = v$VERSION ] || exit 2 +- +-v=${descr#v} +-if git diff-index --name-only HEAD | read dummy ; then +-v=$v-dirty +-fi +-else +-v=$VERSION +-fi ++v=$VERSION + + echo '#include iw.h' $OUT + echo const char iw_version[] = \$v\; $OUT diff --git a/meta/recipes-connectivity/iw/iw_3.8.bb b/meta/recipes-connectivity/iw/iw_3.8.bb new file mode 100644 index 000..29dbcd0 --- /dev/null +++ b/meta/recipes-connectivity/iw/iw_3.8.bb @@ -0,0 +1,27 @@ +# Copyright (C) 2013 Digi International. + +SUMMARY = nl80211 based CLI configuration utility for wireless devices +DESCRIPTION = iw is a new nl80211 based CLI configuration utility for \ +wireless devices. It supports almost all new drivers that have been added \ +to the kernel recently. +HOMEPAGE = http://linuxwireless.org/en/users/Documentation/iw; +SECTION = base +LICENSE = BSD +LIC_FILES_CHKSUM = file://COPYING;md5=878618a5c4af25e9b93ef0be1a93f774 + +DEPENDS = libnl pkgconfig + +PR = ${DISTRO}.r0 DISTRO in PR sounds plain wrong. + +SRC_URI = http://www.kernel.org/pub/software/network/iw/iw-${PV}.tar.bz2 \ + file://0001-iw-version.sh-don-t-use-git-describe-for-versioning.patch \ + + +SRC_URI[md5sum] = 618ad1106a196fb1c3d827de96da437c +SRC_URI[sha256sum] = 3dae92ca5989cbc21155941fa01907a5536da3c5f6898642440c61484fc7e0f9 + +EXTRA_OEMAKE = + +do_install() { + oe_runmake DESTDIR=${D} install +} -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] security-flags: Disable PIE for coreutils, elfutils, gcc, iptables
With gcc 5, we need to disable the PIE flags for more recipes in order to have successful builds. Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org diff --git a/meta/conf/distro/include/security_flags.inc b/meta/conf/distro/include/security_flags.inc index 85a3bfe..3724972 100644 --- a/meta/conf/distro/include/security_flags.inc +++ b/meta/conf/distro/include/security_flags.inc @@ -25,11 +25,10 @@ SECURITY_CFLAGS_pn-webkit-gtk_powerpc = # arm specific security flag issues SECURITY_CFLAGS_pn-lttng-tools_arm = ${SECURITY_NO_PIE_CFLAGS} -SECURITY_CFLAGS_pn-elfutils_arm = ${SECURITY_NO_PIE_CFLAGS} - SECURITY_CFLAGS_pn-aspell = ${SECURITY_NO_PIE_CFLAGS} SECURITY_CFLAGS_pn-beecrypt = ${SECURITY_NO_PIE_CFLAGS} SECURITY_CFLAGS_pn-blktrace = ${SECURITY_NO_PIE_CFLAGS} +SECURITY_CFLAGS_pn-coreutils = ${SECURITY_NO_PIE_CFLAGS} # Curl seems to check for FORTIFY_SOURCE in CFLAGS, but even assigned # to CPPFLAGS it gets picked into CFLAGS in bitbake. #TARGET_CPPFLAGS_pn-curl += -D_FORTIFY_SOURCE=2 @@ -39,10 +38,12 @@ SECURITY_CFLAGS_pn-db = ${SECURITY_NO_PIE_CFLAGS} SECURITY_CFLAGS_pn-directfb = ${SECURITY_NO_PIE_CFLAGS} SECURITY_CFLAGS_pn-glibc = SECURITY_CFLAGS_pn-glibc-initial = +SECURITY_CFLAGS_pn-elfutils = ${SECURITY_NO_PIE_CFLAGS} SECURITY_CFLAGS_pn-enchant = ${SECURITY_NO_PIE_CFLAGS} SECURITY_CFLAGS_pn-expect = ${SECURITY_NO_PIE_CFLAGS} SECURITY_CFLAGS_pn-flac = ${SECURITY_NO_PIE_CFLAGS} SECURITY_CFLAGS_pn-flex = ${SECURITY_NO_PIE_CFLAGS} +SECURITY_CFLAGS_pn-gcc = ${SECURITY_NO_PIE_CFLAGS} SECURITY_CFLAGS_pn-gcc-runtime = ${SECURITY_NO_PIE_CFLAGS} SECURITY_CFLAGS_pn-gcc-sanitizers = ${SECURITY_NO_PIE_CFLAGS} SECURITY_CFLAGS_pn-gdb = ${SECURITY_NO_PIE_CFLAGS} @@ -60,6 +61,7 @@ SECURITY_CFLAGS_pn-gstreamer1.0-plugins-bad = ${SECURITY_NO_PIE_CFLAGS} SECURITY_CFLAGS_pn-gstreamer1.0-plugins-good = ${SECURITY_NO_PIE_CFLAGS} SECURITY_CFLAGS_pn-harfbuzz = ${SECURITY_NO_PIE_CFLAGS} SECURITY_CFLAGS_pn-kexec-tools = ${SECURITY_NO_PIE_CFLAGS} +SECURITY_CFLAGS_pn-iptables = ${SECURITY_NO_PIE_CFLAGS} SECURITY_CFLAGS_pn-libaio = ${SECURITY_NO_PIE_CFLAGS} SECURITY_CFLAGS_pn-libcap = ${SECURITY_NO_PIE_CFLAGS} SECURITY_CFLAGS_pn-libgcc = ${SECURITY_NO_PIE_CFLAGS} -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] nativesdk-qt4-tools: depend on nativesdk-qt4-tools only if DISTRO_FEATURES includes x11
Currently nativesdk-qt4-tools can't be built if the DISTRO_FEATURES doesn't contain x11. To make it build we add a dependency to x11 only if the feature is activated. Signed-off-by: Pascal Bach pascal.b...@siemens.com --- meta/recipes-qt/qt4/nativesdk-qt4-tools.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc b/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc index 1c9ee2e..1adad31 100644 --- a/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc +++ b/meta/recipes-qt/qt4/nativesdk-qt4-tools.inc @@ -1,5 +1,5 @@ SUMMARY = SDK tools for Qt version 4.x -DEPENDS = nativesdk-zlib nativesdk-dbus nativesdk-libx11 qt4-native +DEPENDS = nativesdk-zlib nativesdk-dbus qt4-native ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'virtual/nativesdk-libx11', '', d)} SECTION = libs HOMEPAGE = http://qt-project.org/; LICENSE = LGPLv2.1 | GPLv3 -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] gcc 5.2 failures
On Monday 27 July 2015 09:31:01 Bruce Ashfield wrote: On 15-07-27 09:20 AM, Bruce Ashfield wrote: On 15-07-27 05:30 AM, Richard Purdie wrote: I've run a gcc 5.2 test build on the autobuilder: http://errors.yoctoproject.org/Errors/Search/?items=10query=3628c3c06fa4 195003ac655bcc791acfac775173limit=50 41 errors (with a few more pending). The good news is that if we tweak the security flags, the poky-lsb gcc, elfutils, coreutils and iptables issues can be removed and I have a patch for this. This leaves: 3.14 kernel failures for edgerouter, genericx86-64, qemuarm, beaglebone, mpc8315e-rdb Gah. I had all these building with 5.1 .. chasing gcc is a pain with this older kernel. openssl issue for p1022ds u-boot on imx28evk, p1022ds, mpc8315e-rdb xf86-video-imxfb-vivante on imx6qsabresd linux-imx issue on imx53qsb Some kind of random qemu runtime issue (4 cases). At this point I think we likely need to enter bugs into the bugzilla for each of these. If we want to switch 1.9 to use this (which I think is desirable), we need to get this fixed as a priority. Bruce: How do you want to handle the 3.14 issues? Switch to 4.1? or fix 3.14? Now that 4.1 is in place, and I can't really see a large user base that needs gcc 5.x with the linux-yocto 3.14 kernel (other folks using master with their own kernel's will obviously have to deal with the issue in their trees) .. join that with the fact that we need to update all the reference boards to 4.1 anyway, my suggestion is that we open bugs for the h/w reference updates (and I'll get the appropriate Wind River eyes on them) and walk away from burning more cycles on gcc 5.x and the 3.14 kernel. And of course, I remembered that we updated all the reference boards to 3.19, so if 3.19 builds with gcc 5.2 (it may not), then all we need to do is move the lsb reference to 4.1 and we'll also be free of backporting :) It would be nice if we were able to point to a set of fixes that people can apply onto their older kernels in the migration guide for 1.9 though - I guarantee we'll get people asking... Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 10/11] oeqa/selftest/imagefeatures: remove gummiboot tests
These tests were _deleting_ meta-intel if it happened to appear under COREBASE, which could have been catastrophic if there was any work in progress in that directory. It turns out we don't even need meta-intel, but we do need a machine that's set up appropriately (e.g. genericx86-64). Tests that involve layers outside of OE-Core don't really belong in OE-Core, and genericx86-64 is in meta-yocto-bsp; however we will soon have the capability to have selftest tests in other layers, so remove this here so we can add a fixed version in meta-yocto-bsp after that happens. Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com --- meta/lib/oeqa/selftest/imagefeatures.py | 75 - 1 file changed, 75 deletions(-) diff --git a/meta/lib/oeqa/selftest/imagefeatures.py b/meta/lib/oeqa/selftest/imagefeatures.py index a370d1e..fcffc42 100644 --- a/meta/lib/oeqa/selftest/imagefeatures.py +++ b/meta/lib/oeqa/selftest/imagefeatures.py @@ -2,9 +2,6 @@ from oeqa.selftest.base import oeSelfTest from oeqa.utils.commands import runCmd, bitbake, get_bb_var, runqemu from oeqa.utils.decorators import testcase from oeqa.utils.sshcontrol import SSHControl -from os.path import isfile -from os import system -import glob import os import sys import logging @@ -169,75 +166,3 @@ class ImageFeatures(oeSelfTest): # Build a core-image-weston bitbake('core-image-weston') - -class Gummiboot(oeSelfTest): - -meta_intel_dir = '' - -def setUpLocal(self): - -Common setup for test cases: 1101, 1103 - - -self.meta_intel_dir = get_bb_var('COREBASE') + '/meta-intel' -meta_nuc_dir = self.meta_intel_dir + '/meta-nuc' -meta_intel_repo = 'http://git.yoctoproject.org/git/meta-intel' - -# Delete meta_intel_dir -system('rm -rf ' + self.meta_intel_dir) - -# Delete meta-intel dir even if the setUp fails -self.add_command_to_tearDown('rm -rf ' + self.meta_intel_dir) - -# Clone meta-intel -runCmd('git clone ' + meta_intel_repo + ' ' + self.meta_intel_dir) - -# Add meta-intel and meta-nuc layers in conf/bblayers.conf -features = 'BBLAYERS += ' + self.meta_intel_dir + ' ' + meta_nuc_dir + '' -self.append_bblayers_config(features) - -# Set EFI_PROVIDER = gummiboot and MACHINE = nuc in conf/local.conf -features = 'EFI_PROVIDER = gummiboot\n' -features += 'MACHINE = nuc' -self.append_config(features) - -# Run bitbake syslinux syslinux-native parted-native dosfstools-native mtools-native core-image-minimal -# to build a nuc/efi gummiboot image - -bitbake('syslinux syslinux-native parted-native dosfstools-native mtools-native core-image-minimal') - -@testcase(1101) -def test_efi_gummiboot_images_can_be_build(self): - -Summary: Check if efi/gummiboot images can be buit -Expected:1. File gummibootx64.efi should be available in build/tmp/deploy/images/nuc - 2. Efi/gummiboot images can be built -Product: oe-core -Author: Ionut Chisanovici ionutx.chisanov...@intel.com -AutomatedBy: Daniel Istrate daniel.alexandrux.istr...@intel.com - - -look_for_file = 'gummibootx64.efi' -file_location = get_bb_var('COREBASE') + '/build/tmp/deploy/images/nuc/' - -found = isfile(file_location + look_for_file) -self.assertTrue(found, 'File {} not found under {}.'.format(look_for_file, file_location)) - -@testcase(1103) -def test_wic_command_can_create_efi_gummiboot_installation_images(self): - -Summary: Check that wic command can create efi/gummiboot installation images -Expected:A .direct file in folder /var/tmp/wic/ must be created. -Product: oe-core -Author: Ionut Chisanovici ionutx.chisanov...@intel.com -AutomatedBy: Daniel Istrate daniel.alexandrux.istr...@intel.com - - -# Create efi/gummiboot installation images -wic_create_cmd = 'wic create mkgummidisk -e core-image-minimal' -runCmd(wic_create_cmd) - -# Verify that a .direct file was created -direct_file = '/var/tmp/wic/build/*.direct' -ret = glob.glob(direct_file) -self.assertEqual(1, len(ret), 'Failed to find the .direct file') -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 09/11] oeqa/selftest/imagefeatures: fix RPM4 test
* Use our new runqemu function * Don't hard-code the RPM4 version * Double-check the native version is RPM4 * Check that an rpm 4.x package is in the image manifest (this isn't strictly necessary, but belt-and-braces and it serves as an example of how to do that) * Check that the database is working on the target * Ensure the image actually has openssh in it so we can connect to it Initial runqemu adaptation by Richard Purdie richard.pur...@linuxfoundation.org Part of the fix for [YOCTO #7994]. Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com --- meta/lib/oeqa/selftest/imagefeatures.py | 75 +++-- 1 file changed, 44 insertions(+), 31 deletions(-) diff --git a/meta/lib/oeqa/selftest/imagefeatures.py b/meta/lib/oeqa/selftest/imagefeatures.py index 20cc58d..a370d1e 100644 --- a/meta/lib/oeqa/selftest/imagefeatures.py +++ b/meta/lib/oeqa/selftest/imagefeatures.py @@ -78,16 +78,17 @@ class ImageFeatures(oeSelfTest): def test_rpm_version_4_support_on_image(self): Summary: Check rpm version 4 support on image -Expected:Rpm version must be 4.11.2 +Expected:Rpm version must be 4.x Product: oe-core Author: Ionut Chisanovici ionutx.chisanov...@intel.com AutomatedBy: Daniel Istrate daniel.alexandrux.istr...@intel.com -rpm_version = '4.11.2' -features = 'IMAGE_INSTALL_append = rpm\n' -features += 'PREFERRED_VERSION_rpm = {}\n'.format(rpm_version) -features += 'PREFERRED_VERSION_rpm-native = {}\n'.format(rpm_version) +features = 'PREFERRED_VERSION_rpm = 4.%\n' +features += 'PREFERRED_VERSION_rpm-native = 4.%\n' +# Use openssh in IMAGE_INSTALL instead of ssh-server-openssh in EXTRA_IMAGE_FEATURES as a workaround for bug 8047 +features += 'IMAGE_INSTALL_append = openssh\n' +features += 'EXTRA_IMAGE_FEATURES = empty-root-password allow-empty-password package-management\n' features += 'RPMROOTFSDEPENDS_remove = rpmresolve-native:do_populate_sysroot' # Append 'features' to local.conf @@ -96,32 +97,44 @@ class ImageFeatures(oeSelfTest): # Build a core-image-minimal bitbake('core-image-minimal') -# Boot qemu image get rpm version -proc_qemu = pexpect.spawn('runqemu qemux86 nographic') -try: -proc_qemu.expect('qemux86 login:', timeout=100) -proc_qemu.sendline(self.root_user) -proc_qemu.expect(self.prompt) -proc_qemu.sendline('rpm --version') -proc_qemu.expect(self.prompt) -except Exception as e: -try: -killpg(proc_qemu.pid, signal.SIGTERM) -except: -pass -self.fail('Failed to start qemu: %s' % e) - -found_rpm_version = proc_qemu.before - -# Make sure the retrieved rpm version is the expected one -self.assertIn(rpm_version, found_rpm_version, - 'RPM version is not {}, found instead {}.'.format(rpm_version, found_rpm_version)) - -# Cleanup (close qemu) -try: -killpg(proc_qemu.pid, signal.SIGTERM) -except: -pass +# Check the native version of rpm is correct +native_bindir = get_bb_var('STAGING_BINDIR_NATIVE') +result = runCmd(os.path.join(native_bindir, 'rpm') + ' --version') +self.assertIn('version 4.', result.output) + +# Check manifest for the rpm package +deploydir = get_bb_var('DEPLOY_DIR_IMAGE') +imgname = get_bb_var('IMAGE_LINK_NAME', 'core-image-minimal') +with open(os.path.join(deploydir, imgname) + '.manifest', 'r') as f: +for line in f: +splitline = line.split() +if len(splitline) 2: +rpm_version = splitline[2] +if splitline[0] == 'rpm': +if not rpm_version.startswith('4.'): +self.fail('rpm version %s found in image, expected 4.x' % rpm_version) +break +else: +self.fail('No rpm package found in image') + +# Now do a couple of runtime tests +with runqemu(core-image-minimal, self) as qemu: +command = rpm --version +status, output = qemu.run(command) +self.assertEqual(0, status, 'Failed to run command %s: %s' % (command, output)) +found_rpm_version = output.strip() + +# Make sure the retrieved rpm version is the expected one +if rpm_version not in found_rpm_version: +self.fail('RPM version is not {}, found instead {}.'.format(rpm_version, found_rpm_version)) + +# Test that the rpm database is there and working +command = rpm -qa +status, output = qemu.run(command) +self.assertEqual(0, status, 'Failed to run
Re: [OE-core] [PATCH] toaster.bbclass: Fix ValueError
On Mon, 2015-07-27 at 13:55 +0300, Ed Bartosh wrote: The reason for this exception was usage of ':' as a field delimiter in toasterstatlist file. As target can optionally contain ':task' suffix it caused split(':') to throw exception: File toaster_collect_task_stats(e), line 71, in toaster_collect_task_stats(e=bb.event.BuildCompleted object at 0x7f8434deed50) ValueError: too many values to unpack Fixed by changing delimiter ':' - '::' Signed-off-by: Ed Bartosh ed.bart...@linux.intel.com Since this is causing other blockages and is simple I've merged it, thanks! One thing I did tweak was mentioning in the commit message that bitbake xxx:do_yyy triggers this. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] gcc 5.2 failures
Wow, 5.2? I can't even get the broadcom MIPS kernels to compile using the current master's 4.9.3 (I'm investigating still whether the kernel or gcc or OE is the problem here). M. On 27-07-15 11:30, Richard Purdie wrote: I've run a gcc 5.2 test build on the autobuilder: http://errors.yoctoproject.org/Errors/Search/?items=10query=3628c3c06fa4195003ac655bcc791acfac775173limit=50 41 errors (with a few more pending). The good news is that if we tweak the security flags, the poky-lsb gcc, elfutils, coreutils and iptables issues can be removed and I have a patch for this. This leaves: 3.14 kernel failures for edgerouter, genericx86-64, qemuarm, beaglebone, mpc8315e-rdb openssl issue for p1022ds u-boot on imx28evk, p1022ds, mpc8315e-rdb xf86-video-imxfb-vivante on imx6qsabresd linux-imx issue on imx53qsb Some kind of random qemu runtime issue (4 cases). At this point I think we likely need to enter bugs into the bugzilla for each of these. If we want to switch 1.9 to use this (which I think is desirable), we need to get this fixed as a priority. Bruce: How do you want to handle the 3.14 issues? Switch to 4.1? or fix 3.14? Otavio: The freescale machines are looking unwell, can you help us make sure the right people know about this? Cheers, Richard Kind regards, Mike Looijmans System Expert TOPIC Embedded Products Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: +31 (0) 499 33 69 79 Telefax: +31 (0) 499 33 69 70 E-mail: mike.looijm...@topicproducts.com Website: www.topicproducts.com Please consider the environment before printing this e-mail -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 11/11] oeqa/selftest/devtool: use new runqemu function
Use the common code we now have to run QEMU instead of running it ourselves, avoiding reliance on the machine showing up at 192.168.7.2. This also makes a copy of the image rather than using -snapshot so if we need to inspect the image after a failure, we can. Fixes [YOCTO #7928]. Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com --- meta/lib/oeqa/selftest/devtool.py | 72 ++- 1 file changed, 34 insertions(+), 38 deletions(-) diff --git a/meta/lib/oeqa/selftest/devtool.py b/meta/lib/oeqa/selftest/devtool.py index 21cd7f5..c833e54 100644 --- a/meta/lib/oeqa/selftest/devtool.py +++ b/meta/lib/oeqa/selftest/devtool.py @@ -8,7 +8,7 @@ import glob import oeqa.utils.ftools as ftools from oeqa.selftest.base import oeSelfTest -from oeqa.utils.commands import runCmd, bitbake, get_bb_var, create_temp_layer +from oeqa.utils.commands import runCmd, bitbake, get_bb_var, create_temp_layer, runqemu from oeqa.utils.decorators import testcase class DevtoolBase(oeSelfTest): @@ -799,12 +799,10 @@ class DevtoolTests(DevtoolBase): self.skipTest('No tap devices found - you must set up tap devices with scripts/runqemu-gen-tapdevs before running this test') workspacedir = os.path.join(self.builddir, 'workspace') self.assertTrue(not os.path.exists(workspacedir), 'This test cannot be run with a workspace directory under the build directory') -import pexpect # Definitions testrecipe = 'mdadm' testfile = '/sbin/mdadm' testimage = 'oe-selftest-image' -testhost = '192.168.7.2' testcommand = '/sbin/mdadm --help' # Build an image to run bitbake(%s qemu-native qemu-helper-native % testimage) @@ -821,44 +819,42 @@ class DevtoolTests(DevtoolBase): self.add_command_to_tearDown('bitbake -c clean %s' % testrecipe) result = runCmd('devtool modify %s -x %s' % (testrecipe, tempdir)) # Test that deploy-target at this point fails (properly) -result = runCmd('devtool deploy-target -n %s root@%s' % (testrecipe, testhost), ignore_status=True) +result = runCmd('devtool deploy-target -n %s root@localhost' % testrecipe, ignore_status=True) self.assertNotEqual(result.output, 0, 'devtool deploy-target should have failed, output: %s' % result.output) self.assertNotIn(result.output, 'Traceback', 'devtool deploy-target should have failed with a proper error not a traceback, output: %s' % result.output) result = runCmd('devtool build %s' % testrecipe) # First try a dry-run of deploy-target -result = runCmd('devtool deploy-target -n %s root@%s' % (testrecipe, testhost)) +result = runCmd('devtool deploy-target -n %s root@localhost' % testrecipe) self.assertIn(' %s' % testfile, result.output) # Boot the image -console = pexpect.spawn('runqemu %s %s qemuparams=-snapshot nographic' % (machine, testimage)) -console.expect(login:, timeout=120) -# Now really test deploy-target -result = runCmd('devtool deploy-target -c %s root@%s' % (testrecipe, testhost)) -# Run a test command to see if it was installed properly -sshargs = '-o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no' -result = runCmd('ssh %s root@%s %s' % (sshargs, testhost, testcommand)) -# Check if it deployed all of the files with the right ownership/perms -# First look on the host - need to do this under pseudo to get the correct ownership/perms -installdir = get_bb_var('D', testrecipe) -fakerootenv = get_bb_var('FAKEROOTENV', testrecipe) -fakerootcmd = get_bb_var('FAKEROOTCMD', testrecipe) -result = runCmd('%s %s find . -type f -exec ls -l {} \;' % (fakerootenv, fakerootcmd), cwd=installdir) -filelist1 = self._process_ls_output(result.output) - -# Now look on the target -tempdir2 = tempfile.mkdtemp(prefix='devtoolqa') -self.track_for_cleanup(tempdir2) -tmpfilelist = os.path.join(tempdir2, 'files.txt') -with open(tmpfilelist, 'w') as f: -for line in filelist1: -splitline = line.split() -f.write(splitline[-1] + '\n') -result = runCmd('cat %s | ssh -q %s root@%s \'xargs ls -l\'' % (tmpfilelist, sshargs, testhost)) -filelist2 = self._process_ls_output(result.output) -filelist1.sort(key=lambda item: item.split()[-1]) -filelist2.sort(key=lambda item: item.split()[-1]) -self.assertEqual(filelist1, filelist2) -# Test undeploy-target -result = runCmd('devtool undeploy-target -c %s root@%s' % (testrecipe, testhost)) -result = runCmd('ssh %s root@%s %s' % (sshargs, testhost, testcommand), ignore_status=True) -self.assertNotEqual(result, 0, 'undeploy-target did not remove command as it should have') -console.close() +with
[OE-core] [PATCH 04/11] oeqa/utils/qemurunner: avoid blocking on stty when running under oe-selftest
runqemu-internal runs stty to return the terminal to its previous state in case QEMU hasn't done that properly (which it at least used to do when it crashed). For some reason I have yet to determine, stty blocks (on tcsetattr() according to gdb) when run within QemuRunner() under oe-selftest, with the result that we always wait until the timeout and then we kill the script, which adds an extra delay after QEMU is stopped. Naturally you would assume that this is something to do with the nature of the terminal under which it is being run; however no amount of playing around with stdin/stdout/stderr seemed to fix the issue, apart from passing in subprocess.PIPE as stdin which makes stty error out with stty: standard input: Inappropriate ioctl for device. I was also unable to come up with a reliable test for the terminal which we could use inside runqemu-internal to avoid calling stty. For now, go with the stdin=subprocess.PIPE workaround to at least avoid the delay with minimal ill effect. Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com --- meta/lib/oeqa/utils/qemurunner.py | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/meta/lib/oeqa/utils/qemurunner.py b/meta/lib/oeqa/utils/qemurunner.py index 4de3c64..11186d6 100644 --- a/meta/lib/oeqa/utils/qemurunner.py +++ b/meta/lib/oeqa/utils/qemurunner.py @@ -94,7 +94,11 @@ class QemuRunner: self.qemuparams = self.qemuparams[:-1] + + qemuparams + + '\' launch_cmd = 'runqemu %s %s %s' % (self.machine, self.rootfs, self.qemuparams) -self.runqemu = subprocess.Popen(launch_cmd,shell=True,stdout=subprocess.PIPE,stderr=subprocess.STDOUT,preexec_fn=os.setpgrp) +# FIXME: We pass in stdin=subprocess.PIPE here to work around stty +# blocking at the end of the runqemu script when using this within +# oe-selftest (this makes stty error out immediately). There ought +# to be a proper fix but this will suffice for now. +self.runqemu = subprocess.Popen(launch_cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, stdin=subprocess.PIPE, preexec_fn=os.setpgrp) logger.info(runqemu started, pid is %s % self.runqemu.pid) logger.info(waiting at most %s seconds for qemu pid % self.runqemutime) -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 07/11] oeqa/selftest/imagefeatures: Use QemuTarget code
From: Richard Purdie richard.pur...@linuxfoundation.org Create a runqemu function which uses the QemuTarget() code from oeqa.targetcontrol to setup the QEMU instance, with all of the added robustness that that gives us. To do this, a datastore is needed for the recipe in question (core-image-minimal) so we do the work needed to set this up. We then use this runqemu function within the imagefeatures tests instead of a hand-rolled implementation. We can then use SSHControl to run the SSH tests rather than rolling our own code to do that as an added bonus. Fixed and extended by Paul Eggleton paul.eggle...@linux.intel.com. Part of the fix for [YOCTO #7994]. Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org --- meta/lib/oeqa/selftest/imagefeatures.py | 96 +++-- meta/lib/oeqa/utils/commands.py | 49 + 2 files changed, 67 insertions(+), 78 deletions(-) diff --git a/meta/lib/oeqa/selftest/imagefeatures.py b/meta/lib/oeqa/selftest/imagefeatures.py index 1795b7b..d48435f 100644 --- a/meta/lib/oeqa/selftest/imagefeatures.py +++ b/meta/lib/oeqa/selftest/imagefeatures.py @@ -1,20 +1,18 @@ from oeqa.selftest.base import oeSelfTest -from oeqa.utils.commands import runCmd, bitbake, get_bb_var +from oeqa.utils.commands import runCmd, bitbake, get_bb_var, runqemu from oeqa.utils.decorators import testcase -import pexpect +from oeqa.utils.sshcontrol import SSHControl from os.path import isfile -from os import system, killpg +from os import system import glob -import signal - +import os +import sys +import logging class ImageFeatures(oeSelfTest): test_user = 'tester' root_user = 'root' -prompt = r'qemux86:\S+[$#]\s+' -ssh_cmd = ssh {} -l {} -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -get_ip_patt = r'\s+ip=(?Pqemu_ip(\d+.){3}\d+)::' @testcase(1107) def test_non_root_user_can_connect_via_ssh_without_password(self): @@ -37,41 +35,12 @@ class ImageFeatures(oeSelfTest): # Build a core-image-minimal bitbake('core-image-minimal') -# Boot qemu image -proc_qemu = pexpect.spawn('runqemu qemux86 nographic') -try: -proc_qemu.expect(self.get_ip_patt, timeout=100) -qemu_ip = proc_qemu.match.group('qemu_ip') -proc_qemu.expect('qemux86 login:', timeout=100) -except Exception as e: -try: -killpg(proc_qemu.pid, signal.SIGTERM) -except: -pass -self.fail('Failed to start qemu: %s' % e) - -# Attempt to ssh with each user into qemu with empty password -for user in [self.root_user, self.test_user]: -proc_ssh = pexpect.spawn(self.ssh_cmd.format(qemu_ip, user)) -index = proc_ssh.expect([self.prompt, pexpect.TIMEOUT, pexpect.EOF]) -if index == 0: -# user successfully logged in with empty password -pass -elif index == 1: -killpg(proc_qemu.pid, signal.SIGTERM) -proc_ssh.terminate() -self.fail('Failed to ssh with {} user into qemu (timeout).'.format(user)) -else: -killpg(proc_qemu.pid, signal.SIGTERM) -proc_ssh.terminate() -self.fail('Failed to ssh with {} user into qemu (eof).'.format(user)) -proc_ssh.terminate() - -# Cleanup -try: -killpg(proc_qemu.pid, signal.SIGTERM) -except: -pass +with runqemu(core-image-minimal, self) as qemu: +# Attempt to ssh with each user into qemu with empty password +for user in [self.root_user, self.test_user]: +ssh = SSHControl(ip=qemu.ip, logfile=qemu.sshlog, user=user) +status, output = ssh.run(true) +self.assertEqual(status, 0, 'ssh to user %s failed with %s' % (user, output)) @testcase(1115) def test_all_users_can_connect_via_ssh_without_password(self): @@ -82,7 +51,6 @@ class ImageFeatures(oeSelfTest): Author: Ionut Chisanovici ionutx.chisanov...@intel.com AutomatedBy: Daniel Istrate daniel.alexandrux.istr...@intel.com - features = 'EXTRA_IMAGE_FEATURES += ssh-server-openssh allow-empty-password\n' features += 'INHERIT += extrausers\n' features += 'EXTRA_USERS_PARAMS = useradd -p \'\' {}; usermod -s /bin/sh {};'.format(self.test_user, self.test_user) @@ -93,41 +61,13 @@ class ImageFeatures(oeSelfTest): # Build a core-image-minimal bitbake('core-image-minimal') -# Boot qemu image -proc_qemu = pexpect.spawn('runqemu qemux86 nographic') -try: -proc_qemu.expect(self.get_ip_patt, timeout=100) -qemu_ip = proc_qemu.match.group('qemu_ip') -proc_qemu.expect('qemux86 login:', timeout=100)
[OE-core] [PATCH 06/11] oeqa/targetcontrol: write QemuRunner log output to a file
If we use this outside of testimage we don't have a task log; so let's just explicitly write the log output to a file all the time so it's always there to look at (particularly useful when runqemu exits immediately with an error.) Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com --- meta/lib/oeqa/targetcontrol.py | 11 +++ 1 file changed, 11 insertions(+) diff --git a/meta/lib/oeqa/targetcontrol.py b/meta/lib/oeqa/targetcontrol.py index beacdaf..138e6178 100644 --- a/meta/lib/oeqa/targetcontrol.py +++ b/meta/lib/oeqa/targetcontrol.py @@ -10,6 +10,7 @@ import subprocess import bb import traceback import sys +import logging from oeqa.utils.sshcontrol import SSHControl from oeqa.utils.qemurunner import QemuRunner from oeqa.utils.qemutinyrunner import QemuTinyRunner @@ -123,6 +124,16 @@ class QemuTarget(BaseTarget): self.rootfs = os.path.join(self.testdir, d.getVar(IMAGE_LINK_NAME, True) + '-testimage.' + self.image_fstype) self.kernel = os.path.join(d.getVar(DEPLOY_DIR_IMAGE, True), d.getVar(KERNEL_IMAGETYPE, False) + '-' + d.getVar('MACHINE', False) + '.bin') +# Log QemuRunner log output to a file +import oe.path +bb.utils.mkdirhier(self.testdir) +self.qemurunnerlog = os.path.join(self.testdir, 'qemurunner_log.%s' % self.datetime) +logger = logging.getLogger('BitBake.QemuRunner') +loggerhandler = logging.FileHandler(self.qemurunnerlog) +loggerhandler.setFormatter(logging.Formatter(%(levelname)s: %(message)s)) +logger.addHandler(loggerhandler) +oe.path.symlink(os.path.basename(self.qemurunnerlog), os.path.join(self.testdir, 'qemurunner_log'), force=True) + if d.getVar(DISTRO, True) == poky-tiny: self.runner = QemuTinyRunner(machine=d.getVar(MACHINE, True), rootfs=self.rootfs, -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 03/11] oeqa/utils/qemurunner: fix logging
OE-Core commit 519e381278d40bdac79add340e4c0460a9f97e17 unfortunately broke logging in two different ways: 1) it prevented logging to the task log from working within bitbake -c testimage. This is due to the logger object being set up too early which interferes with BitBake's own logging. If we prefix the name with BitBake. everything works (and we don't need to set the logging level). 2) Additionally because it called the log functions on the logging module and not the logger object it set up, this caused the oe-selftest logging to start printing everything from that point forward. Fix these two issues and return us to the desired behaviour for do_testimage. Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com --- meta/lib/oeqa/utils/qemurunner.py | 49 +++ 1 file changed, 24 insertions(+), 25 deletions(-) diff --git a/meta/lib/oeqa/utils/qemurunner.py b/meta/lib/oeqa/utils/qemurunner.py index 59c9934..4de3c64 100644 --- a/meta/lib/oeqa/utils/qemurunner.py +++ b/meta/lib/oeqa/utils/qemurunner.py @@ -14,8 +14,7 @@ import socket import select import logging -logger = logging.getLogger(QemuRunner) -logger.setLevel(logging.DEBUG - 2) +logger = logging.getLogger(BitBake.QemuRunner) class QemuRunner: @@ -51,11 +50,11 @@ class QemuRunner: self.server_socket.bind((127.0.0.1,0)) self.server_socket.listen(2) self.serverport = self.server_socket.getsockname()[1] -logging.info(Created listening socket for qemu serial console on: 127.0.0.1:%s % self.serverport) +logger.info(Created listening socket for qemu serial console on: 127.0.0.1:%s % self.serverport) return True except socket.error, msg: self.server_socket.close() -logging.error(Failed to create listening socket: %s % msg[1]) +logger.error(Failed to create listening socket: %s % msg[1]) return False @@ -68,18 +67,18 @@ class QemuRunner: if self.display: os.environ[DISPLAY] = self.display else: -logging.error(To start qemu I need a X desktop, please set DISPLAY correctly (e.g. DISPLAY=:1)) +logger.error(To start qemu I need a X desktop, please set DISPLAY correctly (e.g. DISPLAY=:1)) return False if not os.path.exists(self.rootfs): -logging.error(Invalid rootfs %s % self.rootfs) +logger.error(Invalid rootfs %s % self.rootfs) return False if not os.path.exists(self.tmpdir): -logging.error(Invalid TMPDIR path %s % self.tmpdir) +logger.error(Invalid TMPDIR path %s % self.tmpdir) return False else: os.environ[OE_TMPDIR] = self.tmpdir if not os.path.exists(self.deploy_dir_image): -logging.error(Invalid DEPLOY_DIR_IMAGE path %s % self.deploy_dir_image) +logger.error(Invalid DEPLOY_DIR_IMAGE path %s % self.deploy_dir_image) return False else: os.environ[DEPLOY_DIR_IMAGE] = self.deploy_dir_image @@ -97,28 +96,28 @@ class QemuRunner: launch_cmd = 'runqemu %s %s %s' % (self.machine, self.rootfs, self.qemuparams) self.runqemu = subprocess.Popen(launch_cmd,shell=True,stdout=subprocess.PIPE,stderr=subprocess.STDOUT,preexec_fn=os.setpgrp) -logging.info(runqemu started, pid is %s % self.runqemu.pid) -logging.info(waiting at most %s seconds for qemu pid % self.runqemutime) +logger.info(runqemu started, pid is %s % self.runqemu.pid) +logger.info(waiting at most %s seconds for qemu pid % self.runqemutime) endtime = time.time() + self.runqemutime while not self.is_alive() and time.time() endtime: time.sleep(1) if self.is_alive(): -logging.info(qemu started - qemu procces pid is %s % self.qemupid) +logger.info(qemu started - qemu procces pid is %s % self.qemupid) cmdline = '' with open('/proc/%s/cmdline' % self.qemupid) as p: cmdline = p.read() ips = re.findall(((?:[0-9]{1,3}\.){3}[0-9]{1,3}), cmdline.split(ip=)[1]) if not ips or len(ips) != 3: -logging.info(Couldn't get ip from qemu process arguments! Here is the qemu command line used: %s % cmdline) +logger.info(Couldn't get ip from qemu process arguments! Here is the qemu command line used: %s % cmdline) self.stop() return False else: self.ip = ips[0] self.server_ip = ips[1] -logging.info(Target IP: %s % self.ip) -logging.info(Server IP: %s % self.server_ip) -logging.info(Waiting at most %d seconds for login banner % self.boottime) +logger.info(Target IP: %s % self.ip) +logger.info(Server IP: %s %
[OE-core] [PATCH 08/11] oeqa/selftest/imagefeatures: fix SSH without password tests
From: Richard Purdie richard.pur...@linuxfoundation.org * We need to set EXTRA_IMAGE_FEATURES outright or existing values will affect the test * For test case 1107 we need empty-root-password to match the behaviour described in the test case * For test case 1115 we shouldn't be able to connect as root with the features we are setting Test cases 1107 and 1115 have been updated in Testopia to match. Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org --- meta/lib/oeqa/selftest/imagefeatures.py | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/meta/lib/oeqa/selftest/imagefeatures.py b/meta/lib/oeqa/selftest/imagefeatures.py index d48435f..20cc58d 100644 --- a/meta/lib/oeqa/selftest/imagefeatures.py +++ b/meta/lib/oeqa/selftest/imagefeatures.py @@ -25,7 +25,7 @@ class ImageFeatures(oeSelfTest): AutomatedBy: Daniel Istrate daniel.alexandrux.istr...@intel.com -features = 'EXTRA_IMAGE_FEATURES += ssh-server-openssh empty-root-password\n' +features = 'EXTRA_IMAGE_FEATURES = ssh-server-openssh empty-root-password allow-empty-password\n' features += 'INHERIT += extrausers\n' features += 'EXTRA_USERS_PARAMS = useradd -p \'\' {}; usermod -s /bin/sh {};'.format(self.test_user, self.test_user) @@ -46,12 +46,14 @@ class ImageFeatures(oeSelfTest): def test_all_users_can_connect_via_ssh_without_password(self): Summary: Check if all users can connect via ssh without password -Expected:1. Connection to the image via ssh using root or tester user without providing a password should be allowed. +Expected: 1. Connection to the image via ssh using root user without providing a password should NOT be allowed. + 2. Connection to the image via ssh using tester user without providing a password should be allowed. Product: oe-core Author: Ionut Chisanovici ionutx.chisanov...@intel.com AutomatedBy: Daniel Istrate daniel.alexandrux.istr...@intel.com -features = 'EXTRA_IMAGE_FEATURES += ssh-server-openssh allow-empty-password\n' + +features = 'EXTRA_IMAGE_FEATURES = ssh-server-openssh allow-empty-password\n' features += 'INHERIT += extrausers\n' features += 'EXTRA_USERS_PARAMS = useradd -p \'\' {}; usermod -s /bin/sh {};'.format(self.test_user, self.test_user) @@ -66,7 +68,10 @@ class ImageFeatures(oeSelfTest): for user in [self.root_user, self.test_user]: ssh = SSHControl(ip=qemu.ip, logfile=qemu.sshlog, user=user) status, output = ssh.run(true) -self.assertEqual(status, 0, 'ssh to user tester failed with %s' % output) +if user == 'root': +self.assertNotEqual(status, 0, 'ssh to user root was allowed when it should not have been') +else: +self.assertEqual(status, 0, 'ssh to user tester failed with %s' % output) @testcase(1114) -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 05/11] oeqa/utils/qemurunner: fix error handling if runqemu exits with an error
* Don't wait for QEMU to start if it's never going to (because runqemu exited with an error) * Don't error out if killing the process fails with no such process (we don't care if it's already dead) Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com --- meta/lib/oeqa/utils/qemurunner.py | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/meta/lib/oeqa/utils/qemurunner.py b/meta/lib/oeqa/utils/qemurunner.py index 11186d6..71da21c 100644 --- a/meta/lib/oeqa/utils/qemurunner.py +++ b/meta/lib/oeqa/utils/qemurunner.py @@ -12,6 +12,7 @@ import signal import re import socket import select +import errno import logging logger = logging.getLogger(BitBake.QemuRunner) @@ -104,6 +105,14 @@ class QemuRunner: logger.info(waiting at most %s seconds for qemu pid % self.runqemutime) endtime = time.time() + self.runqemutime while not self.is_alive() and time.time() endtime: +if self.runqemu.poll(): +if self.runqemu.returncode: +# No point waiting any longer +logger.info('runqemu exited with code %d' % self.runqemu.returncode) +output = self.runqemu.stdout +self.stop() +logger.info(Output from runqemu:\n%s % output.read()) +return False time.sleep(1) if self.is_alive(): @@ -169,7 +178,11 @@ class QemuRunner: if self.runqemu: logger.info(Sending SIGTERM to runqemu) -os.killpg(self.runqemu.pid, signal.SIGTERM) +try: +os.killpg(self.runqemu.pid, signal.SIGTERM) +except OSError as e: +if e.errno != errno.ESRCH: +raise endtime = time.time() + self.runqemutime while self.runqemu.poll() is None and time.time() endtime: time.sleep(1) -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 01/11] oe-selftest: add scripts/lib and bitbake/lib to path
In particular, this allows us to use code from bitbake's bb module (such as tinfoil). Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com --- scripts/oe-selftest | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/scripts/oe-selftest b/scripts/oe-selftest index fa6245a..6db6e23 100755 --- a/scripts/oe-selftest +++ b/scripts/oe-selftest @@ -31,7 +31,10 @@ import unittest import logging import argparse -sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__), '..', 'meta/lib'))) +sys.path.insert(0, os.path.dirname(os.path.realpath(__file__)) + '/lib') +import scriptpath +scriptpath.add_bitbake_lib_path() +scriptpath.add_oe_lib_path() import oeqa.selftest import oeqa.utils.ftools as ftools -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 02/11] oeqa/targetcontrol: create test directory before copying rootfs image
The test directory might not exist at this point so just go ahead and create it. Signed-off-by: Paul Eggleton paul.eggle...@linux.intel.com --- meta/lib/oeqa/targetcontrol.py | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/lib/oeqa/targetcontrol.py b/meta/lib/oeqa/targetcontrol.py index 60b09b2..beacdaf 100644 --- a/meta/lib/oeqa/targetcontrol.py +++ b/meta/lib/oeqa/targetcontrol.py @@ -143,6 +143,7 @@ class QemuTarget(BaseTarget): def deploy(self): try: +bb.utils.mkdirhier(self.testdir) shutil.copyfile(self.origrootfs, self.rootfs) except Exception as e: bb.fatal(Error copying rootfs: %s % e) -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 00/11] Properly fix oe-selftest QEMU usage + related fixes
The tests in oeqa/selftest/imagefeatures have had a long list of issues that we've worked around; this patchset implements the ability to run QEMU from oe-selftest tests properly and attempts to fix the remaining known issues with the tests. At the same time we can make the devtool test that uses QEMU use the new runqemu() logic, so do that as well. When we did do the proper runqemu() implementation however, I uncovered a number of other problems to do with error handling, process termination and logging. This patchset should address those as well. Thanks to Richard for the initial set of fixes which I built upon here. The following changes since commit 03d01393d14b7b20dcb40ff89b1628883fd3b545: toaster.bbclass: Fix ValueError (2015-07-27 12:26:57 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib paule/oe-selftest-qemu-fixes http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/oe-selftest-qemu-fixes Paul Eggleton (9): oe-selftest: add scripts/lib and bitbake/lib to path oeqa/targetcontrol: create test directory before copying rootfs image oeqa/utils/qemurunner: fix logging oeqa/utils/qemurunner: avoid blocking on stty when running under oe-selftest oeqa/utils/qemurunner: fix error handling if runqemu exits with an error oeqa/targetcontrol: write QemuRunner log output to a file oeqa/selftest/imagefeatures: fix RPM4 test oeqa/selftest/imagefeatures: remove gummiboot tests oeqa/selftest/devtool: use new runqemu function Richard Purdie (2): oeqa/selftest/imagefeatures: Use QemuTarget code oeqa/selftest/imagefeatures: fix SSH without password tests meta/lib/oeqa/selftest/devtool.py | 72 +- meta/lib/oeqa/selftest/imagefeatures.py | 247 +--- meta/lib/oeqa/targetcontrol.py | 12 ++ meta/lib/oeqa/utils/commands.py | 49 +++ meta/lib/oeqa/utils/qemurunner.py | 70 + scripts/oe-selftest | 5 +- 6 files changed, 207 insertions(+), 248 deletions(-) -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] gcc 5.2 failures
On 15-07-27 09:50 AM, Paul Eggleton wrote: On Monday 27 July 2015 09:31:01 Bruce Ashfield wrote: On 15-07-27 09:20 AM, Bruce Ashfield wrote: On 15-07-27 05:30 AM, Richard Purdie wrote: I've run a gcc 5.2 test build on the autobuilder: http://errors.yoctoproject.org/Errors/Search/?items=10query=3628c3c06fa4 195003ac655bcc791acfac775173limit=50 41 errors (with a few more pending). The good news is that if we tweak the security flags, the poky-lsb gcc, elfutils, coreutils and iptables issues can be removed and I have a patch for this. This leaves: 3.14 kernel failures for edgerouter, genericx86-64, qemuarm, beaglebone, mpc8315e-rdb Gah. I had all these building with 5.1 .. chasing gcc is a pain with this older kernel. openssl issue for p1022ds u-boot on imx28evk, p1022ds, mpc8315e-rdb xf86-video-imxfb-vivante on imx6qsabresd linux-imx issue on imx53qsb Some kind of random qemu runtime issue (4 cases). At this point I think we likely need to enter bugs into the bugzilla for each of these. If we want to switch 1.9 to use this (which I think is desirable), we need to get this fixed as a priority. Bruce: How do you want to handle the 3.14 issues? Switch to 4.1? or fix 3.14? Now that 4.1 is in place, and I can't really see a large user base that needs gcc 5.x with the linux-yocto 3.14 kernel (other folks using master with their own kernel's will obviously have to deal with the issue in their trees) .. join that with the fact that we need to update all the reference boards to 4.1 anyway, my suggestion is that we open bugs for the h/w reference updates (and I'll get the appropriate Wind River eyes on them) and walk away from burning more cycles on gcc 5.x and the 3.14 kernel. And of course, I remembered that we updated all the reference boards to 3.19, so if 3.19 builds with gcc 5.2 (it may not), then all we need to do is move the lsb reference to 4.1 and we'll also be free of backporting :) It would be nice if we were able to point to a set of fixes that people can apply onto their older kernels in the migration guide for 1.9 though - I guarantee we'll get people asking... There's unfortunately no clean set of fixes, the mips one for example, is a bit of a knarly backport in the assembly code. If it was easy to point them out, we would have just done all the ports :) Bruce Cheers, Paul -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V3 3/4] sysklogd: add systemd support
Hello Chen, May I know why your patch series is still pending merge? Noor -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Chen Qi Sent: Sunday, September 28, 2014 8:00 AM To: openembedded-core@lists.openembedded.org Subject: [OE-core] [PATCH V3 3/4] sysklogd: add systemd support This patch includes the following changes: 1. Add socket activation support for sysklogd 2. Add systemd service file 3. Use ALTERNATIVE mechanism in OE to manage the syslog service 4. Set ALTERNATIVE_PRIORITY to 100 regardless of whether 'systemd' is in DISTRO_FEATURES or not because sysklogd now has systemd support. Signed-off-by: Chen Qi qi.c...@windriver.com --- .../files/0001-syslogd.c-add-systemd-support.patch | 246 + meta/recipes-extended/sysklogd/files/klogd.service | 9 + .../sysklogd/files/sysklogd.service| 14 ++ meta/recipes-extended/sysklogd/sysklogd.inc| 38 +++- 4 files changed, 300 insertions(+), 7 deletions(-) create mode 100644 meta/recipes-extended/sysklogd/files/0001-syslogd.c-add-systemd-support.patch create mode 100644 meta/recipes-extended/sysklogd/files/klogd.service create mode 100644 meta/recipes-extended/sysklogd/files/sysklogd.service diff --git a/meta/recipes-extended/sysklogd/files/0001-syslogd.c-add-systemd-support.patch b/meta/recipes-extended/sysklogd/files/0001-syslogd.c-add-systemd-support.patch new file mode 100644 index 000..1706906 --- /dev/null +++ b/meta/recipes-extended/sysklogd/files/0001-syslogd.c-add-systemd-su +++ pport.patch @@ -0,0 +1,246 @@ +Upstream-Status: Pending + +Subject: syslogd.c: add systemd support + +1. add socket activation support +2. unlink /dev/log if it's not provided by systemd + +Signed-off-by: Chen Qi qi.c...@windriver.com +--- + syslogd.c | 157 +++ + 1 file changed, 137 insertions(+), 20 deletions(-) + +diff --git a/syslogd.c b/syslogd.c +index acfd8f1..81e45e6 100644 +--- a/syslogd.c b/syslogd.c +@@ -602,6 +602,9 @@ static char sccsid[] = @(#)syslogd.c 5.27 (Berkeley) 10/10/88; + #define _PATH_LOG /dev/log + #endif + ++/* systemd support */ ++#define SD_LISTEN_FDS_START 3 ++ + char *ConfFile = _PATH_LOGCONF; + char *PidFile = _PATH_LOGPID; + char ctty[] = _PATH_CONSOLE; +@@ -612,6 +615,7 @@ int inetm = 0; + static int debugging_on = 0; + static int nlogs = -1; + static int restart = 0; ++static int socket_from_systemd = 0; + + #define MAXFUNIX 20 + +@@ -822,6 +826,8 @@ int decode(char *name, struct code *codetab); +static void dprintf(char *, ...); static void allocate_log(void); +void sighup_handler(); ++/* systemd support */ ++int sd_listen_fds(void); + + #ifdef SYSLOG_UNIXAF + static int create_unix_socket(const char *path); @@ -963,9 +969,37 @@ +int main(argc, argv) +*/ + exit(1); + } ++ ++ /* We keep stdout and stderr open in case we have to emit something */ ++ close(0); ++ i = 3; ++ ++ /* Trying to pass on LISTEN_PID with appropriate value */ ++ const char *e; ++ unsigned long l; ++ char buf[24] = { '\0' }; ++ int sd_fds; ++ ++ if ( (e = getenv(LISTEN_PID)) ) { ++ errno = 0; ++ l = strtoul(e, NULL, 10); ++ if (errno == 0) { ++ if (getppid() == (pid_t)l) { ++ snprintf(buf,sizeof(buf), %d, (int)getpid()); ++ setenv(LISTEN_PID, buf, 1); ++ } ++ } ++ } ++ + signal (SIGTERM, SIG_DFL); + num_fds = getdtablesize(); +- for (i= 0; i num_fds; i++) ++ ++ /* close all further fds except of the fds provided by systemd */ ++ sd_fds = sd_listen_fds(); ++ if (sd_fds 0) { ++ i = SD_LISTEN_FDS_START + sd_fds; ++ } ++ for ( ; i num_fds; i++) + (void) close(i); + untty(); + } +@@ -1248,28 +1282,37 @@ static int create_unix_socket(const char *path) +{ + struct sockaddr_un sunx; + int fd; ++ int n; + char line[MAXLINE +1]; + +- if (path[0] == '\0') ++ n = sd_listen_fds(); ++ if (n 1) { + return -1; +- +- (void) unlink(path); +- +- memset(sunx, 0, sizeof(sunx)); +- sunx.sun_family = AF_UNIX; +- (void)
Re: [OE-core] gcc 5.2 failures
On 15-07-27 09:20 AM, Bruce Ashfield wrote: On 15-07-27 05:30 AM, Richard Purdie wrote: I've run a gcc 5.2 test build on the autobuilder: http://errors.yoctoproject.org/Errors/Search/?items=10query=3628c3c06fa4195003ac655bcc791acfac775173limit=50 41 errors (with a few more pending). The good news is that if we tweak the security flags, the poky-lsb gcc, elfutils, coreutils and iptables issues can be removed and I have a patch for this. This leaves: 3.14 kernel failures for edgerouter, genericx86-64, qemuarm, beaglebone, mpc8315e-rdb Gah. I had all these building with 5.1 .. chasing gcc is a pain with this older kernel. openssl issue for p1022ds u-boot on imx28evk, p1022ds, mpc8315e-rdb xf86-video-imxfb-vivante on imx6qsabresd linux-imx issue on imx53qsb Some kind of random qemu runtime issue (4 cases). At this point I think we likely need to enter bugs into the bugzilla for each of these. If we want to switch 1.9 to use this (which I think is desirable), we need to get this fixed as a priority. Bruce: How do you want to handle the 3.14 issues? Switch to 4.1? or fix 3.14? Now that 4.1 is in place, and I can't really see a large user base that needs gcc 5.x with the linux-yocto 3.14 kernel (other folks using master with their own kernel's will obviously have to deal with the issue in their trees) .. join that with the fact that we need to update all the reference boards to 4.1 anyway, my suggestion is that we open bugs for the h/w reference updates (and I'll get the appropriate Wind River eyes on them) and walk away from burning more cycles on gcc 5.x and the 3.14 kernel. And of course, I remembered that we updated all the reference boards to 3.19, so if 3.19 builds with gcc 5.2 (it may not), then all we need to do is move the lsb reference to 4.1 and we'll also be free of backporting :) Bruce Cheers, Bruce Otavio: The freescale machines are looking unwell, can you help us make sure the right people know about this? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] gcc 5.2 failures
On 15-07-27 09:52 AM, Richard Purdie wrote: On Mon, 2015-07-27 at 09:20 -0400, Bruce Ashfield wrote: On 15-07-27 05:30 AM, Richard Purdie wrote: I've run a gcc 5.2 test build on the autobuilder: http://errors.yoctoproject.org/Errors/Search/?items=10query=3628c3c06fa4195003ac655bcc791acfac775173limit=50 41 errors (with a few more pending). The good news is that if we tweak the security flags, the poky-lsb gcc, elfutils, coreutils and iptables issues can be removed and I have a patch for this. This leaves: 3.14 kernel failures for edgerouter, genericx86-64, qemuarm, beaglebone, mpc8315e-rdb Gah. I had all these building with 5.1 .. chasing gcc is a pain with this older kernel. I'm not sure if this is a 5.1 verses 5.2 issue or not. I'm starting to wonder if the SRCREVs we're using pull in the gcc 5.x fixes? Hmm. True enough, I'll double check, since I did have everything building against 5.1 about a week ago. E.g. one of the failures was: /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm-lsb/build/build/tmp/work-shared/beaglebone/kernel-source/include/linux/compiler-gcc.h:106:30: fatal error: linux/compiler-gcc5.h: No such file or directory which doesn't look 5.2. Bruce: How do you want to handle the 3.14 issues? Switch to 4.1? or fix 3.14? Now that 4.1 is in place, and I can't really see a large user base that needs gcc 5.x with the linux-yocto 3.14 kernel (other folks using master with their own kernel's will obviously have to deal with the issue in their trees) .. join that with the fact that we need to update all the reference boards to 4.1 anyway, my suggestion is that we open bugs for the h/w reference updates (and I'll get the appropriate Wind River eyes on them) and walk away from burning more cycles on gcc 5.x and the 3.14 kernel. That seems reasonable to me, assuming we don't have an easy SRCREV fix we've just missed/lost somehow... I'll get back to you on that one, I'm turning 5.x back on in my local builds. Bruce Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] recipes-connectivity: Add hostapd configuration for enabling Marvell 8897 WiFi feature
On Thu, 2015-07-09 at 13:10 +0800, wei.tee...@intel.com wrote: From: Ng Shui Lei shui.lei...@intel.com Hostapd features was created in the recipes-connectivity layer to enable Marvell 8897 module in AP mode and STA mode. Signed-off-by: Ng Shui Lei shui.lei...@intel.com Signed-off-by: Ng Wei Tee wei.tee...@intel.com --- .../hostapd/hostapd-2.2/defconfig | 145 .../hostapd/hostapd-2.2/hostapd.service| 11 ++ meta/recipes-connectivity/hostapd/hostapd-2.2/init | 58 meta/recipes-connectivity/hostapd/hostapd_2.2.bb | 48 +++ 4 files changed, 262 insertions(+) create mode 100644 meta/recipes-connectivity/hostapd/hostapd-2.2/defconfig create mode 100644 meta/recipes-connectivity/hostapd/hostapd-2.2/hostapd.service create mode 100644 meta/recipes-connectivity/hostapd/hostapd-2.2/init create mode 100644 meta/recipes-connectivity/hostapd/hostapd_2.2.bb I'm by no means a comms expert which is one of the reasons I've not replied to this, I'd hoped someone with more knowledge would. Part of the issue here is that hostapd and connmand have overlapping functionality, conflicting in some cases. So the question is why do we need hostapd if we have connman (which is already in OE-Core)? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] toaster.bbclass: Fix ValueError
The reason for this exception was usage of ':' as a field delimiter in toasterstatlist file. As target can optionally contain ':task' suffix it caused split(':') to throw exception: File toaster_collect_task_stats(e), line 71, in toaster_collect_task_stats(e=bb.event.BuildCompleted object at 0x7f8434deed50) ValueError: too many values to unpack Fixed by changing delimiter ':' - '::' Signed-off-by: Ed Bartosh ed.bart...@linux.intel.com --- meta/classes/toaster.bbclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/classes/toaster.bbclass b/meta/classes/toaster.bbclass index eeca9de..d63cff5 100644 --- a/meta/classes/toaster.bbclass +++ b/meta/classes/toaster.bbclass @@ -192,7 +192,7 @@ python toaster_collect_task_stats() { bn = get_bn(e) bsdir = os.path.join(e.data.getVar('BUILDSTATS_BASE', True), bn) taskdir = os.path.join(bsdir, e.data.expand(${PF})) -fout.write(%s:%s:%s:%s\n % (e.taskfile, e.taskname, os.path.join(taskdir, e.task), e.data.expand(${PN}))) +fout.write(%s::%s::%s::%s\n % (e.taskfile, e.taskname, os.path.join(taskdir, e.task), e.data.expand(${PN}))) bb.utils.unlockfile(lock) @@ -245,7 +245,7 @@ python toaster_collect_task_stats() { events = [] with open(os.path.join(e.data.getVar('BUILDSTATS_BASE', True), toasterstatlist), r) as fin: for line in fin: -(taskfile, taskname, filename, recipename) = line.strip().split(:) +(taskfile, taskname, filename, recipename) = line.strip().split(::) events.append((taskfile, taskname, _read_stats(filename), recipename)) bb.event.fire(bb.event.MetadataEvent(BuildStatsList, events), e.data) os.unlink(os.path.join(e.data.getVar('BUILDSTATS_BASE', True), toasterstatlist)) -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv3 0/6] recipetool/devtool/oe-selftest: pull from BBPATH
On Sat, 2015-07-25 at 12:18 -0700, Christopher Larson wrote: On Sat, Jul 25, 2015 at 9:09 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: however when I apply this and your other series, the autobuilder oe-selftest does this: https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/92/steps/Running%20oe-selftest/logs/stdio which is substantially worse. I can't immediately see what the issue is but the two runs above pretty much bisect this down to the patch series. I'm therefore reluctant to merge these until we can figure out what is going on... Given that both failures have nothing to do with devtool, recipetool, or oe-selftest and are simply bitbake build failures as called by tests, I don’t really see how these could have anything to do with that, but understood. FWIW, the issue is that you use the xxx:do_unpack syntax in one of the tests. This breaks toaster.bbclass and once its broken, it stays broken as its doing a split(:) on data in a file it never cleans up if the function fails. I've taken a fix which should avoid these issues. Will rerun a build with that applied (and various other fixes) and hopefully we can then get things merged. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v3] oeqa/buildoptions.py: automate test case 929: check for correct GPL licenses
Signed-off-by: Costin Constantin costin.c.constan...@intel.com --- meta/lib/oeqa/selftest/buildoptions.py | 29 + 1 file changed, 29 insertions(+) diff --git a/meta/lib/oeqa/selftest/buildoptions.py b/meta/lib/oeqa/selftest/buildoptions.py index e79be9e..9ef7776 100644 --- a/meta/lib/oeqa/selftest/buildoptions.py +++ b/meta/lib/oeqa/selftest/buildoptions.py @@ -132,6 +132,35 @@ class BuildImagesTest(oeSelfTest): res = bitbake(core-image-directfb, ignore_status=True) self.assertEqual(res.status, 0, \ncoreimagedirectfb failed to build. Please check logs for further details.\nbitbake output %s % res.output) +@testcase(929) +def test_gpl_licenses(self): + +Test for checking that correct GPL licenses are used when explicitly required. + +self.write_config(MACHINE = \qemux86\\nINHERIT += \archiver\\nARCHIVER_MODE[src] = \original\\nCOPYLEFT_LICENSE_INCLUDE = \GPLv2* GPLv3*\) +res = bitbake(core-image-minimal, ignore_status=True) +self.remove_config(MACHINE = \qemux86\\nINHERIT += \archiver\\nARCHIVER_MODE[src] = \original\\nCOPYLEFT_LICENSE_INCLUDE = \GPLv2* GPLv3*\) +self.assertEqual(res.status, 0, core-image-minimal didn't build. Please check logs for further details %s % res.output) +built_pkgs_list = os.listdir(self.builddir + /tmp/deploy/sources/i586-poky-linux/)# the list containing built pkgs with ver. +pkg_name_split = [i.split(-) for i in built_pkgs_list] +pkgs = [] # this will contain the pkgs name as found in tmp/deploy/licenses +for i in pkg_name_split: + name = + for j in i: +if i.index(j) == 0: + name = j +elif j.isalpha() and i.index(j) != 0: + name = name + - + j +else: + pkgs.append(name) + break +license_dir = self.builddir + /tmp/deploy/licenses/ +for i in pkgs: + if os.path.isdir(license_dir + i): +self.assertTrue(g.glob(license_dir + i + /*GPL*), couldn't find GPL license in + license_dir + for package + i) + else: +self.log.info(\nNo license dir for %s % i) + class ArchiverTest(oeSelfTest): @testcase(926) def test_arch_work_dir_and_export_source(self): -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] mesa: fix sed for MESA_EGL_NO_X11_HEADERS in fido
On Tue, Jul 21, 2015 at 10:46:11AM -0700, Tobias Olausson wrote: In 10.4 versions of mesa, the check for MESA_EGL_NO_X11_HEADERS uses an #ifdef, not an #if define(). So this commit which was recently backported to fido branch should be reverted: commit 12e467f436fbc22f274558c753f0ac9756ce1071 Author: Robert Yang liezhi.y...@windriver.com AuthorDate: Wed May 6 00:08:35 2015 -0700 Commit: Richard Purdie richard.pur...@linuxfoundation.org CommitDate: Sun Jun 28 09:41:54 2015 +0100 mesa: fix do_install_append ifdef MESA_EGL_NO_X11_HEADERS - if defined(MESA_EGL_NO_X11_HEADERS) (From OE-Core master rev: 3a464d67b60f70b865f7db768e7edc53e40ff450) Signed-off-by: Robert Yang liezhi.y...@windriver.com Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org Signed-off-by: Joshua Lock joshua.l...@collabora.co.uk with proper commit message (preferably separately from 9c746017af381884cc20c7cd563fc429c2c66112 backport), otherwise I like what this patch is doing. Thanks Also, this backports commit 9c746017af381884cc20c7cd563fc429c2c66112 to fido from master. Signed-off-by: Tobias Olausson tobias.olaus...@pelagicore.com --- meta/recipes-graphics/mesa/mesa_10.4.4.bb | 2 +- meta/recipes-graphics/mesa/mesa_git.bb| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-graphics/mesa/mesa_10.4.4.bb b/meta/recipes-graphics/mesa/mesa_10.4.4.bb index 90cccbe..a5f510d 100644 --- a/meta/recipes-graphics/mesa/mesa_10.4.4.bb +++ b/meta/recipes-graphics/mesa/mesa_10.4.4.bb @@ -11,6 +11,6 @@ S = ${WORKDIR}/Mesa-${PV} #make eglplatform.h independent of MESA_EGL_NO_X11_HEADER do_install_append() { if ${@bb.utils.contains('PACKAGECONFIG', 'egl', 'true', 'false', d)}; then -sed -i -e 's/^#if defined(MESA_EGL_NO_X11_HEADERS)/#if ${@bb.utils.contains('PACKAGECONFIG', 'x11', '0', '1', d)}/' ${D}${includedir}/EGL/eglplatform.h +sed -i -e 's/^#ifdef MESA_EGL_NO_X11_HEADERS/#if defined(MESA_EGL_NO_X11_HEADERS) || ${@bb.utils.contains('PACKAGECONFIG', 'x11', '0', '1', d)}/' ${D}${includedir}/EGL/eglplatform.h fi } diff --git a/meta/recipes-graphics/mesa/mesa_git.bb b/meta/recipes-graphics/mesa/mesa_git.bb index 1598019..269ae1e 100644 --- a/meta/recipes-graphics/mesa/mesa_git.bb +++ b/meta/recipes-graphics/mesa/mesa_git.bb @@ -13,6 +13,6 @@ S = ${WORKDIR}/git #make eglplatform.h independent of MESA_EGL_NO_X11_HEADER do_install_append() { if ${@bb.utils.contains('PACKAGECONFIG', 'egl', 'true', 'false', d)}; then -sed -i -e 's/^#if defined(MESA_EGL_NO_X11_HEADERS)/#if ${@bb.utils.contains('PACKAGECONFIG', 'x11', '0', '1', d)}/' ${D}${includedir}/EGL/eglplatform.h +sed -i -e 's/^#ifdef MESA_EGL_NO_X11_HEADERS/#if defined(MESA_EGL_NO_X11_HEADERS) || ${@bb.utils.contains('PACKAGECONFIG', 'x11', '0', '1', d)}/' ${D}${includedir}/EGL/eglplatform.h fi } -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] qt5 webkit Nothing RPROVIDES 'liborc-0.4'
On Thu, Jul 23, 2015 at 02:01:40PM +0300, Life Life wrote: Hello, I'm trying to build qt5 webkit. I seen this error message Build Configuration: BB_VERSION= 1.24.0 BUILD_SYS = x86_64-linux NATIVELSBSTRING = Ubuntu-14.04 TARGET_SYS= arm-poky-linux-gnueabi MACHINE = phyboard-wega-am335x-2 DISTRO= poky DISTRO_VERSION= 1.7 TUNE_FEATURES = arm armv7a vfp thumb neon callconvention-hard cortexa8 TARGET_FPU= vfp-neon meta meta-yocto= (nobranch):9aff3a4ec058a1a1149d026ebedcc6251089fffb meta-phytec = (nobranch):ccf1c78f312f84933b90926e9bf4f72de59e8e94 meta-phyam335x= (nobranch):a6c488b268d0c2e506f293221703dafcc05b9610 meta-oe meta-networking meta-python meta-multimedia = (nobranch):9efaed99125b1c4324663d9a1b2d3319c74e7278 meta-qt5 = master:6d9e2a6dfc21f7d9a3a11b4bcb426b5dfe6feaeb meta-ruby = (nobranch):9efaed99125b1c4324663d9a1b2d3319c74e7278 NOTE: Preparing runqueue NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks NOTE: Tasks Summary: Attempted 3367 tasks of which 3367 didn't need to be rerun and all succeeded. NOTE: Resolving any missing task queue dependencies ERROR: Nothing RPROVIDES 'liborc-0.4' (but /home/xy/yocto/build/recipes/images/ core-image-base-edited-20150723-135844.bb RDEPENDS on or otherwise requires it) My guess is that qtwebkit is autodetecting orc (as provided in meta/recipes-devtools/orc/orc_0.4.23.bb) so if you build qtwebkit in sysroot with orc already staged and then reuse the same qtwebkit build in build directory without orc you'll get this kind of error message. Proper fix is to explicitly disable orc support in qtwebkit (or even better add PACKAGECONFIG[orc] which will explicitly enable/disable it). Regards, -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com signature.asc Description: Digital signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] harfbuzz: upgrade to 1.0.1
- Update to Unicode 8.0; - Implement Universal Shaping Engine; - Bug fixes. Signed-off-by: Cristian Iorga cristian.io...@intel.com --- .../harfbuzz/{harfbuzz_0.9.41.bb = harfbuzz_1.0.1.bb}| 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-graphics/harfbuzz/{harfbuzz_0.9.41.bb = harfbuzz_1.0.1.bb} (88%) diff --git a/meta/recipes-graphics/harfbuzz/harfbuzz_0.9.41.bb b/meta/recipes-graphics/harfbuzz/harfbuzz_1.0.1.bb similarity index 88% rename from meta/recipes-graphics/harfbuzz/harfbuzz_0.9.41.bb rename to meta/recipes-graphics/harfbuzz/harfbuzz_1.0.1.bb index 1ea4563..a199126 100644 --- a/meta/recipes-graphics/harfbuzz/harfbuzz_0.9.41.bb +++ b/meta/recipes-graphics/harfbuzz/harfbuzz_1.0.1.bb @@ -11,8 +11,8 @@ LIC_FILES_CHKSUM = file://COPYING;md5=e021dd6dda6ff1e6b1044002fc662b9b \ SECTION = libs SRC_URI = http://www.freedesktop.org/software/harfbuzz/release/${BP}.tar.bz2; -SRC_URI[md5sum] = a2966f1b6a470c2cd84eb511f924cf68 -SRC_URI[sha256sum] = d81aa53d0c02b437beeaac159d7fc16394d676bbce0860fb6f6a10b587dc057c +SRC_URI[md5sum] = b9c144965dfde96672a7c6bdd4f9bf64 +SRC_URI[sha256sum] = 32a1a7ad584a2f2cfba5c1d234d046c0521e86e7a21d403e15e89aa509ef0ea8 inherit autotools pkgconfig lib_package -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] opkg-utils: fix bashism in opkg-build
Fix error '[[: not found' if /bin/sh is not bash. This issue was introduced by the recent addition of tar_ignore_error.patch to the opkg-utils recipe. Signed-off-by: Dominic Sacré dominic.sa...@gmx.de --- meta/recipes-devtools/opkg-utils/opkg-utils/tar_ignore_error.patch | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils/tar_ignore_error.patch b/meta/recipes-devtools/opkg-utils/opkg-utils/tar_ignore_error.patch index e8250b7..4dddb08 100644 --- a/meta/recipes-devtools/opkg-utils/opkg-utils/tar_ignore_error.patch +++ b/meta/recipes-devtools/opkg-utils/opkg-utils/tar_ignore_error.patch @@ -32,13 +32,13 @@ Index: git/opkg-build +# Ignore error code 1, caused by modifying the number of hard links while creating the tar file +rc=0 +( cd $pkg_dir tar $ogargs -X $tmp_dir/tarX -cz $tarformat -f $tmp_dir/data.tar.gz . ) || rc=$? -+if [[ $rc -ne 1 ]] [[ $rc -ne 0 ]] ;then ++if [ $rc -ne 1 ] [ $rc -ne 0 ]; then +exit $rc +fi + +rc=0 +( cd $pkg_dir/$CONTROL tar $ogargs -cz $tarformat -f $tmp_dir/control.tar.gz . ) || rc=$? -+if [[ $rc -ne 1 ]] [[ $rc -ne 0 ]] ;then ++if [ $rc -ne 1 ] [ $rc -ne 0 ]; then +exit $rc +fi + -- 2.4.6 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [poky][PATCH v2 1/6] gstreamer1.0-plugins-base: Bug fix for id3demux issue
On 27 July 2015 at 18:13, Otavio Salvador otavio.salva...@ossystems.com.br wrote: On Mon, Jul 27, 2015 at 2:05 PM, Burton, Ross ross.bur...@intel.com wrote: How many of these patches are applied in the 1.5 releases of GStreamer? We can upgrade instead and a colleague is going to be looking at the upgrades tomorrow, so if several can be dropped then that will save time and effort. Many but 1.5 is a development release and we should stay in 1.4 until 1.6 is out. Why did I think that GStreamer wasn't following odd/even releases? Sorry, ignore me. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] [master][dizzy] Enable Marvel 8897 Wifi feature
On Thu, Jul 9, 2015 at 2:10 AM, wei.tee...@intel.com wrote: I would like to add hostapd and iw configuration for enabling Marvell 8897 Wifi feature. Hostapd and iw configuration were created in the recipes-connectivity layer to enable Marvell 8897 module function in AP mode and STA mode. It can be added for master, I think. For Dizzy it makes no sense to backport this feature. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] [master][dizzy] Enable Marvel 8897 Wifi feature
On Mon, Jul 27, 2015 at 01:41:45PM -0300, Otavio Salvador wrote: On Thu, Jul 9, 2015 at 2:10 AM, wei.tee...@intel.com wrote: I would like to add hostapd and iw configuration for enabling Marvell 8897 Wifi feature. Hostapd and iw configuration were created in the recipes-connectivity layer to enable Marvell 8897 module function in AP mode and STA mode. It can be added for master, I think. For Dizzy it makes no sense to backport this feature. FWIW, both recipes are available in meta-oe layer, including dizzy branch. -- Hugo -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [poky][PATCH v2 1/6] gstreamer1.0-plugins-base: Bug fix for id3demux issue
How many of these patches are applied in the 1.5 releases of GStreamer? We can upgrade instead and a colleague is going to be looking at the upgrades tomorrow, so if several can be dropped then that will save time and effort. Ross On 27 July 2015 at 17:44, Otavio Salvador otavio.salva...@ossystems.com.br wrote: Hello, I am fine with the patch but it needs fixing. Check below. On Mon, Jul 27, 2015 at 8:26 AM, Yuqing Zhu b54...@freescale.com wrote: Use g_utf16_to_utf8() instead of g_convert to fix the issue that id3 tags utf16 charaters cannot be extreacted in id3demux when try to get the id3v2 tag such as TIT2, TALB etc. Signed-off-by: Yuqing Zhu b54...@freescale.com --- .../fix-id3demux-utf16-to-utf8-issue.patch | 54 ++ .../gstreamer/gstreamer1.0-plugins-base_1.4.5.bb | 1 + 2 files changed, 55 insertions(+) create mode 100755 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/fix-id3demux-utf16-to-utf8-issue.patch diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/fix-id3demux-utf16-to-utf8-issue.patch b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/fix-id3demux-utf16-to-utf8-issue.patch new file mode 100755 index 000..458d153 --- /dev/null +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/fix-id3demux-utf16-to-utf8-issue.patch @@ -0,0 +1,54 @@ +Author: Lyon Wang b12...@freescale.com +Date: Thu Oct 9 17:37:43 2014 +0800 + +[id3v2frames] Bug fix for id3demux issue + +Fix the issue that id3 tags utf16 charaters cannot be extreacted in id3demux +when I tried to get the id3v2 tag such as TIT2, TALB etc. it will return extrac +failed. + +Checked in id3v2frame.c, When parse the UTF-16 streams, it used g_convert() to +convert the buffer from UTF-16 to UTF-8, however it will return err that this +conversion is not supported which cause the extraction failed with these UTF-16 +characters. + +In the patch, use g_utf16_to_utf8() instead of g_convert, which can convert the +character format successfully. + +https://bugzilla.gnome.org/show_bug.cgi?id=741144 + +Upstream Status: Pending It is: Upstream-Status: and it seems all patches you sent has this very same error. Please update it and resend the whole serie (with this fixed in ALL patches) as it is easy to get missed while applying the patches and makes tracking harder. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [poky][PATCH v2 2/2] gstreamer1.0: Add basesink related patch
On Mon, Jul 27, 2015 at 8:29 AM, Yuqing Zhu b54...@freescale.com wrote: Fix QoS/lateness checking if subclass implements prepare/prepare_list vfuncs Signed-off-by: Yuqing Zhu b54...@freescale.com --- ...x-QoS-lateness-checking-if-subclass-imple.patch | 70 ++ .../gstreamer/gstreamer1.0_1.4.5.bb| 1 + 2 files changed, 71 insertions(+) create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0/0002-basesink-Fix-QoS-lateness-checking-if-subclass-imple.patch diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0/0002-basesink-Fix-QoS-lateness-checking-if-subclass-imple.patch b/meta/recipes-multimedia/gstreamer/gstreamer1.0/0002-basesink-Fix-QoS-lateness-checking-if-subclass-imple.patch new file mode 100644 index 000..2adfadc --- /dev/null +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0/0002-basesink-Fix-QoS-lateness-checking-if-subclass-imple.patch @@ -0,0 +1,70 @@ +From 6914566ed6a89c96973a578aa5ecd01ee68cdcfd Mon Sep 17 00:00:00 2001 +From: Jian jian...@freescale.com +Date: Thu, 14 May 2015 15:49:43 +0800 +Subject: [PATCH] basesink: Fix QoS/lateness checking if subclass implements + prepare/prepare_list vfuncs +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +In basesink functions gst_base_sink_chain_unlocked(), below code is used to +checking if buffer is late before doing prepare call to save some effort: +if (syncable do_sync) + late = + gst_base_sink_is_too_late (basesink, obj, rstart, rstop, + GST_CLOCK_EARLY, 0, FALSE); + +if (G_UNLIKELY (late)) + goto dropped; + +But this code has problem, it should calculate jitter based on current media +clock, rather than just passing 0. I found it will drop all the frames when +rewind in slow speed, such as -2X. + +https://bugzilla.gnome.org/show_bug.cgi?id=749258 + +Upstream Status: Backport-GST 1.5.1 The field is: Upstream-Status: Backport [1.5.1] -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [poky][PATCH v2 1/6] gstreamer1.0-plugins-base: Bug fix for id3demux issue
Hello, I am fine with the patch but it needs fixing. Check below. On Mon, Jul 27, 2015 at 8:26 AM, Yuqing Zhu b54...@freescale.com wrote: Use g_utf16_to_utf8() instead of g_convert to fix the issue that id3 tags utf16 charaters cannot be extreacted in id3demux when try to get the id3v2 tag such as TIT2, TALB etc. Signed-off-by: Yuqing Zhu b54...@freescale.com --- .../fix-id3demux-utf16-to-utf8-issue.patch | 54 ++ .../gstreamer/gstreamer1.0-plugins-base_1.4.5.bb | 1 + 2 files changed, 55 insertions(+) create mode 100755 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/fix-id3demux-utf16-to-utf8-issue.patch diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/fix-id3demux-utf16-to-utf8-issue.patch b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/fix-id3demux-utf16-to-utf8-issue.patch new file mode 100755 index 000..458d153 --- /dev/null +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/fix-id3demux-utf16-to-utf8-issue.patch @@ -0,0 +1,54 @@ +Author: Lyon Wang b12...@freescale.com +Date: Thu Oct 9 17:37:43 2014 +0800 + +[id3v2frames] Bug fix for id3demux issue + +Fix the issue that id3 tags utf16 charaters cannot be extreacted in id3demux +when I tried to get the id3v2 tag such as TIT2, TALB etc. it will return extrac +failed. + +Checked in id3v2frame.c, When parse the UTF-16 streams, it used g_convert() to +convert the buffer from UTF-16 to UTF-8, however it will return err that this +conversion is not supported which cause the extraction failed with these UTF-16 +characters. + +In the patch, use g_utf16_to_utf8() instead of g_convert, which can convert the +character format successfully. + +https://bugzilla.gnome.org/show_bug.cgi?id=741144 + +Upstream Status: Pending It is: Upstream-Status: and it seems all patches you sent has this very same error. Please update it and resend the whole serie (with this fixed in ALL patches) as it is easy to get missed while applying the patches and makes tracking harder. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [poky][PATCH v2 4/6] gstreamer1.0-plugins-base: Add video-frame related patch
On Mon, Jul 27, 2015 at 8:26 AM, Yuqing Zhu b54...@freescale.com wrote: -Add GST_VIDEO_FRAME_MAP_FLAG_NO_REF This makes sure that the buffer is not reffed another time when storing it in the GstVideoFrame, keeping it writable if it was writable. -Don't ref buffers twice when mapping Signed-off-by: Yuqing Zhu b54...@freescale.com Which recipe is applying this? It seems it is not being applied. --- ...rame-Don-t-ref-buffers-twice-when-mapping.patch | 25 +++ ...frame-Add-GST_VIDEO_FRAME_MAP_FLAG_NO_REF.patch | 87 ++ 2 files changed, 112 insertions(+) create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0001-video-frame-Don-t-ref-buffers-twice-when-mapping.patch create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0002-video-frame-Add-GST_VIDEO_FRAME_MAP_FLAG_NO_REF.patch diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0001-video-frame-Don-t-ref-buffers-twice-when-mapping.patch b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0001-video-frame-Don-t-ref-buffers-twice-when-mapping.patch new file mode 100644 index 000..c4eef00 --- /dev/null +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0001-video-frame-Don-t-ref-buffers-twice-when-mapping.patch @@ -0,0 +1,25 @@ +From 269f642c45d85cfd630ed490478e6bd6b71a767f Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Sebastian=20Dr=C3=B6ge?= sebast...@centricular.com +Date: Tue, 16 Sep 2014 01:07:18 +0300 +Subject: [PATCH] video-frame: Don't ref buffers twice when mapping Upstream-Status: ??? +--- + gst-libs/gst/video/video-frame.c |2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/gst-libs/gst/video/video-frame.c b/gst-libs/gst/video/video-frame.c +index 01f23c0..8a9ae96 100644 +--- a/gst-libs/gst/video/video-frame.c b/gst-libs/gst/video/video-frame.c +@@ -105,7 +105,7 @@ gst_video_frame_map_id (GstVideoFrame * frame, GstVideoInfo * info, + frame-data[i] = frame-map[0].data + info-offset[i]; + } + } +- frame-buffer = gst_buffer_ref (buffer); ++ frame-buffer = buffer; + if ((flags GST_VIDEO_FRAME_MAP_FLAG_NO_REF) == 0) + gst_buffer_ref (frame-buffer); + +-- +1.7.9.5 + diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0002-video-frame-Add-GST_VIDEO_FRAME_MAP_FLAG_NO_REF.patch b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0002-video-frame-Add-GST_VIDEO_FRAME_MAP_FLAG_NO_REF.patch new file mode 100644 index 000..554b8ac --- /dev/null +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0002-video-frame-Add-GST_VIDEO_FRAME_MAP_FLAG_NO_REF.patch @@ -0,0 +1,87 @@ +From 40a293d44d1aeccf5eb8e86f23a0b13666111c5c Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Sebastian=20Dr=C3=B6ge?= sebast...@centricular.com +Date: Fri, 12 Sep 2014 14:39:16 +0300 +Subject: [PATCH 2/3] video-frame: Add GST_VIDEO_FRAME_MAP_FLAG_NO_REF + +This makes sure that the buffer is not reffed another time when +storing it in the GstVideoFrame, keeping it writable if it was +writable. + +Upstream Status: Accepted +https://bugzilla.gnome.org/show_bug.cgi?id=736118 The field is: Upstream-Status: Submitted [https://...] +--- + gst-libs/gst/video/video-frame.c |9 - + gst-libs/gst/video/video-frame.h | 18 ++ + 2 files changed, 26 insertions(+), 1 deletion(-) + +diff --git a/gst-libs/gst/video/video-frame.c b/gst-libs/gst/video/video-frame.c +index 537cf70..01f23c0 100644 +--- a/gst-libs/gst/video/video-frame.c b/gst-libs/gst/video/video-frame.c +@@ -106,6 +106,9 @@ gst_video_frame_map_id (GstVideoFrame * frame, GstVideoInfo * info, + } + } + frame-buffer = gst_buffer_ref (buffer); ++ if ((flags GST_VIDEO_FRAME_MAP_FLAG_NO_REF) == 0) ++gst_buffer_ref (frame-buffer); ++ + frame-meta = meta; + + /* buffer flags enhance the frame flags */ +@@ -189,11 +192,13 @@ gst_video_frame_unmap (GstVideoFrame * frame) + GstBuffer *buffer; + GstVideoMeta *meta; + gint i; ++ GstMapFlags flags; + + g_return_if_fail (frame != NULL); + + buffer = frame-buffer; + meta = frame-meta; ++ flags = frame-map[0].flags; + + if (meta) { + for (i = 0; i frame-info.finfo-n_planes; i++) { +@@ -202,7 +207,9 @@ gst_video_frame_unmap (GstVideoFrame * frame) + } else { + gst_buffer_unmap (buffer, frame-map[0]); + } +- gst_buffer_unref (buffer); ++ ++ if ((flags GST_VIDEO_FRAME_MAP_FLAG_NO_REF) == 0) ++gst_buffer_unref (frame-buffer); + } + + /** +diff --git a/gst-libs/gst/video/video-frame.h b/gst-libs/gst/video/video-frame.h +index 627fab0..f8e6304 100644 +--- a/gst-libs/gst/video/video-frame.h b/gst-libs/gst/video/video-frame.h +@@ -149,6 +149,24 @@ typedef enum { + GST_VIDEO_BUFFER_FLAG_LAST= (GST_BUFFER_FLAG_LAST 8) + } GstVideoBufferFlags; + ++/** ++ *
Re: [OE-core] [poky][PATCH v2 1/6] gstreamer1.0-plugins-base: Bug fix for id3demux issue
On Mon, Jul 27, 2015 at 2:05 PM, Burton, Ross ross.bur...@intel.com wrote: How many of these patches are applied in the 1.5 releases of GStreamer? We can upgrade instead and a colleague is going to be looking at the upgrades tomorrow, so if several can be dropped then that will save time and effort. Many but 1.5 is a development release and we should stay in 1.4 until 1.6 is out. 1.5 is very nice and promising as we have been involved with some development funding and effort due a specific customer. Once 1.6 is out we ought to upgrade but for OE-Core 1.4 seems to be the one to focus for now. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [poky][PATCH v2 3/6] gstreamer1.0-plugins-base: update video alignment after video alignment
On Mon, Jul 27, 2015 at 8:26 AM, Yuqing Zhu b54...@freescale.com wrote: Video buffer pool will update video alignment to respect stride alignment requirement. But haven't update it to video alignment in configure. Which will cause user get wrong video alignment. Signed-off-by: Yuqing Zhu b54...@freescale.com --- .../videobuffer_updata_alignment_update.patch | 53 ++ .../gstreamer/gstreamer1.0-plugins-base_1.4.5.bb | 1 + 2 files changed, 54 insertions(+) create mode 100755 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/videobuffer_updata_alignment_update.patch diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/videobuffer_updata_alignment_update.patch b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/videobuffer_updata_alignment_update.patch new file mode 100755 index 000..57edd8b --- /dev/null +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/videobuffer_updata_alignment_update.patch @@ -0,0 +1,53 @@ +commit 88d253ea23b06289df40401160b606323f16c910 +Author: Song Bing b06...@freescale.com +Date: Mon Dec 15 09:34:35 2014 +0800 + +videopool: update video alignment after video alignment + +Video buffer pool will update video alignment to respect stride alignment +requirement. But haven't update it to video alignment in configure. +Which will cause user get wrong video alignment. + +https://bugzilla.gnome.org/show_bug.cgi?id=741501 + +Upstream Status: Backport Upstream-Status: Backport [WHERE?] -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [poky][PATCH v2 0/6] Upgrade to 3.14.38-6QP_Beta release
On Mon, Jul 27, 2015 at 8:26 AM, Yuqing Zhu b54...@freescale.com wrote: Fix id3demux issue Handle audio/video decoder error Update video alignment after video alignment Add GST_VIDEO_FRAME_MAP_FLAG_NO_REF, keeping buffer writable Gstvideofilter use new GST_VIDEO_FRAME_MAP_FLAG_NO_REF Don't ref buffers twice when mapping Keep sticky events around when doing a soft reset I stopped reviewing the patches as they need rework. All Upstream-Status need checking, they were not using the right format. Last time I reviewed I posted the link for the commit guidelines[1], it seems you didn't read them. Please do. 1. http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCHv3 0/6] recipetool/devtool/oe-selftest: pull from BBPATH
On Mon, Jul 27, 2015 at 5:16 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: On Sat, 2015-07-25 at 12:18 -0700, Christopher Larson wrote: On Sat, Jul 25, 2015 at 9:09 AM, Richard Purdie richard.pur...@linuxfoundation.org wrote: however when I apply this and your other series, the autobuilder oe-selftest does this: https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/92/steps/Running%20oe-selftest/logs/stdio which is substantially worse. I can't immediately see what the issue is but the two runs above pretty much bisect this down to the patch series. I'm therefore reluctant to merge these until we can figure out what is going on... Given that both failures have nothing to do with devtool, recipetool, or oe-selftest and are simply bitbake build failures as called by tests, I don’t really see how these could have anything to do with that, but understood. FWIW, the issue is that you use the xxx:do_unpack syntax in one of the tests. This breaks toaster.bbclass and once its broken, it stays broken as its doing a split(:) on data in a file it never cleans up if the function fails. I've taken a fix which should avoid these issues. Will rerun a build with that applied (and various other fixes) and hopefully we can then get things merged. Ah! That explains it. Thanks. Obviously I could have used -c, but I’m a fan of the new syntax, it gives some nice flexibility :) -- Christopher Larson kergoth at gmail dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] mesa: fix sed for MESA_EGL_NO_X11_HEADERS in fido
On 27 July 2015 at 08:25, Martin Jansa martin.ja...@gmail.com wrote: On Tue, Jul 21, 2015 at 10:46:11AM -0700, Tobias Olausson wrote: In 10.4 versions of mesa, the check for MESA_EGL_NO_X11_HEADERS uses an #ifdef, not an #if define(). So this commit which was recently backported to fido branch should be reverted: Well, reverting the already backported patch would break my patch. I don't mind resubmitting a new patch, but the one I originally submitted builds on top of the backported one, so the backported one would be neutralized. commit 12e467f436fbc22f274558c753f0ac9756ce1071 Author: Robert Yang liezhi.y...@windriver.com AuthorDate: Wed May 6 00:08:35 2015 -0700 Commit: Richard Purdie richard.pur...@linuxfoundation.org CommitDate: Sun Jun 28 09:41:54 2015 +0100 mesa: fix do_install_append ifdef MESA_EGL_NO_X11_HEADERS - if defined(MESA_EGL_NO_X11_HEADERS) (From OE-Core master rev: 3a464d67b60f70b865f7db768e7edc53e40ff450) Signed-off-by: Robert Yang liezhi.y...@windriver.com Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org Signed-off-by: Joshua Lock joshua.l...@collabora.co.uk with proper commit message (preferably separately from 9c746017af381884cc20c7cd563fc429c2c66112 backport), otherwise I like what this patch is doing. Thanks Also, this backports commit 9c746017af381884cc20c7cd563fc429c2c66112 to fido from master. Signed-off-by: Tobias Olausson tobias.olaus...@pelagicore.com --- meta/recipes-graphics/mesa/mesa_10.4.4.bb | 2 +- meta/recipes-graphics/mesa/mesa_git.bb| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-graphics/mesa/mesa_10.4.4.bb b/meta/recipes-graphics/mesa/mesa_10.4.4.bb index 90cccbe..a5f510d 100644 --- a/meta/recipes-graphics/mesa/mesa_10.4.4.bb +++ b/meta/recipes-graphics/mesa/mesa_10.4.4.bb @@ -11,6 +11,6 @@ S = ${WORKDIR}/Mesa-${PV} #make eglplatform.h independent of MESA_EGL_NO_X11_HEADER do_install_append() { if ${@bb.utils.contains('PACKAGECONFIG', 'egl', 'true', 'false', d)}; then -sed -i -e 's/^#if defined(MESA_EGL_NO_X11_HEADERS)/#if ${@bb.utils.contains('PACKAGECONFIG', 'x11', '0', '1', d)}/' ${D}${includedir}/EGL/eglplatform.h +sed -i -e 's/^#ifdef MESA_EGL_NO_X11_HEADERS/#if defined(MESA_EGL_NO_X11_HEADERS) || ${@bb.utils.contains('PACKAGECONFIG', 'x11', '0', '1', d)}/' ${D}${includedir}/EGL/eglplatform.h fi } diff --git a/meta/recipes-graphics/mesa/mesa_git.bb b/meta/recipes-graphics/mesa/mesa_git.bb index 1598019..269ae1e 100644 --- a/meta/recipes-graphics/mesa/mesa_git.bb +++ b/meta/recipes-graphics/mesa/mesa_git.bb @@ -13,6 +13,6 @@ S = ${WORKDIR}/git #make eglplatform.h independent of MESA_EGL_NO_X11_HEADER do_install_append() { if ${@bb.utils.contains('PACKAGECONFIG', 'egl', 'true', 'false', d)}; then -sed -i -e 's/^#if defined(MESA_EGL_NO_X11_HEADERS)/#if ${@bb.utils.contains('PACKAGECONFIG', 'x11', '0', '1', d)}/' ${D}${includedir}/EGL/eglplatform.h +sed -i -e 's/^#ifdef MESA_EGL_NO_X11_HEADERS/#if defined(MESA_EGL_NO_X11_HEADERS) || ${@bb.utils.contains('PACKAGECONFIG', 'x11', '0', '1', d)}/' ${D}${includedir}/EGL/eglplatform.h fi } -- 2.1.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com -- Tobias Olausson M.Sc Software Engineer PELAGICORE | Experience Change Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden Mobile: +46(0)735-873444 E-Mail: tobias.olaus...@pelagicore.com IRC: wto @ FreeNode -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] [master][dizzy] Enable Marvel 8897 Wifi feature
On 27 July 2015 at 19:28, Otavio Salvador otavio.salva...@ossystems.com.br wrote: Sure but this is not a bugfix. I am opposed to backport features without a very clear reason and this does not seem to qualify as a massive need. Indeed, and existence in meta-oe is an even better reason *not* to backport to oe-core dizzy. If there's a product being built on the dizzy release, then these can be added to your distro layer (or meta-oe used directly). Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] [master][dizzy] Enable Marvel 8897 Wifi feature
On Mon, Jul 27, 2015 at 03:28:46PM -0300, Otavio Salvador wrote: On Mon, Jul 27, 2015 at 3:15 PM, Hugo Vasconcelos Saldanha hugo.salda...@aker.com.br wrote: On Mon, Jul 27, 2015 at 01:41:45PM -0300, Otavio Salvador wrote: On Thu, Jul 9, 2015 at 2:10 AM, wei.tee...@intel.com wrote: I would like to add hostapd and iw configuration for enabling Marvell 8897 Wifi feature. Hostapd and iw configuration were created in the recipes-connectivity layer to enable Marvell 8897 module function in AP mode and STA mode. It can be added for master, I think. For Dizzy it makes no sense to backport this feature. FWIW, both recipes are available in meta-oe layer, including dizzy branch. Sure but this is not a bugfix. I am opposed to backport features without a very clear reason and this does not seem to qualify as a massive need. Totally agreed. I was just questioning the need to add these recipes to oe-core since they are available elsewhere. -- Hugo -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] [master][dizzy] Enable Marvel 8897 Wifi feature
On Mon, Jul 27, 2015 at 3:15 PM, Hugo Vasconcelos Saldanha hugo.salda...@aker.com.br wrote: On Mon, Jul 27, 2015 at 01:41:45PM -0300, Otavio Salvador wrote: On Thu, Jul 9, 2015 at 2:10 AM, wei.tee...@intel.com wrote: I would like to add hostapd and iw configuration for enabling Marvell 8897 Wifi feature. Hostapd and iw configuration were created in the recipes-connectivity layer to enable Marvell 8897 module function in AP mode and STA mode. It can be added for master, I think. For Dizzy it makes no sense to backport this feature. FWIW, both recipes are available in meta-oe layer, including dizzy branch. Sure but this is not a bugfix. I am opposed to backport features without a very clear reason and this does not seem to qualify as a massive need. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] oeqa/qemurunner: Fix AttributeError: QemuRunner instance has no attribute 'server_socket'
If start() returns False due to create_socker() failing, stop() may still get called and currently this gives a track back since server_socket doesn't exist. Avoid this. Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org diff --git a/meta/lib/oeqa/utils/qemurunner.py b/meta/lib/oeqa/utils/qemurunner.py index 22bf91b..f81658f 100644 --- a/meta/lib/oeqa/utils/qemurunner.py +++ b/meta/lib/oeqa/utils/qemurunner.py @@ -174,7 +174,7 @@ class QemuRunner: logging.info(Sending SIGKILL to runqemu) os.killpg(self.runqemu.pid, signal.SIGKILL) self.runqemu = None -if self.server_socket: +if hasattr(self, 'server_socket'): self.server_socket.close() self.server_socket = None self.qemupid = None -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] u-boot-mkimage: fix a building failure on OpenSus
From: Roy Li rongqing...@windriver.com Signed-off-by: Roy Li rongqing...@windriver.com --- ...-the-creation-of-include-config-auto.conf.patch | 54 ++ meta/recipes-bsp/u-boot/u-boot-mkimage_2015.01.bb | 1 + 2 files changed, 55 insertions(+) create mode 100644 meta/recipes-bsp/u-boot/u-boot-mkimage/0001-delay-the-creation-of-include-config-auto.conf.patch diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage/0001-delay-the-creation-of-include-config-auto.conf.patch b/meta/recipes-bsp/u-boot/u-boot-mkimage/0001-delay-the-creation-of-include-config-auto.conf.patch new file mode 100644 index 000..071aa67 --- /dev/null +++ b/meta/recipes-bsp/u-boot/u-boot-mkimage/0001-delay-the-creation-of-include-config-auto.conf.patch @@ -0,0 +1,54 @@ +[PATCH] delay the creation of include/config/auto.conf + +Upstream-Statue: Pending + +config.mk will be included only if auto.conf is newer than .config +but in some system, the HPET is not enabled, the smallest unit of +time is second, and can not decise which file is newer, even if +the correct dependency has been created. + +The below shows unit of time: + +under SUSE Linux Enterprise Desktop 11 SP2 (i586): +$ls --full-time include/config/auto.conf .config +2015-07-27 03:46:20.0 -0400 .config +2015-07-27 03:46:20.0 -0400 include/config/auto.conf +$ + +under Ubuntu 14.04 LTS: +$ ls --full-time include/config/auto.conf .config +2015-07-27 13:40:14.008703027 +0800 .config +2015-07-27 13:40:15.020703054 +0800 include/config/auto.conf +$ + +The rule of including config.mk in Makefile as below +autoconf_is_current := $(if $(wildcard $(KCONFIG_CONFIG)),$(shell find . \ +-path ./include/config/auto.conf -newer $(KCONFIG_CONFIG))) +ifneq ($(autoconf_is_current),) +include $(srctree)/config.mk +include $(srctree)/arch/$(ARCH)/Makefile +endif + +The compilation will be failed if config.mk is not included +so delay 1 second to create auto.conf after creating of .config + +Signed-off-by: Roy Li rongqing...@windriver.com +--- + Makefile | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/Makefile b/Makefile +index 36a9a28..5f085ad 100644 +--- a/Makefile b/Makefile +@@ -490,6 +490,7 @@ $(KCONFIG_CONFIG) include/config/auto.conf.cmd: ; + # if auto.conf.cmd is missing then we are probably in a cleaned tree so + # we execute the config step to be sure to catch updated Kconfig files + include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd ++ sleep 1; \ + $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig + + -include include/autoconf.mk +-- +1.9.1 + diff --git a/meta/recipes-bsp/u-boot/u-boot-mkimage_2015.01.bb b/meta/recipes-bsp/u-boot/u-boot-mkimage_2015.01.bb index 7735288..c0007c9 100644 --- a/meta/recipes-bsp/u-boot/u-boot-mkimage_2015.01.bb +++ b/meta/recipes-bsp/u-boot/u-boot-mkimage_2015.01.bb @@ -14,6 +14,7 @@ PV = v2015.01+git${SRCPV} SRC_URI = git://git.denx.de/u-boot.git;branch=master \ file://gcc5.patch \ + file://0001-delay-the-creation-of-include-config-auto.conf.patch \ S = ${WORKDIR}/git -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 7/9] help2man-native: 1.46.4 - 1.47.1
Signed-off-by: Robert Yang liezhi.y...@windriver.com --- ...-native_1.46.4.bb = help2man-native_1.47.1.bb} |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-devtools/help2man/{help2man-native_1.46.4.bb = help2man-native_1.47.1.bb} (79%) diff --git a/meta/recipes-devtools/help2man/help2man-native_1.46.4.bb b/meta/recipes-devtools/help2man/help2man-native_1.47.1.bb similarity index 79% rename from meta/recipes-devtools/help2man/help2man-native_1.46.4.bb rename to meta/recipes-devtools/help2man/help2man-native_1.47.1.bb index 5b90da9..bc6d50e 100644 --- a/meta/recipes-devtools/help2man/help2man-native_1.46.4.bb +++ b/meta/recipes-devtools/help2man/help2man-native_1.47.1.bb @@ -6,8 +6,8 @@ DEPENDS = autoconf-native automake-native SRC_URI = ${GNU_MIRROR}/${BPN}/${BPN}-${PV}.tar.xz -SRC_URI[md5sum] = a1b7fe49eddae8a2537ed74ee9ef11cb -SRC_URI[sha256sum] = 1ae7f15f53b0cc55b070ae49df2ee5caa942c71529054e157599427bba3c5633 +SRC_URI[md5sum] = cf7aaaeea40bff1176df825430694173 +SRC_URI[sha256sum] = c59b26f60cb06e45b00e729dea721e7a17220e2c17d800eb428271a750382b06 inherit autotools native -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 9/9] pax-utils: 1.0.3 - 1.0.5
Signed-off-by: Robert Yang liezhi.y...@windriver.com --- .../{pax-utils_1.0.3.bb = pax-utils_1.0.5.bb} |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-devtools/pax-utils/{pax-utils_1.0.3.bb = pax-utils_1.0.5.bb} (83%) diff --git a/meta/recipes-devtools/pax-utils/pax-utils_1.0.3.bb b/meta/recipes-devtools/pax-utils/pax-utils_1.0.5.bb similarity index 83% rename from meta/recipes-devtools/pax-utils/pax-utils_1.0.3.bb rename to meta/recipes-devtools/pax-utils/pax-utils_1.0.5.bb index b063f20..0716a08 100644 --- a/meta/recipes-devtools/pax-utils/pax-utils_1.0.3.bb +++ b/meta/recipes-devtools/pax-utils/pax-utils_1.0.5.bb @@ -9,8 +9,8 @@ LIC_FILES_CHKSUM = file://COPYING;md5=eb723b61539feef013de476e68b5c50a SRC_URI = http://gentoo.osuosl.org/distfiles/pax-utils-${PV}.tar.xz; -SRC_URI[md5sum] = e1c9f808a661204fbdca5e3b17da791e -SRC_URI[sha256sum] = 8535a94e1f77841da92d5526d2935abb786437fdf11be9ed077a78ab5e6b5670 +SRC_URI[md5sum] = d731f5385682a7a62ee2e7b7dacc13a7 +SRC_URI[sha256sum] = f69a9938e4af7912d26d585094bc0203e43571a990fdd048319088a8b8ad906f RDEPENDS_${PN} += bash python -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/9] cracklib: 2.9.4 - 2.9.5
Signed-off-by: Robert Yang liezhi.y...@windriver.com --- .../{cracklib_2.9.4.bb = cracklib_2.9.5.bb} |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-extended/cracklib/{cracklib_2.9.4.bb = cracklib_2.9.5.bb} (91%) diff --git a/meta/recipes-extended/cracklib/cracklib_2.9.4.bb b/meta/recipes-extended/cracklib/cracklib_2.9.5.bb similarity index 91% rename from meta/recipes-extended/cracklib/cracklib_2.9.4.bb rename to meta/recipes-extended/cracklib/cracklib_2.9.5.bb index 24730b8..c0ffe33 100644 --- a/meta/recipes-extended/cracklib/cracklib_2.9.4.bb +++ b/meta/recipes-extended/cracklib/cracklib_2.9.5.bb @@ -15,8 +15,8 @@ SRC_URI = ${SOURCEFORGE_MIRROR}/cracklib/cracklib-${PV}.tar.gz \ file://0001-packlib.c-support-dictionary-byte-order-dependent.patch \ file://0002-craklib-fix-testnum-and-teststr-failed.patch -SRC_URI[md5sum] = b31f7e3618cda7a2ac38588067275013 -SRC_URI[sha256sum] = f2a866b4b9808344228ea6d68b69e3ba9a8a99210e23dfd718d4b95c60be8958 +SRC_URI[md5sum] = 376790a95c1fb645e59e6e9803c78582 +SRC_URI[sha256sum] = 59ab0138bc8cf90cccb8509b6969a024d5e58d2d02bcbdccbb9ba9b88be3fa33 inherit autotools gettext pythonnative python-dir -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 8/9] man-pages: 4.00 - 4.01
Signed-off-by: Robert Yang liezhi.y...@windriver.com --- .../{man-pages_4.00.bb = man-pages_4.01.bb} | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) rename meta/recipes-extended/man-pages/{man-pages_4.00.bb = man-pages_4.01.bb} (81%) diff --git a/meta/recipes-extended/man-pages/man-pages_4.00.bb b/meta/recipes-extended/man-pages/man-pages_4.01.bb similarity index 81% rename from meta/recipes-extended/man-pages/man-pages_4.00.bb rename to meta/recipes-extended/man-pages/man-pages_4.01.bb index 121dd6c..f6a5c49 100644 --- a/meta/recipes-extended/man-pages/man-pages_4.00.bb +++ b/meta/recipes-extended/man-pages/man-pages_4.01.bb @@ -7,18 +7,13 @@ LICENSE = GPLv2+ LIC_FILES_CHKSUM = file://README;md5=8f2a3d43057d458e5066714980567a60 SRC_URI = ${KERNELORG_MIRROR}/linux/docs/${BPN}/Archive/${BP}.tar.gz -SRC_URI[md5sum] = c9bd70494ae18b19eb6be9c3845536ec -SRC_URI[sha256sum] = 6eea4583b8688c7d305b48d5908fa22700f57792617e4b1f3cd3766ddb520553 +SRC_URI[md5sum] = 575f4e8920166b1433c329bb621819d1 +SRC_URI[sha256sum] = ba89f3453982fae6c699a877368d51ee27883b4de709e753eee3783b447a8381 RDEPENDS_${PN} = man -do_configure () { - : -} - -do_compile() { - : -} +do_configure[noexec] = 1 +do_compile[noexec] = 1 do_install() { oe_runmake install DESTDIR=${D} -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/9] git: 2.4.4 - 2.4.6
Signed-off-by: Robert Yang liezhi.y...@windriver.com --- meta/recipes-devtools/git/git_2.4.4.bb | 11 --- meta/recipes-devtools/git/git_2.4.6.bb | 11 +++ 2 files changed, 11 insertions(+), 11 deletions(-) delete mode 100644 meta/recipes-devtools/git/git_2.4.4.bb create mode 100644 meta/recipes-devtools/git/git_2.4.6.bb diff --git a/meta/recipes-devtools/git/git_2.4.4.bb b/meta/recipes-devtools/git/git_2.4.4.bb deleted file mode 100644 index f9c81ed..000 --- a/meta/recipes-devtools/git/git_2.4.4.bb +++ /dev/null @@ -1,11 +0,0 @@ -require git.inc - -SRC_URI[tarball.md5sum] = f122606aee328de3e1019cde720cb0aa -SRC_URI[tarball.sha256sum] = a5d9e3e340a3e5a297092430752f61a9ae5b8b5e4ac042b0341d17189e653456 -SRC_URI[manpages.md5sum] = 285b126907d59647248577a7df01c44c -SRC_URI[manpages.sha256sum] = 15afc42909078909ca7a48d73b7cb358b37f734b81fc3a0c6438be183f05480f - -EXTRA_OECONF += ac_cv_snprintf_returns_bogus=no \ - ac_cv_fread_reads_directories=${ac_cv_fread_reads_directories=yes} \ - -EXTRA_OEMAKE += NO_GETTEXT=1 diff --git a/meta/recipes-devtools/git/git_2.4.6.bb b/meta/recipes-devtools/git/git_2.4.6.bb new file mode 100644 index 000..3655756 --- /dev/null +++ b/meta/recipes-devtools/git/git_2.4.6.bb @@ -0,0 +1,11 @@ +require git.inc + +EXTRA_OECONF += ac_cv_snprintf_returns_bogus=no \ + ac_cv_fread_reads_directories=${ac_cv_fread_reads_directories=yes} \ + +EXTRA_OEMAKE += NO_GETTEXT=1 + +SRC_URI[tarball.md5sum] = af7f48ebe09eef41504241d4a845610b +SRC_URI[tarball.sha256sum] = c4220a6a24de853044702d9727204ef6bf254012d64e9e0f22ef46a63ec2dbe4 +SRC_URI[manpages.md5sum] = b4bd9c649e263240035708ac28a7b680 +SRC_URI[manpages.sha256sum] = 9a84a7e7b8ea7272fac103a1c4b390872faf31a96754aa41e76ed48c437b382f -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/9] Packages Upgrade
The following changes since commit 27d068d05239c26a3848eb101571acab54635e37: harfbuzz: upgrade to 1.0.1 (2015-07-27 23:28:23 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rbt/PU http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/PU Robert Yang (9): git: 2.4.4 - 2.4.6 file: 5.23 - 5.24 libuser: 0.61 - 0.62 less: 478 - 479 cracklib: 2.9.4 - 2.9.5 gnupg: 2.1.5 - 2.1.6 help2man-native: 1.46.4 - 1.47.1 man-pages: 4.00 - 4.01 pax-utils: 1.0.3 - 1.0.5 ...h-long-options-and-explicitly-number-them.patch | 116 .../file/0002-fix-bug-with-5.23-long-options.patch | 26 - .../file/{file_5.23.bb = file_git.bb} | 17 ++- meta/recipes-devtools/git/git_2.4.4.bb | 11 -- meta/recipes-devtools/git/git_2.4.6.bb | 11 ++ ...-native_1.46.4.bb = help2man-native_1.47.1.bb} |4 +- .../{pax-utils_1.0.3.bb = pax-utils_1.0.5.bb} |4 +- .../{cracklib_2.9.4.bb = cracklib_2.9.5.bb} |4 +- .../less/{less_478.bb = less_479.bb} |4 +- .../libuser/{libuser_0.61.bb = libuser_0.62.bb} |4 +- .../{man-pages_4.00.bb = man-pages_4.01.bb} | 13 +-- .../gnupg/{gnupg_2.1.5.bb = gnupg_2.1.6.bb} |4 +- 12 files changed, 35 insertions(+), 183 deletions(-) delete mode 100644 meta/recipes-devtools/file/file/0001-Fix-bug-with-long-options-and-explicitly-number-them.patch delete mode 100644 meta/recipes-devtools/file/file/0002-fix-bug-with-5.23-long-options.patch rename meta/recipes-devtools/file/{file_5.23.bb = file_git.bb} (64%) delete mode 100644 meta/recipes-devtools/git/git_2.4.4.bb create mode 100644 meta/recipes-devtools/git/git_2.4.6.bb rename meta/recipes-devtools/help2man/{help2man-native_1.46.4.bb = help2man-native_1.47.1.bb} (79%) rename meta/recipes-devtools/pax-utils/{pax-utils_1.0.3.bb = pax-utils_1.0.5.bb} (83%) rename meta/recipes-extended/cracklib/{cracklib_2.9.4.bb = cracklib_2.9.5.bb} (91%) rename meta/recipes-extended/less/{less_478.bb = less_479.bb} (88%) rename meta/recipes-extended/libuser/{libuser_0.61.bb = libuser_0.62.bb} (88%) rename meta/recipes-extended/man-pages/{man-pages_4.00.bb = man-pages_4.01.bb} (81%) rename meta/recipes-support/gnupg/{gnupg_2.1.5.bb = gnupg_2.1.6.bb} (89%) -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/9] less: 478 - 479
Signed-off-by: Robert Yang liezhi.y...@windriver.com --- .../less/{less_478.bb = less_479.bb} |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-extended/less/{less_478.bb = less_479.bb} (88%) diff --git a/meta/recipes-extended/less/less_478.bb b/meta/recipes-extended/less/less_479.bb similarity index 88% rename from meta/recipes-extended/less/less_478.bb rename to meta/recipes-extended/less/less_479.bb index fc63774d..618954b 100644 --- a/meta/recipes-extended/less/less_478.bb +++ b/meta/recipes-extended/less/less_479.bb @@ -27,8 +27,8 @@ DEPENDS = ncurses SRC_URI = http://www.greenwoodsoftware.com/${BPN}/${BPN}-${PV}.tar.gz \ -SRC_URI[md5sum] = 934fcc9f137b9ef66a943c224f413d39 -SRC_URI[sha256sum] = 495c7df52199a0c7e6bfbbe7697b2b54f4bf197c8b10b43957762d74483574ce +SRC_URI[md5sum] = 049f51ccfe2686009c6ce943eeb4bbaf +SRC_URI[sha256sum] = 5bf06cb30ee2a2bd1f79f39aa91e46444e7cb19b48c95c4992fa63cfe4527a80 inherit autotools update-alternatives -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/9] file: 5.23 - 5.24
* Remove backported patch: - 0001-Fix-bug-with-long-options-and-explicitly-number-them.patch \ - 0002-fix-bug-with-5.23-long-options.patch \ * Use git repo rather than tarball since the original SRC_URI is not stable, it is not reachable sometimes. Signed-off-by: Robert Yang liezhi.y...@windriver.com --- ...h-long-options-and-explicitly-number-them.patch | 116 .../file/0002-fix-bug-with-5.23-long-options.patch | 26 - .../file/{file_5.23.bb = file_git.bb} | 17 ++- 3 files changed, 8 insertions(+), 151 deletions(-) delete mode 100644 meta/recipes-devtools/file/file/0001-Fix-bug-with-long-options-and-explicitly-number-them.patch delete mode 100644 meta/recipes-devtools/file/file/0002-fix-bug-with-5.23-long-options.patch rename meta/recipes-devtools/file/{file_5.23.bb = file_git.bb} (64%) diff --git a/meta/recipes-devtools/file/file/0001-Fix-bug-with-long-options-and-explicitly-number-them.patch b/meta/recipes-devtools/file/file/0001-Fix-bug-with-long-options-and-explicitly-number-them.patch deleted file mode 100644 index 0a3e27a..000 --- a/meta/recipes-devtools/file/file/0001-Fix-bug-with-long-options-and-explicitly-number-them.patch +++ /dev/null @@ -1,116 +0,0 @@ -From 21f9d5f0e0340ada998f7f9d316368c7167a4afa Mon Sep 17 00:00:00 2001 -From: Christos Zoulas chris...@zoulas.com -Date: Thu, 11 Jun 2015 12:52:32 + -Subject: [PATCH 1/2] Fix bug with long options and explicitly number them to - avoid this in the future. - -Upstream-Status: Backport - -Signed-off-by: Robert Yang liezhi.y...@windriver.com - - src/file.c | 44 +++-- - src/file_opts.h | 10 +- - 2 files changed, 27 insertions(+), 26 deletions(-) - -diff --git a/src/file.c b/src/file.c -index f60dde0..c700f66 100644 a/src/file.c -+++ b/src/file.c -@@ -89,10 +89,15 @@ private int/* Global command-line options */ - - private const char *separator = :; /* Default field separator */ - private const struct option long_options[] = { -+#define OPT_HELP 1 -+#define OPT_APPLE 2 -+#define OPT_EXTENSIONS3 -+#define OPT_MIME_TYPE 4 -+#define OPT_MIME_ENCODING 5 - #define OPT(shortname, longname, opt, doc) \ - {longname, opt, NULL, shortname}, --#define OPT_LONGONLY(longname, opt, doc)\ --{longname, opt, NULL, 0}, -+#define OPT_LONGONLY(longname, opt, doc, id)\ -+{longname, opt, NULL, id}, - #include file_opts.h - #undef OPT - #undef OPT_LONGONLY -@@ -182,24 +187,20 @@ main(int argc, char *argv[]) - while ((c = getopt_long(argc, argv, OPTSTRING, long_options, - longindex)) != -1) - switch (c) { -- case 0 : -- switch (longindex) { -- case 0: -- help(); -- break; -- case 10: -- flags |= MAGIC_APPLE; -- break; -- case 11: -- flags |= MAGIC_EXTENSION; -- break; -- case 12: -- flags |= MAGIC_MIME_TYPE; -- break; -- case 13: -- flags |= MAGIC_MIME_ENCODING; -- break; -- } -+ case OPT_HELP: -+ help(); -+ break; -+ case OPT_APPLE: -+ flags |= MAGIC_APPLE; -+ break; -+ case OPT_EXTENSIONS: -+ flags |= MAGIC_EXTENSION; -+ break; -+ case OPT_MIME_TYPE: -+ flags |= MAGIC_MIME_TYPE; -+ break; -+ case OPT_MIME_ENCODING: -+ flags |= MAGIC_MIME_ENCODING; - break; - case '0': - nulsep = 1; -@@ -595,7 +596,7 @@ help(void) - #define OPT(shortname, longname, opt, doc) \ - fprintf(stdout, -%c, -- longname, shortname), \ - docprint(doc); --#define OPT_LONGONLY(longname, opt, doc)\ -+#define OPT_LONGONLY(longname, opt, doc, id)\ - fprintf(stdout, -- longname), \ - docprint(doc); - #include file_opts.h -diff --git a/src/file_opts.h b/src/file_opts.h -index 036505f..2e30d06 100644 a/src/file_opts.h -+++ b/src/file_opts.h -@@ -12,7 +12,7 @@ - * switch statement! - */ - --OPT_LONGONLY(help, 0, display this help and exit\n) -+OPT_LONGONLY(help, 0, display this help and exit\n, OPT_HELP) - OPT('v', version, 0, output version information and exit\n) - OPT('m', magic-file, 1, LIST use LIST as a colon-separated list of magic\n -
[OE-core] [PATCH 6/9] gnupg: 2.1.5 - 2.1.6
Signed-off-by: Robert Yang liezhi.y...@windriver.com --- .../gnupg/{gnupg_2.1.5.bb = gnupg_2.1.6.bb} |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-support/gnupg/{gnupg_2.1.5.bb = gnupg_2.1.6.bb} (89%) diff --git a/meta/recipes-support/gnupg/gnupg_2.1.5.bb b/meta/recipes-support/gnupg/gnupg_2.1.6.bb similarity index 89% rename from meta/recipes-support/gnupg/gnupg_2.1.5.bb rename to meta/recipes-support/gnupg/gnupg_2.1.6.bb index 8eb6b90..59aac37 100644 --- a/meta/recipes-support/gnupg/gnupg_2.1.5.bb +++ b/meta/recipes-support/gnupg/gnupg_2.1.6.bb @@ -14,8 +14,8 @@ SRC_URI = ftp://ftp.gnupg.org/gcrypt/${BPN}/${BPN}-${PV}.tar.bz2 \ file://dirmngr-uses-libgpg-error.patch \ -SRC_URI[md5sum] = ff16648f14ec164c7afce1066019364b -SRC_URI[sha256sum] = b5105a7160c39ba6e3aa53789b09f1bfac6e3422d15cc9f3a2f71f82320aa84c +SRC_URI[md5sum] = cc7345b1d9ada92a0d19f4ae406741b4 +SRC_URI[sha256sum] = 5e599ad542199f3bd733eed2b88a539d1b4c3beda2dbab0ff69f1896f52e92fd EXTRA_OECONF = --disable-ldap \ --disable-ccid-driver \ -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/9] libuser: 0.61 - 0.62
Signed-off-by: Robert Yang liezhi.y...@windriver.com --- .../libuser/{libuser_0.61.bb = libuser_0.62.bb} |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename meta/recipes-extended/libuser/{libuser_0.61.bb = libuser_0.62.bb} (88%) diff --git a/meta/recipes-extended/libuser/libuser_0.61.bb b/meta/recipes-extended/libuser/libuser_0.62.bb similarity index 88% rename from meta/recipes-extended/libuser/libuser_0.61.bb rename to meta/recipes-extended/libuser/libuser_0.62.bb index f2b9ddb..c4ed459 100644 --- a/meta/recipes-extended/libuser/libuser_0.61.bb +++ b/meta/recipes-extended/libuser/libuser_0.62.bb @@ -14,8 +14,8 @@ SECTION = base SRC_URI = https://fedorahosted.org/releases/l/i/libuser/libuser-${PV}.tar.xz \ -SRC_URI[md5sum] = d977dc59161272c1491edd9ca7ba22f2 -SRC_URI[sha256sum] = 0a114a52446e12781e2ffdf26f59df0d14e7809c7db5e551d3cf61c4e398751d +SRC_URI[md5sum] = 63e5e5c551e99dc5302b40b80bd6d4f2 +SRC_URI[sha256sum] = a58ff4fabb01a25043b142185a33eeea961109dd60d4b40b6a9df4fa3cace20b DEPENDS = popt libpam glib-2.0 xz-native docbook-utils-native linuxdoc-tools-native python -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V3 0/4] Fixes for systemd services in systemd
ping Any comment is welcome. If these patches look OK, I'll rebase them and send out a new version. Best Regards, Chen Qi On 09/28/2014 11:00 AM, Chen Qi wrote: Changes since V2: sysklogd: Unlink /dev/log only if it's not from systemd The following changes since commit f6a39cc957bf85ff43513f0b76afc3b2c9c906b6: sstatesig: fix overrides behaviour to remove SIGGEN_LOCKEDSIGS_i586 (2014-09-17 22:00:05 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib ChenQi/systemd-syslog-service http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=ChenQi/systemd-syslog-service Chen Qi (4): systemd: enable syslog.socket by default busybox: fix for syslog service in systemd sysklogd: add systemd support sysklog: comment out configuration regarding xconsole meta/recipes-core/busybox/busybox.inc | 9 +- .../busybox/files/busybox-klogd.service.in | 4 +- .../busybox/files/busybox-syslog.service.in| 7 +- meta/recipes-core/systemd/systemd_216.bb | 2 + .../files/0001-syslogd.c-add-systemd-support.patch | 246 + meta/recipes-extended/sysklogd/files/klogd.service | 9 + .../sysklogd/files/sysklogd.service| 14 ++ meta/recipes-extended/sysklogd/files/syslog.conf | 8 +- meta/recipes-extended/sysklogd/sysklogd.inc| 38 +++- 9 files changed, 317 insertions(+), 20 deletions(-) create mode 100644 meta/recipes-extended/sysklogd/files/0001-syslogd.c-add-systemd-support.patch create mode 100644 meta/recipes-extended/sysklogd/files/klogd.service create mode 100644 meta/recipes-extended/sysklogd/files/sysklogd.service -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [poky][PATCH v2 4/6] gstreamer1.0-plugins-base: Add video-frame related patch
Hi Otavio, Really sorry for the Upstream-Status format error, we just kept the same with some patches on fido branch, maybe they are old version. And I still have a little confusion about the third comment. My question are as followed. -Original Message- From: Otavio Salvador [mailto:otavio.salva...@ossystems.com.br] Sent: Tuesday, July 28, 2015 12:51 AM To: Zhu Yuqing-B54851 Cc: Patches and discussions about the oe-core layer Subject: Re: [OE-core] [poky][PATCH v2 4/6] gstreamer1.0-plugins-base: Add video-frame related patch On Mon, Jul 27, 2015 at 8:26 AM, Yuqing Zhu b54...@freescale.com wrote: -Add GST_VIDEO_FRAME_MAP_FLAG_NO_REF This makes sure that the buffer is not reffed another time when storing it in the GstVideoFrame, keeping it writable if it was writable. -Don't ref buffers twice when mapping Signed-off-by: Yuqing Zhu b54...@freescale.com Which recipe is applying this? It seems it is not being applied. --- ...rame-Don-t-ref-buffers-twice-when-mapping.patch | 25 +++ ...frame-Add-GST_VIDEO_FRAME_MAP_FLAG_NO_REF.patch | 87 ++ 2 files changed, 112 insertions(+) create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0001-video -frame-Don-t-ref-buffers-twice-when-mapping.patch create mode 100644 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0002-video -frame-Add-GST_VIDEO_FRAME_MAP_FLAG_NO_REF.patch diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0001-vid eo-frame-Don-t-ref-buffers-twice-when-mapping.patch b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0001-vid eo-frame-Don-t-ref-buffers-twice-when-mapping.patch new file mode 100644 index 000..c4eef00 --- /dev/null +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0001 +++ -video-frame-Don-t-ref-buffers-twice-when-mapping.patch @@ -0,0 +1,25 @@ +From 269f642c45d85cfd630ed490478e6bd6b71a767f Mon Sep 17 00:00:00 +2001 +From: =?UTF-8?q?Sebastian=20Dr=C3=B6ge?= sebast...@centricular.com +Date: Tue, 16 Sep 2014 01:07:18 +0300 +Subject: [PATCH] video-frame: Don't ref buffers twice when mapping Upstream-Status: ??? +--- + gst-libs/gst/video/video-frame.c |2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/gst-libs/gst/video/video-frame.c +b/gst-libs/gst/video/video-frame.c +index 01f23c0..8a9ae96 100644 +--- a/gst-libs/gst/video/video-frame.c b/gst-libs/gst/video/video-frame.c +@@ -105,7 +105,7 @@ gst_video_frame_map_id (GstVideoFrame * frame, GstVideoInfo * info, + frame-data[i] = frame-map[0].data + info-offset[i]; + } + } +- frame-buffer = gst_buffer_ref (buffer); ++ frame-buffer = buffer; + if ((flags GST_VIDEO_FRAME_MAP_FLAG_NO_REF) == 0) + gst_buffer_ref (frame-buffer); + +-- +1.7.9.5 + diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0002-vid eo-frame-Add-GST_VIDEO_FRAME_MAP_FLAG_NO_REF.patch b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0002-vid eo-frame-Add-GST_VIDEO_FRAME_MAP_FLAG_NO_REF.patch new file mode 100644 index 000..554b8ac --- /dev/null +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base/0002 +++ -video-frame-Add-GST_VIDEO_FRAME_MAP_FLAG_NO_REF.patch @@ -0,0 +1,87 @@ +From 40a293d44d1aeccf5eb8e86f23a0b13666111c5c Mon Sep 17 00:00:00 +2001 +From: =?UTF-8?q?Sebastian=20Dr=C3=B6ge?= sebast...@centricular.com +Date: Fri, 12 Sep 2014 14:39:16 +0300 +Subject: [PATCH 2/3] video-frame: Add GST_VIDEO_FRAME_MAP_FLAG_NO_REF + +This makes sure that the buffer is not reffed another time when +storing it in the GstVideoFrame, keeping it writable if it was +writable. + +Upstream Status: Accepted +https://bugzilla.gnome.org/show_bug.cgi?id=736118 The field is: Upstream-Status: Submitted [https://...] [Yuqing Zhu-b54851]: the Upstream-Status of this patch is Accepted, I am not very clear about your comments Submitted, do you mean I should add the web site in the same line with Upstream-Status? Just like this: Upstream-Status: Accepted [https://bugzilla.gnome.org/show_bug.cgi?id=736118] I've read the guide line, here is my understanding: Upstream-Status: Pending Upstream-Status: Submitted [where] Upstream-Status: Accepted Upstream-Status: Backport [from where] Upstream-Status: Denied Upstream-Status: Inappropriate [reason] Just obey this, right? So that is Upstream-Status: Accepted That's it ? +--- + gst-libs/gst/video/video-frame.c |9 - + gst-libs/gst/video/video-frame.h | 18 ++ + 2 files changed, 26 insertions(+), 1 deletion(-) + +diff --git a/gst-libs/gst/video/video-frame.c +b/gst-libs/gst/video/video-frame.c +index 537cf70..01f23c0 100644 +--- a/gst-libs/gst/video/video-frame.c b/gst-libs/gst/video/video-frame.c +@@ -106,6 +106,9 @@ gst_video_frame_map_id (GstVideoFrame * frame, GstVideoInfo * info, + } + } + frame-buffer =
[OE-core] [PATCH] libhugetlbfs: Uprev to v2.19 from v2.18
From: Jianchuan Wang jianchuan.w...@windriver.com The 5 patches which are deleted have been in the v2.19 Signed-off-by: Jianchuan Wang jianchuan.w...@windriver.com --- ...tend-arm32-support-to-include-BE-variants.patch | 38 --- .../0001-Makefile-Recognize-all-ix86-arches.patch | 32 .../files/0001-aarch64-fix-cross-compilation.patch | 34 - ...s-arm-arches-fix-page-size-and-text-offse.patch | 57 -- ...-lib64-hardcoded-values-by-LIBDIR32-LIBDI.patch | 29 --- .../libhugetlbfs/libhugetlbfs_git.bb | 9 +--- 6 files changed, 2 insertions(+), 197 deletions(-) delete mode 100644 meta-oe/recipes-benchmark/libhugetlbfs/files/0001-Extend-arm32-support-to-include-BE-variants.patch delete mode 100644 meta-oe/recipes-benchmark/libhugetlbfs/files/0001-Makefile-Recognize-all-ix86-arches.patch delete mode 100644 meta-oe/recipes-benchmark/libhugetlbfs/files/0001-aarch64-fix-cross-compilation.patch delete mode 100644 meta-oe/recipes-benchmark/libhugetlbfs/files/0001-ld.hugetlbfs-arm-arches-fix-page-size-and-text-offse.patch delete mode 100644 meta-oe/recipes-benchmark/libhugetlbfs/files/0001-replace-lib-lib64-hardcoded-values-by-LIBDIR32-LIBDI.patch diff --git a/meta-oe/recipes-benchmark/libhugetlbfs/files/0001-Extend-arm32-support-to-include-BE-variants.patch b/meta-oe/recipes-benchmark/libhugetlbfs/files/0001-Extend-arm32-support-to-include-BE-variants.patch deleted file mode 100644 index f6147cb..000 --- a/meta-oe/recipes-benchmark/libhugetlbfs/files/0001-Extend-arm32-support-to-include-BE-variants.patch +++ /dev/null @@ -1,38 +0,0 @@ -From 5af6dec8764375ca4f13bd9fed96af090228351a Mon Sep 17 00:00:00 2001 -From: Gary S. Robertson gary.robert...@linaro.org -Date: Mon, 11 Aug 2014 11:06:04 -0500 -Subject: [libhugetlbfs][PATCH] Extend arm32 support to include BE variants - -This patch applies the same technique used by Koen Kool in the following patch -which was accepted by the libhugetlbfs project: - -[0a4f6] Add aarch64_be_support 2014-03-31 10:52:37 - -It modifies the libhugetlbfs Makefile to mark all 32-bit arm architectures -as supported by the libhugetlbfs build. Builds and successful functional -tests have been performed for armv7a LE and BE runtime platforms. - -This patch replaces and renders obsolete the following patch: -arm32-support.patch submitted by: Chunrong Guo b40...@freescale.com - -Signed-off-by: Gary S. Robertson gary.robert...@linaro.org - Makefile |2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -diff --git a/Makefile b/Makefile -index 91502e1..ba79607 100644 a/Makefile -+++ b/Makefile -@@ -59,7 +59,7 @@ ELF32 = elf32ppclinux - TMPLIB32 = lib - CPPFLAGS += -DPPC_NO_SEGMENTS - else --ifeq ($(ARCH),armv7l) -+ifneq (,$(findstring arm,$(ARCH))) - CC32 = $(CC) - TMPLIB32 = lib - ELF32 += armelf_linux_eabi --- -1.7.9.5 - diff --git a/meta-oe/recipes-benchmark/libhugetlbfs/files/0001-Makefile-Recognize-all-ix86-arches.patch b/meta-oe/recipes-benchmark/libhugetlbfs/files/0001-Makefile-Recognize-all-ix86-arches.patch deleted file mode 100644 index 2718275..000 --- a/meta-oe/recipes-benchmark/libhugetlbfs/files/0001-Makefile-Recognize-all-ix86-arches.patch +++ /dev/null @@ -1,32 +0,0 @@ -From a0166583ba5f7b6a6d2de434f633126fb12c9d29 Mon Sep 17 00:00:00 2001 -From: Gary S. Robertson gary.robert...@linaro.org -Date: Wed, 24 Sep 2014 15:27:31 -0500 -Subject: [PATCH] Makefile: Recognize all ix86 arches - -In a non-native build scenario, the makefile -only recognized i386 or x86_64 arches. Added support -to recognize i486, i586, i686. - -Upstream Status: Accepted by libhugetlbfs project - -Signed-off-by: Gary S. Robertson gary.robert...@linaro.org - Makefile |2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -diff --git a/Makefile b/Makefile -index 91502e1..0bfaee8 100644 a/Makefile -+++ b/Makefile -@@ -71,7 +71,7 @@ ELF64 = aarch64elf - TMPLIB64 = lib64 - CUSTOM_LDSCRIPTS = no - else --ifeq ($(ARCH),i386) -+ifneq (,$(filter i386 i486 i586 i686,$(ARCH))) - CC32 = $(CC) - ELF32 = elf_i386 - TMPLIB32 = lib --- -1.7.9.5 - diff --git a/meta-oe/recipes-benchmark/libhugetlbfs/files/0001-aarch64-fix-cross-compilation.patch b/meta-oe/recipes-benchmark/libhugetlbfs/files/0001-aarch64-fix-cross-compilation.patch deleted file mode 100644 index 215ae72..000 --- a/meta-oe/recipes-benchmark/libhugetlbfs/files/0001-aarch64-fix-cross-compilation.patch +++ /dev/null @@ -1,34 +0,0 @@ -Subject: [PATCH] aarch64: fix cross compilation - -This patch allow to override CC and use it for aarch64 case like -the other architectures. - -Signed-off-by: Fathi Boudra fathi.bou...@linaro.org - -Upstream-Status: Submitted - Makefile | 4 ++-- - 1 file changed, 2 insertions(+), 2 deletions(-) - -diff --git a/Makefile b/Makefile -index 91502e1..5aa1e12 100644 a/Makefile -+++ b/Makefile -@@ -33,7 +33,7 @@ CFLAGS += -Wall -fPIC - CPPFLAGS += -D__LIBHUGETLBFS__ -
Re: [OE-core] [PATCH 0/2] insane.bbclass: fix package_qa_check_buildpaths
ping. // Robert On 07/15/2015 05:16 PM, Robert Yang wrote: The following changes since commit 6be698b7270f73f40d38713ecf13f12aec0ced61: dpkg: Fix for Fedora22 and new versions of tar (2015-07-13 13:46:45 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rbt/buildpath http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/buildpath Robert Yang (2): insane.bbclass: fix package_qa_check_buildpaths insane.bbclass: make package_qa_clean_path return a relative path meta/classes/insane.bbclass | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] rootfs.py: fix PRE/POSTPROCESS_COMMANDS for rpm and deb
The following changes since commit 27d068d05239c26a3848eb101571acab54635e37: harfbuzz: upgrade to 1.0.1 (2015-07-27 23:28:23 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rbt/post http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/PU Robert Yang (1): rootfs.py: fix PRE/POSTPROCESS_COMMANDS for rpm and deb meta/lib/oe/rootfs.py | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] rootfs.py: fix PRE/POSTPROCESS_COMMANDS for rpm and deb
The rpm didn't run RPM_PREPROCESS_COMMANDS or RPM_POSTPROCESS_COMMANDS, the similar to deb, this patch fix the problem. And fix a typo: DEB_POSTPROCESS_COMMAND - DEB_POSTPROCESS_COMMANDS Signed-off-by: Robert Yang liezhi.y...@windriver.com --- meta/lib/oe/rootfs.py | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py index 0bd1cf6..8c8244c 100644 --- a/meta/lib/oe/rootfs.py +++ b/meta/lib/oe/rootfs.py @@ -408,10 +408,14 @@ class RpmRootfs(Rootfs): def _create(self): pkgs_to_install = self.manifest.parse_initial_manifest() +rpm_pre_process_cmds = self.d.getVar('RPM_PREPROCESS_COMMANDS', True) +rpm_post_process_cmds = self.d.getVar('RPM_POSTPROCESS_COMMANDS', True) # update PM index files self.pm.write_index() +execute_pre_post_process(self.d, rpm_pre_process_cmds) + self.pm.dump_all_available_pkgs() if self.inc_rpm_image_gen == 1: @@ -435,6 +439,10 @@ class RpmRootfs(Rootfs): self._setup_dbg_rootfs(['/etc/rpm', '/var/lib/rpm', '/var/lib/smart']) +execute_pre_post_process(self.d, rpm_post_process_cmds) + +self._log_check() + if self.inc_rpm_image_gen == 1: self.pm.backup_packaging_data() @@ -615,6 +623,8 @@ class DpkgRootfs(DpkgOpkgRootfs): def _create(self): pkgs_to_install = self.manifest.parse_initial_manifest() +deb_pre_process_cmds = self.d.getVar('DEB_PREPROCESS_COMMANDS', True) +deb_post_process_cmds = self.d.getVar('DEB_POSTPROCESS_COMMANDS', True) alt_dir = self.d.expand(${IMAGE_ROOTFS}/var/lib/dpkg/alternatives) bb.utils.mkdirhier(alt_dir) @@ -622,6 +632,8 @@ class DpkgRootfs(DpkgOpkgRootfs): # update PM index files self.pm.write_index() +execute_pre_post_process(self.d, deb_pre_process_cmds) + self.pm.update() for pkg_type in self.install_order: @@ -639,9 +651,11 @@ class DpkgRootfs(DpkgOpkgRootfs): self.pm.run_pre_post_installs() +execute_pre_post_process(self.d, deb_post_process_cmds) + @staticmethod def _depends_list(): -return ['DEPLOY_DIR_DEB', 'DEB_SDK_ARCH', 'APTCONF_TARGET', 'APT_ARGS', 'DPKG_ARCH', 'DEB_PREPROCESS_COMMANDS', 'DEB_POSTPROCESS_COMMAND'] +return ['DEPLOY_DIR_DEB', 'DEB_SDK_ARCH', 'APTCONF_TARGET', 'APT_ARGS', 'DPKG_ARCH', 'DEB_PREPROCESS_COMMANDS', 'DEB_POSTPROCESS_COMMANDS'] def _get_delayed_postinsts(self): status_file = self.image_rootfs + /var/lib/dpkg/status -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2 0/2] Yocto Bug #6945
Ping. On 07/27/2015 10:51 AM, He Zhe wrote: Ping. On 07/23/2015 03:48 PM, He Zhe wrote: Ping. On 07/21/2015 03:23 PM, zhe...@windriver.com wrote: From: He Zhe zhe...@windriver.com - To support building packaging and installing multi types of kernel images, such as zImage uImage, at one time define KERNEL_IMAGETYPE as a list. - Modify wherever reference KERNEL_IMAGETYPE accordingly. - Pass mkimage in sysroot to kernel makefile by NATIVE_MKIMAGE to avoid depending on build machine's, when KEEPUIMAGE is yes. - v2: update with the latest oe-core He Zhe (2): kernel: Define KERNEL_IMAGETYPE as a list kernel: Pass sysroot mkimage to kernel makefile meta/classes/image_types.bbclass | 6 +- meta/classes/kernel-fitimage.bbclass | 22 +++--- meta/classes/kernel-grub.bbclass | 47 meta/classes/kernel-uimage.bbclass | 31 +--- meta/classes/kernel.bbclass | 127 ++- meta/conf/documentation.conf | 2 +- meta/lib/oeqa/controllers/masterimage.py | 2 +- meta/lib/oeqa/targetcontrol.py | 2 +- meta/recipes-kernel/linux/linux-dtb.inc | 15 ++-- scripts/test-remote-image| 2 +- 10 files changed, 175 insertions(+), 81 deletions(-) -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/5] file: 5.23 - 5.24
On 07/21/2015 07:05 PM, Burton, Ross wrote: On 17 July 2015 at 03:31, Robert Yang liezhi.y...@windriver.com mailto:liezhi.y...@windriver.com wrote: * Use git repo rather than tarball, rename file_5.23.bb http://file_5.23.bb - file_git.bb http://file_git.bb Why? Hi Ross, The old SRC_URI ftp://ftp.astron.com/pub/file/ is down again atm, it is not stable as you met the same problems several days ago, I think that use git hub's repo is better. I will add more comments and resend the patch. // Robert Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH v3 2/3] systemd.bbclass: Use systemd_system_unitdir
Hi Khem, This series of patches have as an objective to improve systemd support in OE, specifically improve support for user services. If you want more information, you can follow the discussion from last patch version I sent and also the yocto bug report: https://bugzilla.yoctoproject.org/show_bug.cgi?id=7801 http://patches.openembedded.org/patch/97291/ Pau Espin Pedrol mail/jabber: pespin.s...@gmail.com http://blog.espeweb.net 2015-07-25 3:26 GMT+02:00 Khem Raj raj.k...@gmail.com: On Fri, Jul 24, 2015 at 7:02 AM, Pau Espin Pedrol pau.es...@aweurope.be wrote: Signed-off-by: Pau Espin Pedrol pau.es...@aweurope.be --- meta/classes/systemd.bbclass | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/meta/classes/systemd.bbclass b/meta/classes/systemd.bbclass index cfe1eb5..46e72c7 100644 --- a/meta/classes/systemd.bbclass +++ b/meta/classes/systemd.bbclass @@ -136,8 +136,7 @@ python systemd_populate_packages() { # Check service-files and call systemd_add_files_and_parse for each entry def systemd_check_services(): searchpaths = [oe.path.join(d.getVar(sysconfdir, True), systemd, system),] -searchpaths.append(oe.path.join(d.getVar(nonarch_base_libdir, True), systemd, system)) -searchpaths.append(oe.path.join(d.getVar(exec_prefix, True), d.getVar(nonarch_base_libdir, True), systemd, system)) +searchpaths.append(d.getVar(systemd_system_unitdir, True)) systemd_packages = d.getVar('SYSTEMD_PACKAGES', True) keys = 'Also' @@ -185,10 +184,10 @@ python rm_sysvinit_initddir (){ if bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d) and \ not bb.utils.contains('DISTRO_FEATURES', 'sysvinit', True, False, d) and \ os.path.exists(sysv_initddir): -systemd_unitdir = oe.path.join(d.getVar(D, True), d.getVar('systemd_unitdir', True), system) +systemd_system_unitdir = oe.path.join(d.getVar(D, True), d.getVar('systemd_system_unitdir', True)) -# If systemd_unitdir contains anything, delete sysv_initddir -if (os.path.exists(systemd_unitdir) and os.listdir(systemd_unitdir)): +# If systemd_system_unitdir contains anything, delete sysv_initddir +if (os.path.exists(systemd_system_unitdir) and os.listdir(systemd_system_unitdir)): shutil.rmtree(sysv_initddir) } do_install[postfuncs] += rm_sysvinit_initddir what does this patch solve ? -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH v3 2/3] systemd.bbclass: Use systemd_system_unitdir
OK Tanu, I will try to do some tests and prepare new patches during the following days. Thanks for reviewing, Pau Espin Pedrol mail/jabber: pespin.s...@gmail.com http://blog.espeweb.net 2015-07-25 9:29 GMT+02:00 Tanu Kaskinen tanu.kaski...@linux.intel.com: On Fri, 2015-07-24 at 17:10 +0200, Pau Espin Pedrol wrote: Hi, actually this breaks build of systemd.bb itself, because it installs its system recipes using paths from Makefile.am: userunitdir=$(prefix)/lib/systemd/user systemunitdir=$(rootprefix)/lib/systemd/system And in the recipe for systemd_219.bb we have: # Helper variables to clarify locations. This mirrors the logic in systemd's # build system. rootprefix ?= ${base_prefix} rootlibdir ?= ${base_libdir} rootlibexecdir = ${rootprefix}/lib So, that means it installs its own services into /lib, not /usr/lib. The changes done in systemd.bbclass in this patch remove the search path of /lib, allowing only ${system_system_unitdir} which is /usr/lib/systemd/system. I tried changing rootprefix to use ${prefix} but then I get other problems: ERROR: QA Issue: systemd: Files/directories were installed but not shipped /usr/bin/udevadm /usr/bin/journalctl /usr/bin/loginctl /usr/bin/machinectl /usr/bin/systemctl /usr/lib/udev/.debug /usr/lib/udev/.debug/cdrom_id /usr/lib/udev/.debug/collect /usr/lib/udev/.debug/ata_id /usr/lib/udev/.debug/v4l_id /usr/lib/udev/.debug/mtd_probe /usr/lib/udev/.debug/scsi_id /usr/lib/udev/.debug/accelerometer /usr/lib/udev/rules.d/70-uaccess.rules /usr/lib/udev/rules.d/73-seat-late.rules /usr/lib/udev/rules.d/71-seat.rules /usr/lib/udev/rules.d/99-systemd.rules Which at the end makes me think... is it really a good idea to set systemd_unitdir and system_system_unitdir to use ${nonarch_libdir}? I think we should be better using ${nonarch_base_libdir} for those, as systemd guys themselves make distinction between both (prefix vs rootprefix). I agree. ${nonarch_base_libdir} seems to be definitely the right place to put system service files. This may change if some day nobody will have a separate /usr partition any more (which is what the systemd developers are pushing for, AFAIK), but as long as we have to deal with systems with a separate /usr partition, I think using /lib is the only safe choice. -- Tanu -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] gcc 5.2 failures
I've run a gcc 5.2 test build on the autobuilder: http://errors.yoctoproject.org/Errors/Search/?items=10query=3628c3c06fa4195003ac655bcc791acfac775173limit=50 41 errors (with a few more pending). The good news is that if we tweak the security flags, the poky-lsb gcc, elfutils, coreutils and iptables issues can be removed and I have a patch for this. This leaves: 3.14 kernel failures for edgerouter, genericx86-64, qemuarm, beaglebone, mpc8315e-rdb openssl issue for p1022ds u-boot on imx28evk, p1022ds, mpc8315e-rdb xf86-video-imxfb-vivante on imx6qsabresd linux-imx issue on imx53qsb Some kind of random qemu runtime issue (4 cases). At this point I think we likely need to enter bugs into the bugzilla for each of these. If we want to switch 1.9 to use this (which I think is desirable), we need to get this fixed as a priority. Bruce: How do you want to handle the 3.14 issues? Switch to 4.1? or fix 3.14? Otavio: The freescale machines are looking unwell, can you help us make sure the right people know about this? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core