[OE-core] [PATCH] psplash: upgrade to latest git revision

[Ross Burton]

Non-housekeeping commits:

2015f70 Fix text width calculation.
5b3c1cc Add --fbdev option to psplash like --rotation.
505aeca psplash: fix remaining unused-parameter warnings
e3e0ab4 psplash: remove unused parameter length from parse_command
121720e psplash-fb: remove unused parameter from psplash_fb_text_size
9f6baa6 psplash-fb: fix sign-compare warning

Signed-off-by: Ross Burton 
---
 meta/recipes-core/psplash/psplash_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/psplash/psplash_git.bb 
b/meta/recipes-core/psplash/psplash_git.bb
index 1339f1eec11..3b7f818fc56 100644
--- a/meta/recipes-core/psplash/psplash_git.bb
+++ b/meta/recipes-core/psplash/psplash_git.bb
@@ -5,7 +5,7 @@ SECTION = "base"
 LICENSE = "GPLv2+"
 LIC_FILES_CHKSUM = 
"file://psplash.h;beginline=1;endline=16;md5=840fb2356b10a85bed78dd09dc7745c6"
 
-SRCREV = "88343ad23c90fa1dd8d79ac0d784a691aa0c6d2b"
+SRCREV = "2015f7073e98dd9562db0936a254af5ef56356cf"
 PV = "0.1+git${SRCPV}"
 PR = "r15"
 
-- 
2.11.0

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

Re: [OE-core] [PATCH 2/2] rootfs-postcommands: add test for unsatisfied RRECOMMENDS

[Burton, Ross]

On 26 August 2017 at 12:26, Jose Alarcon  wrote:

> The do_rootfs log contains a number of unsatisfied package
> recommendations. At the moment those are only visible when
> reviewing the rootfs log.
>
> This patch adds an extra check to surface any unsatisfied
> recommendation  as WARNINGS to the build output when
> "debug-tweaks" is enabled.
>

But isn't that the point of recommends?

If the user uses BAD_RECOMMENDATIONS to explicitly stop specific
recommendations being installed, or the package just isn't available,
that's fine.

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

[OE-core] [PATCH] initramfs-framework: split setup-live and install-efi into separate recipes

[California Sullivan]

Having these the initramfs-framework recipe forced initramfs-framework
users to build several tools they didn't need, and made it more
difficult to declare the recipe as allarch.

Fixes [YOCTO #12024].

Signed-off-by: California Sullivan 
---
 .../initrdscripts/initramfs-framework_1.0.bb | 20 ++--
 .../initramfs-module-install-efi_1.0.bb  | 18 ++
 .../initrdscripts/initramfs-module-setup-live_1.0.bb | 18 ++
 3 files changed, 38 insertions(+), 18 deletions(-)
 create mode 100644 
meta/recipes-core/initrdscripts/initramfs-module-install-efi_1.0.bb
 create mode 100644 
meta/recipes-core/initrdscripts/initramfs-module-setup-live_1.0.bb

diff --git a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb 
b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
index 77b2ff8..c07a5fc 100644
--- a/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
+++ b/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb
@@ -14,8 +14,7 @@ SRC_URI = "file://init \
file://udev \
file://e2fs \
file://debug \
-   file://setup-live \
-   file://install-efi.sh"
+  "
 
 S = "${WORKDIR}"
 
@@ -27,9 +26,6 @@ do_install() {
 install -m 0755 ${WORKDIR}/rootfs ${D}/init.d/90-rootfs
 install -m 0755 ${WORKDIR}/finish ${D}/init.d/99-finish
 
-# setup-live
-install -m 0755 ${WORKDIR}/setup-live ${D}/init.d/80-setup-live
-
 # mdev
 install -m 0755 ${WORKDIR}/mdev ${D}/init.d/01-mdev
 
@@ -42,9 +38,6 @@ do_install() {
 # debug
 install -m 0755 ${WORKDIR}/debug ${D}/init.d/00-debug
 
-# install-efi
-install -m 0755 ${WORKDIR}/install-efi.sh ${D}/init.d/install-efi.sh
-
 # Create device nodes expected by some kernels in initramfs
 # before even executing /init.
 install -d ${D}/dev
@@ -57,8 +50,7 @@ PACKAGES = "${PN}-base \
 initramfs-module-e2fs \
 initramfs-module-rootfs \
 initramfs-module-debug \
-initramfs-module-setup-live \
-initramfs-module-install-efi"
+   "
 
 FILES_${PN}-base = "/init /init.d/99-finish /dev"
 
@@ -78,10 +70,6 @@ SUMMARY_initramfs-module-udev = "initramfs support for udev"
 RDEPENDS_initramfs-module-udev = "${PN}-base udev"
 FILES_initramfs-module-udev = "/init.d/01-udev"
 
-SUMMARY_initramfs-module-setup-live = "initramfs support for setup live"
-RDEPENDS_initramfs-module-setup-live = "${PN}-base udev-extraconf"
-FILES_initramfs-module-setup-live = "/init.d/80-setup-live"
-
 SUMMARY_initramfs-module-e2fs = "initramfs support for ext4/ext3/ext2 
filesystems"
 RDEPENDS_initramfs-module-e2fs = "${PN}-base"
 FILES_initramfs-module-e2fs = "/init.d/10-e2fs"
@@ -93,7 +81,3 @@ FILES_initramfs-module-rootfs = "/init.d/90-rootfs"
 SUMMARY_initramfs-module-debug = "initramfs dynamic debug support"
 RDEPENDS_initramfs-module-debug = "${PN}-base"
 FILES_initramfs-module-debug = "/init.d/00-debug"
-
-SUMMARY_initramfs-module-install-efi = "initramfs support for installation 
option"
-RDEPENDS_initramfs-module-install-efi = "${PN}-base parted e2fsprogs-mke2fs 
dosfstools util-linux-blkid"
-FILES_initramfs-module-install-efi = "/init.d/install-efi.sh"
diff --git 
a/meta/recipes-core/initrdscripts/initramfs-module-install-efi_1.0.bb 
b/meta/recipes-core/initrdscripts/initramfs-module-install-efi_1.0.bb
new file mode 100644
index 000..8143f31
--- /dev/null
+++ b/meta/recipes-core/initrdscripts/initramfs-module-install-efi_1.0.bb
@@ -0,0 +1,18 @@
+SUMMARY = "initramfs-framework module for installation option"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = 
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+RDEPENDS_${PN} = "initramfs-framework-base parted e2fsprogs-mke2fs dosfstools 
util-linux-blkid"
+
+PR = "r1"
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/initramfs-framework:"
+SRC_URI = "file://install-efi.sh"
+
+S = "${WORKDIR}"
+
+do_install() {
+install -d ${D}/init.d
+install -m 0755 ${WORKDIR}/install-efi.sh ${D}/init.d/install-efi.sh
+}
+
+FILES_${PN} = "/init.d/install-efi.sh"
diff --git a/meta/recipes-core/initrdscripts/initramfs-module-setup-live_1.0.bb 
b/meta/recipes-core/initrdscripts/initramfs-module-setup-live_1.0.bb
new file mode 100644
index 000..7627cdc
--- /dev/null
+++ b/meta/recipes-core/initrdscripts/initramfs-module-setup-live_1.0.bb
@@ -0,0 +1,18 @@
+SUMMARY = "initramfs-framework module for live booting"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = 
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+RDEPENDS_${PN} = "initramfs-framework-base udev-extraconf"
+
+PR = "r1"
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/initramfs-framework:"
+SRC_URI = "file://setup-live"
+
+S = "${WORKDIR}"
+
+do_install() {
+install -d ${D}/init.d
+install -m 0755 ${WORKDIR}/setup-live ${D}/init.d/80-setup-live
+}
+
+FILES_${PN} = "/init.d/80-setup-live"
-- 
2.9.5

-- 

Re: [OE-core] [PATCH] glibc: add ld.so locks in _libc_fork

[Burton, Ross]

Can you rebase this to current master, which has glibc 2.26?

Ross

On 11 August 2017 at 04:16, Zhixiong Chi  wrote:

> The patch in this Bugzilla entry was requested by a customer:
>   https://sourceware.org/bugzilla/show_bug.cgi?id=4578
>   https://www.sourceware.org/bugzilla/show_bug.cgi?id=19282
>
> If a thread happens to hold dl_load_lock and have r_state set to RT_ADD or
> RT_DELETE at the time another thread calls fork(), then the child exit code
> from fork (in nptl/sysdeps/unix/sysv/linux/fork.c in our case)
> re-initializes
> dl_load_lock but does not restore r_state to RT_CONSISTENT. If the child
> subsequently requires ld.so functionality before calling exec(), then the
> assertion will fire.
>
> The patch acquires dl_load_lock on entry to fork() and releases it on exit
> from the parent path.  The child path is initialized as currently done.
> This is essentially pthreads_atfork, but forced to be first because the
> acquisition of dl_load_lock must happen before malloc_atfork is active
> to avoid a deadlock.
>
> The __libc_fork() code reset dl_load_lock, but it also needed to reset
> dl_load_write_lock.
>
> Signed-off-by: Zhixiong Chi 
> ---
>  .../0001-Bug-4578-add-ld.so-lock-while-fork.patch  | 57
> ++
>  ...bc-reset-dl-load-write-lock-after-forking.patch | 37 ++
>  meta/recipes-core/glibc/glibc_2.25.90.bb   |  2 +
>  3 files changed, 96 insertions(+)
>  create mode 100644 meta/recipes-core/glibc/glibc/
> 0001-Bug-4578-add-ld.so-lock-while-fork.patch
>  create mode 100644 meta/recipes-core/glibc/glibc/
> 0001-glibc-reset-dl-load-write-lock-after-forking.patch
>
> diff --git 
> a/meta/recipes-core/glibc/glibc/0001-Bug-4578-add-ld.so-lock-while-fork.patch
> b/meta/recipes-core/glibc/glibc/0001-Bug-4578-add-ld.so-
> lock-while-fork.patch
> new file mode 100644
> index 000..ab82866
> --- /dev/null
> +++ b/meta/recipes-core/glibc/glibc/0001-Bug-4578-add-ld.so-
> lock-while-fork.patch
> @@ -0,0 +1,57 @@
> +The patch in this Bugzilla entry was requested by a customer:
> +  https://sourceware.org/bugzilla/show_bug.cgi?id=4578
> +
> +If a thread happens to hold dl_load_lock and have r_state set to RT_ADD or
> +RT_DELETE at the time another thread calls fork(), then the child exit
> code
> +from fork (in nptl/sysdeps/unix/sysv/linux/fork.c in our case)
> re-initializes
> +dl_load_lock but does not restore r_state to RT_CONSISTENT. If the child
> +subsequently requires ld.so functionality before calling exec(), then the
> +assertion will fire.
> +
> +The patch acquires dl_load_lock on entry to fork() and releases it on exit
> +from the parent path.  The child path is initialized as currently done.
> +This is essentially pthreads_atfork, but forced to be first because the
> +acquisition of dl_load_lock must happen before malloc_atfork is active
> +to avoid a deadlock.
> +The patch has not yet been integrated upstream.
> +
> +Upstream-Status: Pending [ Not Author See bugzilla]
> +
> +Signed-off-by: Raghunath Lolur 
> +Signed-off-by: Yuanjie Huang 
> +Signed-off-by: Zhixiong Chi 
> +
> +Index: git/sysdeps/nptl/fork.c
> +===
> +--- git.orig/sysdeps/nptl/fork.c   2017-08-03 16:02:15.674704080
> +0800
>  git/sysdeps/nptl/fork.c2017-08-04 18:15:02.463362015 +0800
> +@@ -25,6 +25,7 @@
> + #include 
> + #include 
> + #include 
> ++#include 
> + #include 
> + #include 
> + #include 
> +@@ -60,6 +61,10 @@
> +  but our current fork implementation is not.  */
> +   bool multiple_threads = THREAD_GETMEM (THREAD_SELF,
> header.multiple_threads);
> +
> ++  /* grab ld.so lock BEFORE switching to malloc_atfork */
> ++  __rtld_lock_lock_recursive (GL(dl_load_lock));
> ++  __rtld_lock_lock_recursive (GL(dl_load_write_lock));
> ++
> +   /* Run all the registered preparation handlers.  In reverse order.
> +  While doing this we build up a list of all the entries.  */
> +   struct fork_handler *runp;
> +@@ -258,6 +263,10 @@
> +
> + allp = allp->next;
> +   }
> ++
> ++  /* unlock ld.so last, because we locked it first */
> ++  __rtld_lock_unlock_recursive (GL(dl_load_write_lock));
> ++  __rtld_lock_unlock_recursive (GL(dl_load_lock));
> + }
> +
> +   return pid;
> diff --git a/meta/recipes-core/glibc/glibc/0001-glibc-reset-dl-
> load-write-lock-after-forking.patch b/meta/recipes-core/glibc/
> glibc/0001-glibc-reset-dl-load-write-lock-after-forking.patch
> new file mode 100644
> index 000..777b253
> --- /dev/null
> +++ b/meta/recipes-core/glibc/glibc/0001-glibc-reset-dl-
> load-write-lock-after-forking.patch
> @@ -0,0 +1,37 @@
> +From a6bb73d1cfd20a73fbbe6076008376fb87879d1b Mon Sep 17 00:00:00 2001
> +From: Yuanjie Huang 
> +Date: Thu, 18 Aug 2016 17:59:13 +0800
> +Subject: [PATCH] reset 

Re: [OE-core] [PATCH] packagegroup-python3: add packagegroup

[Burton, Ross]

On 18 August 2017 at 18:09, Jose Lamego 
wrote:

> Please disregard this patch. The python3 recipe provides python-modules,
> which includes all of the listed packages, making a new packagegroup
> unnecessary.


Its even better than that now:

RPROVIDES_${PN}-modules = "${PN}"

Adding just "python3" to an image will pull in python3-modules, which pulls
in the lot.

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

Re: [OE-core] [PATCH] gstreamer1.0-plugins-good: fix 4k playback for v4l2 decoder

[Burton, Ross]

On 1 September 2017 at 13:45, Nicolas Dechesne 
wrote:

> +++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-
> plugins-good/0001-v4l2-Fix-4K-colorimetry.patch
> @@ -0,0 +1,47 @@
> +From 545646cccba243236e10362fe7325f89be57da1f Mon Sep 17 00:00:00 2001
> +From: Nicolas Dufresne 
> +Date: Tue, 18 Jul 2017 11:28:37 -0400
> +Subject: [PATCH] v4l2: Fix 4K colorimetry
> +
> +Since 1.6, the transfer function for BT2020 has been changed from BT709
> +to BT2020_12. It's the same function, but with more precision. As a side
> +effect, the V4L2 colorpsace didn't match GStreamer colorspace. When
> +GStreamer ended up making a guess, it would not match anything supported
> +by V4L2 anymore. This this by using BT2020_12 for BT2020 colorspace and
> +BT2020 transfer function in replacement of BT709 whenever a 4K
> +resolution is detected.
> +
> +Upstream-Status: Backport
>

This needs your s-o-b.

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

[OE-core] [PATCH v2] insane.bbclass: Warn if ${COREBASE}/LICENSE is used

[Saul Wold]

The top level LICENSE file is not actually a license, it refers
other licenses that are used by Bitbake and Meta-data. Relying
on this file could cause problems for recipes when this file
changes, which it is about to.

(From OE-Core rev: a1948ab38c9cb7f0b16cce9dadc03ae6e2fe44ad)

Signed-off-by: Saul Wold 
Signed-off-by: Richard Purdie 
---
v2: Made one bb.warn instead of 2 and changed up comment

Available in poky-contrib/sgw/insane

 meta/classes/insane.bbclass | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 3906ba7..aa304f1 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -589,7 +589,7 @@ python populate_lic_qa_checksum() {
 sane = package_qa_handle_error("license-checksum", pn + ": Recipe file 
fetches files and does not have license file information (LIC_FILES_CHKSUM)", d)
 
 srcdir = d.getVar('S')
-
+corebase_licensefile = d.getVar('COREBASE') + "/LICENSE"
 for url in lic_files.split():
 try:
 (type, host, path, user, pswd, parm) = bb.fetch.decodeurl(url)
@@ -601,6 +601,9 @@ python populate_lic_qa_checksum() {
 package_qa_handle_error("license-checksum", pn + ": 
LIC_FILES_CHKSUM points to an invalid file: " + srclicfile, d)
 continue
 
+if (srclicfile == corebase_licensefile):
+bb.warn("${COREBASE}/LICENSE is not a valid license file, please 
use '${COMMON_LICENSE_DIR}/MIT' for a MIT License file in LIC_FILES_CHKSUM. 
This will become an error in the future")
+
 recipemd5 = parm.get('md5', '')
 beginline, endline = 0, 0
 if 'beginline' in parm:
-- 
2.7.5

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

[OE-core] [PATCH v2] oeqa/selftest: Add missing IDs to various test cases

[jose . perez . carranza]

From: Jose Perez Carranza 

Add decorator @OETestID() with Tesopia TC-ID to the test cases
that did not have it properly set.

[YOCTO #11873]

Signed-off-by: Jose Perez Carranza 
---
 meta/lib/oeqa/selftest/cases/archiver.py  |  3 ++-
 meta/lib/oeqa/selftest/cases/distrodata.py|  2 ++
 meta/lib/oeqa/selftest/cases/imagefeatures.py |  3 +++
 meta/lib/oeqa/selftest/cases/runcmd.py| 17 +
 meta/lib/oeqa/selftest/cases/wic.py   |  1 +
 5 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/selftest/cases/archiver.py 
b/meta/lib/oeqa/selftest/cases/archiver.py
index 72026d573c..f61a522017 100644
--- a/meta/lib/oeqa/selftest/cases/archiver.py
+++ b/meta/lib/oeqa/selftest/cases/archiver.py
@@ -40,7 +40,7 @@ class Archiver(OESelftestTestCase):
 excluded_present = len(glob.glob(src_path + '/%s-*' % exclude_recipe))
 self.assertFalse(excluded_present, 'Recipe %s was not excluded.' % 
exclude_recipe)
 
-
+@OETestID(1900)
 def test_archiver_filters_by_type(self):
 """
 Summary: The archiver is documented to filter on the recipe type.
@@ -73,6 +73,7 @@ class Archiver(OESelftestTestCase):
 excluded_present = len(glob.glob(src_path_native + '/%s-*' % 
native_recipe))
 self.assertFalse(excluded_present, 'Recipe %s was not excluded.' % 
native_recipe)
 
+@OETestID(1901)
 def test_archiver_filters_by_type_and_name(self):
 """
 Summary: Test that the archiver archives by recipe type, taking the
diff --git a/meta/lib/oeqa/selftest/cases/distrodata.py 
b/meta/lib/oeqa/selftest/cases/distrodata.py
index ecb15d9aea..12540adc7d 100644
--- a/meta/lib/oeqa/selftest/cases/distrodata.py
+++ b/meta/lib/oeqa/selftest/cases/distrodata.py
@@ -2,6 +2,7 @@ from oeqa.selftest.case import OESelftestTestCase
 from oeqa.utils.commands import runCmd, bitbake, get_bb_var, get_bb_vars
 from oeqa.utils.decorators import testcase
 from oeqa.utils.ftools import write_file
+from oeqa.core.decorator.oeid import OETestID
 
 class Distrodata(OESelftestTestCase):
 
@@ -9,6 +10,7 @@ class Distrodata(OESelftestTestCase):
 def setUpClass(cls):
 super(Distrodata, cls).setUpClass()
 
+@OETestID(1902)
 def test_checkpkg(self):
 """
 Summary: Test that upstream version checks do not regress
diff --git a/meta/lib/oeqa/selftest/cases/imagefeatures.py 
b/meta/lib/oeqa/selftest/cases/imagefeatures.py
index bb2e0dba4c..1a850008ef 100644
--- a/meta/lib/oeqa/selftest/cases/imagefeatures.py
+++ b/meta/lib/oeqa/selftest/cases/imagefeatures.py
@@ -131,6 +131,7 @@ class ImageFeatures(OESelftestTestCase):
 # check if the resulting gzip is valid
 self.assertTrue(runCmd('gzip -t %s' % gzip_path))
 
+@OETestID(1903)
 def test_hypervisor_fmts(self):
 """
 Summary: Check various hypervisor formats
@@ -165,6 +166,7 @@ class ImageFeatures(OESelftestTestCase):
 native_sysroot=sysroot)
 self.assertTrue(json.loads(result.output).get('format') == itype)
 
+@OETestID(1905)
 def test_long_chain_conversion(self):
 """
 Summary: Check for chaining many CONVERSION_CMDs together
@@ -196,6 +198,7 @@ class ImageFeatures(OESelftestTestCase):
 self.assertTrue(runCmd('cd %s;sha256sum -c %s.%s.sha256sum' %
(deploy_dir_image, link_name, conv)))
 
+@OETestID(1904)
 def test_image_fstypes(self):
 """
 Summary: Check if image of supported image fstypes can be built
diff --git a/meta/lib/oeqa/selftest/cases/runcmd.py 
b/meta/lib/oeqa/selftest/cases/runcmd.py
index 6c785caadc..d76d7063c6 100644
--- a/meta/lib/oeqa/selftest/cases/runcmd.py
+++ b/meta/lib/oeqa/selftest/cases/runcmd.py
@@ -1,6 +1,7 @@
 from oeqa.selftest.case import OESelftestTestCase
 from oeqa.utils.commands import runCmd
 from oeqa.utils import CommandError
+from oeqa.core.decorator.oeid import OETestID
 
 import subprocess
 import threading
@@ -26,49 +27,60 @@ class RunCmdTests(OESelftestTestCase):
 TIMEOUT = 2
 DELTA = 1
 
+@OETestID(1916)
 def test_result_okay(self):
 result = runCmd("true")
 self.assertEqual(result.status, 0)
 
+@OETestID(1915)
 def test_result_false(self):
 result = runCmd("false", ignore_status=True)
 self.assertEqual(result.status, 1)
 
+@OETestID(1917)
 def test_shell(self):
 # A shell is used for all string commands.
 result = runCmd("false; true", ignore_status=True)
 self.assertEqual(result.status, 0)
 
+@OETestID(1910)
 def test_no_shell(self):
 self.assertRaises(FileNotFoundError,
   runCmd, "false; true", shell=False)
 
+@OETestID(1906)
 def test_list_not_found(self):
 self.assertRaises(FileNotFoundError,
   

[OE-core] ✗ patchtest: failure for oeqa/selftest: Add missing IDs to various test cases

[Patchwork]

== Series Details ==

Series: oeqa/selftest: Add missing IDs to various test cases
Revision: 1
URL   : https://patchwork.openembedded.org/series/8650/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue Series does not apply on top of target branch 
[test_series_merge_on_head] 
  Suggested fixRebase your series on top of targeted branch
  Targeted branch  master (currently at 811edd9542)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] [PATCH] oeqa/selftest: Add missing IDs to various test cases

[jose . perez . carranza]

From: Jose Perez Carranza 

Add decorator @OETestID() with Tesopia TC-ID to the test cases
that did not have it properly set.

[YOCTO #11873]

Signed-off-by: Jose Perez Carranza 
---
 meta/lib/oeqa/selftest/cases/archiver.py  |  3 ++-
 meta/lib/oeqa/selftest/cases/distrodata.py|  2 ++
 meta/lib/oeqa/selftest/cases/imagefeatures.py |  3 +++
 meta/lib/oeqa/selftest/cases/runcmd.py| 17 +
 meta/lib/oeqa/selftest/cases/wic.py   |  1 +
 5 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/selftest/cases/archiver.py 
b/meta/lib/oeqa/selftest/cases/archiver.py
index 72026d573c..f61a522017 100644
--- a/meta/lib/oeqa/selftest/cases/archiver.py
+++ b/meta/lib/oeqa/selftest/cases/archiver.py
@@ -40,7 +40,7 @@ class Archiver(OESelftestTestCase):
 excluded_present = len(glob.glob(src_path + '/%s-*' % exclude_recipe))
 self.assertFalse(excluded_present, 'Recipe %s was not excluded.' % 
exclude_recipe)
 
-
+@OETestID(1900)
 def test_archiver_filters_by_type(self):
 """
 Summary: The archiver is documented to filter on the recipe type.
@@ -73,6 +73,7 @@ class Archiver(OESelftestTestCase):
 excluded_present = len(glob.glob(src_path_native + '/%s-*' % 
native_recipe))
 self.assertFalse(excluded_present, 'Recipe %s was not excluded.' % 
native_recipe)
 
+@OETestID(1901)
 def test_archiver_filters_by_type_and_name(self):
 """
 Summary: Test that the archiver archives by recipe type, taking the
diff --git a/meta/lib/oeqa/selftest/cases/distrodata.py 
b/meta/lib/oeqa/selftest/cases/distrodata.py
index d5d286d5cc..bcbcfb4f63 100644
--- a/meta/lib/oeqa/selftest/cases/distrodata.py
+++ b/meta/lib/oeqa/selftest/cases/distrodata.py
@@ -2,6 +2,7 @@ from oeqa.selftest.case import OESelftestTestCase
 from oeqa.utils.commands import runCmd, bitbake, get_bb_var, get_bb_vars
 from oeqa.utils.decorators import testcase
 from oeqa.utils.ftools import write_file
+from oeqa.core.decorator.oeid import OETestID
 
 class Distrodata(OESelftestTestCase):
 
@@ -10,6 +11,7 @@ class Distrodata(OESelftestTestCase):
 super(Distrodata, cls).setUpClass()
 cls.exceptions_path = os.path.join(cls.testlayer_path, 'files', 
'distrodata', "checkpkg_exceptions")
 
+@OETestID(1902)
 def test_checkpkg(self):
 """
 Summary: Test that upstream version checks do not regress
diff --git a/meta/lib/oeqa/selftest/cases/imagefeatures.py 
b/meta/lib/oeqa/selftest/cases/imagefeatures.py
index bb2e0dba4c..1a850008ef 100644
--- a/meta/lib/oeqa/selftest/cases/imagefeatures.py
+++ b/meta/lib/oeqa/selftest/cases/imagefeatures.py
@@ -131,6 +131,7 @@ class ImageFeatures(OESelftestTestCase):
 # check if the resulting gzip is valid
 self.assertTrue(runCmd('gzip -t %s' % gzip_path))
 
+@OETestID(1903)
 def test_hypervisor_fmts(self):
 """
 Summary: Check various hypervisor formats
@@ -165,6 +166,7 @@ class ImageFeatures(OESelftestTestCase):
 native_sysroot=sysroot)
 self.assertTrue(json.loads(result.output).get('format') == itype)
 
+@OETestID(1905)
 def test_long_chain_conversion(self):
 """
 Summary: Check for chaining many CONVERSION_CMDs together
@@ -196,6 +198,7 @@ class ImageFeatures(OESelftestTestCase):
 self.assertTrue(runCmd('cd %s;sha256sum -c %s.%s.sha256sum' %
(deploy_dir_image, link_name, conv)))
 
+@OETestID(1904)
 def test_image_fstypes(self):
 """
 Summary: Check if image of supported image fstypes can be built
diff --git a/meta/lib/oeqa/selftest/cases/runcmd.py 
b/meta/lib/oeqa/selftest/cases/runcmd.py
index 6c785caadc..d76d7063c6 100644
--- a/meta/lib/oeqa/selftest/cases/runcmd.py
+++ b/meta/lib/oeqa/selftest/cases/runcmd.py
@@ -1,6 +1,7 @@
 from oeqa.selftest.case import OESelftestTestCase
 from oeqa.utils.commands import runCmd
 from oeqa.utils import CommandError
+from oeqa.core.decorator.oeid import OETestID
 
 import subprocess
 import threading
@@ -26,49 +27,60 @@ class RunCmdTests(OESelftestTestCase):
 TIMEOUT = 2
 DELTA = 1
 
+@OETestID(1916)
 def test_result_okay(self):
 result = runCmd("true")
 self.assertEqual(result.status, 0)
 
+@OETestID(1915)
 def test_result_false(self):
 result = runCmd("false", ignore_status=True)
 self.assertEqual(result.status, 1)
 
+@OETestID(1917)
 def test_shell(self):
 # A shell is used for all string commands.
 result = runCmd("false; true", ignore_status=True)
 self.assertEqual(result.status, 0)
 
+@OETestID(1910)
 def test_no_shell(self):
 self.assertRaises(FileNotFoundError,
   runCmd, "false; true", shell=False)
 
+@OETestID(1906)
 def 

Re: [OE-core] [PATCH v7] kernel: Add support for multiple kernel packages

[Otavio Salvador]

On Thu, Aug 17, 2017 at 6:14 PM, Haris Okanovic  wrote:
...
>  7. Verified image contains two bzImage's under /boot/, with
> "yocto-standard" selected to boot via symlink.

Please take a look at
https://patchwork.openembedded.org/patch/143549/; it will impact this
change.

I think you could have a symlink with the kernel name on it. So using
your example we'd have a zImage-tiny-linux next to zImage.

...
> [PATCH v5]
>  - Warn when PN == KERNEL_PACKAGE_NAME (bug # 11905)
>  - Add KERNEL_DEPLOYSUBDIR to avoid DEPLOYDIR collisions

Instead of a subdir, why not using a suffix? it avoids sub directories
and allows for an easier find of the generated files.


-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] alsa-utils: Do not hardcode path to /lib/udev

[Peter Kjellerstedt]

Use ${nonarch_base_libdir}/udev instead. This avoids problems when
usrmerge is enabled in DISTRO_FEATURES and udev support is disabled.

Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-multimedia/alsa/alsa-utils_1.1.4.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-multimedia/alsa/alsa-utils_1.1.4.bb 
b/meta/recipes-multimedia/alsa/alsa-utils_1.1.4.bb
index 54be50ed82..c8f4b861bd 100644
--- a/meta/recipes-multimedia/alsa/alsa-utils_1.1.4.bb
+++ b/meta/recipes-multimedia/alsa/alsa-utils_1.1.4.bb
@@ -103,7 +103,7 @@ do_install() {
 
if ${@bb.utils.contains('PACKAGECONFIG', 'udev', 'false', 'true', d)}; 
then
# This is where alsa-utils will install its rules if we don't 
tell it anything else.
-   rm -rf ${D}/lib/udev
-   rmdir --ignore-fail-on-non-empty ${D}/lib
+   rm -rf ${D}${nonarch_base_libdir}/udev
+   rmdir --ignore-fail-on-non-empty ${D}${nonarch_base_libdir}
fi
 }
-- 
2.12.0

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

Re: [OE-core] [PATCH] kernel: Stop using update-alternatives

[Otavio Salvador]

On Fri, Sep 1, 2017 at 2:07 PM, Saul Wold  wrote:
> On Thu, 2017-08-31 at 18:34 -0300, Otavio Salvador wrote:
>> The update-alternatives where using relative links so not being
>> really
>> in use since December 2016 (see OE-Core:c7bc46b9 "kernel: Fix
>> symlinks") so instead we now generate the relative symlinks during
>> the
>> do_install task and drop the update-alternatives use at all.
>>
> Is there a reason not to fix the U-A usage of the relative links?

Conceptually the update-alternatives use is wrong as the database is
on /etc and /boot can potentially be in another partition and loaded
directly so relative links are required ...

In fact using symbolic links is not used in generic distributions as
they generate the boot script as post inst action so user can choose
which to boot but for our use case, it makes sense.


> How will this affect the installation of multiple kernels?
> for example with Haris's patch: http://lists.openembedded.org/pipermail
> /openembedded-core/2017-August/140996.html

It can be adapted to work with it; we could, for example, use the
KERNEL_NAME to be a prefix or suffix for the image and device tree
binaries.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] kernel: Stop using update-alternatives

[Saul Wold]

On Fri, 2017-09-01 at 10:07 -0700, Saul Wold wrote:
> On Thu, 2017-08-31 at 18:34 -0300, Otavio Salvador wrote:
> > 
> > The update-alternatives where using relative links so not being
> > really
> > in use since December 2016 (see OE-Core:c7bc46b9 "kernel: Fix
> > symlinks") so instead we now generate the relative symlinks during
> > the
> > do_install task and drop the update-alternatives use at all.
> > 
> Is there a reason not to fix the U-A usage of the relative links?
> 
> How will this affect the installation of multiple kernels?
> for example with Haris's patch: http://lists.openembedded.org/piperma
> il
> /openembedded-core/2017-August/140996.html
> 
> Sau!
> 
I chatted with Otavio and we agree this is correct.

Acked-by: Saul Wold 

Sau!

> 
> > 
> > Signed-off-by: Otavio Salvador 
> > ---
> > 
> >  meta/classes/kernel.bbclass | 16 +++
> >  meta/recipes-kernel/linux/linux-dtb.inc | 36 -
> > --
> > --
> >  2 files changed, 7 insertions(+), 45 deletions(-)
> > 
> > diff --git a/meta/classes/kernel.bbclass
> > b/meta/classes/kernel.bbclass
> > index 3cc0432fcf..02a5e961cb 100644
> > --- a/meta/classes/kernel.bbclass
> > +++ b/meta/classes/kernel.bbclass
> > @@ -2,7 +2,7 @@ inherit linux-kernel-base kernel-module-split
> >  
> >  PROVIDES += "virtual/kernel"
> >  DEPENDS += "virtual/${TARGET_PREFIX}binutils
> > virtual/${TARGET_PREFIX}gcc kmod-native bc-native lzop-native"
> > -PACKAGE_WRITE_DEPS += "depmodwrapper-cross virtual/update-
> > alternatives-native"
> > +PACKAGE_WRITE_DEPS += "depmodwrapper-cross"
> >  
> >  do_deploy[depends] += "depmodwrapper-cross:do_populate_sysroot"
> >  
> > @@ -57,7 +57,7 @@ python __anonymous () {
> >  
> >  d.appendVar('PACKAGES', ' ' + 'kernel-image-' + typelower)
> >  
> > -d.setVar('FILES_kernel-image-' + typelower, '/' +
> > imagedest
> > + '/' + type + '-${KERNEL_VERSION_NAME}')
> > +d.setVar('FILES_kernel-image-' + typelower, '/' +
> > imagedest
> > + '/' + type + '-${KERNEL_VERSION_NAME}' + ' /' + imagedest + '/' +
> > type)
> >  
> >  d.appendVar('RDEPENDS_kernel-image', ' ' + 'kernel-image-' 
> > +
> > typelower)
> >  
> > @@ -65,13 +65,6 @@ python __anonymous () {
> >  
> >  d.setVar('ALLOW_EMPTY_kernel-image-' + typelower, '1')
> >  
> > -priority = d.getVar('KERNEL_PRIORITY')
> > -postinst = '#!/bin/sh\n' + 'update-alternatives --install
> > /'
> > + imagedest + '/' + type + ' ' + type + ' ' + type + '-
> > ${KERNEL_VERSION_NAME} ' + priority + ' || true' + '\n'
> > -d.setVar('pkg_postinst_kernel-image-' + typelower,
> > postinst)
> > -
> > -postrm = '#!/bin/sh\n' + 'update-alternatives --remove' +
> > '
> > ' + type + ' ' + type + '-${KERNEL_VERSION_NAME} || true' + '\n'
> > -d.setVar('pkg_postrm_kernel-image-' + typelower, postrm)
> > -
> >  image = d.getVar('INITRAMFS_IMAGE')
> >  if image:
> >  d.appendVarFlag('do_bundle_initramfs', 'depends', '
> > ${INITRAMFS_IMAGE}:do_image_complete')
> > @@ -137,10 +130,6 @@ export CROSS_COMPILE = "${TARGET_PREFIX}"
> >  export KBUILD_BUILD_USER = "oe-user"
> >  export KBUILD_BUILD_HOST = "oe-host"
> >  
> > -KERNEL_PRIORITY ?= "${@int(d.getVar('PV').split('-
> > ')[0].split('+')[0].split('.')[0]) * 1 + \
> > -   int(d.getVar('PV').split('-
> > ')[0].split('+')[0].split('.')[1]) * 100 + \
> > -   int(d.getVar('PV').split('-
> > ')[0].split('+')[0].split('.')[-1])}"
> > -
> >  KERNEL_RELEASE ?= "${KERNEL_VERSION}"
> >  
> >  # The directory where built kernel lies in the kernel tree
> > @@ -350,6 +339,7 @@ kernel_do_install() {
> >     install -d ${D}/boot
> >     for type in ${KERNEL_IMAGETYPES} ; do
> >     install -m 0644 ${KERNEL_OUTPUT_DIR}/${type}
> > ${D}/${KERNEL_IMAGEDEST}/${type}-${KERNEL_VERSION}
> > +   ln -sf ${type}-${KERNEL_VERSION}
> > ${D}/${KERNEL_IMAGEDEST}/${type}
> >     done
> >     install -m 0644 System.map ${D}/boot/System.map-
> > ${KERNEL_VERSION}
> >     install -m 0644 .config ${D}/boot/config-${KERNEL_VERSION}
> > diff --git a/meta/recipes-kernel/linux/linux-dtb.inc
> > b/meta/recipes-
> > kernel/linux/linux-dtb.inc
> > index 0174c80d85..6e6f39e640 100644
> > --- a/meta/recipes-kernel/linux/linux-dtb.inc
> > +++ b/meta/recipes-kernel/linux/linux-dtb.inc
> > @@ -1,7 +1,5 @@
> >  # Support for device tree generation
> > -FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/devicetree*"
> > -
> > -PACKAGE_WRITE_DEPS += "virtual/update-alternatives-native"
> > +FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/*.dtb
> > /${KERNEL_IMAGEDEST}/*.dtbo"
> >  
> >  python __anonymous () {
> >  d.appendVar("PACKAGES", " kernel-devicetree")
> > @@ -36,12 +34,13 @@ do_install_append() {
> >     for DTB in ${KERNEL_DEVICETREE}; do
> >     DTB=`normalize_dtb "${DTB}"`
> >     DTB_EXT=${DTB##*.}
> > +   

Re: [OE-core] [PATCH] kernel: Stop using update-alternatives

[Saul Wold]

On Thu, 2017-08-31 at 18:34 -0300, Otavio Salvador wrote:
> The update-alternatives where using relative links so not being
> really
> in use since December 2016 (see OE-Core:c7bc46b9 "kernel: Fix
> symlinks") so instead we now generate the relative symlinks during
> the
> do_install task and drop the update-alternatives use at all.
> 
Is there a reason not to fix the U-A usage of the relative links?

How will this affect the installation of multiple kernels?
for example with Haris's patch: http://lists.openembedded.org/pipermail
/openembedded-core/2017-August/140996.html

Sau!


> Signed-off-by: Otavio Salvador 
> ---
> 
>  meta/classes/kernel.bbclass | 16 +++
>  meta/recipes-kernel/linux/linux-dtb.inc | 36 ---
> --
>  2 files changed, 7 insertions(+), 45 deletions(-)
> 
> diff --git a/meta/classes/kernel.bbclass
> b/meta/classes/kernel.bbclass
> index 3cc0432fcf..02a5e961cb 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -2,7 +2,7 @@ inherit linux-kernel-base kernel-module-split
>  
>  PROVIDES += "virtual/kernel"
>  DEPENDS += "virtual/${TARGET_PREFIX}binutils
> virtual/${TARGET_PREFIX}gcc kmod-native bc-native lzop-native"
> -PACKAGE_WRITE_DEPS += "depmodwrapper-cross virtual/update-
> alternatives-native"
> +PACKAGE_WRITE_DEPS += "depmodwrapper-cross"
>  
>  do_deploy[depends] += "depmodwrapper-cross:do_populate_sysroot"
>  
> @@ -57,7 +57,7 @@ python __anonymous () {
>  
>  d.appendVar('PACKAGES', ' ' + 'kernel-image-' + typelower)
>  
> -d.setVar('FILES_kernel-image-' + typelower, '/' + imagedest
> + '/' + type + '-${KERNEL_VERSION_NAME}')
> +d.setVar('FILES_kernel-image-' + typelower, '/' + imagedest
> + '/' + type + '-${KERNEL_VERSION_NAME}' + ' /' + imagedest + '/' +
> type)
>  
>  d.appendVar('RDEPENDS_kernel-image', ' ' + 'kernel-image-' +
> typelower)
>  
> @@ -65,13 +65,6 @@ python __anonymous () {
>  
>  d.setVar('ALLOW_EMPTY_kernel-image-' + typelower, '1')
>  
> -priority = d.getVar('KERNEL_PRIORITY')
> -postinst = '#!/bin/sh\n' + 'update-alternatives --install /'
> + imagedest + '/' + type + ' ' + type + ' ' + type + '-
> ${KERNEL_VERSION_NAME} ' + priority + ' || true' + '\n'
> -d.setVar('pkg_postinst_kernel-image-' + typelower, postinst)
> -
> -postrm = '#!/bin/sh\n' + 'update-alternatives --remove' + '
> ' + type + ' ' + type + '-${KERNEL_VERSION_NAME} || true' + '\n'
> -d.setVar('pkg_postrm_kernel-image-' + typelower, postrm)
> -
>  image = d.getVar('INITRAMFS_IMAGE')
>  if image:
>  d.appendVarFlag('do_bundle_initramfs', 'depends', '
> ${INITRAMFS_IMAGE}:do_image_complete')
> @@ -137,10 +130,6 @@ export CROSS_COMPILE = "${TARGET_PREFIX}"
>  export KBUILD_BUILD_USER = "oe-user"
>  export KBUILD_BUILD_HOST = "oe-host"
>  
> -KERNEL_PRIORITY ?= "${@int(d.getVar('PV').split('-
> ')[0].split('+')[0].split('.')[0]) * 1 + \
> -   int(d.getVar('PV').split('-
> ')[0].split('+')[0].split('.')[1]) * 100 + \
> -   int(d.getVar('PV').split('-
> ')[0].split('+')[0].split('.')[-1])}"
> -
>  KERNEL_RELEASE ?= "${KERNEL_VERSION}"
>  
>  # The directory where built kernel lies in the kernel tree
> @@ -350,6 +339,7 @@ kernel_do_install() {
>   install -d ${D}/boot
>   for type in ${KERNEL_IMAGETYPES} ; do
>   install -m 0644 ${KERNEL_OUTPUT_DIR}/${type}
> ${D}/${KERNEL_IMAGEDEST}/${type}-${KERNEL_VERSION}
> + ln -sf ${type}-${KERNEL_VERSION}
> ${D}/${KERNEL_IMAGEDEST}/${type}
>   done
>   install -m 0644 System.map ${D}/boot/System.map-
> ${KERNEL_VERSION}
>   install -m 0644 .config ${D}/boot/config-${KERNEL_VERSION}
> diff --git a/meta/recipes-kernel/linux/linux-dtb.inc b/meta/recipes-
> kernel/linux/linux-dtb.inc
> index 0174c80d85..6e6f39e640 100644
> --- a/meta/recipes-kernel/linux/linux-dtb.inc
> +++ b/meta/recipes-kernel/linux/linux-dtb.inc
> @@ -1,7 +1,5 @@
>  # Support for device tree generation
> -FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/devicetree*"
> -
> -PACKAGE_WRITE_DEPS += "virtual/update-alternatives-native"
> +FILES_kernel-devicetree = "/${KERNEL_IMAGEDEST}/*.dtb
> /${KERNEL_IMAGEDEST}/*.dtbo"
>  
>  python __anonymous () {
>  d.appendVar("PACKAGES", " kernel-devicetree")
> @@ -36,12 +34,13 @@ do_install_append() {
>   for DTB in ${KERNEL_DEVICETREE}; do
>   DTB=`normalize_dtb "${DTB}"`
>   DTB_EXT=${DTB##*.}
> + DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
>   DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
> + install -m 0644 ${DTB_PATH}
> ${D}/${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.${DTB_EXT}
>   for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
>   symlink_name=${type}"-
> "${KERNEL_IMAGE_SYMLINK_NAME}
>   DTB_SYMLINK_NAME=`echo ${symlink_name} | sed
> 

Re: [OE-core] [PATCH 1/3] lib/oe/package: Improve filedeprunner subprocess handling

[Richard Purdie]

On Fri, 2017-09-01 at 16:32 +, Peter Kjellerstedt wrote:
> Even with these changes applied, I still see texinfo succeed to
> build 
> even when it should not (i.e., without having applied the patch to 
> package_deb.bbclass that I just sent).

Right, there are some nasty bugs with python's multiprocessing
exception handling in a few places. I've sent some patches for some
others which I ran into with other problems, Leo should have a patch
for this specific issue shortly. Thanks for the colon fix!

Cheers,

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

Re: [OE-core] [PATCH 1/3] lib/oe/package: Improve filedeprunner subprocess handling

[Peter Kjellerstedt]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Richard Purdie
> Sent: den 1 september 2017 16:21
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 1/3] lib/oe/package: Improve filedeprunner
> subprocess handling
> 
> Currently the exit code of the spawned program isn't checked so it can
> fail and the do_package task will continue merrily upon its way.
> 
> Use subprocess.check_output() to ensure we check the exit code and
> redirect stderr to stdout so if it fails, we see the error output.
> 
> We can then drop the existing exception handling as the subprocess
> exception gives a much better error.
> 
> Signed-off-by: Richard Purdie 
> ---
>  meta/lib/oe/package.py | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
> index fcee389..1e5c3aa 100644
> --- a/meta/lib/oe/package.py
> +++ b/meta/lib/oe/package.py
> @@ -176,8 +176,7 @@ def filedeprunner(arg):
> 
>  def process_deps(pipe, pkg, pkgdest, provides, requires):
>  file = None
> -for line in pipe:
> -line = line.decode("utf-8")
> +for line in pipe.split("\n"):
> 
>  m = file_re.match(line)
>  if m:
> @@ -226,12 +225,8 @@ def filedeprunner(arg):
> 
>  return provides, requires
> 
> -try:
> -dep_popen = subprocess.Popen(shlex.split(rpmdeps) + pkgfiles, 
> stdout=subprocess.PIPE)
> -provides, requires = process_deps(dep_popen.stdout, pkg, pkgdest, 
> provides, requires)
> -except OSError as e:
> -bb.error("rpmdeps: '%s' command failed, '%s'" % 
> (shlex.split(rpmdeps) + pkgfiles, e))
> -raise e
> +output = subprocess.check_output(shlex.split(rpmdeps) + pkgfiles, 
> stderr=subprocess.STDOUT).decode("utf-8")
> +provides, requires = process_deps(output, pkg, pkgdest, provides, 
> requires)
> 
>  return (pkg, provides, requires)
> 
> --
> 2.7.4

Even with these changes applied, I still see texinfo succeed to build 
even when it should not (i.e., without having applied the patch to 
package_deb.bbclass that I just sent).

//Peter

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

Re: [OE-core] [PATCH 0/7] kernel-yocto: conslidated pull request

[Bruce Ashfield]

On 09/01/2017 12:08 PM, Richard Purdie wrote:

On Thu, 2017-08-31 at 15:30 -0400, Bruce Ashfield wrote:

Now that 4.12 + headers are in the tree, this is the next (and
possibly final)
around of -stable updates for the active kernels.

I've built and booted them on all four architectures. But as usual,
this is a lot of combinations to confirm.

The 4.12 update doesn't specifically address the kernel traces that
RP has been seeing, but it also doesn't regress things here. I'd be
interested to know if they help/hinder in the search to find the root
cause.

I'll of course continue to track it down myself.

I also have some functionality fixes as well as configuration updates
as part of this update.


I ran these on the autobuilder. We did see:

https://autobuilder.yocto.io/builders/nightly-ppc/builds/465

which is the latest 4.12 kernel and the latest qemu hanging with no
boot output (but the pid did appear).

So we're still seeing something odd with ppc occasionally. Why? Don't
know :(


The only thing crappier than IDE support, is the PPC platforms that
qemu supports for system emulation.

I'll continue to try and track down the issues.

Bruce



Cheers,

Richard



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

[OE-core] [PATCH] package_deb.bbclass: Handle colons in dependencies

[Peter Kjellerstedt]

Perl dependencies may look as "Perl(Foo::Bar)", but dpkg does not
support the non-alphanumeric characters. There was already special
handling present for turning '(' and ')' into '__'. This change does
the same for ':'.

Signed-off-by: Peter Kjellerstedt 
---
 meta/classes/package_deb.bbclass | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/meta/classes/package_deb.bbclass b/meta/classes/package_deb.bbclass
index c5824aab97..83baa6c21b 100644
--- a/meta/classes/package_deb.bbclass
+++ b/meta/classes/package_deb.bbclass
@@ -192,8 +192,8 @@ def deb_write_pkg(pkg, d):
 mapping_rename_hook(localdata)
 
 def debian_cmp_remap(var):
-# dpkg does not allow for '(' or ')' in a dependency name
-# replace these instances with '__' and '__'
+# dpkg does not allow for '(', ')' or ':' in a dependency name
+# Replace any instances of them with '__'
 #
 # In debian '>' and '<' do not mean what it appears they mean
 #   '<' = less or equal
@@ -202,8 +202,7 @@ def deb_write_pkg(pkg, d):
 #
 for dep in var:
 if '(' in dep:
-newdep = dep.replace('(', '__')
-newdep = newdep.replace(')', '__')
+newdep = re.sub(r'[(:)]', '__', dep)
 if newdep != dep:
 var[newdep] = var[dep]
 del var[dep]
-- 
2.12.0

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

Re: [OE-core] [PATCH 0/7] kernel-yocto: conslidated pull request

[Richard Purdie]

On Thu, 2017-08-31 at 15:30 -0400, Bruce Ashfield wrote:
> Now that 4.12 + headers are in the tree, this is the next (and
> possibly final)
> around of -stable updates for the active kernels.
> 
> I've built and booted them on all four architectures. But as usual,
> this is a lot of combinations to confirm.
> 
> The 4.12 update doesn't specifically address the kernel traces that
> RP has been seeing, but it also doesn't regress things here. I'd be
> interested to know if they help/hinder in the search to find the root
> cause.
> 
> I'll of course continue to track it down myself.
> 
> I also have some functionality fixes as well as configuration updates
> as part of this update.

I ran these on the autobuilder. We did see:

https://autobuilder.yocto.io/builders/nightly-ppc/builds/465

which is the latest 4.12 kernel and the latest qemu hanging with no
boot output (but the pid did appear).

So we're still seeing something odd with ppc occasionally. Why? Don't
know :(

Cheers,

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

[OE-core] [PATCH 2/2] package_manager: Clean up horrible 'None' return values

[Richard Purdie]

If this fails the exception will now be raised. Lets use that and drop
all this 'None' return value ugliness.

Signed-off-by: Richard Purdie 
---
 meta/lib/oe/package_manager.py | 19 ---
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index 5efb286..994e462 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -17,18 +17,11 @@ from oe.gpg_sign import get_signer
 def create_index(arg):
 index_cmd = arg
 
-try:
-bb.note("Executing '%s' ..." % index_cmd)
-result = subprocess.check_output(index_cmd, stderr=subprocess.STDOUT, 
shell=True).decode("utf-8")
-except subprocess.CalledProcessError as e:
-return("Index creation command '%s' failed with return code %d:\n%s" %
-   (e.cmd, e.returncode, e.output.decode("utf-8")))
-
+bb.note("Executing '%s' ..." % index_cmd)
+result = subprocess.check_output(index_cmd, stderr=subprocess.STDOUT, 
shell=True).decode("utf-8")
 if result:
 bb.note(result)
 
-return None
-
 """
 This method parse the output from the package managerand return
 a dictionary with the information of the packages. This is used
@@ -164,9 +157,7 @@ class OpkgIndexer(Indexer):
 bb.note("There are no packages in %s!" % self.deploy_dir)
 return
 
-result = oe.utils.multiprocess_exec(index_cmds, create_index)
-if result:
-bb.fatal('%s' % ('\n'.join(result)))
+oe.utils.multiprocess_exec(index_cmds, create_index)
 
 if signer:
 feed_sig_type = self.d.getVar('PACKAGE_FEED_GPG_SIGNATURE_TYPE')
@@ -247,9 +238,7 @@ class DpkgIndexer(Indexer):
 bb.note("There are no packages in %s" % self.deploy_dir)
 return
 
-result = oe.utils.multiprocess_exec(index_cmds, create_index)
-if result:
-bb.fatal('%s' % ('\n'.join(result)))
+oe.utils.multiprocess_exec(index_cmds, create_index)
 if self.d.getVar('PACKAGE_FEED_SIGN') == '1':
 raise NotImplementedError('Package feed signing not implementd for 
dpkg')
 
-- 
2.7.4

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

[OE-core] [PATCH 1/2] package: Change PACKAGE_BBCLASS_VERSION

[Richard Purdie]

The silent rpmdeps failures fixed in a preceeding commit mean we
need to rerun all packaging.

Signed-off-by: Richard Purdie 
---
 meta/classes/package.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index a051617..7a62181 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -2073,7 +2073,7 @@ python do_package () {
 # cache.  This is useful if an item this class depends on changes in a
 # way that the output of this class changes.  rpmdeps is a good example
 # as any change to rpmdeps requires this to be rerun.
-# PACKAGE_BBCLASS_VERSION = "1"
+# PACKAGE_BBCLASS_VERSION = "2"
 
 # Init cachedpath
 global cpath
-- 
2.7.4

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

Re: [OE-core] [PATCH] initramfs-live-boot: disable systemd-update-done.service on live images

[Randy MacLeod]

On 2017-08-31 01:00 PM, Burton, Ross wrote:
On 31 August 2017 at 17:57, Carlos Alberto Lopez Perez 
> wrote:


Better done than promised! :)
https://github.com/systemd/systemd/issues/6716



And staged :)

Ross



and closed by Mr Poettering as "Not a bug" :-/

--
# Randy MacLeod.  WR Linux
# Wind River an Intel Company
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] package_manager.py: Add PACKAGE_ENABLE_FILELIST option to OpkgIndexer

[Richard Purdie]

On Fri, 2017-09-01 at 16:04 +0300, Alexander Kanavin wrote:
> On 08/31/2017 09:46 PM, Haris Okanovic wrote:
> > 
> > Setting PACKAGE_ENABLE_FILELIST option generates Packages.filelist
> > on
> > `bitbake package-index`, which is index of files provided by each
> > IPK package in the feed. It's useful for figuring out which package
> > provides a particular file/program/library/etc.
> > 
> > Disabled by default since generating a filelist involves reading
> > the
> > payload of every package in the feed, a time and IO intensive
> > operation
> > many users won't want to run. Those who do may flip this switch.
> > 
> > Testing:
> >   * Built an opkg index with PACKAGE_ENABLE_FILELIST unset and
> > verified
> > no Packages.filelist are generated.
> >   * Built with PACKAGE_ENABLE_FILELIST="1" and verified each
> > subfeed
> > has Packages.filelist; took ~3min longer for 8,200 IPKs.
> 
>
> The only way to discover that this option exists is to read the code
> for OpkgIndexer. And it's specific to opkg, which is not reflected in
> the option name at all.
> 
> Can you instead just place the index generation into a custom recipe 
> that depends on package-index recipe?

I'm going to disagree with that, I don't want a separate recipe for
this and I'm not sure that makes sense.

I'm ok with adding an option but we need to come up with a better
namespace. How about OPKG_PACKAGE_INDEX_FILELIST_GEN?

(says its package index and opkg specific)

Cheers,

Richard


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

[OE-core] [PATCH 3/3] staging: Fix a logic error which caused dependency removal

[Richard Purdie]

There was a logic error in the dependency cleanup code which meant
it would remove dependencies which other tasks still depended upon.
Fix the path names so the comparisions work as intended.

This fixes dependencies accidentally disappearing from sysroots
under certain reconfiguration situations.

Signed-off-by: Richard Purdie 
---
 meta/classes/staging.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index eb06f39..f409e9d 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -416,8 +416,8 @@ python extend_recipe_sysroot() {
 for l in f:
 l = l.strip()
 if l not in installed:
-l = depdir + "/" + l
-if not os.path.exists(l):
+fl = depdir + "/" + l
+if not os.path.exists(fl):
 # Was likely already uninstalled
 continue
 potential.append(l)
-- 
2.7.4

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

[OE-core] [PATCH 2/3] lib/oe/utils: Handle exceptions in multiprocess_exec

[Richard Purdie]

Currently exceptions that happen in pool commands are ignored. Any errors
would be printed on the console but everything else is silent.

Switch to use pool.map_async which allows for an error_callback which
we can use to detect exceptions and make sure these errors are handled.

Signed-off-by: Richard Purdie 
---
 meta/lib/oe/utils.py | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
index 822d0cd..643ab78 100644
--- a/meta/lib/oe/utils.py
+++ b/meta/lib/oe/utils.py
@@ -224,25 +224,30 @@ def multiprocess_exec(commands, function):
 def init_worker():
 signal.signal(signal.SIGINT, signal.SIG_IGN)
 
+fails = []
+
+def failures(res):
+fails.append(res)
+
 nproc = min(multiprocessing.cpu_count(), len(commands))
 pool = bb.utils.multiprocessingpool(nproc, init_worker)
-imap = pool.imap(function, commands)
 
 try:
-res = list(imap)
+mapresult = pool.map_async(function, commands, error_callback=failures)
+
 pool.close()
 pool.join()
-results = []
-for result in res:
-if result is not None:
-results.append(result)
-return results
-
+results = mapresult.get()
 except KeyboardInterrupt:
 pool.terminate()
 pool.join()
 raise
 
+if fails:
+raise fails[0]
+
+return results
+
 def squashspaces(string):
 import re
 return re.sub("\s+", " ", string).strip()
-- 
2.7.4

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

[OE-core] [PATCH 1/3] lib/oe/package: Improve filedeprunner subprocess handling

[Richard Purdie]

Currently the exit code of the spawned program isn't checked so it can
fail and the do_package task will continue merrily upon its way.

Use subprocess.check_output() to ensure we check the exit code and
redirect stderr to stdout so if it fails, we see the error output.

We can then drop the existing exception handling as the subprocess
exception gives a much better error.

Signed-off-by: Richard Purdie 
---
 meta/lib/oe/package.py | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index fcee389..1e5c3aa 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -176,8 +176,7 @@ def filedeprunner(arg):
 
 def process_deps(pipe, pkg, pkgdest, provides, requires):
 file = None
-for line in pipe:
-line = line.decode("utf-8")
+for line in pipe.split("\n"):
 
 m = file_re.match(line)
 if m:
@@ -226,12 +225,8 @@ def filedeprunner(arg):
 
 return provides, requires
 
-try:
-dep_popen = subprocess.Popen(shlex.split(rpmdeps) + pkgfiles, 
stdout=subprocess.PIPE)
-provides, requires = process_deps(dep_popen.stdout, pkg, pkgdest, 
provides, requires)
-except OSError as e:
-bb.error("rpmdeps: '%s' command failed, '%s'" % (shlex.split(rpmdeps) 
+ pkgfiles, e))
-raise e
+output = subprocess.check_output(shlex.split(rpmdeps) + pkgfiles, 
stderr=subprocess.STDOUT).decode("utf-8")
+provides, requires = process_deps(output, pkg, pkgdest, provides, requires)
 
 return (pkg, provides, requires)
 
-- 
2.7.4

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

Re: [OE-core] [PATCH] mkelfimage: Add update convert.bin.c file

[Otavio Salvador]

On Thu, Aug 31, 2017 at 7:43 PM, Saul Wold  wrote:
> This is a compile code fragment that has an elf signature, it needs to be
> updated for the newer tools.
>
> After 2.4 we will be removing the elf Image type as it has been expunged
> from the coreboot repo since 2014.
>
> [YOCTO #11967]
>
> Signed-off-by: Saul Wold 

Why not remove it now?

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] package_manager.py: Add PACKAGE_ENABLE_FILELIST option to OpkgIndexer

[Alexander Kanavin]

On 08/31/2017 09:46 PM, Haris Okanovic wrote:

Setting PACKAGE_ENABLE_FILELIST option generates Packages.filelist on
`bitbake package-index`, which is index of files provided by each
IPK package in the feed. It's useful for figuring out which package
provides a particular file/program/library/etc.

Disabled by default since generating a filelist involves reading the
payload of every package in the feed, a time and IO intensive operation
many users won't want to run. Those who do may flip this switch.

Testing:
  * Built an opkg index with PACKAGE_ENABLE_FILELIST unset and verified
no Packages.filelist are generated.
  * Built with PACKAGE_ENABLE_FILELIST="1" and verified each subfeed
has Packages.filelist; took ~3min longer for 8,200 IPKs.


The only way to discover that this option exists is to read the code for 
OpkgIndexer. And it's specific to opkg, which is not reflected in the 
option name at all.


Can you instead just place the index generation into a custom recipe 
that depends on package-index recipe?



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

[OE-core] ✗ patchtest: failure for gstreamer1.0-plugins-good: fix 4k playback for v4l2 decoder

[Patchwork]

== Series Details ==

Series: gstreamer1.0-plugins-good: fix 4k playback for v4l2 decoder
Revision: 1
URL   : https://patchwork.openembedded.org/series/8639/
State : failure

== Summary ==


Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:



* Issue A patch file has been added, but does not have a 
Signed-off-by tag [test_signed_off_by_presence] 
  Suggested fixSign off the added patch file 
(meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/0001-v4l2-Fix-4K-colorimetry.patch)



If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).

---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe

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

[OE-core] [PATCH] gstreamer1.0-plugins-good: fix 4k playback for v4l2 decoder

[Nicolas Dechesne]

Backport a fix already merged upstream in master and 1.12 branch, it fixes 4K 
video
playback on any platform that uses v4l2 codecs, such as Dragonboard 820c.

Signed-off-by: Nicolas Dechesne 
---
 .../0001-v4l2-Fix-4K-colorimetry.patch | 47 ++
 .../gstreamer/gstreamer1.0-plugins-good_1.12.2.bb  |  1 +
 2 files changed, 48 insertions(+)
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/0001-v4l2-Fix-4K-colorimetry.patch

diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/0001-v4l2-Fix-4K-colorimetry.patch
 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/0001-v4l2-Fix-4K-colorimetry.patch
new file mode 100644
index 00..84d22e6b0e
--- /dev/null
+++ 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good/0001-v4l2-Fix-4K-colorimetry.patch
@@ -0,0 +1,47 @@
+From 545646cccba243236e10362fe7325f89be57da1f Mon Sep 17 00:00:00 2001
+From: Nicolas Dufresne 
+Date: Tue, 18 Jul 2017 11:28:37 -0400
+Subject: [PATCH] v4l2: Fix 4K colorimetry
+
+Since 1.6, the transfer function for BT2020 has been changed from BT709
+to BT2020_12. It's the same function, but with more precision. As a side
+effect, the V4L2 colorpsace didn't match GStreamer colorspace. When
+GStreamer ended up making a guess, it would not match anything supported
+by V4L2 anymore. This this by using BT2020_12 for BT2020 colorspace and
+BT2020 transfer function in replacement of BT709 whenever a 4K
+resolution is detected.
+
+Upstream-Status: Backport
+
+---
+ sys/v4l2/gstv4l2object.c | 7 +--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/sys/v4l2/gstv4l2object.c b/sys/v4l2/gstv4l2object.c
+index 61244455f..aae2c55e7 100644
+--- a/sys/v4l2/gstv4l2object.c
 b/sys/v4l2/gstv4l2object.c
+@@ -1960,7 +1960,7 @@ gst_v4l2_object_get_colorspace (struct v4l2_format *fmt,
+ case V4L2_COLORSPACE_BT2020:
+   cinfo->range = GST_VIDEO_COLOR_RANGE_16_235;
+   cinfo->matrix = GST_VIDEO_COLOR_MATRIX_BT2020;
+-  cinfo->transfer = GST_VIDEO_TRANSFER_BT709;
++  cinfo->transfer = GST_VIDEO_TRANSFER_BT2020_12;
+   cinfo->primaries = GST_VIDEO_COLOR_PRIMARIES_BT2020;
+   break;
+ case V4L2_COLORSPACE_SMPTE240M:
+@@ -2062,7 +2062,10 @@ gst_v4l2_object_get_colorspace (struct v4l2_format *fmt,
+ 
+   switch (transfer) {
+ case V4L2_XFER_FUNC_709:
+-  cinfo->transfer = GST_VIDEO_TRANSFER_BT709;
++  if (fmt->fmt.pix.height > 2160)
++cinfo->transfer = GST_VIDEO_TRANSFER_BT2020_12;
++  else
++cinfo->transfer = GST_VIDEO_TRANSFER_BT709;
+   break;
+ case V4L2_XFER_FUNC_SRGB:
+   cinfo->transfer = GST_VIDEO_TRANSFER_SRGB;
+-- 
+2.14.1
+
diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.12.2.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.12.2.bb
index 3d38f007dc..f9593c99aa 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.12.2.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.12.2.bb
@@ -10,6 +10,7 @@ SRC_URI = " \
 file://avoid-including-sys-poll.h-directly.patch \
 file://ensure-valid-sentinel-for-gst_structure_get.patch \
 file://0001-introspection.m4-prefix-pkgconfig-paths-with-PKG_CON.patch \
+file://0001-v4l2-Fix-4K-colorimetry.patch \
 "
 SRC_URI[md5sum] = "20254217d9805484532e08ff1c3aa296"
 SRC_URI[sha256sum] = 
"5591ee7208ab30289a30658a82b76bf87169c927572d9b794f3a41ed48e1ee96"
-- 
2.11.0

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

Re: [OE-core] [PATCH v2 0/2] Make source code browsable locally - devtool srctree

[Peter Kjellerstedt]

> -Original Message-
> From: Andre McCurdy [mailto:armccu...@gmail.com]
> Sent: den 31 augusti 2017 22:10
> To: Peter Kjellerstedt 
> Cc: Tobias Hagelborn ; OE Core mailing list
> 
> Subject: Re: [OE-core] [PATCH v2 0/2] Make source code browsable
> locally - devtool srctree
> 
> On Wed, Aug 30, 2017 at 11:32 PM, Peter Kjellerstedt
>  wrote:
> >>
> >> Just for reference, I think you could achieve something quite
> similar
> >> with:
> >>
> >>   bitbake  --runall clean  ( or rm -rf tmp )
> >>   bitbake  --runall patch
> >
> > Yes, but the drawback with this is that to find the source code for
> the
> > individual packages, you have to dive down into tmp/work/... which
> can
> > be quite discouraging for someone who is not an expert in bitbake.
> What
> > our developers requested was a way to get easy access to all the
> source
> > code being used, typically to be able to search through it all
> looking
> > for some specific feature.
> 
> Right. I wasn't trying to suggest that the two approaches were
> completely equivalent, just drawing some attention to the bitbake
> --runall option, which was added fairly recently (specifically to
> solve this problem).
> 
> The directory structure split under tmp/work between arch and machine
> specific recipes might be a little confusing but obviously serves a
> purpose (target and native sources may need different sets of patches,
> etc) so maybe worth the effort to explain to developers. Below that
> level I don't think there are many surprises in the paths to the
> sources directories?

Well, the most common request we've gotten from the developers is that 
they want to be able to search through all the sources, e.g., to find 
out where a particular function is used. The tmp directory does not 
lend itself very well to this, given that it also contains all build 
trees, applied patches and other meta information that bitbake needs.
Thus the idea for the parallel tree with only the source references.

//Peter

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

Re: [OE-core] [PATCH][resend] insane.bbclass: Warn if ${COREBASE}/LICENSE is used

[Richard Purdie]

On Fri, 2017-09-01 at 10:38 +0100, Burton, Ross wrote:
> This and the other patch have been wrapped by your mailer, and also
> base64 encoded so I can't trivially fix the whitespace.  Are they in
> a branch, or can you resend them using git-send-email?

I found them on a branch and applied it in -next.

Cheers,

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

Re: [OE-core] [PATCH] qemu: upgrade to version 2.10.0

[Martin Jansa]

I don't know how accelerated GL will be in the end, but this commit:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=474114b7305cc1be7c2ee8ba5267be159a9d56e3
made it possible.

I've built qemu with my Gentoo host with virgl and spice support, and I
plan to try how fast it goes.


On Fri, Sep 1, 2017 at 12:09 PM, Burton, Ross  wrote:

> On 1 September 2017 at 11:03, Martin Jansa  wrote:
>
>> Is there any ticket requesting virgl support enabled in qemu-native? It
>> might depend on providing virglrenderer-native, libsdl2-native,
>> epoxy-native and maybe even mesa-native.
>>
>
> It's been something that I've been meaning to look at for a long time, but
> between my build machine being headless and other stuff being more
> important I've not got around to it.  I've not dug into the details: if you
> run headless qemu and a spice client, presumably you don't get any real GL
> acceleration?
>
> Patches welcome, as always.  All the extra build dependencies means I
> expect it will be off by default, but having the option would be great.
>
> Ross
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][resend] insane.bbclass: Warn if ${COREBASE}/LICENSE is used

[Paul Eggleton]

Hi Saul

On Friday, 1 September 2017 10:40:58 AM NZST Saul Wold wrote:
> The top level LICENSE file is not actually a license, it refers
> other licenses that are used by Bitbake and Meta-data. Relying
> on this file could cause problems for recipes when this file
> changes, which it is about to.
> 
> Signed-off-by: Saul Wold 
> ---
>  meta/classes/insane.bbclass | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
> index 479d39c..6d20eb6 100644
> --- a/meta/classes/insane.bbclass
> +++ b/meta/classes/insane.bbclass
> @@ -659,7 +659,7 @@ python populate_lic_qa_checksum() {
>  sane = package_qa_handle_error("license-checksum", pn + ":
> Recipe file fetches files and does not have license file information
> (LIC_FILES_CHKSUM)", d)
>  
>  srcdir = d.getVar('S')
> -
> +corebase_licensefile = d.getVar('COREBASE') + "/LICENSE"
>  for url in lic_files.split():
>  try:
>  (type, host, path, user, pswd, parm) =
> bb.fetch.decodeurl(url)
> @@ -670,6 +670,10 @@ python populate_lic_qa_checksum() {
>  if not os.path.isfile(srclicfile):
>  package_qa_handle_error("license-checksum", pn + ":
> LIC_FILES_CHKSUM points to an invalid file: " + srclicfile, d)
>  continue
> +
> +if (srclicfile == corebase_licensefile):
> +bb.warn("${COREBASE}/LICENSE is not a valid license file,
> please use '${COMMON_LICENSE_DIR}/MIT' for a MIT License file in
> LIC_FILES_CHKSUM")
> +bb.warn("This will become an error in the next release")

Can this be one bb.warn() call? Otherwise it's considered to be two warnings 
by the UI. Also, it's rare for us to even make such a comment in a warning, 
but I think we would say "in future" rather than "in the next release".

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] qemu: upgrade to version 2.10.0

[Burton, Ross]

On 1 September 2017 at 11:03, Martin Jansa  wrote:

> Is there any ticket requesting virgl support enabled in qemu-native? It
> might depend on providing virglrenderer-native, libsdl2-native,
> epoxy-native and maybe even mesa-native.
>

It's been something that I've been meaning to look at for a long time, but
between my build machine being headless and other stuff being more
important I've not got around to it.  I've not dug into the details: if you
run headless qemu and a spice client, presumably you don't get any real GL
acceleration?

Patches welcome, as always.  All the extra build dependencies means I
expect it will be off by default, but having the option would be great.

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

Re: [OE-core] [PATCH] qemu: upgrade to version 2.10.0

[Martin Jansa]

Is there any ticket requesting virgl support enabled in qemu-native? It
might depend on providing virglrenderer-native, libsdl2-native,
epoxy-native and maybe even mesa-native.

It was shortly enabled in Debian and Ubuntu packages, but then disabled
mostly because it requires sdl2 or gtk graphics backend and sdl2 was
missing some features and gtk was pulling so many dependencies to some
headless servers.

For OE this might be smaller issue or we can try to use spice server to
execute qemu-native on headless builders and only run spice client on
developer workstations. Or in my case qemu-native in headless chroot and
spice client in host OS.

What do you think?

Regards,

On Thu, Aug 31, 2017 at 11:33 PM, Juro Bystricky 
wrote:

> Remove recipes for older versions.
> Remove patches no longer needed.
> Modify the patch "add-ptest-in-makefile.patch" for version 2.10.0
>
> Signed-off-by: Juro Bystricky 
> ---
>  ...0001-osdep-Add-runtime-OFD-lock-detection.patch | 141 
>  ...e-posix-Do-runtime-check-for-ofd-lock-API.patch |  71 --
>  ...support-for-VM-suspend-resume-for-TPM-TIS.patch | 719
> -
>  .../qemu/qemu/add-ptest-in-makefile-v10.patch  |  28 +
>  .../qemu/qemu/add-ptest-in-makefile.patch  |  28 -
>  meta/recipes-devtools/qemu/qemu_2.10.0-rc2.bb  |  59 --
>  meta/recipes-devtools/qemu/qemu_2.10.0.bb  |  58 ++
>  meta/recipes-devtools/qemu/qemu_2.8.1.1.bb |  60 --
>  8 files changed, 86 insertions(+), 1078 deletions(-)
>  delete mode 100644 meta/recipes-devtools/qemu/
> qemu/0001-osdep-Add-runtime-OFD-lock-detection.patch
>  delete mode 100644 meta/recipes-devtools/qemu/qemu/0002-file-posix-Do-
> runtime-check-for-ofd-lock-API.patch
>  delete mode 100644 meta/recipes-devtools/qemu/
> qemu/0004-Add-support-for-VM-suspend-resume-for-TPM-TIS.patch
>  create mode 100644 meta/recipes-devtools/qemu/qemu/add-ptest-in-makefile-
> v10.patch
>  delete mode 100644 meta/recipes-devtools/qemu/qemu/add-ptest-in-makefile.
> patch
>  delete mode 100644 meta/recipes-devtools/qemu/qemu_2.10.0-rc2.bb
>  create mode 100644 meta/recipes-devtools/qemu/qemu_2.10.0.bb
>  delete mode 100644 meta/recipes-devtools/qemu/qemu_2.8.1.1.bb
>
> diff --git 
> a/meta/recipes-devtools/qemu/qemu/0001-osdep-Add-runtime-OFD-lock-detection.patch
> b/meta/recipes-devtools/qemu/qemu/0001-osdep-Add-runtime-
> OFD-lock-detection.patch
> deleted file mode 100644
> index f83f0d2..000
> --- a/meta/recipes-devtools/qemu/qemu/0001-osdep-Add-runtime-
> OFD-lock-detection.patch
> +++ /dev/null
> @@ -1,141 +0,0 @@
> -From ca749954b09b89e22cd69c4949fb7e689b057963 Mon Sep 17 00:00:00 2001
> -From: Fam Zheng 
> -Date: Fri, 11 Aug 2017 19:44:46 +0800
> -Subject: [PATCH 1/2] osdep: Add runtime OFD lock detection
> -
> -Build time check of OFD lock is not sufficient and can cause image open
> -errors when the runtime environment doesn't support it.
> -
> -Add a helper function to probe it at runtime, additionally. Also provide
> -a qemu_has_ofd_lock() for callers to check the status.
> -
> -Signed-off-by: Fam Zheng 
> -Signed-off-by: Kevin Wolf 
> -
> -Upstream-Status: Backport
> -Signed-off-by: Chen Qi 
> 
> - include/qemu/osdep.h |  1 +
> - util/osdep.c | 66 ++
> ++
> - 2 files changed, 57 insertions(+), 10 deletions(-)
> -
> -diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
> -index 3b74f6fcb2..6855b94bbf 100644
>  a/include/qemu/osdep.h
> -+++ b/include/qemu/osdep.h
> -@@ -357,6 +357,7 @@ int qemu_dup(int fd);
> - int qemu_lock_fd(int fd, int64_t start, int64_t len, bool exclusive);
> - int qemu_unlock_fd(int fd, int64_t start, int64_t len);
> - int qemu_lock_fd_test(int fd, int64_t start, int64_t len, bool
> exclusive);
> -+bool qemu_has_ofd_lock(void);
> -
> - #if defined(__HAIKU__) && defined(__i386__)
> - #define FMT_pid "%ld"
> -diff --git a/util/osdep.c b/util/osdep.c
> -index a2863c8e53..a479fedc4a 100644
>  a/util/osdep.c
> -+++ b/util/osdep.c
> -@@ -38,14 +38,6 @@ extern int madvise(caddr_t, size_t, int);
> - #include "qemu/error-report.h"
> - #include "monitor/monitor.h"
> -
> --#ifdef F_OFD_SETLK
> --#define QEMU_SETLK F_OFD_SETLK
> --#define QEMU_GETLK F_OFD_GETLK
> --#else
> --#define QEMU_SETLK F_SETLK
> --#define QEMU_GETLK F_GETLK
> --#endif
> --
> - static bool fips_enabled = false;
> -
> - static const char *hw_version = QEMU_HW_VERSION;
> -@@ -82,6 +74,10 @@ int qemu_madvise(void *addr, size_t len, int advice)
> - }
> -
> - #ifndef _WIN32
> -+
> -+static int fcntl_op_setlk = -1;
> -+static int fcntl_op_getlk = -1;
> -+
> - /*
> -  * Dups an fd and sets the flags
> -  */
> -@@ -149,6 +145,54 @@ static int qemu_parse_fdset(const char *param)
> - return qemu_parse_fd(param);
> - }
> -
> -+static void qemu_probe_lock_ops(void)
> -+{
> -+if (fcntl_op_setlk == -1) {
> -+#ifdef 

Re: [OE-core] [PATCH][resend] insane.bbclass: Warn if ${COREBASE}/LICENSE is used

[Burton, Ross]

This and the other patch have been wrapped by your mailer, and also base64
encoded so I can't trivially fix the whitespace.  Are they in a branch, or
can you resend them using git-send-email?

Ross

On 31 August 2017 at 23:40, Saul Wold  wrote:

> The top level LICENSE file is not actually a license, it refers
> other licenses that are used by Bitbake and Meta-data. Relying
> on this file could cause problems for recipes when this file
> changes, which it is about to.
>
> Signed-off-by: Saul Wold 
> ---
>  meta/classes/insane.bbclass | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
> index 479d39c..6d20eb6 100644
> --- a/meta/classes/insane.bbclass
> +++ b/meta/classes/insane.bbclass
> @@ -659,7 +659,7 @@ python populate_lic_qa_checksum() {
>  sane = package_qa_handle_error("license-checksum", pn + ":
> Recipe file fetches files and does not have license file information
> (LIC_FILES_CHKSUM)", d)
>
>  srcdir = d.getVar('S')
> -
> +corebase_licensefile = d.getVar('COREBASE') + "/LICENSE"
>  for url in lic_files.split():
>  try:
>  (type, host, path, user, pswd, parm) =
> bb.fetch.decodeurl(url)
> @@ -670,6 +670,10 @@ python populate_lic_qa_checksum() {
>  if not os.path.isfile(srclicfile):
>  package_qa_handle_error("license-checksum", pn + ":
> LIC_FILES_CHKSUM points to an invalid file: " + srclicfile, d)
>  continue
> +
> +if (srclicfile == corebase_licensefile):
> +bb.warn("${COREBASE}/LICENSE is not a valid license file,
> please use '${COMMON_LICENSE_DIR}/MIT' for a MIT License file in
> LIC_FILES_CHKSUM")
> +bb.warn("This will become an error in the next release")
>
>  recipemd5 = parm.get('md5', '')
>  beginline, endline = 0, 0
> --
> 2.7.5
>
> --
> ___
> 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] [PATCH] acpica: use update-alternatives for acpixtract

[jackie.huang]

From: Jackie Huang 

acpixtract is both provided by acpica and pmtools, so use
update-alternatives to fix conflicts:

| file /usr/bin/acpixtract conflicts between attempted installs of
  pmtools-20130209+git0+3ebe0e54c5-r0.i586 and acpica-20170303-r0.i586

Signed-off-by: Jackie Huang 
---
 meta/recipes-extended/acpica/acpica_20170303.bb | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-extended/acpica/acpica_20170303.bb 
b/meta/recipes-extended/acpica/acpica_20170303.bb
index 12dfc6da3f..e712ca008d 100644
--- a/meta/recipes-extended/acpica/acpica_20170303.bb
+++ b/meta/recipes-extended/acpica/acpica_20170303.bb
@@ -27,6 +27,11 @@ UPSTREAM_CHECK_URI = "https://acpica.org/downloads;
 
 S = "${WORKDIR}/acpica-unix2-${PV}"
 
+inherit update-alternatives
+
+ALTERNATIVE_PRIORITY = "100"
+ALTERNATIVE_${PN} = "acpixtract"
+
 EXTRA_OEMAKE = "CC='${CC}' 'OPT_CFLAGS=-Wall'"
 
 do_install() {
-- 
2.11.0

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

[OE-core] [PATCH] python-numpy, python3-numpy: Fix CVE-2017-12852

[Dengke Du]

Backport upstream patch to fix CVE-2017-12852

Signed-off-by: Dengke Du 
---
 ...inite-loop-when-creating-np.pad-on-an-emp.patch | 45 ++
 .../python-numpy/python-numpy_1.13.1.bb|  1 +
 .../python-numpy/python3-numpy_1.13.1.bb   |  1 +
 3 files changed, 47 insertions(+)
 create mode 100644 
meta/recipes-devtools/python-numpy/files/0001-BUG-fix-infinite-loop-when-creating-np.pad-on-an-emp.patch

diff --git 
a/meta/recipes-devtools/python-numpy/files/0001-BUG-fix-infinite-loop-when-creating-np.pad-on-an-emp.patch
 
b/meta/recipes-devtools/python-numpy/files/0001-BUG-fix-infinite-loop-when-creating-np.pad-on-an-emp.patch
new file mode 100644
index 000..b9e5856
--- /dev/null
+++ 
b/meta/recipes-devtools/python-numpy/files/0001-BUG-fix-infinite-loop-when-creating-np.pad-on-an-emp.patch
@@ -0,0 +1,45 @@
+From 4170b98e0d5864ef4db1c5704a6e9428c3be9fb8 Mon Sep 17 00:00:00 2001
+From: Iryna Shcherbina 
+Date: Thu, 24 Aug 2017 18:01:43 +0200
+Subject: [PATCH] BUG: fix infinite loop when creating np.pad on an empty array
+
+Upstream-Status: Backport 
[https://github.com/numpy/numpy/pull/9599/commits/6f9ea0abbd305d53f9017debab3a3a591fe0e249]
+CVE: CVE-2017-12852
+Signed-off-by: Dengke Du 
+---
+ numpy/lib/arraypad.py| 3 +++
+ numpy/lib/tests/test_arraypad.py | 4 
+ 2 files changed, 7 insertions(+)
+
+diff --git a/numpy/lib/arraypad.py b/numpy/lib/arraypad.py
+index 2dad99c..294a689 100644
+--- a/numpy/lib/arraypad.py
 b/numpy/lib/arraypad.py
+@@ -1406,6 +1406,9 @@ def pad(array, pad_width, mode, **kwargs):
+ newmat = _append_min(newmat, pad_after, chunk_after, axis)
+ 
+ elif mode == 'reflect':
++if narray.size == 0:
++raise ValueError("There aren't any elements to reflect in 
`array`")
++
+ for axis, (pad_before, pad_after) in enumerate(pad_width):
+ # Recursive padding along any axis where `pad_amt` is too large
+ # for indexing tricks. We can only safely pad the original axis
+diff --git a/numpy/lib/tests/test_arraypad.py 
b/numpy/lib/tests/test_arraypad.py
+index 056aa45..0f71d32 100644
+--- a/numpy/lib/tests/test_arraypad.py
 b/numpy/lib/tests/test_arraypad.py
+@@ -1014,6 +1014,10 @@ class ValueError1(TestCase):
+ assert_raises(ValueError, pad, arr, ((-2, 3), (3, 2)),
+   **kwargs)
+ 
++def test_check_empty_array(self):
++assert_raises(ValueError, pad, [], 4, mode='reflect')
++assert_raises(ValueError, pad, np.ndarray(0), 4, mode='reflect')
++
+ 
+ class ValueError2(TestCase):
+ def test_check_negative_pad_amount(self):
+-- 
+2.8.1
+
diff --git a/meta/recipes-devtools/python-numpy/python-numpy_1.13.1.bb 
b/meta/recipes-devtools/python-numpy/python-numpy_1.13.1.bb
index 63821d3..13e8f4f 100644
--- a/meta/recipes-devtools/python-numpy/python-numpy_1.13.1.bb
+++ b/meta/recipes-devtools/python-numpy/python-numpy_1.13.1.bb
@@ -9,6 +9,7 @@ SRC_URI = 
"https://github.com/${SRCNAME}/${SRCNAME}/releases/download/v${PV}/${S

file://0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch \
file://remove-build-path-in-comments.patch \
file://fix_shebang_f2py.patch \
+   
file://0001-BUG-fix-infinite-loop-when-creating-np.pad-on-an-emp.patch \
${CONFIGFILESURI} "
 
 SRC_URI[md5sum] = "6d459e4a24f5035f720dda3c57716a92"
diff --git a/meta/recipes-devtools/python-numpy/python3-numpy_1.13.1.bb 
b/meta/recipes-devtools/python-numpy/python3-numpy_1.13.1.bb
index 0bf9e91..29874b8 100644
--- a/meta/recipes-devtools/python-numpy/python3-numpy_1.13.1.bb
+++ b/meta/recipes-devtools/python-numpy/python3-numpy_1.13.1.bb
@@ -9,6 +9,7 @@ SRC_URI = 
"https://github.com/${SRCNAME}/${SRCNAME}/releases/download/v${PV}/${S

file://0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch \
file://remove-build-path-in-comments.patch \
file://fix_shebang_f2py.patch \
+   
file://0001-BUG-fix-infinite-loop-when-creating-np.pad-on-an-emp.patch \
${CONFIGFILESURI} "
 SRC_URI[md5sum] = "6d459e4a24f5035f720dda3c57716a92"
 SRC_URI[sha256sum] = 
"de020ec06f1e9ce1115a50161a38bf8d4c2525379900f9cb478cc613a1e7cd93"
-- 
2.8.1

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

Re: [OE-core] [PATCH v4] initramfs-framework: Change recipe to be allarch

[Patrick Ohly]

On Wed, 2017-08-30 at 11:39 +0200, Patrick Ohly wrote:
> As I said before ("Re: [OE-core] [PATCH v6 1/1] initramfs-framework:
> module to support boot live image" from July 31st), I consider it a
> mistake that support for live boot with all its dependencies was
> added directly to initramfs-framework.bb.
> 
> I was in a hurry at the time and therefore didn't file a bug, but I
> can also do that.

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

-- 
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/2] rootfs-postcommands: add test for unsatisfied RRECOMMENDS

[Jose Alarcon]

On 26.08.2017 14:26, Jose Alarcon wrote:
> The do_rootfs log contains a number of unsatisfied package
> recommendations. At the moment those are only visible when
> reviewing the rootfs log.
>
> This patch adds an extra check to surface any unsatisfied
> recommendation  as WARNINGS to the build output when
> "debug-tweaks" is enabled.
>
> Signed-off-by: Jose Alarcon 

Hello,

Gentle reminder, has anyone have a chance to review this patch?

Thanks,

--
Jose Alarcon

> ---
>  meta/classes/rootfs-postcommands.bbclass | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/meta/classes/rootfs-postcommands.bbclass 
> b/meta/classes/rootfs-postcommands.bbclass
> index fb36bad..e7ef382 100644
> --- a/meta/classes/rootfs-postcommands.bbclass
> +++ b/meta/classes/rootfs-postcommands.bbclass
> @@ -50,6 +50,9 @@ python () {
>  d.appendVar('ROOTFS_POSTPROCESS_COMMAND', 
> '${SORT_PASSWD_POSTPROCESS_COMMAND}')
>  }
>  
> +# Enable QA check for unsatisfied recommendations if debug-tweaks is enabled
> +ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", 
> "debug-tweaks", "rootfs_log_check_recommends; ", "",d)}'
> +
>  systemd_create_users () {
>   for conffile in ${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd.conf 
> ${IMAGE_ROOTFS}/usr/lib/sysusers.d/systemd-remote.conf; do
>   [ -e $conffile ] || continue
> @@ -307,3 +310,15 @@ python write_image_test_data() {
> os.remove(testdata_link)
>  os.symlink(os.path.basename(testdata), testdata_link)
>  }
> +
> +# Check for unsatisfied recommendations (RRECOMMENDS)
> +python rootfs_log_check_recommends() {
> +log_path = d.expand("${T}/log.do_rootfs")
> +with open(log_path, 'r') as log:
> +for line in log:
> +if 'log_check' in line:
> +continue
> +
> +if 'unsatisfied recommendation for' in line:
> +bb.warn('[log_check] %s: %s' % (d.getVar('PN', True), line))
> +}

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