Re: [OE-core] gcc 5.2 failures

2015-07-27 Thread Bruce Ashfield

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

2015-07-27 Thread Yi Qingliang
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

2015-07-27 Thread Richard Purdie
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

2015-07-27 Thread Richard Purdie
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

2015-07-27 Thread Richard Purdie
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

2015-07-27 Thread Pascal Bach
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

2015-07-27 Thread Paul Eggleton
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

2015-07-27 Thread Paul Eggleton
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

2015-07-27 Thread Paul Eggleton
* 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

2015-07-27 Thread Richard Purdie
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

2015-07-27 Thread Mike Looijmans
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

2015-07-27 Thread Paul Eggleton
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

2015-07-27 Thread Paul Eggleton
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

2015-07-27 Thread Paul Eggleton
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

2015-07-27 Thread Paul Eggleton
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

2015-07-27 Thread Paul Eggleton
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

2015-07-27 Thread Paul Eggleton
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

2015-07-27 Thread Paul Eggleton
* 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

2015-07-27 Thread Paul Eggleton
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

2015-07-27 Thread Paul Eggleton
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

2015-07-27 Thread Paul Eggleton
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

2015-07-27 Thread Bruce Ashfield

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

2015-07-27 Thread Ahsan, Noor
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

2015-07-27 Thread Bruce Ashfield

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

2015-07-27 Thread Bruce Ashfield

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

2015-07-27 Thread Richard Purdie
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

2015-07-27 Thread Ed Bartosh
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

2015-07-27 Thread Richard Purdie
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

2015-07-27 Thread Costin Constantin
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

2015-07-27 Thread Martin Jansa
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'

2015-07-27 Thread Martin Jansa
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

2015-07-27 Thread Cristian Iorga
- 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

2015-07-27 Thread Dominic Sacré
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

2015-07-27 Thread Burton, Ross
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

2015-07-27 Thread Otavio Salvador
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

2015-07-27 Thread Hugo Vasconcelos Saldanha
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

2015-07-27 Thread Burton, Ross
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

2015-07-27 Thread Otavio Salvador
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

2015-07-27 Thread Otavio Salvador
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

2015-07-27 Thread Otavio Salvador
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

2015-07-27 Thread Otavio Salvador
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

2015-07-27 Thread Otavio Salvador
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

2015-07-27 Thread Otavio Salvador
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

2015-07-27 Thread Christopher Larson
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

2015-07-27 Thread Tobias Olausson
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

2015-07-27 Thread Burton, Ross
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

2015-07-27 Thread Hugo Vasconcelos Saldanha
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

2015-07-27 Thread Otavio Salvador
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'

2015-07-27 Thread Richard Purdie
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

2015-07-27 Thread rongqing.li
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

2015-07-27 Thread Robert Yang
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

2015-07-27 Thread Robert Yang
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

2015-07-27 Thread Robert Yang
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

2015-07-27 Thread Robert Yang
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

2015-07-27 Thread Robert Yang
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

2015-07-27 Thread Robert Yang
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

2015-07-27 Thread Robert Yang
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

2015-07-27 Thread Robert Yang
* 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

2015-07-27 Thread Robert Yang
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

2015-07-27 Thread Robert Yang
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

2015-07-27 Thread ChenQi

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

2015-07-27 Thread Zhu Carol
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

2015-07-27 Thread jianchuan.wang
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

2015-07-27 Thread Robert Yang

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

2015-07-27 Thread Robert Yang
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

2015-07-27 Thread Robert Yang
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

2015-07-27 Thread He Zhe
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

2015-07-27 Thread Robert Yang



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

2015-07-27 Thread Pau Espin Pedrol
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

2015-07-27 Thread Pau Espin Pedrol
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

2015-07-27 Thread Richard Purdie
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