Re: [OE-core] [oe] "sub" machine types?

[Steffen Sledz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 04.09.2015 um 09:45 schrieb Nicolas Dechesne:
> On Fri, Sep 4, 2015 at 9:35 AM, Steffen Sledz  wrote:
>> We have some products which differ in bootloaders (u-boot) and kernel device 
>> trees only. They use the same kernel and root filesystem.
>> 
>> Does OE have concepts for this? Or any suggestions to realize this without 
>> building for many machines?
> 
> most BSP layers use SOC_FAMILY, see [1] for this type of things, such that 
> you can create 'SOC' specific packages that are reused across multiple (OE) 
> machines. That sounds like that would help in your situation.
> 
> [1] 
> http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#var-SOC_FAMILY

I'm not really sure if this is what we need. You suggest to use different 
MACHINEs of one SOC_FAMILY, Right?

But if I bitbake the root filesystem for each MACHINE an *own* image is 
created. And not *one* usable for all of them.

What we wish is one image containing one kernel and device tree files for each 
product.

In addition a u-boot image for each product so that we can use a boot setup 
running different u-boot images starting the same kernel and root filesystem 
with different parameters (e.g. for the device trees).

- -- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJV6o9aAAoJEIz5slJ1krPhF9UP/0cp0JrohbZOeRen1ksJfGIr
J3kGKKEqBlw4s+0ugsPIMSp3pR2La/7/IgGV938H5mc6+88CobTpQU25TaE31ukq
hgfoG/SHuZCucp1TpTahANkt+d8OmrDOTDLYTzEmWD47VGRp64PiMzlQBKIg27Bo
NUdG3cFoUzPrS6tu24LR/EiM+ve2+ItZ8/pEXY0RiCYD/vhehP8qq2Yunow5cvyj
xvy1kxbJYCYvjXQF52z9L+R68vvZVzXFF7VrTeT00DJlj99KP5R97vvbIyHzFsHK
1YJfmRkkSx5d41QGegM9GHJGaGOKxHQekh/V5PgwfgQKBxgXq/5slWAvIzH7l6Fq
udkqX9goeeEmkztiUhK1VbEQr8wd5SyRI/9wfEJD8AuJPiV460JZrC2lhh/dOxnf
sEOGzgNMe/lddcGty6ns5Jn9ztJhnaYNtYK1NFdY/aGUPASgcXCCcPxUNW00KEsp
yCwmVEUE37vIGJltqJ2XfUCPhIZ4eiuPZOkzYHo4s+CtArKHiWlzWWREXSrNREql
92FDTuOCkBuYDrmiRMbIuHRxO7gguE2ZS8YPCSRbGsE/VwwUhlMAtRddnGr5QA1G
FL1qnW+28wrqwHZlVfzFzO+qUnAo7/LqfnF525ABObdlF6sk4/b9r2MeTEoPwLkx
qd2HFZDh4HBu2h4t6E1s
=m/r6
-END PGP SIGNATURE-
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] busybox: more nails in the coffin

[Richard Purdie]

On Fri, 2015-09-04 at 19:18 -0700, Joe Slater wrote:
> Create packagegroup-busybox and modify packagegroup-core-boot
> to conditionally use it.

This says what it goes but not why. I'm also less than keen on the
subject line :/.

> Signed-off-by: Joe Slater 
> ---
>  .../packagegroups/packagegroup-busybox.bb  |   23 
> 
>  .../packagegroups/packagegroup-core-boot.bb|   17 ---
>  2 files changed, 32 insertions(+), 8 deletions(-)
>  create mode 100644 meta/recipes-core/packagegroups/packagegroup-busybox.bb
> 
> diff --git a/meta/recipes-core/packagegroups/packagegroup-busybox.bb 
> b/meta/recipes-core/packagegroups/packagegroup-busybox.bb
> new file mode 100644
> index 000..acf0791
> --- /dev/null
> +++ b/meta/recipes-core/packagegroups/packagegroup-busybox.bb
> @@ -0,0 +1,23 @@
> +#
> +# Copyright (C) 2015 Wind River Inc.
> +#
> +
> +SUMMARY = "Busybox related information"
> +DESCRIPTION = "Busybox packages and variables"
> +LICENSE = "MIT"
> +
> +PACKAGE_ARCH = "${MACHINE_ARCH}"
> +
> +inherit packagegroup
> +
> +# Do not ever, ever override LOCAL variables.
> +#

Why?

> +LOCAL_sysvinit = " \
> +   ${@bb.utils.contains('MACHINE_FEATURES', 'rtc', 
> 'busybox-hwclock', '', d)} \
> +   "
> +
> +RDEPENDS_${PN} = "\
> +busybox \
> +${@bb.utils.contains("DISTRO_FEATURES", "sysvinit", "${LOCAL_sysvinit}", 
> "", d)} \
> +"
> +
> diff --git a/meta/recipes-core/packagegroups/packagegroup-core-boot.bb 
> b/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
> index 09f5373..b2d0775 100644
> --- a/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
> +++ b/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
> @@ -17,14 +17,17 @@ inherit packagegroup
>  MACHINE_ESSENTIAL_EXTRA_RDEPENDS ?= ""
>  MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS ?= ""
>  
> -# Distro can override the following VIRTUAL-RUNTIME providers:
> +# These can be overridden in any .conf file.
> +#
>  VIRTUAL-RUNTIME_dev_manager ?= "udev"
> -VIRTUAL-RUNTIME_login_manager ?= "busybox"
> -VIRTUAL-RUNTIME_init_manager ?= "sysvinit"
>  VIRTUAL-RUNTIME_initscripts ?= "initscripts"
>  VIRTUAL-RUNTIME_keymaps ?= "keymaps"
> +VIRTUAL-RUNTIME_busybox ?= "packagegroup-busybox"

What about anyone who actually use these existing VIRTUAL-RUNTIME
variables?

Cheers,

Richard


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] busybox: Use UTMPX instead of legacy UTMP

[Richard Purdie]

On Thu, 2015-09-03 at 16:54 +, Khem Raj wrote:
> This makes busybox honor UTMPX feature if available in a libc
> 
> [YOCTO #8243]
> 
> Signed-off-by: Khem Raj 
> ---
>  .../busybox/0001-Switch-to-POSIX-utmpx-API.patch   | 388 
> +
>  meta/recipes-core/busybox/busybox_1.23.2.bb|   1 +
>  2 files changed, 389 insertions(+)
>  create mode 100644 
> meta/recipes-core/busybox/busybox/0001-Switch-to-POSIX-utmpx-API.patch

This breaks poky-tiny.

https://autobuilder.yoctoproject.org/main/builders/poky-tiny/builds/490/steps/BuildImages/logs/stdio

Cheers,

Richard

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] testimage: handle SIGTERM to conclude runqemu

[mariano . lopez]

From: Mariano Lopez 

In the current state if a SIGTERM is sent to
the testimage worker, the worker will exit but
runqemu and qemu won't exit and the processes
need to be killed manually to free the
bitbake lock.

This allows to catch the SIGTERM signal in
testimage, this way it is possible to stop
runqemu and qemu and allow to free the bitbake lock.

Also this allows to skip the rest of the tests
when running the tests in qemu or real hardware.

This also solves minimal breaks when handling the
SIGCHLD in qemurunner and when checking if qemu
is alive in the test setup.

[YOCTO #8239]

Signed-off-by: Benjamin Esquivel 
Signed-off-by: Mariano Lopez 
---
 meta/classes/testimage.bbclass| 12 +++-
 meta/lib/oeqa/oetest.py   |  6 +-
 meta/lib/oeqa/utils/qemurunner.py |  3 +--
 3 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index 7c783ea..19a37cb 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -236,6 +236,7 @@ def testimage_main(d):
 import os
 import oeqa.runtime
 import time
+import signal
 from oeqa.oetest import loadTests, runTests
 from oeqa.targetcontrol import get_target_controller
 from oeqa.utils.dump import get_host_dumper
@@ -273,12 +274,20 @@ def testimage_main(d):
 self.imagefeatures = d.getVar("IMAGE_FEATURES", True).split()
 self.distrofeatures = d.getVar("DISTRO_FEATURES", True).split()
 manifest = os.path.join(d.getVar("DEPLOY_DIR_IMAGE", True), 
d.getVar("IMAGE_LINK_NAME", True) + ".manifest")
+self.sigterm = False
+self.origsigtermhandler = signal.getsignal(signal.SIGTERM)
+signal.signal(signal.SIGTERM, self.sigterm_exception)
 try:
 with open(manifest) as f:
 self.pkgmanifest = f.read()
 except IOError as e:
 bb.fatal("No package manifest file found. Did you build the 
image?\n%s" % e)
 
+def sigterm_exception(self, signum, stackframe):
+bb.warn("TestImage received SIGTERM, shutting down...")
+self.sigterm = True
+self.target.stop()
+
 # test context
 tc = TestContext()
 
@@ -293,8 +302,8 @@ def testimage_main(d):
 
 target.deploy()
 
-target.start()
 try:
+target.start()
 if export:
 exportTests(d,tc)
 else:
@@ -311,6 +320,7 @@ def testimage_main(d):
 else:
 raise bb.build.FuncFailed("%s - FAILED - check the task log 
and the ssh log" % pn )
 finally:
+signal.signal(signal.SIGTERM, tc.origsigtermhandler)
 target.stop()
 
 testimage_main[vardepsexclude] =+ "BB_ORIGENV"
diff --git a/meta/lib/oeqa/oetest.py b/meta/lib/oeqa/oetest.py
index ff62c30..0fe68d4 100644
--- a/meta/lib/oeqa/oetest.py
+++ b/meta/lib/oeqa/oetest.py
@@ -145,7 +145,11 @@ class oeRuntimeTest(oeTest):
 super(oeRuntimeTest, self).__init__(methodName)
 
 def setUp(self):
-self.assertTrue(self.target.check(), msg = "Qemu not running?")
+# Check if test needs to run
+if self.tc.sigterm:
+self.fail("Got SIGTERM")
+elif (type(self.target).__name__ == "QemuTarget"):
+self.assertTrue(self.target.check(), msg = "Qemu not running?")
 
 def tearDown(self):
 # If a test fails or there is an exception
diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index c04ee0d..4b29284 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -232,7 +232,7 @@ class QemuRunner:
 return self.is_alive()
 
 def stop(self):
-
+signal.signal(signal.SIGCHLD, self.origchldhandler)
 self.stop_thread()
 if self.runqemu:
 logger.info("Sending SIGTERM to runqemu")
@@ -253,7 +253,6 @@ class QemuRunner:
 self.server_socket = None
 self.qemupid = None
 self.ip = None
-signal.signal(signal.SIGCHLD, self.origchldhandler)
 
 def stop_thread(self):
 if self.thread and self.thread.is_alive():
-- 
1.8.4.5

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core][PATCH 1/1] busybox: more nails in the coffin

[Joe Slater]

Create packagegroup-busybox and modify packagegroup-core-boot
to conditionally use it.

Signed-off-by: Joe Slater 
---
 .../packagegroups/packagegroup-busybox.bb  |   23 
 .../packagegroups/packagegroup-core-boot.bb|   17 ---
 2 files changed, 32 insertions(+), 8 deletions(-)
 create mode 100644 meta/recipes-core/packagegroups/packagegroup-busybox.bb

diff --git a/meta/recipes-core/packagegroups/packagegroup-busybox.bb 
b/meta/recipes-core/packagegroups/packagegroup-busybox.bb
new file mode 100644
index 000..acf0791
--- /dev/null
+++ b/meta/recipes-core/packagegroups/packagegroup-busybox.bb
@@ -0,0 +1,23 @@
+#
+# Copyright (C) 2015 Wind River Inc.
+#
+
+SUMMARY = "Busybox related information"
+DESCRIPTION = "Busybox packages and variables"
+LICENSE = "MIT"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+inherit packagegroup
+
+# Do not ever, ever override LOCAL variables.
+#
+LOCAL_sysvinit = " \
+   ${@bb.utils.contains('MACHINE_FEATURES', 'rtc', 
'busybox-hwclock', '', d)} \
+   "
+
+RDEPENDS_${PN} = "\
+busybox \
+${@bb.utils.contains("DISTRO_FEATURES", "sysvinit", "${LOCAL_sysvinit}", 
"", d)} \
+"
+
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-boot.bb 
b/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
index 09f5373..b2d0775 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
@@ -17,14 +17,17 @@ inherit packagegroup
 MACHINE_ESSENTIAL_EXTRA_RDEPENDS ?= ""
 MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS ?= ""
 
-# Distro can override the following VIRTUAL-RUNTIME providers:
+# These can be overridden in any .conf file.
+#
 VIRTUAL-RUNTIME_dev_manager ?= "udev"
-VIRTUAL-RUNTIME_login_manager ?= "busybox"
-VIRTUAL-RUNTIME_init_manager ?= "sysvinit"
 VIRTUAL-RUNTIME_initscripts ?= "initscripts"
 VIRTUAL-RUNTIME_keymaps ?= "keymaps"
+VIRTUAL-RUNTIME_busybox ?= "packagegroup-busybox"
 
-SYSVINIT_SCRIPTS = "${@bb.utils.contains('MACHINE_FEATURES', 'rtc', 
'busybox-hwclock', '', d)} \
+# Do not ever, ever override LOCAL variables.
+#
+LOCAL_sysvinit = " \
+sysvinit \
 modutils-initscripts \
 init-ifupdown \
 ${VIRTUAL-RUNTIME_initscripts} \
@@ -33,12 +36,10 @@ SYSVINIT_SCRIPTS = 
"${@bb.utils.contains('MACHINE_FEATURES', 'rtc', 'busybox-hwc
 RDEPENDS_${PN} = "\
 base-files \
 base-passwd \
-busybox \
-${@bb.utils.contains("DISTRO_FEATURES", "sysvinit", "${SYSVINIT_SCRIPTS}", 
"", d)} \
+${@bb.utils.contains("DISTRO_FEATURES", "sysvinit", "${LOCAL_sysvinit}", 
"", d)} \
 ${@bb.utils.contains("MACHINE_FEATURES", "keyboard", 
"${VIRTUAL-RUNTIME_keymaps}", "", d)} \
 netbase \
-${VIRTUAL-RUNTIME_login_manager} \
-${VIRTUAL-RUNTIME_init_manager} \
+${VIRTUAL-RUNTIME_busybox} \
 ${VIRTUAL-RUNTIME_dev_manager} \
 ${VIRTUAL-RUNTIME_update-alternatives} \
 ${MACHINE_ESSENTIAL_EXTRA_RDEPENDS}"
-- 
1.7.9.5

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Fido and dizzy collaboration?

[akuster808]

On 09/01/2015 01:39 PM, Richard Purdie wrote:
> Hi Armin, Joshua,
> 
> I've just been looking at the patches queued for the dizzy/fido
> branches. In fact I ended up merging them before I realised there are
> some issues.
> 
> The problem is there are dizzy patches which aren't in fido, which
> breaks our policies. 

I thought the changes had to be in Master first. Are you saying I need
to wait for them to be in fido first?

Could the two of you work to resolve that and give
> me fido branch to pull which resolved it please?

Will do.

- armin
> 
> I didn't take the dizzy patch related to S = ${WORKDIR} since that
> looked more like a change appropriate to master only. The bitbake
> patches also need handling on the bitbake list if we really do want to
> backport them to 1.26 and 1.24.
> 
> Cheers,
> 
> Richard
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][master/fido/dizzy] oprofileui: Use inherit gettext

[akuster808]

Queuing up,

Thanks,
Armin

On 09/03/2015 01:20 PM, Saul Wold wrote:
> oprofileui uses gettext during the configuration task so should be inherit
> gettext. This issue appears when an older version of gettext is used do to
> pinning to the older non-gplv3 version.
> 
> [YOCTO #7795]
> 
> Signed-off-by: Saul Wold 
> ---
>  meta/recipes-kernel/oprofile/oprofileui.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-kernel/oprofile/oprofileui.inc 
> b/meta/recipes-kernel/oprofile/oprofileui.inc
> index 1dfd0c6..8fcf014 100644
> --- a/meta/recipes-kernel/oprofile/oprofileui.inc
> +++ b/meta/recipes-kernel/oprofile/oprofileui.inc
> @@ -10,7 +10,7 @@ LIC_FILES_CHKSUM = 
> "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
>  
>  DEPENDS = "glib-2.0 avahi intltool-native"
>  
> -inherit autotools pkgconfig
> +inherit autotools pkgconfig gettext
>  
>  EXTRA_OECONF = "--with-avahi"
>  
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][dizzy] icu: CVE-2014-8146-CVE-2014-8147

[akuster808]

queuing up,

thanks,
Armin

On 09/04/2015 03:51 AM, Sona Sarmadi wrote:
> CVE-2014-8146 icu: heap overflow via incorrect isolateCount
> CVE-2014-8147 icu: integer truncation in the resolveImplicitLevels function
> 
> References:
> [1] https://github.com/pedrib/PoC/raw/master/generic/i-c-u-fail.7z
> [2] https://www.kb.cert.org/vuls/id/602540
> [3] http://bugs.icu-project.org/trac/changeset/37080
> [4] http://bugs.icu-project.org/trac/changeset/37162
> 
> Signed-off-by: Sona Sarmadi 
> ---
>  .../icu/icu/icu-CVE-2014-8146-CVE-2014-8147.patch  | 49 
> ++
>  meta/recipes-support/icu/icu_53.1.bb   |  1 +
>  2 files changed, 50 insertions(+)
>  create mode 100644 
> meta/recipes-support/icu/icu/icu-CVE-2014-8146-CVE-2014-8147.patch
> 
> diff --git 
> a/meta/recipes-support/icu/icu/icu-CVE-2014-8146-CVE-2014-8147.patch 
> b/meta/recipes-support/icu/icu/icu-CVE-2014-8146-CVE-2014-8147.patch
> new file mode 100644
> index 000..2460357
> --- /dev/null
> +++ b/meta/recipes-support/icu/icu/icu-CVE-2014-8146-CVE-2014-8147.patch
> @@ -0,0 +1,49 @@
> +icu: CVE-2014-8146-CVE-2014-8147
> +
> +CVE-2014-8146 icu: heap overflow via incorrect isolateCount
> +CVE-2014-8147 icu: integer truncation in the resolveImplicitLevels function
> +
> +References:
> +[1] https://github.com/pedrib/PoC/raw/master/generic/i-c-u-fail.7z
> +[2] https://www.kb.cert.org/vuls/id/602540
> +[3] http://bugs.icu-project.org/trac/changeset/37080
> +[4] http://bugs.icu-project.org/trac/changeset/37162
> +
> +Upstream-Status: Backport
> +
> +Signed-off-by: Sona Sarmadi 
> +---
> +diff -ruN a/common/ubidi.c b/common/ubidi.c
> +--- a/common/ubidi.c 2014-10-03 18:11:20.0 +0200
>  b/common/ubidi.c 2015-08-28 08:22:39.455906194 +0200
> +@@ -2138,7 +2138,7 @@
> + /* The isolates[] entries contain enough information to
> +resume the bidi algorithm in the same state as it was
> +when it was interrupted by an isolate sequence. */
> +-if(dirProps[start]==PDI) {
> ++if(dirProps[start]==PDI  && pBiDi->isolateCount >= 0) {
> + levState.startON=pBiDi->isolates[pBiDi->isolateCount].startON;
> + start1=pBiDi->isolates[pBiDi->isolateCount].start1;
> + stateImp=pBiDi->isolates[pBiDi->isolateCount].stateImp;
> +diff -ruN a/common/ubidiimp.h b/common/ubidiimp.h
> +--- a/common/ubidiimp.h  2014-10-03 18:11:16.0 +0200
>  b/common/ubidiimp.h  2015-08-28 08:28:24.069163845 +0200
> +@@ -1,7 +1,7 @@
> + /*
> + 
> **
> + *
> +-*   Copyright (C) 1999-2014, International Business Machines
> ++*   Copyright (C) 1999-2015, International Business Machines
> + *   Corporation and others.  All Rights Reserved.
> + *
> + 
> **
> +@@ -184,8 +184,8 @@
> + typedef struct Isolate {
> + int32_t startON;
> + int32_t start1;
> ++int32_t state;
> + int16_t stateImp;
> +-int16_t state;
> + } Isolate;
> +
> + typedef struct Run {
> diff --git a/meta/recipes-support/icu/icu_53.1.bb 
> b/meta/recipes-support/icu/icu_53.1.bb
> index d93af68..2906e8f 100644
> --- a/meta/recipes-support/icu/icu_53.1.bb
> +++ b/meta/recipes-support/icu/icu_53.1.bb
> @@ -11,6 +11,7 @@ ICU_PV = "${@icu_download_version(d)}"
>  BASE_SRC_URI = 
> "http://download.icu-project.org/files/icu4c/${PV}/icu4c-${ICU_PV}-src.tgz";
>  SRC_URI = "${BASE_SRC_URI} \
> file://icu-pkgdata-large-cmd.patch \
> +   file://icu-CVE-2014-8146-CVE-2014-8147.patch \
>"
>  
>  SRC_URI_append_class-target = "\
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][dizzy] gnutls: CVE-2015-3308

[akuster808]

in my queue.

Thanks,
Armin

On 09/03/2015 04:53 AM, Sona Sarmadi wrote:
> Fixes use-after-free flaw in CRL distribution points parsing
> 
> Reference:
> https://gitlab.com/gnutls/gnutls/commit/d6972be33264ecc49a86cd0958209cd7363af1e9
> https://gitlab.com/gnutls/gnutls/commit/053ae65403216acdb0a4e78b25ad66ee9f444f02
> 
> http://www.openwall.com/lists/oss-security/2015/04/15/6
> 
> Signed-off-by: Sona Sarmadi 
> ---
>  .../better-fix-for-double-free-CVE-2015-3308.patch | 65 
> ++
>  .../eliminated-double-free-CVE-2015-3308.patch | 33 +++
>  meta/recipes-support/gnutls/gnutls_3.3.5.bb|  2 +
>  3 files changed, 100 insertions(+)
>  create mode 100644 
> meta/recipes-support/gnutls/gnutls/better-fix-for-double-free-CVE-2015-3308.patch
>  create mode 100644 
> meta/recipes-support/gnutls/gnutls/eliminated-double-free-CVE-2015-3308.patch
> 
> diff --git 
> a/meta/recipes-support/gnutls/gnutls/better-fix-for-double-free-CVE-2015-3308.patch
>  
> b/meta/recipes-support/gnutls/gnutls/better-fix-for-double-free-CVE-2015-3308.patch
> new file mode 100644
> index 000..8824729
> --- /dev/null
> +++ 
> b/meta/recipes-support/gnutls/gnutls/better-fix-for-double-free-CVE-2015-3308.patch
> @@ -0,0 +1,65 @@
> +From 053ae65403216acdb0a4e78b25ad66ee9f444f02 Mon Sep 17 00:00:00 2001
> +From: Nikos Mavrogiannopoulos 
> +Date: Sat, 28 Mar 2015 22:41:03 +0100
> +Subject: [PATCH] Better fix for the double free in dist point parsing
> +
> +Fixes CVE-2015-3308
> +Upstream-Status: Backport
> +
> +Signed-off-by: Sona Sarmadi 
> +---
> + lib/x509/x509_ext.c | 10 ++
> + 1 file changed, 6 insertions(+), 4 deletions(-)
> +
> +diff --git a/lib/x509/x509_ext.c b/lib/x509/x509_ext.c
> +index 2e69ed0..f974b02 100644
> +--- a/lib/x509/x509_ext.c
>  b/lib/x509/x509_ext.c
> +@@ -2287,7 +2287,7 @@ int gnutls_x509_ext_import_crl_dist_points(const 
> gnutls_datum_t * ext,
> + int len, ret;
> + uint8_t reasons[2];
> + unsigned i, type, rflags, j;
> +-gnutls_datum_t san;
> ++gnutls_datum_t san = {NULL, 0};
> + 
> + result = asn1_create_element
> + (_gnutls_get_pkix(), "PKIX1.CRLDistributionPoints", &c2);
> +@@ -2310,9 +2310,6 @@ int gnutls_x509_ext_import_crl_dist_points(const 
> gnutls_datum_t * ext,
> + 
> + i = 0;
> + do {
> +-san.data = NULL;
> +-san.size = 0;
> +-
> + snprintf(name, sizeof(name), "?%u.reasons", (unsigned)i + 1);
> + 
> + len = sizeof(reasons);
> +@@ -2337,6 +2334,9 @@ int gnutls_x509_ext_import_crl_dist_points(const 
> gnutls_datum_t * ext,
> + 
> + j = 0;
> + do {
> ++san.data = NULL;
> ++san.size = 0;
> ++
> + ret =
> + _gnutls_parse_general_name2(c2, name, j, &san,
> + &type, 0);
> +@@ -2351,6 +2351,7 @@ int gnutls_x509_ext_import_crl_dist_points(const 
> gnutls_datum_t * ext,
> + ret = crl_dist_points_set(cdp, type, &san, rflags);
> + if (ret < 0)
> + break;
> ++san.data = NULL; /* it is now in cdp */
> + 
> + j++;
> + } while (ret >= 0);
> +@@ -2360,6 +2361,7 @@ int gnutls_x509_ext_import_crl_dist_points(const 
> gnutls_datum_t * ext,
> + 
> + if (ret < 0 && ret != GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE) {
> + gnutls_assert();
> ++gnutls_free(san.data);
> + goto cleanup;
> + }
> + 
> +-- 
> +1.9.1
> +
> diff --git 
> a/meta/recipes-support/gnutls/gnutls/eliminated-double-free-CVE-2015-3308.patch
>  
> b/meta/recipes-support/gnutls/gnutls/eliminated-double-free-CVE-2015-3308.patch
> new file mode 100644
> index 000..628103f
> --- /dev/null
> +++ 
> b/meta/recipes-support/gnutls/gnutls/eliminated-double-free-CVE-2015-3308.patch
> @@ -0,0 +1,33 @@
> +From d6972be33264ecc49a86cd0958209cd7363af1e9 Mon Sep 17 00:00:00 2001
> +From: Nikos Mavrogiannopoulos 
> +Date: Mon, 23 Mar 2015 22:55:29 +0100
> +Subject: [PATCH] eliminated double-free in the parsing of dist points
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +Reported by Robert Święcki.
> +
> +Fixes CVE-2015-3308
> +Upstream-Status: Backport
> +
> +Signed-off-by: Sona Sarmadi 
> +---
> + lib/x509/x509_ext.c | 1 -
> + 1 file changed, 1 deletion(-)
> +
> +diff --git a/lib/x509/x509_ext.c b/lib/x509/x509_ext.c
> +index c8d5867..6f09438 100644
> +--- a/lib/x509/x509_ext.c
>  b/lib/x509/x509_ext.c
> +@@ -2360,7 +2360,6 @@ int gnutls_x509_ext_import_crl_dist_points(const 
> gnutls_datum_t * ext,
> + 
> + if (ret < 0 && ret != GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE) {
> + gnutls_assert();
> +-gnutls_free(san.data);
> + goto cleanup;
> + }
> + 
> +-- 
> +1.9.1
> +
> diff --git a/meta/recipes-support/gnutls/gnutls_3.3

[OE-core] [PATCH] mkefidisk: Create interactive menu for the script

[Bruno Bottazzini]

If it is passed only the image parameter, it will show some interactive
options to help to conclude the script.

With this patch it will detect devices available in the machine, asking
to choose what it is wanted to be flashed.

it will suggest the target device. If it is a SD card the suggestion
is /dev/mmcblk0. If it is a pendrive it will suggest to use /dev/sda.

Signed-off-by: Bruno Bottazzini 
---
 scripts/contrib/mkefidisk.sh | 63 
 1 file changed, 58 insertions(+), 5 deletions(-)

diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
index 55f72b0..66e0e58 100755
--- a/scripts/contrib/mkefidisk.sh
+++ b/scripts/contrib/mkefidisk.sh
@@ -152,8 +152,55 @@ unmount() {
 # Parse and validate arguments
 #
 if [ $# -lt 3 ] || [ $# -gt 4 ]; then
-   usage
-   exit 1
+if [ $# -eq 1 ]; then
+AVAILABLE_DISK=`lsblk | grep "disk" | cut -f 1 -d " "`
+X=0
+for disk in `echo $AVAILABLE_DISK`; do
+mounted=`blkid -o list | grep "/dev/$disk" | grep "not mounted"`
+if [ -n "$mounted" ]; then
+UNMOUNTED_AVAILABLES="$UNMOUNTED_AVAILABLES /dev/$disk\n"
+info "$X - /dev/$disk"
+X=`expr $X + 1`
+fi
+done
+if [ $X -eq 0 ]; then
+die "No unmounted device found."
+fi
+read -p "Choose unmounted device number: " DISK_NUMBER
+X=0
+for line in `echo $UNMOUNTED_AVAILABLES`; do
+if [ $DISK_NUMBER -eq $X ]; then
+DISK_TO_BE_FLASHED=$line
+break
+else
+X=`expr $X + 1`
+fi
+done
+if [ -z "$DISK_TO_BE_FLASHED" ]; then
+die "Option \"$DISK_NUMBER\" is invalid. Choose a valid option"
+else
+if [ -z `echo $DISK_TO_BE_FLASHED | grep "mmc"` ]; then
+TARGET_TO_BE_BOOT="/dev/sda"
+else
+TARGET_TO_BE_BOOT="/dev/mmcblk0"
+fi
+fi
+echo ""
+echo "Choose a name of the device that will be boot from"
+echo -n "Recommended name is: "
+info "$TARGET_TO_BE_BOOT\n"
+read -p "Is target device okay? [y/N]: " RESPONSE
+if [ "$RESPONSE" != "y" ]; then
+read -p "Choose target device name: " TARGET_TO_BE_BOOT
+fi
+echo ""
+if [ -z "$TARGET_TO_BE_BOOT" ]; then
+die "Error: choose a valid target name"
+fi
+else
+usage
+   exit 1
+fi
 fi
 
 if [ "$1" = "-v" ]; then
@@ -162,9 +209,15 @@ if [ "$1" = "-v" ]; then
shift
 fi
 
-DEVICE=$1
-HDDIMG=$2
-TARGET_DEVICE=$3
+if [ -z "$AVAILABLE_DISK" ]; then
+DEVICE=$1
+HDDIMG=$2
+TARGET_DEVICE=$3
+else
+DEVICE=$DISK_TO_BE_FLASHED
+HDDIMG=$1
+TARGET_DEVICE=$TARGET_TO_BE_BOOT
+fi
 
 LINK=$(readlink $DEVICE)
 if [ $? -eq 0 ]; then
-- 
2.5.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] mkefidisk: Create interactive menu for the script

[Bruno Bottazzini]

Differences from v1:
- Now it will show only unmounted devices as Saul Wold has suggested
- Commit message changed as Saul Wold has suggested

Bruno Bottazzini (1):
  mkefidisk: Create interactive menu for the script

 scripts/contrib/mkefidisk.sh | 63 
 1 file changed, 58 insertions(+), 5 deletions(-)

-- 
2.5.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] any day now: pseudo 1.7, really

[Peter Seebach]

So there was a bogus argument on an fchmodat(), which resulted in
mkdirat() being able to set errno on success, and glibc's localedef
errors out if errno is set even if it has already confirmed that the
operation was successful. But it is not *intended* that I set errno
even on success, so that's fixed now.

Tarball sent to RP/halstead, may not be on server yet. I left the
branch name alone because I am gradually slipping into despair and
anguish and updating branch names no longer seems like it will
help slow down the universe's gradual decline into entropy.

The following changes since commit aba3ef50d65e0dc8659a48bf98d0fb00dd44a6fc:

  debianutils: create package for run-parts (2015-09-02 23:51:16 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib seebs/pseudo172
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=seebs/pseudo172

Peter Seebach (1):
  pseudo_1.7.3.bb: New version of pseudo

 meta/recipes-devtools/pseudo/pseudo_1.7.3.bb | 19 +++
 meta/recipes-devtools/pseudo/pseudo_git.bb   |  4 ++--
 2 files changed, 21 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-devtools/pseudo/pseudo_1.7.3.bb

-- 
2.3.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] pseudo_1.7.3.bb: New version of pseudo

[Peter Seebach]

Pseudo 1.7 adds an experimental feature (which I think needs more testing
before it becomes the default) allowing the pseudo client to store modes
and uid/gid values in extended attributes rather than using the sqlite
database. On most Linux-like systems, this works only if the underlying
file is a plain file or a directory.

Also added is a profiling feature to allow some amount of reporting on
the wall-clock time the client spends in wrappers, processing operations,
or in IPC. This feature is not intendeded to be precisely accurate, but
gives a good overview of where time is going.

Based on the results from the profiling feature, the client now suppresses
OP_OPEN and OP_EXEC messages if the server is not logging messages, and
no longer uses constant dynamic allocation and free cycles for canonicalized
paths.

There's a few other likely-looking optimizations being considered, but
this seemed like a good cutoff for now.

1.7.1 fixes two bugs, one affecting mostly XFS systems with 64-bit
inode values, and one affecting code that called realpath(x, NULL), such
as the RPM backend.

1.7.2 fixes an indirect side-effect of the chmod fixes to deal with
umask 0700, which had no effect with opkg 0.2.4 but appears to cause
failures with 0.3.0.

1.7.3 prevents mkdirat() (and mkfifoat()) from setting errno on success,
because glibc's localedef inexplicably errors out if errno was set, even
if the operation's actual return code (which it tests) indicated
success.

Signed-off-by: Peter Seebach 
---
 meta/recipes-devtools/pseudo/pseudo_1.7.3.bb | 19 +++
 meta/recipes-devtools/pseudo/pseudo_git.bb   |  4 ++--
 2 files changed, 21 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-devtools/pseudo/pseudo_1.7.3.bb

diff --git a/meta/recipes-devtools/pseudo/pseudo_1.7.3.bb 
b/meta/recipes-devtools/pseudo/pseudo_1.7.3.bb
new file mode 100644
index 000..1e9ef3b
--- /dev/null
+++ b/meta/recipes-devtools/pseudo/pseudo_1.7.3.bb
@@ -0,0 +1,19 @@
+require pseudo.inc
+
+SRC_URI = " \
+http://downloads.yoctoproject.org/releases/pseudo/${BPN}-${PV}.tar.bz2 \
+file://fallback-passwd \
+file://fallback-group \
+"
+
+SRC_URI[md5sum] = "2bd0a44eadd4713e90ad8c152eea77aa"
+SRC_URI[sha256sum] = 
"e9fc3922f8feb97839b50d14eb1987afdc8f22cdcac93119323cccd5f8444652"
+
+PSEUDO_EXTRA_OPTS ?= "--enable-force-async --without-passwd-fallback"
+
+do_install_append_class-native () {
+   install -d ${D}${sysconfdir}
+   # The fallback files should never be modified
+   install -m 444 ${WORKDIR}/fallback-passwd ${D}${sysconfdir}/passwd
+   install -m 444 ${WORKDIR}/fallback-group ${D}${sysconfdir}/group
+}
diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb 
b/meta/recipes-devtools/pseudo/pseudo_git.bb
index aa315d3..31e1223 100644
--- a/meta/recipes-devtools/pseudo/pseudo_git.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
@@ -1,7 +1,7 @@
 require pseudo.inc
 
-SRCREV = "db758fb11167c79d9682a17d359568e2a3c4acd5"
-PV = "1.6.5+git${SRCPV}"
+SRCREV = "e795df44a90a426a76b790f1b2774f3046a8fc31"
+PV = "1.7.2+git${SRCPV}"
 
 DEFAULT_PREFERENCE = "-1"
 
-- 
2.3.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2 1/9] kmod: fix link creation when base_bindir != /bin

[Richard Purdie]

On Fri, 2015-09-04 at 15:59 +0100, Joshua Lock wrote:
> If base_bindir is not a direct child of / the link creation in
> do_install_append creates incorrect relative links.
> 
> Instead pass a full path to the link source and use the -r flag
> to ln to ensure the link is relative.
> 
> Signed-off-by: Joshua Lock 
> ---
>  meta/recipes-kernel/kmod/kmod_git.bb | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-kernel/kmod/kmod_git.bb 
> b/meta/recipes-kernel/kmod/kmod_git.bb
> index ba4d85e..120fd87 100644
> --- a/meta/recipes-kernel/kmod/kmod_git.bb
> +++ b/meta/recipes-kernel/kmod/kmod_git.bb
> @@ -21,9 +21,9 @@ do_install_append () {
>  install -dm755 ${D}${base_bindir}
>  install -dm755 ${D}${base_sbindir}
>  # add symlinks to kmod
> -ln -s ..${base_bindir}/kmod ${D}${base_bindir}/lsmod
> +ln -sr ${D}${base_bindir}/kmod ${D}${base_bindir}/lsmod
>  for tool in insmod rmmod depmod modinfo modprobe; do
> -ln -s ..${base_bindir}/kmod ${D}${base_sbindir}/${tool}
> +ln -sr ${D}${base_bindir}/kmod ${D}${base_sbindir}/${tool}
>  done
>  # configuration directories
>  install -dm755 ${D}${base_libdir}/depmod.d

Not all our build machines appear to support ln -r, e.g.:

https://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/479/steps/BuildImages/logs/stdio

(debian7)

We do however have a python script called "lnr" in scripts which might
help...

Cheers,

Richard

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] Move BUILDDIR chmod fix after checks

[Alex Franco]

Makes more sense to have this fix after checking BUILDDIR exists, is
a directory and is writable.

[YOCTO #7669]

Signed-off-by: Alex Franco 
---
 scripts/oe-setup-builddir | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir
index 25d9f13..2598ba8 100755
--- a/scripts/oe-setup-builddir
+++ b/scripts/oe-setup-builddir
@@ -25,10 +25,6 @@ fi
 
 mkdir -p "$BUILDDIR/conf"
 
-# Attempting to remove sticky and setuid bits from BUILDDIR and
-# BUILDDIR/conf directories. #TODO appropriate checks for this
-chmod -st "$BUILDDIR" "$BUILDDIR/conf"
-
 if [ ! -d "$BUILDDIR" ]; then
 echo >&2 "Error: The builddir ($BUILDDIR) does not exist!"
 exit 1
@@ -39,6 +35,10 @@ if [ ! -w "$BUILDDIR" ]; then
 exit 1
 fi
 
+# Attempting removal of sticky,setuid bits from BUILDDIR, BUILDDIR/conf
+chmod -st "$BUILDDIR" 2>/dev/null || echo "WARNING: unable to chmod $BUILDDIR"
+chmod -st "$BUILDDIR/conf" 2>/dev/null || echo "WARNING: unable to chmod 
$BUILDDIR/conf"
+
 cd "$BUILDDIR"
 
 if [ -f "$BUILDDIR/conf/templateconf.cfg" ]; then
-- 
2.5.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCHv4] Fix recursive mode -st on BUILDDIR setup

[Alex Franco]

I agree these operations should take place after those checks.

Alex

On 09/04/2015 02:17 AM, Patrick Ohly wrote:

On Thu, 2015-09-03 at 16:56 -0500, Alex Franco wrote:

Removing recursive option from chmod -st on BUILDDIR as it would
take very long on existing build directories

Okay, so this *is* a problem others are also seeing ;-}


diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir
index f5b7e4e..91bd86b 100755
--- a/scripts/oe-setup-builddir
+++ b/scripts/oe-setup-builddir
@@ -24,7 +24,10 @@ if [ -z "$BUILDDIR" ]; then
  fi
  
  mkdir -p "$BUILDDIR/conf"

-chmod -R -st "$BUILDDIR"
+
+# Attempting removal of sticky,setuid bits from BUILDDIR, BUILDDIR/conf
+chmod -st "$BUILDDIR" 2>/dev/null || echo "WARNING: unable to chmod $BUILDDIR"
+chmod -st "$BUILDDIR/conf" 2>/dev/null || echo "WARNING: unable to chmod 
$BUILDDIR/conf"
  
  if [ ! -d "$BUILDDIR" ]; then

  echo >&2 "Error: The builddir ($BUILDDIR) does not exist!"

What was the reasoning behind adding these operations on $BUILDDIR/conf
before the check whether BUILDDIR exists and is a directory? Looks a bit
fishy to me.



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V3 3/3] runqemu: Define OECORE_MACHINE_SYSROOT on setup_sysroot

[Patrick Ohly]

On Wed, 2015-09-02 at 14:40 -0500, Leonardo Sandoval wrote:
> these set of patches should be merged into master(next). I do not see 
> any heavy objection doing it. As you mentioned, there are some points to 
> improve but I think the latter can be done before 2.1 release.
> 
> Let me know if you have any objections, otherwise the merge is pending.

No objections from me.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [RFC][PATCH] rootfs.py: show intercept script output in log.do_rootfs

[Martin Jansa]

* without this the output wasn't shown anywhere even when the bb.warn
  says:
  "See log for details!"

Signed-off-by: Martin Jansa 
---
 meta/lib/oe/rootfs.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 76950ec..2372226 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -279,7 +279,7 @@ class Rootfs(object):
 bb.note("> Executing %s intercept ..." % script)
 
 try:
-subprocess.check_output(script_full)
+subprocess.check_call(script_full)
 except subprocess.CalledProcessError as e:
 bb.warn("The postinstall intercept hook '%s' failed (exit 
code: %d)! See log for details!" %
 (script, e.returncode))
-- 
2.5.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] pseudo_1.7.2.bb: New version of pseudo

[Richard Purdie]

On Thu, 2015-09-03 at 22:28 -0500, Peter Seebach wrote:
> Pseudo 1.7 adds an experimental feature (which I think needs more testing
> before it becomes the default) allowing the pseudo client to store modes
> and uid/gid values in extended attributes rather than using the sqlite
> database. On most Linux-like systems, this works only if the underlying
> file is a plain file or a directory.
> 
> Also added is a profiling feature to allow some amount of reporting on
> the wall-clock time the client spends in wrappers, processing operations,
> or in IPC. This feature is not intendeded to be precisely accurate, but
> gives a good overview of where time is going.
> 
> Based on the results from the profiling feature, the client now suppresses
> OP_OPEN and OP_EXEC messages if the server is not logging messages, and
> no longer uses constant dynamic allocation and free cycles for canonicalized
> paths.
> 
> There's a few other likely-looking optimizations being considered, but
> this seemed like a good cutoff for now.
> 
> 1.7.1 fixes two bugs, one affecting mostly XFS systems with 64-bit
> inode values, and one affecting code that called realpath(x, NULL), such
> as the RPM backend.
> 
> 1.7.2 fixes an indirect side-effect of the chmod fixes to deal with
> umask 0700, which had no effect with opkg 0.2.4 but appears to cause
> failures with 0.3.0.

https://autobuilder.yoctoproject.org/main/builders/buildtools/builds/473/steps/BuildImages/logs/stdio

:(

Cheers,

Richard

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] How to put a correct dependency with regards to gcc?

[Reshetova, Elena]

Hi,

 

I have a simple problem but not able to come with simple and elegant
solution for it, so would be very thankful for the suggestions. 

 

I have a task that is specified to run after do_fetch. The task needs the
source to be *actually* fetched, since it operates on archives. It works
well for everything apart gcc. 

For example in fido branch, my task run for libgcc will fail, because
do_fetch task for libgcc actually *does not* not fetch the gcc sources (only
puts a nice lock file in the download folder).

 

When I noticed this, I tried to put the dependency on gcc-source:do_fetch
for my task (because that actually fetches the gcc sources) and it works in
fido, but in master after changes to gcc nothing provides gcc-source and it
wants to specify the version, which I don't want to do (ideally I don't want
to put any dependencies to gcc, since I don't really depend on it!). In
master a run for libgcc-initial fails for the same reasons: gcc tar ball is
not there. 

 

Is there a way to make it work correctly? 

 

Here is the history of issue we are trying to solve:
https://github.com/01org/meta-security-isafw/issues/1

 

Best Regards,
Elena.



smime.p7s
Description: S/MIME cryptographic signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V2] oeqa/decorators: Fixed a problem with tests having the same names.

[Richard Purdie]

On Fri, 2015-09-04 at 16:48 +0300, Lucian Musat wrote:
> When two or more tests had the same name but different classes then
> the decorator log whould have the output all wrong. This was because
> a comparison which was made only between method names but now it
> compares classes too.
> 
> YOCTO #8029

[YOCTO #8029]

using []. No need to resend again, I've fixed it this time.


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] pseudo_1.7.2.bb: New version of pseudo

[Richard Purdie]

On Fri, 2015-09-04 at 14:19 +0100, Burton, Ross wrote:
> On 4 September 2015 at 04:28, Peter Seebach
>  wrote:
> +SRC_URI = " \
> +
> 
> http://downloads.yoctoproject.org/releases/pseudo/${BPN}-${PV}.tar.bz2 \
>
> ERROR: Fetcher failure: Fetch command failed with exit code 8, output:
> http://downloads.yoctoproject.org/releases/pseudo/pseudo-1.7.2.tar.bz2:
> 2015-09-04 14:11:21 ERROR 404: Not Found.
>
> There isn't a 1.7.2 tarball uploaded yet.

There is now...

Cheers,

Richard


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Remove oprofileui-server

[Richard Purdie]

On Fri, 2015-09-04 at 16:59 +0100, Burton, Ross wrote:
> On 4 September 2015 at 10:05, Felipe Tonello 
> wrote:
> oprofileui-server is obsolete since it uses legacy OProfile's
> 'opcontrol'  commands to record a session, instead of operf.
> It
> doesn't work on fido builds.
> >
> Anyone familiar with the code base can tell if it is too much
> work to
> update it to use operf?
>
> Yes, its known that it's broken (bug 7054).
>
> It hopefully isn't too much work to update it,

It just needs someone with some glib knowledge to look at it, its
straight forward enough. I did get part way through it before realising
my glib knowledge is lacking (conversion of some sync code to become
async) and I haven't had the time :(.

Cheers,

Richard
 



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] tcmode-default: Set gcc 5.2 as the default

[Khem Raj]

> On Sep 4, 2015, at 8:33 AM, Richard Purdie 
>  wrote:
> 
> On Fri, 2015-09-04 at 08:29 -0700, Khem Raj wrote:
>>> On Sep 4, 2015, at 8:27 AM, Richard Purdie 
>>>  wrote:
>>> 
>>> -GCCVERSION ?= "4.9%"
>>> +GCCVERSION ?= "5.2%"
>> 
>> a small nit. Make it 5.% to logically indicate that 5.x is a bug fix release 
>> and next big upgrade will be
>> 6.x
> 
> I'm not sure this would be a good idea. We have had 4.8 alongside 4.9
> and can imagine doing something like that with newer 5.x releases
> depending on how they work out. I doubt 5.2% hurts anything, apart from
> needing to tweak that file slightly more often…
> 

I was asking so that it gets to people that 5.1 and 5.2 are not major release 
anymore instead 5.x and 6.x
will be major release in future. So there will never be 5.2 and 5.3 
simultaneously existing but 5.2 and 6.0 might. So it just reflects the upstream 
release model change. We can always change the minor as well there is no other 
technical advantage of using 5.%


> Cheers,
> 
> Richard
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] oeqa: Test failure/cleanup improvements

[Richard Purdie]

Currently, if qemu segfaults, the tests merrily continue trying to execute
which takes time for them to timeout and is a bit silly. Worse, no logs about
the segfault are shown to the user, its silent!

This patch tries to unravel the tangled web of issues and ensures that we:

* install a SIGCHLD handler which tells the user qemu exited
* check if qemu is running, if it isn't fail the test outright
* don't leave processes behind in sshcontrol which would hold
  bitbake.lock and block shutdown

Signed-off-by: Richard Purdie 

diff --git a/meta/lib/oeqa/oetest.py b/meta/lib/oeqa/oetest.py
index 9724325..ff62c30 100644
--- a/meta/lib/oeqa/oetest.py
+++ b/meta/lib/oeqa/oetest.py
@@ -144,6 +144,9 @@ class oeRuntimeTest(oeTest):
 self.target = oeRuntimeTest.tc.target
 super(oeRuntimeTest, self).__init__(methodName)
 
+def setUp(self):
+self.assertTrue(self.target.check(), msg = "Qemu not running?")
+
 def tearDown(self):
 # If a test fails or there is an exception
 if not exc_info() == (None, None, None):
diff --git a/meta/lib/oeqa/targetcontrol.py b/meta/lib/oeqa/targetcontrol.py
index 542e259..edc0d01 100644
--- a/meta/lib/oeqa/targetcontrol.py
+++ b/meta/lib/oeqa/targetcontrol.py
@@ -188,6 +188,9 @@ class QemuTarget(BaseTarget):
 bb.error("Qemu log output from %s:\n%s" % (self.qemulog, 
f.read()))
 raise bb.build.FuncFailed("%s - FAILED to start qemu - check the 
task log and the boot log" % self.pn)
 
+def check(self):
+return self.runner.is_alive()
+
 def stop(self):
 self.runner.stop()
 self.connection = None
diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index 3ad747a..c04ee0d 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -64,6 +64,22 @@ class QemuRunner:
 with open(self.logfile, "a") as f:
 f.write("%s" % msg)
 
+def getOutput(self, o):
+import fcntl
+fl = fcntl.fcntl(o, fcntl.F_GETFL)
+fcntl.fcntl(o, fcntl.F_SETFL, fl | os.O_NONBLOCK)
+return os.read(o.fileno(), 100)
+
+
+def handleSIGCHLD(self, signum, frame):
+if self.runqemu and self.runqemu.poll():
+if self.runqemu.returncode:
+logger.info('runqemu exited with code %d' % 
self.runqemu.returncode)
+logger.info("Output from runqemu:\n%s" % 
self.getOutput(self.runqemu.stdout))
+self.stop()
+self._dump_host()
+raise SystemExit
+
 def start(self, qemuparams = None):
 if self.display:
 os.environ["DISPLAY"] = self.display
@@ -98,11 +114,8 @@ class QemuRunner:
 if qemuparams:
 self.qemuparams = self.qemuparams[:-1] + " " + qemuparams + " " + 
'\"'
 
-def getOutput(o):
-import fcntl
-fl = fcntl.fcntl(o, fcntl.F_GETFL)
-fcntl.fcntl(o, fcntl.F_SETFL, fl | os.O_NONBLOCK)
-return os.read(o.fileno(), 100)
+self.origchldhandler = signal.getsignal(signal.SIGCHLD)
+signal.signal(signal.SIGCHLD, self.handleSIGCHLD)
 
 launch_cmd = 'runqemu tcpserial=%s %s %s %s' % (self.serverport, 
self.machine, self.rootfs, self.qemuparams)
 # FIXME: We pass in stdin=subprocess.PIPE here to work around stty
@@ -122,7 +135,7 @@ class QemuRunner:
 logger.info('runqemu exited with code %d' % 
self.runqemu.returncode)
 self._dump_host()
 self.stop()
-logger.info("Output from runqemu:\n%s" % getOutput(output))
+logger.info("Output from runqemu:\n%s" % 
self.getOutput(output))
 return False
 time.sleep(1)
 
@@ -139,7 +152,7 @@ class QemuRunner:
 self.ip = ips[0]
 self.server_ip = ips[1]
 except IndexError, ValueError:
-logger.info("Couldn't get ip from qemu process arguments! Here 
is the qemu command line used:\n%s\nand output from runqemu:\n%s" % (cmdline, 
getOutput(output)))
+logger.info("Couldn't get ip from qemu process arguments! Here 
is the qemu command line used:\n%s\nand output from runqemu:\n%s" % (cmdline, 
self.getOutput(output)))
 self._dump_host()
 self.stop()
 return False
@@ -154,7 +167,7 @@ class QemuRunner:
 logger.error("Didn't receive a console connection from qemu. "
  "Here is the qemu command line used:\n%s\nand "
  "output from runqemu:\n%s" % (cmdline,
-   getOutput(output)))
+   
self.getOutput(output)))
 self.stop_thread()
 return False
 
@@ -213,7 +226,7 @@ class QemuRunner:
 logger

Re: [OE-core] Remove oprofileui-server

[Burton, Ross]

On 4 September 2015 at 10:05, Felipe Tonello  wrote:

> oprofileui-server is obsolete since it uses legacy OProfile's
> 'opcontrol'  commands to record a session, instead of operf. It
> doesn't work on fido builds.
>
> Anyone familiar with the code base can tell if it is too much work to
> update it to use operf?
>

Yes, its known that it's broken (bug 7054).

It hopefully isn't too much work to update it, although part of me wonders
if a better use of time would be to add remote debugging support to the
Eclipse OProfile support.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] tcmode-default: Set gcc 5.2 as the default

[Khem Raj]

> On Sep 4, 2015, at 8:32 AM, Burton, Ross  wrote:
> 
> 
> On 4 September 2015 at 16:29, Khem Raj  > wrote:
> a small nit. Make it 5.% to logically indicate that 5.x is a bug fix release 
> and next big upgrade will be
> 6.x
> 
> To be honest I'd prefer *any* change to the compiler beyond eg 5.2.0 -> 5.2.1 
> to be explicit.  I think we've all seen enough breakage from a "bug fix" 
> release to know that it needs a proper test.
> 

well to put it in simple way gcc has changes its release numbers so

4.9.x  is same as 5.x now ( bug fix release) . Does that help

> Ross



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] tcmode-default: Set gcc 5.2 as the default

[Martin Jansa]

On Fri, Sep 04, 2015 at 04:33:20PM +0100, Richard Purdie wrote:
> On Fri, 2015-09-04 at 08:29 -0700, Khem Raj wrote:
> > > On Sep 4, 2015, at 8:27 AM, Richard Purdie 
> > >  wrote:
> > > 
> > > -GCCVERSION ?= "4.9%"
> > > +GCCVERSION ?= "5.2%"
> > 
> > a small nit. Make it 5.% to logically indicate that 5.x is a bug fix 
> > release and next big upgrade will be
> > 6.x
> 
> I'm not sure this would be a good idea. We have had 4.8 alongside 4.9
> and can imagine doing something like that with newer 5.x releases
> depending on how they work out. I doubt 5.2% hurts anything, apart from
> needing to tweak that file slightly more often...

But that was before GCC changed versioning scheme in 5, see
"Version Numbering Scheme for GCC 5 and Up" section in
https://gcc.gnu.org/develop.html

Having 5.1 alongside 5.2 isn't the same as 4.8 alongside 4.9 was.

I agree with Khem.

Ross: I agree that even small point release has to be tested, but this
variable is useful only to have multiple versions alongside each other,
which shouldn't be the case for 5.1 and 5.2 (or even 5.2.0 and 5.2.1 in
your example).

-- 
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] [PATCH] tcmode-default: Set gcc 5.2 as the default

[Richard Purdie]

On Fri, 2015-09-04 at 08:29 -0700, Khem Raj wrote:
> > On Sep 4, 2015, at 8:27 AM, Richard Purdie 
> >  wrote:
> > 
> > -GCCVERSION ?= "4.9%"
> > +GCCVERSION ?= "5.2%"
> 
> a small nit. Make it 5.% to logically indicate that 5.x is a bug fix release 
> and next big upgrade will be
> 6.x

I'm not sure this would be a good idea. We have had 4.8 alongside 4.9
and can imagine doing something like that with newer 5.x releases
depending on how they work out. I doubt 5.2% hurts anything, apart from
needing to tweak that file slightly more often...

Cheers,

Richard



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] tcmode-default: Set gcc 5.2 as the default

[Burton, Ross]

On 4 September 2015 at 16:29, Khem Raj  wrote:

> a small nit. Make it 5.% to logically indicate that 5.x is a bug fix
> release and next big upgrade will be
> 6.x
>

To be honest I'd prefer *any* change to the compiler beyond eg 5.2.0 ->
5.2.1 to be explicit.  I think we've all seen enough breakage from a "bug
fix" release to know that it needs a proper test.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] tcmode-default: Set gcc 5.2 as the default

[Khem Raj]

> On Sep 4, 2015, at 8:27 AM, Richard Purdie 
>  wrote:
> 
> -GCCVERSION ?= "4.9%"
> +GCCVERSION ?= "5.2%"

a small nit. Make it 5.% to logically indicate that 5.x is a bug fix release 
and next big upgrade will be
6.x


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] tcmode-default: Set gcc 5.2 as the default

[Richard Purdie]

gcc 5.2 is now working in all the places we test it in, its been in
testing for quite some time. Time to make it the default (we have some
room in M4 for any other bugfixes). Its easy to switch back to 4.9, we
should really remove 4.8 at this point (to meta-oe?).

Signed-off-by: Richard Purdie 

diff --git a/meta/conf/distro/include/tcmode-default.inc 
b/meta/conf/distro/include/tcmode-default.inc
index fabd347..f34cd22 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -22,7 +22,7 @@ PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libc-initial = 
"${TCLIBC}-initial"
 PREFERRED_PROVIDER_virtual/nativesdk-${SDK_PREFIX}libc-initial = 
"nativesdk-${TCLIBC}-initial"
 PREFERRED_PROVIDER_virtual/gettext ??= "gettext"
 
-GCCVERSION ?= "4.9%"
+GCCVERSION ?= "5.2%"
 SDKGCCVERSION ?= "${GCCVERSION}"
 BINUVERSION ?= "2.25%"
 GDBVERSION ?= "7.9%"


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Yocto Project Status WW36

[Jolley, Stephen K]

Current Dev Position: 1.9 Milestone 3 (M3)
Next Deadline: M3 cut off of August 24th at noon GMT (On hold until most likely 
late next week)

SWAT team rotation: Jussi -> Beth
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

Key Status/Updates:

  *   M3/Feature freeze is still being worked on. A status email was sent to 
OE-Core for the issues which are still pending inclusion.
  *   Test builds are continuing as fast as the infrastructure allows us to 
validate changes and get them merged.
  *   YP 2.0 will ship with gcc 5.2 as the default, we no longer have any 
failures related to the new version of gcc.
  *   We have tracked down one key random failure issue we were seeing in qemu. 
Many thanks to Anibal for his work on this, it was a tricky bug to figure out. 
We are also hot on the trail of another arm specific qemu issue.
  *   Other autobuilder issues remain and these continue to be worked on.
  *   Reminder: The current version that is in development will launch as YP 
2.0 in October, 2015. We have renamed YP 1.9 M4 to YP 2.0.  This will be the 
stabilization milestone for YP 2.0 release.
  *   Since we have passed YP 1.9 M3; we are at YP 1.9 / 2.0 feature freeze.   
All enhancements now will be pushed YP 2.1 other than those listed in the 
status email referred to above.
  *   The kernel versions in YP 2.0 are now pretty finalized other than some 
references many moving from 3.14 to 4.1 even in the lsb/ltsi case.
  *   The release name for YP 2.0 is 'jethro'.

Key YP 1.9/2.0 Dates:
YP 1.9 M3 Release Target: Before Sept. 11 2015  (Will be late)
YP 2.0 Final - 2.0 Cut off: Sept. 28, 2015 noon GMT
YP 2.0 final Release Target: Before Oct. 30, 2015

Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.9_Status
https://wiki.yoctoproject.org/wiki/Yocto_1.9_Schedule
https://wiki.yoctoproject.org/wiki/Yocto_1.9_Features

Tracking Metrics:
WDD 2054 (last week 2023 )
(https://wiki.yoctoproject.org/charts/combo.html)

[If anyone has suggestions for other information you'd like to see on this 
weekly status update, let us know!]

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:  (503) 712-0534
*Cell:(208) 244-4460
* Email: stephen.k.jol...@intel.com

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 7/9] pcmciautils: handle udev dir being 2 levels below /

[Joshua Lock]

When building with a merged /usr dir the udev directory
lives at /usr/lib/udev - update the FILES pattern to also
pick up udev files installed two levels below the / to
ensure a merged /usr works.

Signed-off-by: Joshua Lock 
---
 meta/recipes-bsp/pcmciautils/pcmciautils_018.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-bsp/pcmciautils/pcmciautils_018.bb 
b/meta/recipes-bsp/pcmciautils/pcmciautils_018.bb
index 24ceed8..857bd07 100644
--- a/meta/recipes-bsp/pcmciautils/pcmciautils_018.bb
+++ b/meta/recipes-bsp/pcmciautils/pcmciautils_018.bb
@@ -9,5 +9,5 @@ SRC_URI[sha256sum] = 
"79e6ae441278e178c07501d492394ed2c0326fdb66894f6d040ec811b0
 
 PR = "r1"
 
-FILES_${PN}-dbg += "*/udev/.debug"
-FILES_${PN} += "*/udev"
+FILES_${PN}-dbg += "*/udev/.debug */*/udev/.debug"
+FILES_${PN} += "*/udev */*/udev"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 6/9] bluez: handle udev dir being 2 levels below /

[Joshua Lock]

When building with a merged /usr dir the udev directory
lives at /usr/lib/udev - update the FILES pattern to also
pick up udev files installed two levels below the / to
ensure a merged /usr works.

Signed-off-by: Joshua Lock 
---
 meta/recipes-connectivity/bluez5/bluez5.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index 0fe5be5..039c443 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -95,6 +95,7 @@ FILES_${PN}-dbg += "\
   ${libdir}/bluetooth/plugins/.debug \
   ${libdir}/*/.debug \
   */udev/.debug \
+  */*/udev/.debug \
   "
 
 RDEPENDS_${PN}-testtools += "python python-dbus python-pygobject"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 8/9] nfs-utils: don't force use of /sbin as sbindir

[Joshua Lock]

The Makefile for mount and osd_login utilities forces
/sbin as asbindir, however on a merged /usr system this directory
might not exist. Instead sed in the system sbindir.

Signed-off-by: Joshua Lock 
---
 meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb | 8 
 1 file changed, 8 insertions(+)

diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb 
b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
index 6da8509..42101de 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_1.3.1.bb
@@ -90,6 +90,14 @@ RDEPENDS_${PN}-stats = "python"
 
 FILES_${PN} += "${systemd_unitdir}"
 
+do_configure_prepend() {
+sed -i -e 's,sbindir = /sbin,sbindir = ${base_sbindir},g' \
+${S}/utils/mount/Makefile.am
+
+sed -i -e 's,sbindir = /sbin,sbindir = ${base_sbindir},g' \
+${S}/utils/osd_login/Makefile.am
+}
+
 # Make clean needed because the package comes with
 # precompiled 64-bit objects that break the build
 do_compile_prepend() {
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 2/9] busybox: fixes for when base_bindir != /bin

[Joshua Lock]

* Replace all hard-coded paths with variables
* Run sed over busybox.links.* to replace /bin with ${base_bindir}

Signed-off-by: Joshua Lock 
---
 meta/recipes-core/busybox/busybox.inc | 49 +++
 1 file changed, 26 insertions(+), 23 deletions(-)

diff --git a/meta/recipes-core/busybox/busybox.inc 
b/meta/recipes-core/busybox/busybox.inc
index 0769d92..ed8f9fe 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -178,6 +178,9 @@ do_install () {
if [ "${base_sbindir}" != "/sbin" ]; then
sed -i "s:^/sbin/:${base_sbindir}/:" busybox.links*
fi
+   if [ "${base_bindir}" != "/bin" ]; then
+   sed -i "s:^/bin/:${base_bindir}/:" busybox.links*
+   fi
 
install -d ${D}${sysconfdir}/init.d
 
@@ -338,10 +341,10 @@ python do_package_prepend () {
 return
 
 if os.path.exists('%s/etc/busybox.links' % (dvar)):
-set_alternative_vars("/etc/busybox.links", "/bin/busybox")
+set_alternative_vars("${sysconfdir}/busybox.links", 
"${base_bindir}/busybox")
 else:
-set_alternative_vars("/etc/busybox.links.nosuid", 
"/bin/busybox.nosuid")
-set_alternative_vars("/etc/busybox.links.suid", "/bin/busybox.suid")
+set_alternative_vars("${sysconfdir}/busybox.links.nosuid", 
"${base_bindir}/busybox.nosuid")
+set_alternative_vars("${sysconfdir}/busybox.links.suid", 
"${base_bindir}/busybox.suid")
 }
 
 pkg_postinst_${PN} () {
@@ -353,22 +356,22 @@ pkg_postinst_${PN} () {
if test "x$D" = "x"; then
# Remove busybox.nosuid if it's a symlink, because this 
situation indicates
# that we're installing or upgrading to a one-binary busybox.
-   if test -h /bin/busybox.nosuid; then
-   rm -f /bin/busybox.nosuid
+   if test -h ${base_bindir}/busybox.nosuid; then
+   rm -f ${base_bindir}/busybox.nosuid
fi
for suffix in "" ".nosuid" ".suid"; do
-   if test -e /etc/busybox.links$suffix; then
+   if test -e ${sysconfdir}/busybox.links$suffix; then
while read link; do
if test ! -e "$link"; then
case "$link" in
/*/*/*)
-   
to="../../bin/busybox$suffix"
+   
to="../..${base_bindir}/busybox$suffix"
;;
/bin/*)

to="busybox$suffix"
;;
/*/*)
-   
to="../bin/busybox$suffix"
+   
to="..${base_bindir}/busybox$suffix"
;;
esac
# we can use busybox here 
because even if we are using splitted busybox
@@ -376,7 +379,7 @@ pkg_postinst_${PN} () {
busybox rm -f $link
busybox ln -s $to $link
fi
-   done < /etc/busybox.links$suffix
+   done < ${sysconfdir}/busybox.links$suffix
fi
done
fi
@@ -387,19 +390,19 @@ pkg_prerm_${PN} () {
# providing its files, this will make update-alternatives work, but the 
update-rc.d part
# for syslog, httpd and/or udhcpd will fail if there is no other 
package providing sh
tmpdir=`mktemp -d /tmp/busyboxrm-XX`
-   ln -s /bin/busybox $tmpdir/[
-   ln -s /bin/busybox $tmpdir/test
-   ln -s /bin/busybox $tmpdir/head
-   ln -s /bin/busybox $tmpdir/sh
-   ln -s /bin/busybox $tmpdir/basename
-   ln -s /bin/busybox $tmpdir/echo
-   ln -s /bin/busybox $tmpdir/mv
-   ln -s /bin/busybox $tmpdir/ln
-   ln -s /bin/busybox $tmpdir/dirname
-   ln -s /bin/busybox $tmpdir/rm
-   ln -s /bin/busybox $tmpdir/sed
-   ln -s /bin/busybox $tmpdir/sort
-   ln -s /bin/busybox $tmpdir/grep
+   ln -s ${base_bindir}/busybox $tmpdir/[
+   ln -s ${base_bindir}/busybox $tmpdir/test
+   ln -s ${base_bindir}/busybox $tmpdir/head
+   ln -s ${base_bindir}/busybox $tmpdir/sh
+   ln -s ${base_bindir}/busybox $tmpdir/basename
+   ln -s ${base_bindir}/busybox $tmpdir/echo
+   ln -s ${base_bindir}/busybox $tmpd

[OE-core] [PATCH v2 9/9] procps: fix for base_sbindir == sbindir

[Joshua Lock]

An rmdir call in do_install_append was trying to remove the
sbindir, however in a system with a merged usr this directory
is not empty and therefore failing to rm it causes an ERROR.

Instead check that sbindir != base_sbindir before trying to
remove the directory.

Signed-off-by: Joshua Lock 
---
 meta/recipes-extended/procps/procps_3.3.10.bb | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-extended/procps/procps_3.3.10.bb 
b/meta/recipes-extended/procps/procps_3.3.10.bb
index 65d64ec..dcfaba7 100644
--- a/meta/recipes-extended/procps/procps_3.3.10.bb
+++ b/meta/recipes-extended/procps/procps_3.3.10.bb
@@ -31,8 +31,9 @@ do_install_append () {
[ "${bindir}" != "${base_bindir}" ] && for i in ${base_bindir_progs}; 
do mv ${D}${bindir}/$i ${D}${base_bindir}/$i; done
install -d ${D}${base_sbindir}
[ "${sbindir}" != "${base_sbindir}" ] && for i in 
${base_sbindir_progs}; do mv ${D}${sbindir}/$i ${D}${base_sbindir}/$i; done
-# Remove now empty dir
-   rmdir ${D}/${sbindir}
+if [ "${base_sbindir}" != "${sbindir}" ]; then
+rmdir ${D}${sbindir}
+fi
 
 install -d ${D}${sysconfdir}
 install -m 0644 ${WORKDIR}/sysctl.conf ${D}${sysconfdir}/sysctl.conf
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 5/9] pulseaudio: handle udev dir being 2 levels below /

[Joshua Lock]

When building with a merged /usr dir the udev directory
lives at /usr/lib/udev - update the FILES pattern to also
pick up udev files installed two levels below the / to
ensure a merged /usr works.

Signed-off-by: Joshua Lock 
---
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index 27e05d3..5b806d7 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -115,7 +115,7 @@ FILES_${PN}-dbg += "${libexecdir}/pulse/.debug \
 FILES_${PN}-dev += "${libdir}/pulse-${PV}/modules/*.la ${datadir}/vala 
${libdir}/cmake"   
 FILES_${PN}-conf = "${sysconfdir}"
 FILES_${PN}-bin += "${sysconfdir}/default/volatiles/volatiles.04_pulse"
-FILES_${PN}-server = "${bindir}/pulseaudio ${bindir}/start-* ${sysconfdir} 
${bindir}/pactl */udev/rules.d/*.rules ${systemd_user_unitdir}/*"
+FILES_${PN}-server = "${bindir}/pulseaudio ${bindir}/start-* ${sysconfdir} 
${bindir}/pactl */udev/rules.d/*.rules */*/udev/rules.d/*.rules 
${systemd_user_unitdir}/*"
 
 #SYSTEMD_PACKAGES = "${PN}-server"
 SYSTEMD_SERVICE_${PN}-server = "pulseaudio.service"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 4/9] alsa-utils: handle udev dir being 2 levels below /

[Joshua Lock]

When building with a merged /usr dir the udev directory
lives at /usr/lib/udev - update the FILES pattern to also
pick up udev files installed two levels below the / to
ensure a merged /usr works.

Signed-off-by: Joshua Lock 
---
 meta/recipes-multimedia/alsa/alsa-utils_1.0.29.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/alsa/alsa-utils_1.0.29.bb 
b/meta/recipes-multimedia/alsa/alsa-utils_1.0.29.bb
index 263f38a..97fe4b2 100644
--- a/meta/recipes-multimedia/alsa/alsa-utils_1.0.29.bb
+++ b/meta/recipes-multimedia/alsa/alsa-utils_1.0.29.bb
@@ -58,7 +58,7 @@ FILES_alsa-utils-midi= "${bindir}/aplaymidi 
${bindir}/arecordmidi ${bind
 FILES_alsa-utils-aconnect= "${bindir}/aconnect"
 FILES_alsa-utils-aseqnet = "${bindir}/aseqnet"
 FILES_alsa-utils-iecset  = "${bindir}/iecset"
-FILES_alsa-utils-alsactl = "${sbindir}/alsactl */udev/rules.d 
${systemd_unitdir} ${localstatedir}/lib/alsa ${datadir}/alsa/init/"
+FILES_alsa-utils-alsactl = "${sbindir}/alsactl */udev/rules.d 
*/*/udev/rules.d ${systemd_unitdir} ${localstatedir}/lib/alsa 
${datadir}/alsa/init/"
 FILES_alsa-utils-aseqdump= "${bindir}/aseqdump"
 FILES_alsa-utils-alsaloop= "${bindir}/alsaloop"
 FILES_alsa-utils-alsaucm = "${bindir}/alsaucm"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 3/9] systemd: remove hard-coded paths in FILES entries

[Joshua Lock]

Signed-off-by: Joshua Lock 
---
 meta/recipes-core/systemd/systemd_219.bb | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-core/systemd/systemd_219.bb 
b/meta/recipes-core/systemd/systemd_219.bb
index 4d32fd5..a64dbac 100644
--- a/meta/recipes-core/systemd/systemd_219.bb
+++ b/meta/recipes-core/systemd/systemd_219.bb
@@ -306,10 +306,10 @@ FILES_${PN} = " ${base_bindir}/* \
 ${exec_prefix}/lib/sysctl.d \
 ${exec_prefix}/lib/sysusers.d \
 ${localstatedir} \
-/lib/udev/rules.d/70-uaccess.rules \
-/lib/udev/rules.d/71-seat.rules \
-/lib/udev/rules.d/73-seat-late.rules \
-/lib/udev/rules.d/99-systemd.rules \
+${nonarch_base_libdir}/udev/rules.d/70-uaccess.rules \
+${nonarch_base_libdir}/udev/rules.d/71-seat.rules \
+${nonarch_base_libdir}/udev/rules.d/73-seat-late.rules \
+${nonarch_base_libdir}/udev/rules.d/99-systemd.rules \
"
 
 FILES_${PN}-dbg += "${rootlibdir}/.debug ${systemd_unitdir}/.debug 
${systemd_unitdir}/*/.debug ${base_libdir}/security/.debug/"
@@ -327,7 +327,7 @@ RRECOMMENDS_${PN} += "systemd-serialgetty 
systemd-vconsole-setup \
 
 PACKAGES =+ "udev-dbg udev udev-hwdb"
 
-FILES_udev-dbg += "/lib/udev/.debug"
+FILES_udev-dbg += "${nonarch_base_libdir}/udev/.debug"
 
 RPROVIDES_udev = "hotplug"
 
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 1/9] kmod: fix link creation when base_bindir != /bin

[Joshua Lock]

If base_bindir is not a direct child of / the link creation in
do_install_append creates incorrect relative links.

Instead pass a full path to the link source and use the -r flag
to ln to ensure the link is relative.

Signed-off-by: Joshua Lock 
---
 meta/recipes-kernel/kmod/kmod_git.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/kmod/kmod_git.bb 
b/meta/recipes-kernel/kmod/kmod_git.bb
index ba4d85e..120fd87 100644
--- a/meta/recipes-kernel/kmod/kmod_git.bb
+++ b/meta/recipes-kernel/kmod/kmod_git.bb
@@ -21,9 +21,9 @@ do_install_append () {
 install -dm755 ${D}${base_bindir}
 install -dm755 ${D}${base_sbindir}
 # add symlinks to kmod
-ln -s ..${base_bindir}/kmod ${D}${base_bindir}/lsmod
+ln -sr ${D}${base_bindir}/kmod ${D}${base_bindir}/lsmod
 for tool in insmod rmmod depmod modinfo modprobe; do
-ln -s ..${base_bindir}/kmod ${D}${base_sbindir}/${tool}
+ln -sr ${D}${base_bindir}/kmod ${D}${base_sbindir}/${tool}
 done
 # configuration directories
 install -dm755 ${D}${base_libdir}/depmod.d
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 0/9] Fixes for a distro with a merged /usr

[Joshua Lock]

I've been playing around with building a distro with a merged /usr[1] and
the following series fixes several issues I ran across in OE core metadata.

These have been build tested by building a core-image-sato image with
ipk packaging for: i) qemux86 with a default configuration, ii) qemux86-64
with a mutlilib configuration where the image includes lib32-ncurses and
iii) for my merged /usr test distro.

I used buildhistory to compare core-image-sato before and after this series
and the only change is:

Changes to images/qemux86/glibc/core-image-sato (files-in-image.txt):
  /bin/lsmod.kmod changed symlink target from ../bin/kmod to kmod

Changes since v1:
* Fix busybox typo/thinko which lead to installing busybox links into /usr/bin
* Fix systemd recipe to use nonarch_base_libdir for udev files

Regards,

Joshua

The following changes since commit aba3ef50d65e0dc8659a48bf98d0fb00dd44a6fc:

  debianutils: create package for run-parts (2015-09-02 23:51:16 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib joshuagl/merged-usr
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=joshuagl/merged-usr

Joshua Lock (9):
  kmod: fix link creation when base_bindir != /bin
  busybox: fixes for when base_bindir != /bin
  systemd: remove hard-coded paths in FILES entries
  alsa-utils: handle udev dir being 2 levels below /
  pulseaudio: handle udev dir being 2 levels below /
  bluez: handle udev dir being 2 levels below /
  pcmciautils: handle udev dir being 2 levels below /
  nfs-utils: don't force use of /sbin as sbindir
  procps: fix for base_sbindir == sbindir

 meta/recipes-bsp/pcmciautils/pcmciautils_018.bb|  4 +-
 meta/recipes-connectivity/bluez5/bluez5.inc|  1 +
 .../nfs-utils/nfs-utils_1.3.1.bb   |  8 
 meta/recipes-core/busybox/busybox.inc  | 49 --
 meta/recipes-core/systemd/systemd_219.bb   | 10 ++---
 meta/recipes-extended/procps/procps_3.3.10.bb  |  5 ++-
 meta/recipes-kernel/kmod/kmod_git.bb   |  4 +-
 meta/recipes-multimedia/alsa/alsa-utils_1.0.29.bb  |  2 +-
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc  |  2 +-
 9 files changed, 49 insertions(+), 36 deletions(-)

-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v3] devtool: add package plugin that lets you create package via devtool

[Paul Eggleton]

On Thursday 03 September 2015 23:09:30 brendan.le.f...@intel.com wrote:
> From: Brendan Le Foll 
> 
> Signed-off-by: Brendan Le Foll 
> ---
>  scripts/lib/devtool/package.py | 61
> ++ 1 file changed, 61 insertions(+)
>  create mode 100644 scripts/lib/devtool/package.py
> 
> diff --git a/scripts/lib/devtool/package.py b/scripts/lib/devtool/package.py
> new file mode 100644
> index 000..e9d4240
> --- /dev/null
> +++ b/scripts/lib/devtool/package.py
> @@ -0,0 +1,61 @@
> +# Development tool - package command plugin
> +#
> +# Copyright (C) 2014-2015 Intel Corporation
> +#
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License version 2 as
> +# published by the Free Software Foundation.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License along
> +# with this program; if not, write to the Free Software Foundation, Inc.,
> +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> +"""Devtool plugin containing the package subcommands"""
> +
> +import os
> +import subprocess
> +import logging
> +from bb.process import ExecutionError
> +from devtool import exec_build_env_command, setup_tinfoil, DevtoolError
> +
> +logger = logging.getLogger('devtool')
> +
> +def plugin_init(pluginlist):
> +"""Plugin initialization"""
> +pass
> +
> +def package(args, config, basepath, workspace):
> +"""Entry point for the devtool 'package' subcommand"""
> +if not args.recipename in workspace:
> +raise DevtoolError("no recipe named %s in your workspace" %
> +   args.recipename)
> +
> +try:
> +image_pkgtype = config.get('image_pkgtype', None)

This isn't quite right - to be fair though I think you may have copy-pasted 
something I sent you privately which wasn't correct. The first parameter is the 
section, second the value name, third the default. If you specify a default 
you won't need to put it in try/except, just "if not image_pkgtype:'.

Don't worry about fixing this though, I'm currently rolling up devtool patches 
into a series and I will fix it as part of that.

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

Re: [OE-core] [PATCH 04/12] gnome-icon-theme: remove the recipe

[Khem Raj]

On Friday, September 4, 2015, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> On 09/04/2015 12:28 AM, Khem Raj wrote:
>
> It is not used by anything in oe-core and will be moved to meta-gnome
>>>
>>>
>> OK, please send the patch for meta-gnome as well. So we can merge them in
>> more or less in sync
>>
>
> I will send these patches only when oe-core is updated. Recipe moving is
> always controversial, and I don't want to cause confusion when the change
> is accepted by one side and rejected by the other.


On the contrary you can make a note in patch to destination layer citing
the patch for source layer being a prerequisite to be accepted. Maintainers
then can schedule it accordingly.

>
> Alex
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/9] systemd: remove hard-coded paths in FILES entries

[Burton, Ross]

On 4 September 2015 at 12:07, Joshua Lock 
wrote:

> I've prepared a v2 that changes this to nonarch_base_libdir but
> systemd+multilib appears to be broken, see:
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=8256
>

As far as I understand it (and that's only a bit, I'll delegate to Mark)
this is because the sanity check is verifying that the files that get
overwritten between different subarches are actually identical, but
lib32-connman and connman have service files in /lib/systemd that refer to
binaries that are in $(libdir), which changes, so the files change.
Arguably connman should be using libexecdir and not libdir, but that also
would mean fixing libexecdir not to change (for which I have a patch series
that failed to re-send in this cycle).

I've commented on the bug that the example should be changed to be a
library such as lib32-glib-2.0, which is possibly a more useful real world
situation ("I have a 32-bit pre-compiled binary that needs glib" is more
likely than "I want a 64-bit distro with a 32-bit connman") and should
actually work.

Ross

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH V2] oeqa/decorators: Fixed a problem with tests having the same names.

[Lucian Musat]

When two or more tests had the same name but different classes then
the decorator log whould have the output all wrong. This was because
a comparison which was made only between method names but now it
compares classes too.

YOCTO #8029

Signed-off-by: Lucian Musat 
---
 meta/lib/oeqa/utils/decorators.py | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/meta/lib/oeqa/utils/decorators.py 
b/meta/lib/oeqa/utils/decorators.py
index b9fc76c..ff84541 100644
--- a/meta/lib/oeqa/utils/decorators.py
+++ b/meta/lib/oeqa/utils/decorators.py
@@ -116,13 +116,14 @@ def LogResults(original_class):
 orig_method(self, result, *args, **kws)
 passed = True
 testMethod = getattr(self, self._testMethodName)
-
 #if test case is decorated then use it's number, else use it's name
 try:
 test_case = testMethod.test_case
 except AttributeError:
 test_case = self._testMethodName
 
+class_name = str(testMethod.im_class).split("'")[1]
+
 #create custom logging level for filtering.
 custom_log_level = 100
 logging.addLevelName(custom_log_level, 'RESULTS')
@@ -143,18 +144,19 @@ def LogResults(original_class):
 local_log = logging.getLogger(caller)
 
 #check status of tests and record it
+
 for (name, msg) in result.errors:
-if self._testMethodName == str(name).split(' ')[0]:
+if (self._testMethodName == str(name).split(' ')[0]) and 
(class_name in str(name).split(' ')[1]):
 local_log.results("Testcase "+str(test_case)+": ERROR")
 local_log.results("Testcase "+str(test_case)+":\n"+msg)
 passed = False
 for (name, msg) in result.failures:
-if self._testMethodName == str(name).split(' ')[0]:
+if (self._testMethodName == str(name).split(' ')[0]) and 
(class_name in str(name).split(' ')[1]):
 local_log.results("Testcase "+str(test_case)+": FAILED")
 local_log.results("Testcase "+str(test_case)+":\n"+msg)
 passed = False
 for (name, msg) in result.skipped:
-if self._testMethodName == str(name).split(' ')[0]:
+if (self._testMethodName == str(name).split(' ')[0]) and 
(class_name in str(name).split(' ')[1]):
 local_log.results("Testcase "+str(test_case)+": SKIPPED")
 passed = False
 if passed:
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] oeqa/decorators: Fixed a problem with tests having the same names.

[Musat, George L]

Hi Paul, 

Forgot about that, thanks.

-Original Message-
From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] 
Sent: Friday, September 4, 2015 4:41 PM
To: Musat, George L
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] oeqa/decorators: Fixed a problem with tests 
having the same names.

Hi Lucian,

On Friday 04 September 2015 16:33:07 Lucian Musat wrote:
> When two or more tests had the same name but different classes then 
> the decorator log whould have the output all wrong. This was because a 
> comparison which was made only between method names but now it 
> compares classes too.
> 
> Bug #8029

The correct way to reference a Yocto Project Bugzilla entry that's fixed by a 
bug is [YOCTO #] i.e. here you would use [YOCTO #8029].

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

Re: [OE-core] [PATCH V3 8/8] populate_sdk_ext: get rid of buildtools

[Paul Eggleton]

On Tuesday 01 September 2015 18:35:53 Paul Eggleton wrote:
> On Tuesday 01 September 2015 17:13:49 Paul Eggleton wrote:
> > Hi Qi,
> > 
> > On Monday 24 August 2015 15:46:56 Chen Qi wrote:
> > > If we do `bitbake buildtools-tarball' and then after one day do `bitbake
> > > core-image-minimal -c populate_sdk_ext', we would meet errors like
> > > below.
> > > 
> > > | install: cannot stat
> > > | '/buildarea2/chenqi/poky/build-systemd/tmp/deploy/sdk/
> > > 
> > > poky-glibc-x86_64-buildtools-tarball-core2-64-buildtools-nativesdk-stand
> > > al
> > > on e -1.8+snapshot-20150429.sh': No such file or directory
> > > 
> > > The problem is that the output name for buildtools-tarball has ${DATE}
> > > in
> > > it. So if populate_sdk_ext task is executed but buildtools-tarball is
> > > not
> > > rebuilt, the above error appears.
> > > 
> > > In fact, ext SDK does not have to depend on buildtools. This patch
> > > removes
> > > the buildtools from the ext SDK. After this patch, the ext SDK still
> > > works
> > > and we can no longer see the buildtools error.
> > > 
> > > [YOCTO #7674]
> > > 
> > > Signed-off-by: Chen Qi 
> > > ---
> > > 
> > >  meta/classes/populate_sdk_ext.bbclass | 29
> > >  +++--
> > >  1 file changed, 19 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/meta/classes/populate_sdk_ext.bbclass
> > > b/meta/classes/populate_sdk_ext.bbclass index 151ae1d..1dcd982 100644
> > > --- a/meta/classes/populate_sdk_ext.bbclass
> > > +++ b/meta/classes/populate_sdk_ext.bbclass
> > > @@ -7,8 +7,25 @@ inherit populate_sdk_base
> > > 
> > >  TOOLCHAIN_HOST_TASK_task-populate-sdk-ext = " \
> > >  
> > >  meta-environment-extsdk-${MACHINE} \
> > > 
> > > +nativesdk-python-core \
> > > +nativesdk-python-modules \
> > > +nativesdk-python-misc \
> > > +nativesdk-python-git \
> > > +nativesdk-python-pexpect \
> > > +nativesdk-ncurses-terminfo-base \
> > > +nativesdk-chrpath \
> > > +nativesdk-tar \
> > > +nativesdk-buildtools-perl-dummy \
> > > +nativesdk-git \
> > > +nativesdk-git-perltools \
> > > +nativesdk-pigz \
> > > +nativesdk-make \
> > > +nativesdk-wget \
> > > +nativesdk-ca-certificates \
> > > 
> > >  "
> > > 
> > > +SDK_PACKAGE_ARCHS =+ "buildtools-dummy-${SDKPKGSUFFIX}"
> > > +
> > > 
> > >  TOOLCHAIN_TARGET_TASK_task-populate-sdk-ext = ""
> > >  
> > >  SDK_RDEPENDS_append_task-populate-sdk-ext = " ${SDK_TARGETS}"
> > > 
> > > @@ -183,8 +200,6 @@ install_tools() {
> > > 
> > >   lnr ${SDK_OUTPUT}/${SDKPATH}/${scriptrelpath}/recipetool
> > > 
> > > ${SDK_OUTPUT}/${SDKPATHNATIVE}${bindir_nativesdk}/recipetool touch
> > > ${SDK_OUTPUT}/${SDKPATH}/.devtoolbase
> > > 
> > > - install
> > > ${SDK_DEPLOY}/${DISTRO}-${TCLIBC}-${SDK_ARCH}-buildtools-tarball-${TUNE_
> > > PK
> > > G
> > > ARCH}-buildtools-nativesdk-standalone-${DISTRO_VERSION}.sh
> > > ${SDK_OUTPUT}/${SDKPATH} -
> > > 
> > >   install ${SDK_DEPLOY}/${BUILD_ARCH}-nativesdk-libc.tar.bz2
> > > 
> > > ${SDK_OUTPUT}/${SDKPATH} }
> > > 
> > > @@ -201,13 +216,7 @@ SDK_PRE_INSTALL_COMMAND_task-populate-sdk-ext =
> > > "${sdk_ext_preinst}"
> > > 
> > >  # FIXME this preparation should be done as part of the SDK construction
> > >  sdk_ext_postinst() {
> > > 
> > > - printf "\nExtracting buildtools...\n"
> > > 
> > >   cd $target_sdk_dir
> > > 
> > > - printf "buildtools\ny" | ./*buildtools-tarball* > /dev/null
> > > -
> > > - # Make sure when the user sets up the environment, they also get
> > > - # the buildtools-tarball tools in their path.
> > > - echo ". $target_sdk_dir/buildtools/environment-setup*" >>
> > > $target_sdk_dir/environment-setup*
> > > 
> > >   # Allow bitbake environment setup to be ran as part of this sdk.
> > >   echo "export OE_SKIP_SDK_CHECK=1" >> $target_sdk_dir/environment-
> 
> setup*
> 
> > > @@ -224,7 +233,7 @@ sdk_ext_postinst() {
> > > 
> > >   # dash which is /bin/sh on Ubuntu will not preserve the
> > >   # current working directory when first ran, nor will it set $1
> 
> when
> 
> > >   # sourcing a script. That is why this has to look so ugly.
> > > 
> > > - sh -c ". buildtools/environment-setup* >
> 
> preparing_build_system.log
> 
> > &&
> > 
> > > cd $target_sdk_dir/`dirname ${oe_init_build_env_path}` && set
> > > $target_sdk_dir && . $target_sdk_dir/${oe_init_build_env_path}
> > > $target_sdk_dir >> preparing_build_system.log && bitbake ${SDK_TARGETS}
> > > >>
> > > preparing_build_system.log" || { echo "SDK preparation failed: see
> > > `pwd`/preparing_build_system.log" ; exit 1 ; } +  sh -c "cd
> > > $target_sdk_dir/`dirname ${oe_init_build_env_path}` && set
> > > $target_sdk_dir
> > > && . $target_sdk_dir/${oe_init_build_env_path} $target_sdk_dir >>
> > > preparing_build_system.log && bitbake ${SDK_TARGETS} >>
> > > preparing_build_system.log" || { echo "SDK preparation failed: see
> > > `pwd`/preparing_build_system.log" ; exit 1 ; } fi
> > > 
> > >   echo done
> > >  
> > >  }
> > > 
> > > @@ -249

[OE-core] [PATCH] oeqa/decorators: Fixed a problem with tests having the same names.

[Lucian Musat]

When two or more tests had the same name but different classes then
the decorator log whould have the output all wrong. This was because
a comparison which was made only between method names but now it
compares classes too.

Bug #8029

Signed-off-by: Lucian Musat 
---
 meta/lib/oeqa/utils/decorators.py | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/meta/lib/oeqa/utils/decorators.py 
b/meta/lib/oeqa/utils/decorators.py
index b9fc76c..ff84541 100644
--- a/meta/lib/oeqa/utils/decorators.py
+++ b/meta/lib/oeqa/utils/decorators.py
@@ -116,13 +116,14 @@ def LogResults(original_class):
 orig_method(self, result, *args, **kws)
 passed = True
 testMethod = getattr(self, self._testMethodName)
-
 #if test case is decorated then use it's number, else use it's name
 try:
 test_case = testMethod.test_case
 except AttributeError:
 test_case = self._testMethodName
 
+class_name = str(testMethod.im_class).split("'")[1]
+
 #create custom logging level for filtering.
 custom_log_level = 100
 logging.addLevelName(custom_log_level, 'RESULTS')
@@ -143,18 +144,19 @@ def LogResults(original_class):
 local_log = logging.getLogger(caller)
 
 #check status of tests and record it
+
 for (name, msg) in result.errors:
-if self._testMethodName == str(name).split(' ')[0]:
+if (self._testMethodName == str(name).split(' ')[0]) and 
(class_name in str(name).split(' ')[1]):
 local_log.results("Testcase "+str(test_case)+": ERROR")
 local_log.results("Testcase "+str(test_case)+":\n"+msg)
 passed = False
 for (name, msg) in result.failures:
-if self._testMethodName == str(name).split(' ')[0]:
+if (self._testMethodName == str(name).split(' ')[0]) and 
(class_name in str(name).split(' ')[1]):
 local_log.results("Testcase "+str(test_case)+": FAILED")
 local_log.results("Testcase "+str(test_case)+":\n"+msg)
 passed = False
 for (name, msg) in result.skipped:
-if self._testMethodName == str(name).split(' ')[0]:
+if (self._testMethodName == str(name).split(' ')[0]) and 
(class_name in str(name).split(' ')[1]):
 local_log.results("Testcase "+str(test_case)+": SKIPPED")
 passed = False
 if passed:
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] scripts: Create interactive menu for mkefidisk script

[Bottazzini, Bruno]

On Fri, 2015-09-04 at 10:32 -0300, Bottazzini, Bruno wrote:
> On Thu, 2015-09-03 at 16:36 -0700, Saul Wold wrote:
> > On 09/01/2015 12:22 PM, Bruno Bottazzini wrote:
> > > If it is passed only the image parameter, it will show some interactive
> > > options to help to conclude the script.
> > >
> > > With this patch it will detect devices available in the machine, asking
> > > to choose what it is wanted to be flashed.
> > >
> > > it will suggest the target device. If it is a SD card the suggestion
> > > is /dev/mmcblk0. If it is a pendrive it will suggest to use /dev/sda.
> > >
> > 
> > I am little concerned by this patch since it allows the root disk to be 
> > selected, even if someone can type it on the command line, but offering 
> > it in list would make someone believe that it was OK.
> 
> You are totally right. 
> 
> However, the script already warn and handles this kind of situation. 
> Also, this gives free will to the user. I don't see this as problem but
> something, besides as you have told the user may pass it as argument

Sorry correcting: s/I don't see this as problem but something/I don't
see this as problem but as feature/

> too. Maybe we can change the header message telling "all detect storage"
> or something like this?
> 
> I was wondering if the user wants to flash a H.D. when running a live CD
> and then maybe the root may be a right choice.
> 
> Since I have started using this patch, it got really faster when it
> comes flashing the device (I don't have to remember parameters every
> time). I think this will be a really good new feature for this script.
> 
> > 
> > 
> > > Signed-off-by: Bruno Bottazzini 
> > > ---
> > >   scripts/contrib/mkefidisk.sh | 60 
> > > 
> > >   1 file changed, 55 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
> > > index 55f72b0..7628de7 100755
> > > --- a/scripts/contrib/mkefidisk.sh
> > > +++ b/scripts/contrib/mkefidisk.sh
> > > @@ -152,8 +152,52 @@ unmount() {
> > >   # Parse and validate arguments
> > >   #
> > >   if [ $# -lt 3 ] || [ $# -gt 4 ]; then
> > > - usage
> > > - exit 1
> > > +if [ $# -eq 1 ]; then
> > > +AVAILABLE_DISK=`fdisk -l | grep "Disk /" | cut -f 1 -d ':' | cut 
> > > -f 2 -d ' '`
> > > +if [ -z "$AVAILABLE_DISK" ]; then
> > > +die "Starting mkefidisk.sh as root is required"
> > > +fi
> > > +echo "Available disks are"
> > > +X=0
> > > +for line in `echo $AVAILABLE_DISK`; do
> > > +info "$X - $line"
> > > +X=`expr $X + 1`
> > > +done
> > > +read -p "Choose flashable device number: " DISK_NUMBER
> > > +X=0
> > > +for line in `echo $AVAILABLE_DISK`; do
> > > +if [ $DISK_NUMBER -eq $X ]; then
> > > +DISK_TO_BE_FLASHED=$line
> > > +break
> > > +else
> > > +X=`expr $X + 1`
> > > +fi
> > > +done
> > > +if [ -z "$DISK_TO_BE_FLASHED" ]; then
> > > +die "Option \"$DISK_NUMBER\" is invalid. Choose a valid 
> > > option"
> > > +else
> > > +if [ -z `echo $DISK_TO_BE_FLASHED | grep "mmc"` ]; then
> > > +TARGET_TO_BE_BOOT="/dev/sda"
> > > +else
> > > +TARGET_TO_BE_BOOT="/dev/mmcblk0"
> > > +fi
> > > +fi
> > > +echo ""
> > > +echo "Choose a name of the device that will be boot from"
> > > +echo -n "Recommended name is: "
> > > +info "$TARGET_TO_BE_BOOT\n"
> > The \n usage is probably wrong here.
> > 
> > > +read -p "Is target device okay? [y/N]: " RESPONSE
> > > +if [ "$RESPONSE" != "y" ]; then
> > > +read -p "Choose target device name: " TARGET_TO_BE_BOOT
> > > +fi
> > > +echo ""
> > > +if [ -z "$TARGET_TO_BE_BOOT" ]; then
> > > +die "Error: choose a valid target name"
> > > +fi
> > > +else
> > > +usage
> > > + exit 1
> > > +fi
> > >   fi
> > >
> > >   if [ "$1" = "-v" ]; then
> > > @@ -162,9 +206,15 @@ if [ "$1" = "-v" ]; then
> > >   shift
> > >   fi
> > >
> > > -DEVICE=$1
> > > -HDDIMG=$2
> > > -TARGET_DEVICE=$3
> > > +if [ -z "$AVAILABLE_DISK" ]; then
> > > +DEVICE=$1
> > > +HDDIMG=$2
> > > +TARGET_DEVICE=$3
> > > +else
> > > +DEVICE=$DISK_TO_BE_FLASHED
> > > +HDDIMG=$1
> > > +TARGET_DEVICE=$TARGET_TO_BE_BOOT
> > > +fi
> > >
> > >   LINK=$(readlink $DEVICE)
> > >   if [ $? -eq 0 ]; then
> > >
> 
> 


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] oeqa/decorators: Fixed a problem with tests having the same names.

[Paul Eggleton]

Hi Lucian,

On Friday 04 September 2015 16:33:07 Lucian Musat wrote:
> When two or more tests had the same name but different classes then
> the decorator log whould have the output all wrong. This was because
> a comparison which was made only between method names but now it
> compares classes too.
> 
> Bug #8029

The correct way to reference a Yocto Project Bugzilla entry that's fixed by a 
bug is [YOCTO #] i.e. here you would use [YOCTO #8029].

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

Re: [OE-core] [PATCH 04/12] gnome-icon-theme: remove the recipe

[Burton, Ross]

On 4 September 2015 at 13:12, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> I just did some tests and indeed pcmanfm looks bad when there is no icon
> theme at all, or when there is gnome-icon-theme, but looks ok with adwaita.
> So it needs a soft dependency on that, and gnome-icon-theme can still be
> dropped. If we find any other app that needs icons, then adwaita is the
> provider (which reminds me, I need to put the same dependency into epiphany
> recipe).
>

Excellent, thanks.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] scripts: Create interactive menu for mkefidisk script

[Bottazzini, Bruno]

On Thu, 2015-09-03 at 16:36 -0700, Saul Wold wrote:
> On 09/01/2015 12:22 PM, Bruno Bottazzini wrote:
> > If it is passed only the image parameter, it will show some interactive
> > options to help to conclude the script.
> >
> > With this patch it will detect devices available in the machine, asking
> > to choose what it is wanted to be flashed.
> >
> > it will suggest the target device. If it is a SD card the suggestion
> > is /dev/mmcblk0. If it is a pendrive it will suggest to use /dev/sda.
> >
> 
> I am little concerned by this patch since it allows the root disk to be 
> selected, even if someone can type it on the command line, but offering 
> it in list would make someone believe that it was OK.

You are totally right. 

However, the script already warn and handles this kind of situation. 
Also, this gives free will to the user. I don't see this as problem but
something, besides as you have told the user may pass it as argument
too. Maybe we can change the header message telling "all detect storage"
or something like this?

I was wondering if the user wants to flash a H.D. when running a live CD
and then maybe the root may be a right choice.

Since I have started using this patch, it got really faster when it
comes flashing the device (I don't have to remember parameters every
time). I think this will be a really good new feature for this script.

> 
> 
> > Signed-off-by: Bruno Bottazzini 
> > ---
> >   scripts/contrib/mkefidisk.sh | 60 
> > 
> >   1 file changed, 55 insertions(+), 5 deletions(-)
> >
> > diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
> > index 55f72b0..7628de7 100755
> > --- a/scripts/contrib/mkefidisk.sh
> > +++ b/scripts/contrib/mkefidisk.sh
> > @@ -152,8 +152,52 @@ unmount() {
> >   # Parse and validate arguments
> >   #
> >   if [ $# -lt 3 ] || [ $# -gt 4 ]; then
> > -   usage
> > -   exit 1
> > +if [ $# -eq 1 ]; then
> > +AVAILABLE_DISK=`fdisk -l | grep "Disk /" | cut -f 1 -d ':' | cut 
> > -f 2 -d ' '`
> > +if [ -z "$AVAILABLE_DISK" ]; then
> > +die "Starting mkefidisk.sh as root is required"
> > +fi
> > +echo "Available disks are"
> > +X=0
> > +for line in `echo $AVAILABLE_DISK`; do
> > +info "$X - $line"
> > +X=`expr $X + 1`
> > +done
> > +read -p "Choose flashable device number: " DISK_NUMBER
> > +X=0
> > +for line in `echo $AVAILABLE_DISK`; do
> > +if [ $DISK_NUMBER -eq $X ]; then
> > +DISK_TO_BE_FLASHED=$line
> > +break
> > +else
> > +X=`expr $X + 1`
> > +fi
> > +done
> > +if [ -z "$DISK_TO_BE_FLASHED" ]; then
> > +die "Option \"$DISK_NUMBER\" is invalid. Choose a valid option"
> > +else
> > +if [ -z `echo $DISK_TO_BE_FLASHED | grep "mmc"` ]; then
> > +TARGET_TO_BE_BOOT="/dev/sda"
> > +else
> > +TARGET_TO_BE_BOOT="/dev/mmcblk0"
> > +fi
> > +fi
> > +echo ""
> > +echo "Choose a name of the device that will be boot from"
> > +echo -n "Recommended name is: "
> > +info "$TARGET_TO_BE_BOOT\n"
> The \n usage is probably wrong here.
> 
> > +read -p "Is target device okay? [y/N]: " RESPONSE
> > +if [ "$RESPONSE" != "y" ]; then
> > +read -p "Choose target device name: " TARGET_TO_BE_BOOT
> > +fi
> > +echo ""
> > +if [ -z "$TARGET_TO_BE_BOOT" ]; then
> > +die "Error: choose a valid target name"
> > +fi
> > +else
> > +usage
> > +   exit 1
> > +fi
> >   fi
> >
> >   if [ "$1" = "-v" ]; then
> > @@ -162,9 +206,15 @@ if [ "$1" = "-v" ]; then
> > shift
> >   fi
> >
> > -DEVICE=$1
> > -HDDIMG=$2
> > -TARGET_DEVICE=$3
> > +if [ -z "$AVAILABLE_DISK" ]; then
> > +DEVICE=$1
> > +HDDIMG=$2
> > +TARGET_DEVICE=$3
> > +else
> > +DEVICE=$DISK_TO_BE_FLASHED
> > +HDDIMG=$1
> > +TARGET_DEVICE=$TARGET_TO_BE_BOOT
> > +fi
> >
> >   LINK=$(readlink $DEVICE)
> >   if [ $? -eq 0 ]; then
> >


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] pseudo_1.7.2.bb: New version of pseudo

[Burton, Ross]

On 4 September 2015 at 04:28, Peter Seebach 
wrote:

> +SRC_URI = " \
> +http://downloads.yoctoproject.org/releases/pseudo
> /${BPN}-${PV}.tar.bz2 \
>

ERROR: Fetcher failure: Fetch command failed with exit code 8, output:
http://downloads.yoctoproject.org/releases/pseudo/pseudo-1.7.2.tar.bz2:
2015-09-04 14:11:21 ERROR 404: Not Found.

There isn't a 1.7.2 tarball uploaded yet.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 10/12] uclibc: update PV to 0.9.33.2 to match latest upstream release

[Alexander Kanavin]

On 09/03/2015 11:14 PM, Khem Raj wrote:

-PV = "0.9.33+git${SRCPV}"
+PV = "0.9.33.2+git${SRCPV}"


technically its not right since we are not on 0.9.33 branch at all.
We could use 0.9.33+0.9.34+git${SRCPV}


You're right. Nevermind then, uclibc is anyway one of those projects 
that can't be bothered to make a release. So there is no sensible 
upstream version check to perform.


Alex

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] qemu: backport patches to fix CVE issues

[Sona Sarmadi]

Hi guys,

These qemu/xen patches have been backported to fido branch: 
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/qemu/qemu_2.2.0.bb?h=fido

but not dizzy:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/qemu/qemu_2.1.0.bb?h=dizzy

Do you know why? 
I backported these to my local dizzy branch and build qemu 2.1, all patches 
apply. I guess 
these patches are applicable for dizzy branch as well. Any comments on this?

Armin, I have patches for dizzy, I can send them if you think that they should 
be backported to dizzy as well.

//Sona


> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of Kai Kang
> Sent: den 18 juni 2015 11:03
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 1/1] qemu: backport patches to fix CVE issues
> 
> Backport patches to fix CVE-2015-4103, CVE-2015-4104, CVE-2015-4105 and
> CVE-2015-4106. These patches are from debian, but they are originally
> from:
> 
> http://git.qemu.org/?p=qemu.git;a=shortlog;h=c25bbf1
> 
> Signed-off-by: Kai Kang 
> ---
>  ...f-modified-PCI-CFG-contents-CVE-2015-4103.patch | 140 +++
>  ...o-control-MSI-mask-register-CVE-2015-4104.patch | 194
> +++
>  ...-MSI-X-limit-error-messages-CVE-2015-4105.patch |  90 +++
>  ...s-through-of-enable-bit-mod-CVE-2015-4106.patch |  76 ++
>  ...date-PM-capability-emu_mask-CVE-2015-4106.patch |  86 +++
>  ...rectly-handle-PM-status-bit-CVE-2015-4106.patch |  38 +++
>  ...ulation-of-throughable-mask-CVE-2015-4106.patch | 265
> +
>  ...e-capability-bits-read-only-CVE-2015-4106.patch |  38 +++
>  ...-in-PCI-config-space-fields-CVE-2015-4106.patch |  94 
>  ...ig-space-field-descriptions-CVE-2015-4106.patch |  77 ++
>  ...e-fields-should-be-readonly-CVE-2015-4106.patch | 137 +++
>  meta/recipes-devtools/qemu/qemu_2.3.0.bb   |  13 +-
>  12 files changed, 1247 insertions(+), 1 deletion(-)
>  create mode 100644 meta/recipes-devtools/qemu/qemu/01-xen-properly-
> gate-host-writes-of-modified-PCI-CFG-contents-CVE-2015-4103.patch
>  create mode 100644 meta/recipes-devtools/qemu/qemu/02-xen-dont-
> allow-guest-to-control-MSI-mask-register-CVE-2015-4104.patch
>  create mode 100644 meta/recipes-devtools/qemu/qemu/03-xen-MSI-X-
> limit-error-messages-CVE-2015-4105.patch
>  create mode 100644 meta/recipes-devtools/qemu/qemu/04-xen-MSI-dont-
> open-code-pass-through-of-enable-bit-mod-CVE-2015-4106.patch
>  create mode 100644 meta/recipes-devtools/qemu/qemu/05-xen-pt-
> consolidate-PM-capability-emu_mask-CVE-2015-4106.patch
>  create mode 100644 meta/recipes-devtools/qemu/qemu/06-xen-pt-
> correctly-handle-PM-status-bit-CVE-2015-4106.patch
>  create mode 100644 meta/recipes-devtools/qemu/qemu/07-xen-pt-split-
> out-calculation-of-throughable-mask-CVE-2015-4106.patch
>  create mode 100644 meta/recipes-devtools/qemu/qemu/08-xen-pt-mark-
> all-PCIe-capability-bits-read-only-CVE-2015-4106.patch
>  create mode 100644 meta/recipes-devtools/qemu/qemu/09-xen-pt-mark-
> reserved-bits-in-PCI-config-space-fields-CVE-2015-4106.patch
>  create mode 100644 meta/recipes-devtools/qemu/qemu/10-xen-pt-add-a-
> few-PCI-config-space-field-descriptions-CVE-2015-4106.patch
>  create mode 100644 meta/recipes-devtools/qemu/qemu/11-xen-pt-
> unknown-PCI-config-space-fields-should-be-readonly-CVE-2015-4106.patch
> 
> diff --git a/meta/recipes-devtools/qemu/qemu/01-xen-properly-gate-host-
> writes-of-modified-PCI-CFG-contents-CVE-2015-4103.patch b/meta/recipes-
> devtools/qemu/qemu/01-xen-properly-gate-host-writes-of-modified-PCI-
> CFG-contents-CVE-2015-4103.patch
> new file mode 100644
> index 000..42a4960
> --- /dev/null
> +++ b/meta/recipes-devtools/qemu/qemu/01-xen-properly-gate-host-
> writes-of-modified-PCI-CFG-contents-CVE-2015-4103.patch
> @@ -0,0 +1,140 @@
> +Upstream-Status: Backport
> +
> +Signed-off-by: Kai Kang 
> +
> +From 5c83b2f5b4b956e91dd6e5711f14df7ab800aefb Mon Sep 17 00:00:00
> 2001
> +From: Jan Beulich 
> +Date: Tue, 2 Jun 2015 15:07:00 +
> +Subject: xen: properly gate host writes of modified PCI CFG contents
> +Bug-Debian: http://bugs.debian.org/787547
> +
> +The old logic didn't work as intended when an access spanned multiple
> +fields (for example a 32-bit access to the location of the MSI Message
> +Data field with the high 16 bits not being covered by any known field).
> +Remove it and derive which fields not to write to from the accessed
> +fields' emulation masks: When they're all ones, there's no point in
> +doing any host write.
> +
> +This fixes a secondary issue at once: We obviously shouldn't make any
> +host write attempt when already the host read failed.
> +
> +This is XSA-128.
> +
> +Signed-off-by: Jan Beulich 
> +Reviewed-by: Stefano Stabellini 
> +---
> + hw/xen/xen_pt.c | 25 +
> + hw/xen/xen_pt.h |  2 --
> +

Re: [OE-core] [RFC][dizzy][fido][master][PATCH 1/3] rootfs.py: Allow to override postinst-intercepts location

[Martin Jansa]

On Fri, Sep 04, 2015 at 02:22:26PM +0200, Martin Jansa wrote:
> * useful when we need to overlay/extend intercept scripts from oe-core

2/3 and 3/3 could be a bit dangerous or controversial (main reason why
this was sent as RFC), but this one is really useful for us to apply
these fixes in advance (and without backporting them all to fido and
dizzy) - so if you agree please merge 1/3 to master, fido and dizzy.

> Signed-off-by: Martin Jansa 
> ---
>  meta/lib/oe/rootfs.py | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
> index c29843b..76950ec 100644
> --- a/meta/lib/oe/rootfs.py
> +++ b/meta/lib/oe/rootfs.py
> @@ -164,6 +164,9 @@ class Rootfs(object):
>  pre_process_cmds = self.d.getVar("ROOTFS_PREPROCESS_COMMAND", True)
>  post_process_cmds = self.d.getVar("ROOTFS_POSTPROCESS_COMMAND", True)
>  
> +postinst_intercepts_dir = self.d.getVar("POSTINST_INTERCEPTS_DIR", 
> True)
> +if not postinst_intercepts_dir:
> +postinst_intercepts_dir = 
> self.d.expand("${COREBASE}/scripts/postinst-intercepts")
>  intercepts_dir = os.path.join(self.d.getVar('WORKDIR', True),
>"intercept_scripts")
>  
> @@ -173,8 +176,7 @@ class Rootfs(object):
>  
>  bb.utils.mkdirhier(self.deploy_dir_image)
>  
> -
> shutil.copytree(self.d.expand("${COREBASE}/scripts/postinst-intercepts"),
> -intercepts_dir)
> +shutil.copytree(postinst_intercepts_dir, intercepts_dir)
>  
>  
> shutil.copy(self.d.expand("${COREBASE}/meta/files/deploydir_readme.txt"),
>  self.deploy_dir_image +
> -- 
> 2.5.0
> 

-- 
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] [PATCH] report-error: send only last 5242000 characters in error logs

[Martin Jansa]

On Fri, Sep 04, 2015 at 02:22:09PM +0200, Martin Jansa wrote:
> * otherwise whole build report submission is rejected because it's too big

Verified in last bitbake world build:
http://errors.yoctoproject.org/Errors/Build/8516/
until now they were rejected because webkit-efl log.do_compile is too
big, now it's uploades in shortened form:
http://errors.yoctoproject.org/Errors/Details/16393/

> Signed-off-by: Martin Jansa 
> ---
>  meta/classes/report-error.bbclass | 15 ---
>  1 file changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/classes/report-error.bbclass 
> b/meta/classes/report-error.bbclass
> index cabd98c..040c29e 100644
> --- a/meta/classes/report-error.bbclass
> +++ b/meta/classes/report-error.bbclass
> @@ -54,13 +54,22 @@ python errorreport_handler () {
>  if log:
>  try:
>  logFile = open(log, 'r')
> -taskdata['log'] = logFile.read().decode('utf-8')
> +logdata = logFile.read().decode('utf-8')
>  logFile.close()
>  except:
> -taskdata['log'] = "Unable to read log file"
> +logdata = "Unable to read log file"
>  
>  else:
> -taskdata['log'] = "No Log"
> +logdata = "No Log"
> +
> +# server will refuse failures longer than param specified in 
> project.settings.py
> +# MAX_UPLOAD_SIZE = "5242880"
> +# use lower value, because 650 chars can be spent in task, 
> package, version
> +max_logdata_size = 5242000
> +# upload last max_logdata_size characters
> +if len(logdata) > max_logdata_size:
> +logdata = "..." + logdata[-max_logdata_size:]
> +taskdata['log'] = logdata
>  lock = bb.utils.lockfile(datafile + '.lock')
>  jsondata = json.loads(errorreport_getdata(e))
>  jsondata['failures'].append(taskdata)
> -- 
> 2.5.0
> 

-- 
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] [RFC][PATCH 3/3] fontcache: allow to pass extra parameters and environment to fc-cache

[Martin Jansa]

* this can be useful for passing extra parameters, pass
  -v by default to see what's going on in do_rootfs
* we need to use this for extra parameter we implemented
  in fontconfig:
  --ignore-mtime always use cache file regardless of font directory mtime
  because the checksum of fontcache generated in do_rootfs
  doesn't match with /usr/share/fonts directory as seen on
  target device causing fontconfig to re-create the cache
  when fontconfig is used for first time or worse create
  new cache in every user's home directory when /usr/
  filesystem is read only and cache cannot be updated.

  Running FC_DEBUG=16 fc-cache -v on such device shows:
  FcCacheTimeValid dir "/usr/share/fonts" cache checksum 1441207803 dir 
checksum 1441206149
* my guess is that the checksum is different, because pseudo
  (which is unloaded when running qemuwrapper) or because some
  influence of running the rootfs under qemu.

Signed-off-by: Martin Jansa 
---
 meta/classes/fontcache.bbclass| 19 +++
 scripts/postinst-intercepts/update_font_cache |  4 ++--
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/meta/classes/fontcache.bbclass b/meta/classes/fontcache.bbclass
index d122387..1dd1418 100644
--- a/meta/classes/fontcache.bbclass
+++ b/meta/classes/fontcache.bbclass
@@ -9,12 +9,23 @@ inherit qemu
 FONT_PACKAGES ??= "${PN}"
 FONT_EXTRA_RDEPENDS ?= "fontconfig-utils"
 FONTCONFIG_CACHE_DIR ?= "${localstatedir}/cache/fontconfig"
+FONTCONFIG_CACHE_PARAMS ?= "-v"
+# You can change this to e.g. FC_DEBUG=16 to debug fc-cache issues,
+# something has to be set, because qemuwrapper is using this variable after -E
+# multiple variables aren't allowed because for qemu they are separated
+# by comma and in -n "$D" case they should be separated by space
+FONTCONFIG_CACHE_ENV ?= "FC_DEBUG=1"
 fontcache_common() {
-if [ "x$D" != "x" ] ; then
-   $INTERCEPT_DIR/postinst_intercept update_font_cache ${PKG} 
mlprefix=${MLPREFIX} bindir=${bindir} \
-   libdir=${libdir} base_libdir=${base_libdir} 
fontconfigcachedir=${FONTCONFIG_CACHE_DIR}
+if [ -n "$D" ] ; then
+   $INTERCEPT_DIR/postinst_intercept update_font_cache ${PKG} 
mlprefix=${MLPREFIX} \
+   'bindir="${bindir}'" \
+   'libdir="${libdir}'" \
+   'base_libdir="${base_libdir}'" \
+   'fontconfigcachedir="${FONTCONFIG_CACHE_DIR}'" \
+   'fontconfigcacheparams="${FONTCONFIG_CACHE_PARAMS}'" \
+   'fontconfigcacheenv="${FONTCONFIG_CACHE_ENV}'"
 else
-   fc-cache
+   ${FONTCONFIG_CACHE_ENV} fc-cache ${FONTCONFIG_CACHE_PARAMS}
 fi
 }
 
diff --git a/scripts/postinst-intercepts/update_font_cache 
b/scripts/postinst-intercepts/update_font_cache
index c8c6018..0deab3c 100644
--- a/scripts/postinst-intercepts/update_font_cache
+++ b/scripts/postinst-intercepts/update_font_cache
@@ -1,5 +1,5 @@
 #!/bin/sh
 
-PSEUDO_UNLOAD=1 qemuwrapper -L $D -E 
LD_LIBRARY_PATH=$D/${libdir}:$D/${base_libdir}\
-   $D${bindir}/fc-cache --sysroot=$D
+PSEUDO_UNLOAD=1 qemuwrapper -L $D -E 
LD_LIBRARY_PATH=$D/${libdir}:$D/${base_libdir} \
+   -E ${fontconfigcacheenv} 
$D${bindir}/fc-cache --sysroot=$D ${fontconfigcacheparams}
 chown -R root:root $D${fontconfigcachedir}
-- 
2.5.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [RFC][PATCH 2/3] postinst_intercept: allow to pass variables with spaces

[Martin Jansa]

* trying to pass foo="a b" through postinst_intercept ends
  with the actual script header to containing:
  b
  foo=a
  which fails because "b" command doesn't exist.

Signed-off-by: Martin Jansa 
---
 scripts/postinst-intercepts/postinst_intercept | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/postinst-intercepts/postinst_intercept 
b/scripts/postinst-intercepts/postinst_intercept
index a257198..b18e806 100755
--- a/scripts/postinst-intercepts/postinst_intercept
+++ b/scripts/postinst-intercepts/postinst_intercept
@@ -48,7 +48,7 @@ if [ -n "$pkgs_line" ]; then
sed -i -e "s/##PKGS:.*/\0${package_name} /" $intercept_script
fi
 else
-   for var in $@; do
+   for var in "$@"; do
sed -i -e "\%^#\!/bin/.*sh%a $var" $intercept_script
done
echo "##PKGS: ${package_name} " >> $intercept_script
-- 
2.5.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [RFC][PATCH 1/3] rootfs.py: Allow to override postinst-intercepts location

[Martin Jansa]

* useful when we need to overlay/extend intercept scripts from oe-core

Signed-off-by: Martin Jansa 
---
 meta/lib/oe/rootfs.py | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index c29843b..76950ec 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -164,6 +164,9 @@ class Rootfs(object):
 pre_process_cmds = self.d.getVar("ROOTFS_PREPROCESS_COMMAND", True)
 post_process_cmds = self.d.getVar("ROOTFS_POSTPROCESS_COMMAND", True)
 
+postinst_intercepts_dir = self.d.getVar("POSTINST_INTERCEPTS_DIR", 
True)
+if not postinst_intercepts_dir:
+postinst_intercepts_dir = 
self.d.expand("${COREBASE}/scripts/postinst-intercepts")
 intercepts_dir = os.path.join(self.d.getVar('WORKDIR', True),
   "intercept_scripts")
 
@@ -173,8 +176,7 @@ class Rootfs(object):
 
 bb.utils.mkdirhier(self.deploy_dir_image)
 
-
shutil.copytree(self.d.expand("${COREBASE}/scripts/postinst-intercepts"),
-intercepts_dir)
+shutil.copytree(postinst_intercepts_dir, intercepts_dir)
 
 
shutil.copy(self.d.expand("${COREBASE}/meta/files/deploydir_readme.txt"),
 self.deploy_dir_image +
-- 
2.5.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] report-error: send only last 5242000 characters in error logs

[Martin Jansa]

* otherwise whole build report submission is rejected because it's too big

Signed-off-by: Martin Jansa 
---
 meta/classes/report-error.bbclass | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/meta/classes/report-error.bbclass 
b/meta/classes/report-error.bbclass
index cabd98c..040c29e 100644
--- a/meta/classes/report-error.bbclass
+++ b/meta/classes/report-error.bbclass
@@ -54,13 +54,22 @@ python errorreport_handler () {
 if log:
 try:
 logFile = open(log, 'r')
-taskdata['log'] = logFile.read().decode('utf-8')
+logdata = logFile.read().decode('utf-8')
 logFile.close()
 except:
-taskdata['log'] = "Unable to read log file"
+logdata = "Unable to read log file"
 
 else:
-taskdata['log'] = "No Log"
+logdata = "No Log"
+
+# server will refuse failures longer than param specified in 
project.settings.py
+# MAX_UPLOAD_SIZE = "5242880"
+# use lower value, because 650 chars can be spent in task, 
package, version
+max_logdata_size = 5242000
+# upload last max_logdata_size characters
+if len(logdata) > max_logdata_size:
+logdata = "..." + logdata[-max_logdata_size:]
+taskdata['log'] = logdata
 lock = bb.utils.lockfile(datafile + '.lock')
 jsondata = json.loads(errorreport_getdata(e))
 jsondata['failures'].append(taskdata)
-- 
2.5.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] pcmanfm: add an icon theme dependency

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-sato/pcmanfm/pcmanfm_1.2.3.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-sato/pcmanfm/pcmanfm_1.2.3.bb 
b/meta/recipes-sato/pcmanfm/pcmanfm_1.2.3.bb
index 6ef0347..4467303 100644
--- a/meta/recipes-sato/pcmanfm/pcmanfm_1.2.3.bb
+++ b/meta/recipes-sato/pcmanfm/pcmanfm_1.2.3.bb
@@ -36,3 +36,5 @@ do_install_append () {
 }
 
 FILES_${PN} += "${libdir}/pcmanfm"
+
+RRECOMMENDS_${PN} += "adwaita-icon-theme"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] pcmanfm: add an icon theme dependency

[Alexander Kanavin]

On 09/04/2015 03:16 PM, Alexander Kanavin wrote:

  FILES_${PN} += "${libdir}/pcmanfm"
+
+RRECOMMENDS_${PN} += "gnome-icon-theme"



Please discard, forgot to revert to correct theme here :)


Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] pcmanfm: add an icon theme dependency

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-sato/pcmanfm/pcmanfm_1.2.3.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-sato/pcmanfm/pcmanfm_1.2.3.bb 
b/meta/recipes-sato/pcmanfm/pcmanfm_1.2.3.bb
index 6ef0347..f41a8c6 100644
--- a/meta/recipes-sato/pcmanfm/pcmanfm_1.2.3.bb
+++ b/meta/recipes-sato/pcmanfm/pcmanfm_1.2.3.bb
@@ -36,3 +36,5 @@ do_install_append () {
 }
 
 FILES_${PN} += "${libdir}/pcmanfm"
+
+RRECOMMENDS_${PN} += "gnome-icon-theme"
-- 
2.1.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 04/12] gnome-icon-theme: remove the recipe

[Alexander Kanavin]

On 09/04/2015 12:28 AM, Khem Raj wrote:


It is not used by anything in oe-core and will be moved to meta-gnome



OK, please send the patch for meta-gnome as well. So we can merge them in more 
or less in sync


I will send these patches only when oe-core is updated. Recipe moving is 
always controversial, and I don't want to cause confusion when the 
change is accepted by one side and rejected by the other.


Alex

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 04/12] gnome-icon-theme: remove the recipe

[Alexander Kanavin]

On 09/04/2015 02:56 PM, Jussi Kukkonen wrote:


I don't think it's likely but there is a chance that gnome-icon-theme
contained icons that Adwaita does not provide (comparing them all turned
out to be tricky). So double-checking how pcmanfm looks with Adwaita
might make sense in any case.


I just did some tests and indeed pcmanfm looks bad when there is no icon 
theme at all, or when there is gnome-icon-theme, but looks ok with 
adwaita. So it needs a soft dependency on that, and gnome-icon-theme can 
still be dropped. If we find any other app that needs icons, then 
adwaita is the provider (which reminds me, I need to put the same 
dependency into epiphany recipe).


Alex

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 04/12] gnome-icon-theme: remove the recipe

[Jussi Kukkonen]

On 3 September 2015 at 19:08, Burton, Ross  wrote:

>
> On 3 September 2015 at 16:34, Alexander Kanavin <
> alexander.kana...@linux.intel.com> wrote:
>
>> It is not used by anything in oe-core and will be moved to meta-gnome
>>
>
> I've a feeling that there are some apps in core-image-sato that actually
> like to have gnome-icon-theme installed (specifically I'm thinking
> pcmanfm).  We should probably check that they work correctly without this
> installed (or more likely, show more icons when it is installed) before
> removing it.
>

Sounds like that's worth checking but I don't think that's related to
Alexanders change: Even before Adwaita applications were supposed
RRECOMMEND gnome-icon-theme if they needed it (not saying it's necessarily
a good idea but that's how it used to work and still works). So if pcmanfm
doesn't do that, it may be missing icons already and did so before adwaita
as well (assuming nothing else in the image pulled in the icon theme).

I don't think it's likely but there is a chance that gnome-icon-theme
contained icons that Adwaita does not provide (comparing them all turned
out to be tricky). So double-checking how pcmanfm looks with Adwaita might
make sense in any case.

Jussi
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/9] systemd: remove hard-coded paths in FILES entries

[Joshua Lock]

On Thu, 2015-09-03 at 12:10 -0500, Mark Hatle wrote:
> On 9/3/15 10:12 AM, Richard Purdie wrote:
> > On Thu, 2015-09-03 at 15:58 +0100, Joshua Lock wrote:
> > > Signed-off-by: Joshua Lock 
> > > ---
> > >  meta/recipes-core/systemd/systemd_219.bb | 10 +-
> > >  1 file changed, 5 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/meta/recipes-core/systemd/systemd_219.bb
> > > b/meta/recipes-core/systemd/systemd_219.bb
> > > index 4d32fd5..fbd86e8 100644
> > > --- a/meta/recipes-core/systemd/systemd_219.bb
> > > +++ b/meta/recipes-core/systemd/systemd_219.bb
> > > @@ -306,10 +306,10 @@ FILES_${PN} = " ${base_bindir}/* \
> > >  ${exec_prefix}/lib/sysctl.d \
> > >  ${exec_prefix}/lib/sysusers.d \
> > >  ${localstatedir} \
> > > -/lib/udev/rules.d/70-uaccess.rules \
> > > -/lib/udev/rules.d/71-seat.rules \
> > > -/lib/udev/rules.d/73-seat-late.rules \
> > > -/lib/udev/rules.d/99-systemd.rules \
> > > +${base_libdir}/udev/rules.d/70-uaccess.rules \
> > > +${base_libdir}/udev/rules.d/71-seat.rules \
> > > +${base_libdir}/udev/rules.d/73-seat-late.rules \
> > > +${base_libdir}/udev/rules.d/99-systemd.rules \
> > > "
> > >  
> > >  FILES_${PN}-dbg += "${rootlibdir}/.debug
> > > ${systemd_unitdir}/.debug ${systemd_unitdir}/*/.debug
> > > ${base_libdir}/security/.debug/"
> > > @@ -327,7 +327,7 @@ RRECOMMENDS_${PN} += "systemd-serialgetty
> > > systemd-vconsole-setup \
> > >  
> > >  PACKAGES =+ "udev-dbg udev udev-hwdb"
> > >  
> > > -FILES_udev-dbg += "/lib/udev/.debug"
> > > +FILES_udev-dbg += "${base_libdir}/udev/.debug"
> > 
> > From what I remember, this is intentional and this change likely
> > breaks
> > multilib. You don't want two sets of rules on a multilib system.
> 
> Correct.. it has to go into /lib or if everything is move to /usr,
> then /usr/lib.

I've prepared a v2 that changes this to nonarch_base_libdir but
systemd+multilib appears to be broken, see:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=8256

Regards,

Joshua 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH][dizzy] icu: CVE-2014-8146-CVE-2014-8147

[Sona Sarmadi]

CVE-2014-8146 icu: heap overflow via incorrect isolateCount
CVE-2014-8147 icu: integer truncation in the resolveImplicitLevels function

References:
[1] https://github.com/pedrib/PoC/raw/master/generic/i-c-u-fail.7z
[2] https://www.kb.cert.org/vuls/id/602540
[3] http://bugs.icu-project.org/trac/changeset/37080
[4] http://bugs.icu-project.org/trac/changeset/37162

Signed-off-by: Sona Sarmadi 
---
 .../icu/icu/icu-CVE-2014-8146-CVE-2014-8147.patch  | 49 ++
 meta/recipes-support/icu/icu_53.1.bb   |  1 +
 2 files changed, 50 insertions(+)
 create mode 100644 
meta/recipes-support/icu/icu/icu-CVE-2014-8146-CVE-2014-8147.patch

diff --git a/meta/recipes-support/icu/icu/icu-CVE-2014-8146-CVE-2014-8147.patch 
b/meta/recipes-support/icu/icu/icu-CVE-2014-8146-CVE-2014-8147.patch
new file mode 100644
index 000..2460357
--- /dev/null
+++ b/meta/recipes-support/icu/icu/icu-CVE-2014-8146-CVE-2014-8147.patch
@@ -0,0 +1,49 @@
+icu: CVE-2014-8146-CVE-2014-8147
+
+CVE-2014-8146 icu: heap overflow via incorrect isolateCount
+CVE-2014-8147 icu: integer truncation in the resolveImplicitLevels function
+
+References:
+[1] https://github.com/pedrib/PoC/raw/master/generic/i-c-u-fail.7z
+[2] https://www.kb.cert.org/vuls/id/602540
+[3] http://bugs.icu-project.org/trac/changeset/37080
+[4] http://bugs.icu-project.org/trac/changeset/37162
+
+Upstream-Status: Backport
+
+Signed-off-by: Sona Sarmadi 
+---
+diff -ruN a/common/ubidi.c b/common/ubidi.c
+--- a/common/ubidi.c   2014-10-03 18:11:20.0 +0200
 b/common/ubidi.c   2015-08-28 08:22:39.455906194 +0200
+@@ -2138,7 +2138,7 @@
+ /* The isolates[] entries contain enough information to
+resume the bidi algorithm in the same state as it was
+when it was interrupted by an isolate sequence. */
+-if(dirProps[start]==PDI) {
++if(dirProps[start]==PDI  && pBiDi->isolateCount >= 0) {
+ levState.startON=pBiDi->isolates[pBiDi->isolateCount].startON;
+ start1=pBiDi->isolates[pBiDi->isolateCount].start1;
+ stateImp=pBiDi->isolates[pBiDi->isolateCount].stateImp;
+diff -ruN a/common/ubidiimp.h b/common/ubidiimp.h
+--- a/common/ubidiimp.h2014-10-03 18:11:16.0 +0200
 b/common/ubidiimp.h2015-08-28 08:28:24.069163845 +0200
+@@ -1,7 +1,7 @@
+ /*
+ **
+ *
+-*   Copyright (C) 1999-2014, International Business Machines
++*   Copyright (C) 1999-2015, International Business Machines
+ *   Corporation and others.  All Rights Reserved.
+ *
+ **
+@@ -184,8 +184,8 @@
+ typedef struct Isolate {
+ int32_t startON;
+ int32_t start1;
++int32_t state;
+ int16_t stateImp;
+-int16_t state;
+ } Isolate;
+
+ typedef struct Run {
diff --git a/meta/recipes-support/icu/icu_53.1.bb 
b/meta/recipes-support/icu/icu_53.1.bb
index d93af68..2906e8f 100644
--- a/meta/recipes-support/icu/icu_53.1.bb
+++ b/meta/recipes-support/icu/icu_53.1.bb
@@ -11,6 +11,7 @@ ICU_PV = "${@icu_download_version(d)}"
 BASE_SRC_URI = 
"http://download.icu-project.org/files/icu4c/${PV}/icu4c-${ICU_PV}-src.tgz";
 SRC_URI = "${BASE_SRC_URI} \
file://icu-pkgdata-large-cmd.patch \
+   file://icu-CVE-2014-8146-CVE-2014-8147.patch \
   "
 
 SRC_URI_append_class-target = "\
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] distutils.bbclass: Handle python-backport modules

[Burton, Ross]

On 3 September 2015 at 23:01, Alejandro Hernandez <
alejandro.hernan...@linux.intel.com> wrote:

> +
> +
> +   if [ -e
> ${STAGING_LIBDIR}/${PYTHON_DIR}/site-packages/backports/__init__.py ]; then
> +   rm ${D}${PYTHON_SITEPACKAGES_DIR}/backports/__init__.py;
> +   rm ${D}${PYTHON_SITEPACKAGES_DIR}/backports/__init__.pyc;
> +   #FILES_${PN}_remove =
> "${PYTHON_SITEPACKAGES_DIR}/backports/__init__.pyc";
> +   fi
>  }
>

Two blank lines with whitespace at the beginning, bad indentation in the
body, and surely the commented out FILES_ can be removed.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] base-files: Fix LSB NG Cases.

[Li, Xin]

Hi, Mark,

Thanks a lot.

>>
>>> Subject: Re: [OE-core] [PATCH] base-files: Fix LSB NG Cases.
>>>
>>> On 9/1/15 4:13 PM, Richard Purdie wrote:
 On Thu, 2015-06-04 at 16:52 +0800, Li xin wrote:
> -/tset/LSB.fhs/var/tmp/tmp-tc.
>
> The LSB Core test requires the /var/tmp directory supports creation of 
> files.
> And the mount tmpfs on /var/volatile cause the /var/tmp directory
> can't be writable for non-root users.

 This change doesn't look correct to me, its a pretty fundamental
 change to the way the system operates and certainly needs more
 thought and justification than the few lines above.

 Surely if its a non-root users issue, the problem is permissions,
 not the tmpfs anyway?
>>>
>>> I agree.. How is /var/volatile mounted in your environment?
>>>
>>> /var/volatile should be mounted as a tmpfs with default root only 
>>> permissions.
>>> (basefiles: fstab)
>>>
>>> A directory, /var/volatile/tmp should be constructed (after volatile
>>> is mounted) with perms 01777.  (initscripts: populate-volatile.sh)
>>>
>>> /var/tmp should be a symbolic link to /var/volatile/tmp.
>>> (meta/files/fs-perms.txt)
>>>
>>> All of this will result in a /var/tmp that permits any user to write
>>> to it (as it should), but keep it in the volatile area.
>>>
>>> You should figure out what part of this is not working properly.  (If
>>> I had to guess it's the mount of the volatile and create of the tmp
>>> dir is not working for you -- or you have a system where the default
>>> mount rules / init scripts have been modified in some way.)
>>>
>>
>> On my system:
>>
>> root # cat /etc/fstab
>> # stock fstab - you probably want to override this with a machine
>> specific one
>>
>> /dev/root/auto   defaults
>1  1
>> proc /procproc   defaults
>0  0
>> devpts   /dev/pts devpts mode=0620,gid=5
>0  0
>> usbdevfs /proc/bus/usbusbdevfs   noauto
>0  0
>> tmpfs/run tmpfs
>mode=0755,nodev,nosuid,strictatime 0  0
>> tmpfs/var/volatiletmpfs  defaults
>0  0
>>
>> # uncomment this if your device has a SD/MMC/Transflash slot
>> #/dev/mmcblk0p1   /media/card  auto
>defaults,sync,noauto  0  0
>>
>> root #
>> root # ls /var/tmp -ld
>> lrwxrwxrwx 1 root root 12 Aug 24 09:24 /var/tmp -> volatile/tmp
>>
>> root # ls /var/tmp/ -ld
>> drwxr-xr-x 3 root root 60 Sep  1 08:11 /var/tmp/ root #
>
>You have a configuration problem somewhere.  The populate-volatile.sh 
>initscript
>used the /etc/default/volatiles configuration file.
>
>It has defined:
>
>#   d root root 1777
>/var/volatile/tmp none l root root 1777 /var/tmp /var/volatile/tmp
>
>So figure out if your configuration file is missing, you don't have the right
>populate-volatile.sh initscript or there is something else going on.
>
>The system is designed, by default, to make /var/volatile/tmp to be 1777.
>
>> This will permit non-root users to write to /var/tmp/ dir, But the LSB
>> test requires it can be writable for non-root users. So the test result is 
>> FAIL.
>
>This doesn't have anything to do with the LSB.  Your system is broken for some
>reason, bug, configuration problem or something else.  If it's a bug in OE, we 
>need
>to get it fixed -- if it's a configuration problem you should fix that instead.

Yes, it is a configuration problem on my system.
And the commit 81d3209 fix it. 

Regards,
Li

> Signed-off-by: Li Xin 
> ---
>  meta/recipes-core/base-files/base-files/fstab | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/meta/recipes-core/base-files/base-files/fstab
> b/meta/recipes-core/base-files/base-files/fstab
> index d79a016..458ec70 100644
> --- a/meta/recipes-core/base-files/base-files/fstab
> +++ b/meta/recipes-core/base-files/base-files/fstab
> @@ -4,7 +4,6 @@
>  proc /procproc   defaults
>>> 0  0
>  devpts   /dev/pts devpts
>>> mode=0620,gid=5   0  0
>  tmpfs/run tmpfs
>>> mode=0755,nodev,nosuid,strictatime 0  0
> -tmpfs/var/volatiletmpfs  defaults
>>> 0  0
>
>  # uncomment this if your device has a SD/MMC/Transflash slot
>  #/dev/mmcblk0p1   /media/card  auto
>>> defaults,sync,noauto  0  0
> --
> 1.8.4.2
>


>>>
>>> --
>>> ___
>>> 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

[OE-core] Remove oprofileui-server

[Felipe Tonello]

Hi,

oprofileui-server is obsolete since it uses legacy OProfile's
'opcontrol'  commands to record a session, instead of operf. It
doesn't work on fido builds.

Anyone familiar with the code base can tell if it is too much work to
update it to use operf?

Felipe
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][master/fido/dizzy] oprofileui: Use inherit gettext

[Joshua Lock]

On Thu, 2015-09-03 at 13:20 -0700, Saul Wold wrote:
> oprofileui uses gettext during the configuration task so should be
> inherit
> gettext. This issue appears when an older version of gettext is used
> do to
> pinning to the older non-gplv3 version.
> 
> [YOCTO #7795]

I've queued this in my fido-next branch[1].

Cheers,

Joshua

1. http://cgit.openembedded.org/openembedded-core-contrib/log/?h=joshua
gl/fido-next

> 
> Signed-off-by: Saul Wold 
> ---
>  meta/recipes-kernel/oprofile/oprofileui.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-kernel/oprofile/oprofileui.inc
> b/meta/recipes-kernel/oprofile/oprofileui.inc
> index 1dfd0c6..8fcf014 100644
> --- a/meta/recipes-kernel/oprofile/oprofileui.inc
> +++ b/meta/recipes-kernel/oprofile/oprofileui.inc
> @@ -10,7 +10,7 @@ LIC_FILES_CHKSUM = "
> file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
>  
>  DEPENDS = "glib-2.0 avahi intltool-native"
>  
> -inherit autotools pkgconfig
> +inherit autotools pkgconfig gettext
>  
>  EXTRA_OECONF = "--with-avahi"
>  
> -- 
> 2.1.0
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] "sub" machine types?

[Nicolas Dechesne]

On Fri, Sep 4, 2015 at 9:35 AM, Steffen Sledz  wrote:
> We have some products which differ in bootloaders (u-boot) and kernel device 
> trees only. They use the same kernel and root filesystem.
>
> Does OE have concepts for this? Or any suggestions to realize this without 
> building for many machines?

most BSP layers use SOC_FAMILY, see [1] for this type of things, such
that you can create 'SOC' specific packages that are reused across
multiple (OE) machines. That sounds like that would help in your
situation.


[1] 
http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html#var-SOC_FAMILY
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] "sub" machine types?

[Steffen Sledz]

We have some products which differ in bootloaders (u-boot) and kernel device 
trees only. They use the same kernel and root filesystem.

Does OE have concepts for this? Or any suggestions to realize this without 
building for many machines?

Steffen

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCHv4] Fix recursive mode -st on BUILDDIR setup

[Patrick Ohly]

On Fri, 2015-09-04 at 09:17 +0200, Patrick Ohly wrote:
> On Thu, 2015-09-03 at 16:56 -0500, Alex Franco wrote:
> > Removing recursive option from chmod -st on BUILDDIR as it would
> > take very long on existing build directories
> 
> Okay, so this *is* a problem others are also seeing ;-}
> 
> > diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir
> > index f5b7e4e..91bd86b 100755
> > --- a/scripts/oe-setup-builddir
> > +++ b/scripts/oe-setup-builddir
> > @@ -24,7 +24,10 @@ if [ -z "$BUILDDIR" ]; then
> >  fi
> >  
> >  mkdir -p "$BUILDDIR/conf"
> > -chmod -R -st "$BUILDDIR" 
> > +
> > +# Attempting removal of sticky,setuid bits from BUILDDIR, BUILDDIR/conf
> > +chmod -st "$BUILDDIR" 2>/dev/null || echo "WARNING: unable to chmod 
> > $BUILDDIR"
> > +chmod -st "$BUILDDIR/conf" 2>/dev/null || echo "WARNING: unable to chmod 
> > $BUILDDIR/conf"
> >  
> >  if [ ! -d "$BUILDDIR" ]; then
> >  echo >&2 "Error: The builddir ($BUILDDIR) does not exist!"
> 
> What was the reasoning behind adding these operations on $BUILDDIR/conf
> before the check whether BUILDDIR exists and is a directory? Looks a bit
> fishy to me.

Non-existent parent of $BUILDDIR is caught elsewhere, but pointing
BUILDDIR to a file instead of a directory indeed leads to sub-optimal
error reporting:

$ touch /tmp/foobar
$ . oe-init-build-env /tmp/foobar
mkdir: cannot create directory ‘/tmp/foobar’: Not a directory
chmod: cannot access ‘/tmp/foobar/conf’: Not a directory
Error: The builddir (/tmp/foobar) does not exist!

Not sure whether it's worth fixing, though. Better get this performance
fix included quickly.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] oe-init-build-env slowdown: chmod -R

[Burton, Ross]

On 4 September 2015 at 07:42, Patrick Ohly  wrote:

> In my case (*), that chmod takes about 2 minutes to complete. strace
> shows that it does a fchmodat on all files, even if nothing needs to be
> changed. atop then shows that this keeps the disk 100% busy with writes.
> I don't know what gets written (can't be the access time, I tried
> mounting with noatime).
>

The autobuilder has been seen to take 14 minutes at this stage before being
killed by buildbot. :) There's a patch on the list for this, and will be
merged soon.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] oe-init-build-env slowdown: chmod -R

[Jussi Kukkonen]

On 4 September 2015 at 09:42, Patrick Ohly  wrote:

> Hello!
>
> The following commit introduced a "chmod -R -st" on the build dir:
>
> commit f0d3587706fffdcc1c708013f6d6ce296dfc5f24
> Author: Alex Franco 
> Date:   Fri Aug 28 17:34:04 2015 -0500
>
> Fix mode +st on TMPDIR when creating it
>
> A sanity check fails when TMPDIR has setuid, setgid set. It was
> proposed to fix this on TMPDIR creation instead of failing with
> a sanity test only. This patch handles removal of those special
> bits (and additonally, the sticky bit) from BUILDDIR and TMPDIR
> when these directories are created.
>
> In my case (*), that chmod takes about 2 minutes to complete. strace
> shows that it does a fchmodat on all files, even if nothing needs to be
> changed. atop then shows that this keeps the disk 100% busy with writes.
> I don't know what gets written (can't be the access time, I tried
> mounting with noatime).
>
> Are others seeing the same behavior? I can't rule out that my disk is
> just slow due to fragmentation.
>

 d8caef4f6 in master should fix this (and yes it was a problem elsewhere
too -- an autobuilder was seen spending 12 minutes on that).

Jussi
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCHv4] Fix recursive mode -st on BUILDDIR setup

[Patrick Ohly]

On Thu, 2015-09-03 at 16:56 -0500, Alex Franco wrote:
> Removing recursive option from chmod -st on BUILDDIR as it would
> take very long on existing build directories

Okay, so this *is* a problem others are also seeing ;-}

> diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir
> index f5b7e4e..91bd86b 100755
> --- a/scripts/oe-setup-builddir
> +++ b/scripts/oe-setup-builddir
> @@ -24,7 +24,10 @@ if [ -z "$BUILDDIR" ]; then
>  fi
>  
>  mkdir -p "$BUILDDIR/conf"
> -chmod -R -st "$BUILDDIR" 
> +
> +# Attempting removal of sticky,setuid bits from BUILDDIR, BUILDDIR/conf
> +chmod -st "$BUILDDIR" 2>/dev/null || echo "WARNING: unable to chmod 
> $BUILDDIR"
> +chmod -st "$BUILDDIR/conf" 2>/dev/null || echo "WARNING: unable to chmod 
> $BUILDDIR/conf"
>  
>  if [ ! -d "$BUILDDIR" ]; then
>  echo >&2 "Error: The builddir ($BUILDDIR) does not exist!"

What was the reasoning behind adding these operations on $BUILDDIR/conf
before the check whether BUILDDIR exists and is a directory? Looks a bit
fishy to me.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/8] initramfs-framework: create /dev/console

[Patrick Ohly]

On Thu, 2015-09-03 at 14:34 -0700, Khem Raj wrote:
> > On Sep 3, 2015, at 11:42 AM, Patrick Ohly  wrote:
> > 
> > install -m 0755 ${WORKDIR}/debug ${D}/init.d/00-debug
> > +
> > +# Create device nodes expected by some kernels in initramfs
> > +# before even executing /init.
> > +install -d ${D}/dev
> > +mknod -m 622 ${D}/dev/console c 5 1
> > }
> > 
> 
> may be just use USE_DEVFS = “0” instead if we are not letting devtmpfs into 
> initrd image

The fix above is meant for the case were devfs is enabled (USE_DEVFS =
"1"). In my observation, a completely empty /dev then prevents booting
under qemu (see the "qemu + initramfs" mail thread).

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core