Re: [OE-core] [PATCH] mkefidisk.sh: add deprecation warning to the output

[Christopher Larson]

On Thu, Nov 3, 2016 at 2:42 PM, Khem Raj  wrote:

> > On Oct 31, 2016, at 3:46 AM, Ed Bartosh 
> wrote:
> >
> > mkefidisk.sh will soon be deprecated in favor of .wic images.
> >
> > Added deprecation warning to the script to inform users that
> > this script will soon be removed from the codebase.
> >
> > Signed-off-by: Ed Bartosh 
> > ---
> > scripts/contrib/mkefidisk.sh | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
> > index d8db3c0..a175895 100755
> > --- a/scripts/contrib/mkefidisk.sh
> > +++ b/scripts/contrib/mkefidisk.sh
> > @@ -20,6 +20,11 @@
> >
> > LANG=C
> >
> > +echo
> > +echo "WARNING: This script is deprecated and will be removed soon."
> > +echo "Please consider using wic EFI images instead."
> > +echo
> > +
>
> is .wic image dd’able directly ?
>

Yes, that’s the point :) Though I prefer bmaptool w/ IMAGE_FSTYPES +=
“wic.bmap” personally, don’t have to rely on the file keeping its
sparseness when scp’ing it around and whatnot.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2 1/1] initrdscripts: add support for NVME target install

[Joe Konno]

From: Joe Konno 

Add awareness of /dev/nvme* block devices to install scripts. As presently
written, installer knows only of /dev/sd* and /dev/mmcblk* block devices.
Building upon scaffolding put in place by Awais in...

80ec9f627915 ("initrdscripts: handle mmc device as installer medium")

Signed-off-by: Joe Konno 
---
 meta/recipes-core/initrdscripts/files/init-install-efi.sh | 5 -
 meta/recipes-core/initrdscripts/files/init-install.sh | 5 -
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/initrdscripts/files/init-install-efi.sh 
b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
index 441e25238d24..ffb709c1ce6a 100644
--- a/meta/recipes-core/initrdscripts/files/init-install-efi.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
@@ -22,6 +22,8 @@ live_dev_name=${live_dev_name#\/dev/}
 case $live_dev_name in
 mmcblk*)
 ;;
+nvme*)
+;;
 *)
 live_dev_name=${live_dev_name%%[0-9]*}
 ;;
@@ -146,7 +148,8 @@ swap_start=$((rootfs_end))
 # 2) they are detected asynchronously (need rootwait)
 rootwait=""
 part_prefix=""
-if [ ! "${device#/dev/mmcblk}" = "${device}" ]; then
+if [ ! "${device#/dev/mmcblk}" = "${device}" ] || \
+   [ ! "${device#/dev/nvme}" = "${device}" ]; then
 part_prefix="p"
 rootwait="rootwait"
 fi
diff --git a/meta/recipes-core/initrdscripts/files/init-install.sh 
b/meta/recipes-core/initrdscripts/files/init-install.sh
index 04ce5fb4b5d5..572613ecd4cd 100644
--- a/meta/recipes-core/initrdscripts/files/init-install.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install.sh
@@ -21,6 +21,8 @@ live_dev_name=${live_dev_name#\/dev/}
 case $live_dev_name in
 mmcblk*)
 ;;
+nvme*)
+;;
 *)
 live_dev_name=${live_dev_name%%[0-9]*}
 ;;
@@ -153,7 +155,8 @@ swap_start=$((rootfs_end))
 # 2) they are detected asynchronously (need rootwait)
 rootwait=""
 part_prefix=""
-if [ ! "${device#/dev/mmcblk}" = "${device}" ]; then
+if [ ! "${device#/dev/mmcblk}" = "${device}" ] || \
+   [ ! "${device#/dev/nvme}" = "${device}" ]; then
 part_prefix="p"
 rootwait="rootwait"
 fi
-- 
2.7.4

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

Re: [OE-core] [PATCH] oe-tests: Migrate tests from /oe/test to /oeqa/selftest/oe-tests

[Benjamin Esquivel]

Hello José, a couple of comments below.

On Thu, 2016-11-03 at 17:46 -0500, jose.perez.carra...@linux.intel.com
wrote:
> From: Jose Perez Carranza 
> 
> Currently the unittests for scripts on meta/lib/oe are not being
> executed by any suite hence the best option is migrate them to
> meta/lib/oeqa/selftest to be executed along with the selftest suite.
> 
How much more time do these tests add to a selftest execution?
> [YOCTO #7376]
> 
> Signed-off-by: Jose Perez Carranza  om>
> ---
>  meta/lib/oe/tests/__init__.py   |  0
>  meta/lib/oe/tests/test_elf.py   | 21 ---
>  meta/lib/oe/tests/test_license.py   | 68 -
> -
>  meta/lib/oe/tests/test_path.py  | 89 -
> ---
>  meta/lib/oe/tests/test_types.py | 62 -
> ---
>  meta/lib/oe/tests/test_utils.py | 51 
>  meta/lib/oeqa/selftest/oe_tests/__init__.py |  0
>  meta/lib/oeqa/selftest/oe_tests/elf.py  | 22 +++
>  meta/lib/oeqa/selftest/oe_tests/license.py  | 69
> ++
>  meta/lib/oeqa/selftest/oe_tests/path.py | 90
> +
>  meta/lib/oeqa/selftest/oe_tests/types.py| 61 +++
>  meta/lib/oeqa/selftest/oe_tests/utils.py| 52 +
>  12 files changed, 294 insertions(+), 291 deletions(-)
>  delete mode 100644 meta/lib/oe/tests/__init__.py
>  delete mode 100644 meta/lib/oe/tests/test_elf.py
>  delete mode 100644 meta/lib/oe/tests/test_license.py
>  delete mode 100644 meta/lib/oe/tests/test_path.py
>  delete mode 100644 meta/lib/oe/tests/test_types.py
>  delete mode 100644 meta/lib/oe/tests/test_utils.py
>  create mode 100644 meta/lib/oeqa/selftest/oe_tests/__init__.py
selftest has no other dir in it and this dir name of oe_test makes
little sense if you see it in the context of oeqa/selftest/oe_test. I
suggest using a dir name that brings some additional info as to what is
inside of it or try and see how to integrate these tests into the
selftest/ plain structure. 
>  create mode 100644 meta/lib/oeqa/selftest/oe_tests/elf.py
>  create mode 100644 meta/lib/oeqa/selftest/oe_tests/license.py
>  create mode 100644 meta/lib/oeqa/selftest/oe_tests/path.py
>  create mode 100644 meta/lib/oeqa/selftest/oe_tests/types.py
>  create mode 100644 meta/lib/oeqa/selftest/oe_tests/utils.py
> 
> diff --git a/meta/lib/oe/tests/__init__.py
> b/meta/lib/oe/tests/__init__.py
> deleted file mode 100644
> index e69de29..000
> diff --git a/meta/lib/oe/tests/test_elf.py
> b/meta/lib/oe/tests/test_elf.py
> deleted file mode 100644
> index 1f59037..000
> --- a/meta/lib/oe/tests/test_elf.py
> +++ /dev/null
> @@ -1,21 +0,0 @@
> -import unittest
> -import oe.qa
> -
> -class TestElf(unittest.TestCase):
> -def test_machine_name(self):
> -"""
> -Test elf_machine_to_string()
> -"""
> -self.assertEqual(oe.qa.elf_machine_to_string(0x02), "SPARC")
> -self.assertEqual(oe.qa.elf_machine_to_string(0x03), "x86")
> -self.assertEqual(oe.qa.elf_machine_to_string(0x08), "MIPS")
> -self.assertEqual(oe.qa.elf_machine_to_string(0x14),
> "PowerPC")
> -self.assertEqual(oe.qa.elf_machine_to_string(0x28), "ARM")
> -self.assertEqual(oe.qa.elf_machine_to_string(0x2A),
> "SuperH")
> -self.assertEqual(oe.qa.elf_machine_to_string(0x32), "IA-64")
> -self.assertEqual(oe.qa.elf_machine_to_string(0x3E), "x86-
> 64")
> -self.assertEqual(oe.qa.elf_machine_to_string(0xB7),
> "AArch64")
> -
> -self.assertEqual(oe.qa.elf_machine_to_string(0x00), "Unknown
> (0)")
> -self.assertEqual(oe.qa.elf_machine_to_string(0xDEADBEEF),
> "Unknown (3735928559)")
> -self.assertEqual(oe.qa.elf_machine_to_string("foobar"),
> "Unknown ('foobar')")
> diff --git a/meta/lib/oe/tests/test_license.py
> b/meta/lib/oe/tests/test_license.py
> deleted file mode 100644
> index c36..000
> --- a/meta/lib/oe/tests/test_license.py
> +++ /dev/null
> @@ -1,68 +0,0 @@
> -import unittest
> -import oe.license
> -
> -class SeenVisitor(oe.license.LicenseVisitor):
> -def __init__(self):
> -self.seen = []
> -oe.license.LicenseVisitor.__init__(self)
> -
> -def visit_Str(self, node):
> -self.seen.append(node.s)
> -
> -class TestSingleLicense(unittest.TestCase):
> -licenses = [
> -"GPLv2",
> -"LGPL-2.0",
> -"Artistic",
> -"MIT",
> -"GPLv3+",
> -"FOO_BAR",
> -]
> -invalid_licenses = ["GPL/BSD"]
> -
> -@staticmethod
> -def parse(licensestr):
> -visitor = SeenVisitor()
> -visitor.visit_string(licensestr)
> -return visitor.seen
> -
> -def test_single_licenses(self):
> -for license in self.licenses:
> -licenses = self.parse(license)
> -self.assertListEqual(licenses, [license])
> -
> -

[OE-core] [PATCH v1 1/1] initrdscripts: add support for NVME target install

[Joe Konno]

From: Joe Konno 

Add awareness of /dev/nvme* block devices to install scripts. As presently
written, installer knows only of /dev/sd* and /dev/mmcblk* block devices.
Building upon scaffolding put in place by Awais in...

80ec9f627915 ("initrdscripts: handle mmc device as installer medium")

Signed-off-by: Joe Konno 
---
 meta/recipes-core/initrdscripts/files/init-install.sh | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/initrdscripts/files/init-install.sh 
b/meta/recipes-core/initrdscripts/files/init-install.sh
index 04ce5fb4b5d5..572613ecd4cd 100644
--- a/meta/recipes-core/initrdscripts/files/init-install.sh
+++ b/meta/recipes-core/initrdscripts/files/init-install.sh
@@ -21,6 +21,8 @@ live_dev_name=${live_dev_name#\/dev/}
 case $live_dev_name in
 mmcblk*)
 ;;
+nvme*)
+;;
 *)
 live_dev_name=${live_dev_name%%[0-9]*}
 ;;
@@ -153,7 +155,8 @@ swap_start=$((rootfs_end))
 # 2) they are detected asynchronously (need rootwait)
 rootwait=""
 part_prefix=""
-if [ ! "${device#/dev/mmcblk}" = "${device}" ]; then
+if [ ! "${device#/dev/mmcblk}" = "${device}" ] || \
+   [ ! "${device#/dev/nvme}" = "${device}" ]; then
 part_prefix="p"
 rootwait="rootwait"
 fi
-- 
2.7.4

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

[OE-core] [PATCH] oe-tests: Migrate tests from /oe/test to /oeqa/selftest/oe-tests

[jose . perez . carranza]

From: Jose Perez Carranza 

Currently the unittests for scripts on meta/lib/oe are not being
executed by any suite hence the best option is migrate them to
meta/lib/oeqa/selftest to be executed along with the selftest suite.

[YOCTO #7376]

Signed-off-by: Jose Perez Carranza 
---
 meta/lib/oe/tests/__init__.py   |  0
 meta/lib/oe/tests/test_elf.py   | 21 ---
 meta/lib/oe/tests/test_license.py   | 68 --
 meta/lib/oe/tests/test_path.py  | 89 
 meta/lib/oe/tests/test_types.py | 62 
 meta/lib/oe/tests/test_utils.py | 51 
 meta/lib/oeqa/selftest/oe_tests/__init__.py |  0
 meta/lib/oeqa/selftest/oe_tests/elf.py  | 22 +++
 meta/lib/oeqa/selftest/oe_tests/license.py  | 69 ++
 meta/lib/oeqa/selftest/oe_tests/path.py | 90 +
 meta/lib/oeqa/selftest/oe_tests/types.py| 61 +++
 meta/lib/oeqa/selftest/oe_tests/utils.py| 52 +
 12 files changed, 294 insertions(+), 291 deletions(-)
 delete mode 100644 meta/lib/oe/tests/__init__.py
 delete mode 100644 meta/lib/oe/tests/test_elf.py
 delete mode 100644 meta/lib/oe/tests/test_license.py
 delete mode 100644 meta/lib/oe/tests/test_path.py
 delete mode 100644 meta/lib/oe/tests/test_types.py
 delete mode 100644 meta/lib/oe/tests/test_utils.py
 create mode 100644 meta/lib/oeqa/selftest/oe_tests/__init__.py
 create mode 100644 meta/lib/oeqa/selftest/oe_tests/elf.py
 create mode 100644 meta/lib/oeqa/selftest/oe_tests/license.py
 create mode 100644 meta/lib/oeqa/selftest/oe_tests/path.py
 create mode 100644 meta/lib/oeqa/selftest/oe_tests/types.py
 create mode 100644 meta/lib/oeqa/selftest/oe_tests/utils.py

diff --git a/meta/lib/oe/tests/__init__.py b/meta/lib/oe/tests/__init__.py
deleted file mode 100644
index e69de29..000
diff --git a/meta/lib/oe/tests/test_elf.py b/meta/lib/oe/tests/test_elf.py
deleted file mode 100644
index 1f59037..000
--- a/meta/lib/oe/tests/test_elf.py
+++ /dev/null
@@ -1,21 +0,0 @@
-import unittest
-import oe.qa
-
-class TestElf(unittest.TestCase):
-def test_machine_name(self):
-"""
-Test elf_machine_to_string()
-"""
-self.assertEqual(oe.qa.elf_machine_to_string(0x02), "SPARC")
-self.assertEqual(oe.qa.elf_machine_to_string(0x03), "x86")
-self.assertEqual(oe.qa.elf_machine_to_string(0x08), "MIPS")
-self.assertEqual(oe.qa.elf_machine_to_string(0x14), "PowerPC")
-self.assertEqual(oe.qa.elf_machine_to_string(0x28), "ARM")
-self.assertEqual(oe.qa.elf_machine_to_string(0x2A), "SuperH")
-self.assertEqual(oe.qa.elf_machine_to_string(0x32), "IA-64")
-self.assertEqual(oe.qa.elf_machine_to_string(0x3E), "x86-64")
-self.assertEqual(oe.qa.elf_machine_to_string(0xB7), "AArch64")
-
-self.assertEqual(oe.qa.elf_machine_to_string(0x00), "Unknown (0)")
-self.assertEqual(oe.qa.elf_machine_to_string(0xDEADBEEF), "Unknown 
(3735928559)")
-self.assertEqual(oe.qa.elf_machine_to_string("foobar"), "Unknown 
('foobar')")
diff --git a/meta/lib/oe/tests/test_license.py 
b/meta/lib/oe/tests/test_license.py
deleted file mode 100644
index c36..000
--- a/meta/lib/oe/tests/test_license.py
+++ /dev/null
@@ -1,68 +0,0 @@
-import unittest
-import oe.license
-
-class SeenVisitor(oe.license.LicenseVisitor):
-def __init__(self):
-self.seen = []
-oe.license.LicenseVisitor.__init__(self)
-
-def visit_Str(self, node):
-self.seen.append(node.s)
-
-class TestSingleLicense(unittest.TestCase):
-licenses = [
-"GPLv2",
-"LGPL-2.0",
-"Artistic",
-"MIT",
-"GPLv3+",
-"FOO_BAR",
-]
-invalid_licenses = ["GPL/BSD"]
-
-@staticmethod
-def parse(licensestr):
-visitor = SeenVisitor()
-visitor.visit_string(licensestr)
-return visitor.seen
-
-def test_single_licenses(self):
-for license in self.licenses:
-licenses = self.parse(license)
-self.assertListEqual(licenses, [license])
-
-def test_invalid_licenses(self):
-for license in self.invalid_licenses:
-with self.assertRaises(oe.license.InvalidLicense) as cm:
-self.parse(license)
-self.assertEqual(cm.exception.license, license)
-
-class TestSimpleCombinations(unittest.TestCase):
-tests = {
-"FOO": ["FOO", "BAR"],
-"BAZ & MOO": ["BAZ", "MOO"],
-"ALPHA|BETA": ["ALPHA"],
-"BAZ|FOO": ["FOO"],
-"FOO|BAZ": ["FOO", "BAR"],
-}
-preferred = ["ALPHA", "FOO", "BAR"]
-
-def test_tests(self):
-def choose(a, b):
-if all(lic in self.preferred for lic in b):
-return b
-else:
-return a
-
-for 

Re: [OE-core] [PATCH] mkefidisk.sh: add deprecation warning to the output

[Khem Raj]

> On Oct 31, 2016, at 3:46 AM, Ed Bartosh  wrote:
> 
> mkefidisk.sh will soon be deprecated in favor of .wic images.
> 
> Added deprecation warning to the script to inform users that
> this script will soon be removed from the codebase.
> 
> Signed-off-by: Ed Bartosh 
> ---
> scripts/contrib/mkefidisk.sh | 5 +
> 1 file changed, 5 insertions(+)
> 
> diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
> index d8db3c0..a175895 100755
> --- a/scripts/contrib/mkefidisk.sh
> +++ b/scripts/contrib/mkefidisk.sh
> @@ -20,6 +20,11 @@
> 
> LANG=C
> 
> +echo
> +echo "WARNING: This script is deprecated and will be removed soon."
> +echo "Please consider using wic EFI images instead."
> +echo
> +

is .wic image dd’able directly ?
We should also document, the wic steps in wiki pages e.g. 
http://wiki.minnowboard.org/Yocto_Project



> # Set to 1 to enable additional output
> DEBUG=0
> OUT="/dev/null"
> --
> 2.1.4
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



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] 2/3] curl: Update to version 7.51.0

[Fabio Berton]

CVE fixed in 7.51.0:

  CVE-2016-8615: cookie injection for other servers
  CVE-2016-8616: case insensitive password comparison
  CVE-2016-8617: OOB write via unchecked multiplication
  CVE-2016-8618: double-free in curl_maprintf
  CVE-2016-8619: double-free in krb5 code
  CVE-2016-8620: glob parser write/read out of bounds
  CVE-2016-8621: curl_getdate read out of bounds
  CVE-2016-8622: URL unescape heap overflow via integer truncation
  CVE-2016-8623: Use-after-free via shared cookies
  CVE-2016-8624: invalid URL parsing with '#'
  CVE-2016-8625: IDNA 2003 makes curl use wrong host

To see complete log access link bellow:
  https://curl.haxx.se/changes.html#7_51_0

Signed-off-by: Fabio Berton 
---
 meta/recipes-support/curl/{curl_7.50.1.bb => curl_7.51.0.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-support/curl/{curl_7.50.1.bb => curl_7.51.0.bb} (94%)

diff --git a/meta/recipes-support/curl/curl_7.50.1.bb 
b/meta/recipes-support/curl/curl_7.51.0.bb
similarity index 94%
rename from meta/recipes-support/curl/curl_7.50.1.bb
rename to meta/recipes-support/curl/curl_7.51.0.bb
index a21419a..e1a996b 100644
--- a/meta/recipes-support/curl/curl_7.50.1.bb
+++ b/meta/recipes-support/curl/curl_7.51.0.bb
@@ -14,8 +14,8 @@ SRC_URI = "http://curl.haxx.se/download/curl-${PV}.tar.bz2 \
 #
 SRC_URI += " file://configure_ac.patch"
 
-SRC_URI[md5sum] = "015f6a0217ca6f2c5442ca406476920b"
-SRC_URI[sha256sum] = 
"3c12c5f54ccaa1d40abc65d672107dcc75d3e1fcb38c267484334280096e5156"
+SRC_URI[md5sum] = "09a7c5769a7eae676d5e2c86d51f167e"
+SRC_URI[sha256sum] = 
"7f8240048907e5030f67be0a6129bc4b333783b9cca1391026d700835a788dde"
 
 inherit autotools pkgconfig binconfig multilib_header
 
-- 
2.1.4

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

[OE-core] [PATCH] 3/3] readline: Update to version 7.0

[Fabio Berton]

Remove readline 6.3 patches and config-dirent-symbols.patch already
apply on upstream.

Signed-off-by: Fabio Berton 
---
 .../configure-fix.patch|  0
 .../{readline-6.3 => readline-7.0}/norpath.patch   |  0
 meta/recipes-core/readline/readline_6.3.bb | 34 --
 meta/recipes-core/readline/readline_7.0.bb |  7 +
 4 files changed, 7 insertions(+), 34 deletions(-)
 rename meta/recipes-core/readline/{readline-6.3 => 
readline-7.0}/configure-fix.patch (100%)
 rename meta/recipes-core/readline/{readline-6.3 => readline-7.0}/norpath.patch 
(100%)
 delete mode 100644 meta/recipes-core/readline/readline_6.3.bb
 create mode 100644 meta/recipes-core/readline/readline_7.0.bb

diff --git a/meta/recipes-core/readline/readline-6.3/configure-fix.patch 
b/meta/recipes-core/readline/readline-7.0/configure-fix.patch
similarity index 100%
rename from meta/recipes-core/readline/readline-6.3/configure-fix.patch
rename to meta/recipes-core/readline/readline-7.0/configure-fix.patch
diff --git a/meta/recipes-core/readline/readline-6.3/norpath.patch 
b/meta/recipes-core/readline/readline-7.0/norpath.patch
similarity index 100%
rename from meta/recipes-core/readline/readline-6.3/norpath.patch
rename to meta/recipes-core/readline/readline-7.0/norpath.patch
diff --git a/meta/recipes-core/readline/readline_6.3.bb 
b/meta/recipes-core/readline/readline_6.3.bb
deleted file mode 100644
index 8ec7c4a..000
--- a/meta/recipes-core/readline/readline_6.3.bb
+++ /dev/null
@@ -1,34 +0,0 @@
-require readline.inc
-
-SRC_URI += 
"${GNU_MIRROR}/readline/readline-6.3-patches/readline63-001;name=patch1;apply=yes;striplevel=0
 \
-
${GNU_MIRROR}/readline/readline-6.3-patches/readline63-002;name=patch2;apply=yes;striplevel=0
 \
-
${GNU_MIRROR}/readline/readline-6.3-patches/readline63-003;name=patch3;apply=yes;striplevel=0
 \
-
${GNU_MIRROR}/readline/readline-6.3-patches/readline63-004;name=patch4;apply=yes;striplevel=0
 \
-
${GNU_MIRROR}/readline/readline-6.3-patches/readline63-005;name=patch5;apply=yes;striplevel=0
 \
-
${GNU_MIRROR}/readline/readline-6.3-patches/readline63-006;name=patch6;apply=yes;striplevel=0
 \
-
${GNU_MIRROR}/readline/readline-6.3-patches/readline63-007;name=patch7;apply=yes;striplevel=0
 \
-
${GNU_MIRROR}/readline/readline-6.3-patches/readline63-008;name=patch8;apply=yes;striplevel=0
 \
-file://configure-fix.patch \
-file://config-dirent-symbols.patch \
-file://norpath.patch"
-
-SRC_URI[archive.md5sum] = "33c8fb279e981274f485fd91da77e94a"
-SRC_URI[archive.sha256sum] = 
"56ba6071b9462f980c5a72ab0023893b65ba6debb4eeb475d7a563dc65cafd43"
-
-SRC_URI[patch1.md5sum]= "4343f5ea9b0f42447f102fb61576b398"
-SRC_URI[patch1.sha256sum] = 
"1a79bbb6eaee750e0d6f7f3d059b30a45fc54e8e388a8e05e9c3ae598590146f"
-SRC_URI[patch2.md5sum]= "700295212f7e2978577feaee584afddb"
-SRC_URI[patch2.sha256sum] = 
"39e304c7a526888f9e112e733848215736fb7b9d540729b9e31f3347b7a1e0a5"
-SRC_URI[patch3.md5sum]= "af4963862f5156fbf9111c2c6fa86ed7"
-SRC_URI[patch3.sha256sum] = 
"ec41bdd8b00fd884e847708513df41d51b1243cecb680189e31b7173d01ca52f"
-SRC_URI[patch4.md5sum]= "11f9def89803a5052db3ba72394ce14f"
-SRC_URI[patch4.sha256sum] = 
"4547b906fb2570866c21887807de5dee19838a60a1afb66385b272155e4355cc"
-SRC_URI[patch5.md5sum]= "93721c31cd225393f80cb3aadb165544"
-SRC_URI[patch5.sha256sum] = 
"877788f9228d1a9907a4bcfe3d6dd0439c08d728949458b41208d9bf9060274b"
-SRC_URI[patch6.md5sum]= "71dc6ecce66d1489b96595f55d142a52"
-SRC_URI[patch6.sha256sum] = 
"5c237ab3c6c97c23cf52b2a118adc265b7fb411b57c93a5f7c221d50fafbe556"
-SRC_URI[patch7.md5sum]= "062a08ed60679d3c4878710b3d595b65"
-SRC_URI[patch7.sha256sum] = 
"4d79b5a2adec3c2e8114cbd3d63c1771f7c6cf64035368624903d257014f5bea"
-SRC_URI[patch8.md5sum]= "ee1c04072154826870848d8b218d7b04"
-SRC_URI[patch8.sha256sum] = 
"3bc093cf526ceac23eb80256b0ec87fa1735540d659742107b6284d635c43787"
-
diff --git a/meta/recipes-core/readline/readline_7.0.bb 
b/meta/recipes-core/readline/readline_7.0.bb
new file mode 100644
index 000..85dfaa6
--- /dev/null
+++ b/meta/recipes-core/readline/readline_7.0.bb
@@ -0,0 +1,7 @@
+require readline.inc
+
+SRC_URI += "file://configure-fix.patch \
+file://norpath.patch"
+
+SRC_URI[archive.md5sum] = "205b03a87fc83dab653b628c59b9fc91"
+SRC_URI[archive.sha256sum] = 
"750d437185286f40a369e1e4f4764eda932b9459b5ec9a731628393dd3d32334"
-- 
2.1.4

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

Re: [OE-core] [PATCH v2] serf: Update to version 1.3.9

[Fabio Berton]

Hi Ross,

I removed UPSTREAM_CHECK_URI and checked with bitbake serf -c checkpkg and
I got the same output. So, I'll remove UPSTREAM_CHECK_URI and send a v3.

Thanks

Fabio

On Thu, Nov 3, 2016 at 5:40 PM, Burton, Ross  wrote:

>
> On 3 November 2016 at 15:34, Fabio Berton 
> wrote:
>
>> -UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/s/serf/"
>> +UPSTREAM_CHECK_URI = "${APACHE_MIRROR}/${BPN}/"
>>
>
> As all the tarballs are in a single directory you can probably just delete
> this line (though please do check with bitbake serf -c checkpkg).
>
> Ross
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] 1/3] grep: Update to version 2.26

[Fabio Berton]

Signed-off-by: Fabio Berton 
---
 meta/recipes-extended/grep/{grep_2.25.bb => grep_2.26.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-extended/grep/{grep_2.25.bb => grep_2.26.bb} (88%)

diff --git a/meta/recipes-extended/grep/grep_2.25.bb 
b/meta/recipes-extended/grep/grep_2.26.bb
similarity index 88%
rename from meta/recipes-extended/grep/grep_2.25.bb
rename to meta/recipes-extended/grep/grep_2.26.bb
index 9720d9f..9e6f05e 100644
--- a/meta/recipes-extended/grep/grep_2.25.bb
+++ b/meta/recipes-extended/grep/grep_2.26.bb
@@ -9,8 +9,8 @@ SRC_URI = "${GNU_MIRROR}/grep/grep-${PV}.tar.xz \
file://0001-Unset-need_charset_alias-when-building-for-musl.patch \
   "
 
-SRC_URI[md5sum] = "04e96b0e6f0fe6a180ae62c88fcd0af6"
-SRC_URI[sha256sum] = 
"e21e83bac50450e0d0d61a42c154ee0dceaacdbf4f604ef6e79071cb8e596830"
+SRC_URI[md5sum] = "afdd61c7221434722671baf002ac9267"
+SRC_URI[sha256sum] = 
"246a8fb37e82aa33d495b07c22fdab994c039ab0f818538eac81b01e78636870"
 
 inherit autotools gettext texinfo
 
-- 
2.1.4

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

[OE-core] [PATCH v3]] serf: Update to version 1.3.9

[Fabio Berton]

Change SRC_URI to use APACHE_MIRROR to download serf from apache
project page and remove UPSTREAM_CHECK_URI.

Signed-off-by: Fabio Berton 
---
 meta/recipes-support/serf/{serf_1.3.8.bb => serf_1.3.9.bb} | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)
 rename meta/recipes-support/serf/{serf_1.3.8.bb => serf_1.3.9.bb} (67%)

diff --git a/meta/recipes-support/serf/serf_1.3.8.bb 
b/meta/recipes-support/serf/serf_1.3.9.bb
similarity index 67%
rename from meta/recipes-support/serf/serf_1.3.8.bb
rename to meta/recipes-support/serf/serf_1.3.9.bb
index c498d90..2be5a06 100644
--- a/meta/recipes-support/serf/serf_1.3.8.bb
+++ b/meta/recipes-support/serf/serf_1.3.9.bb
@@ -1,12 +1,10 @@
 SUMMARY = "High-Performance Asynchronous HTTP Client Library"
-SRC_URI = 
"http://snapshot.debian.org/archive/debian/20160728T043443Z/pool/main/s/${BPN}/${BPN}_${PV}.orig.tar.gz
 \
+SRC_URI = "${APACHE_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
file://norpath.patch \
file://env.patch"
 
-SRC_URI[md5sum] = "713beaf05d7f3329de121e218e2fcb93"
-SRC_URI[sha256sum] = 
"77134cd5010664ca023585bce50978bd4005906ed280ff889f591f86df7c59e4"
-
-UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/s/serf/"
+SRC_URI[md5sum] = "370a6340ff20366ab088012cd13f2b57"
+SRC_URI[sha256sum] = 
"549c2d21c577a8a9c0450facb5cca809f26591f048e466552240947bdf7a87cc"
 
 LICENSE = "Apache-2.0"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=86d3f3a95c324c9479bd8986968f4327"
-- 
2.1.4

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

Re: [OE-core] [krogoth][PATCH 1/2] qemu: Security fix CVE-2016-4439

[Leonardo Sandoval]

Adrian,


On 11/03/2016 07:18 AM, Adrian Dudau wrote:

affects qemu < 2.7.0

Quick Emulator(Qemu) built with the ESP/NCR53C9x controller emulation
support is vulnerable to an OOB write access issue. The controller uses
16-byte FIFO buffer for command and data transfer. The OOB write occurs
while writing to this command buffer in routine get_cmd().

A privileged user inside guest could use this flaw to crash the Qemu
process resulting in DoS.

References:
--
http://www.openwall.com/lists/oss-security/2016/05/19/4
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-4441

Signed-off-by: Adrian Dudau 
---
  .../recipes-devtools/qemu/qemu/CVE-2016-4441.patch | 78 ++
  meta/recipes-devtools/qemu/qemu_2.5.0.bb   |  1 +
  2 files changed, 79 insertions(+)
  create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-4441.patch

diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2016-4441.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2016-4441.patch
new file mode 100644
index 000..3cbe394
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2016-4441.patch
@@ -0,0 +1,78 @@
+From 6c1fef6b59563cc415f21e03f81539ed4b33ad90 Mon Sep 17 00:00:00 2001
+From: Prasad J Pandit 
+Date: Thu, 19 May 2016 16:09:31 +0530
+Subject: [PATCH] esp: check dma length before reading scsi 
command(CVE-2016-4441)
+
+The 53C9X Fast SCSI Controller(FSC) comes with an internal 16-byte
+FIFO buffer. It is used to handle command and data transfer.
+Routine get_cmd() uses DMA to read scsi commands into this buffer.
+Add check to validate DMA length against buffer size to avoid any
+overrun.
+
+Fixes CVE-2016-4441.
+


Correct or include the CVE tag on cve patch with format:'CVE: CVE--'

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

Re: [OE-core] [PATCH v2] serf: Update to version 1.3.9

[Burton, Ross]

On 3 November 2016 at 15:34, Fabio Berton 
wrote:

> -UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/s/serf/"
> +UPSTREAM_CHECK_URI = "${APACHE_MIRROR}/${BPN}/"
>

As all the tarballs are in a single directory you can probably just delete
this line (though please do check with bitbake serf -c checkpkg).

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

Re: [OE-core] Sanity check fails with 'ccache'

[Andre McCurdy]

On Tue, Nov 1, 2016 at 4:35 AM, Enrico Scholz
 wrote:
> Hi,
>
> with 'morty', sanity check fails with
>
> |Please install the following missing utilities: C Compiler (ccache gcc 
> ),C++ Compiler (ccache g++ )
>
> I think, parts of 89f55bf8e9d633cfb508a0885a462afb561c7cee should be
> reverted.

+1

The sanity check changes cause problems when ccache is enabled:

  
http://git.openembedded.org/openembedded-core/commit/?id=89f55bf8e9d633cfb508a0885a462afb561c7cee

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

Re: [OE-core] [master][morty][PATCH 1/2] ltp: Fix QA warning

[Burton, Ross]

On 3 November 2016 at 18:04, Jagadeesh Krishnanjanappa <
jkrishnanjana...@mvista.com> wrote:

> WARNING: ltp-20160126-r0 do_package_qa: QA Issue:
> /opt/ltp/share/licenses/ltp/run_freezer.sh contained in package ltp-lic
> requires /bin/bash, but no providers found in RDEPENDS_ltp-lic? [file-rdeps]
>

So the common problem "if PN-lic contains a license statement embedded in a
file with a hashbang, file-rdeps is triggered", so I'd say file-rdeps
should be added to INSANE_SKIP_${PN}-lic in bitbake.conf instead of dealing
with this per recipe.

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

Re: [OE-core] using devtool for rebasing patches

[Khem Raj]

> On Nov 3, 2016, at 9:29 AM, Christopher Larson  wrote:
> 
> 
> On Thu, Nov 3, 2016 at 9:01 AM, Alexander Kanavin 
>  > wrote:
> it would be very useful if devtool offered support for rebasing source 
> patches when they fail to apply, but currently there does not seem to be any 
> such feature:
> 
> ak@kanavin-desktop:~/development/poky/build$ devtool modify libksba
> Parsing recipes..done.
> NOTE: Fetching libksba...
> NOTE: Unpacking...
> NOTE: Patching...
> ERROR: Applying 'ksba-add-pkgconfig-support.pa 
> tch' failed:
> checking file Makefile.am
> Hunk #1 FAILED at 21.
> 1 out of 1 hunk FAILED
> checking file configure.ac 
> Hunk #1 succeeded at 414 (offset 14 lines).
> checking file ksba.pc.in 
> checking file src/ksba.m4
> ERROR: Function failed: patch_do_patch
> ak@kanavin-desktop:~/development/poky/build$
> 
> What devtool could do here is apply the patches that can be applied and then 
> partially apply the patches that fail. Then give the developer some kind of 
> UI for dealing with the rejected hunks (which typically means finding the 
> place in the target file where the changes should go and then manually 
> editing them in, while looking at the original patch).
> 
> Without this feature devtool is half as useful as it could be particularly 
> for recipe version updates.
> 
> That would be useful, indeed.
> 
> git already provides such a UI, afaik devtool just needs to use git-am to 
> apply the patches, ideally passing -3 to it, and let the user use git am to 
> resolve and continue applying patches.

this seems good. Although, I have seen that all patches are not git am 
applicable, then I use git apply, something even that does not work, then third 
option is
to use patch  < patch and this works if it does not work then patch needs 
manual work.

> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



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] using devtool for rebasing patches

[Paul Eggleton]

On Fri, 04 Nov 2016 08:29:26 Paul Eggleton wrote:
> Hi Alex,
> 
> On Thu, 03 Nov 2016 18:01:27 Alexander Kanavin wrote:
> > it would be very useful if devtool offered support for rebasing source
> > patches when they fail to apply, but currently there does not seem to be
> > any such feature:
> > 
> > ak@kanavin-desktop:~/development/poky/build$ devtool modify libksba
> > Parsing recipes..done.
> > NOTE: Fetching libksba...
> > NOTE: Unpacking...
> > NOTE: Patching...
> > ERROR: Applying 'ksba-add-pkgconfig-support.patch' failed:
> > checking file Makefile.am
> > Hunk #1 FAILED at 21.
> > 1 out of 1 hunk FAILED
> > checking file configure.ac
> > Hunk #1 succeeded at 414 (offset 14 lines).
> > checking file ksba.pc.in
> > checking file src/ksba.m4
> > ERROR: Function failed: patch_do_patch
> > ak@kanavin-desktop:~/development/poky/build$
> > 
> > What devtool could do here is apply the patches that can be applied and
> > then partially apply the patches that fail. Then give the developer some
> > kind of UI for dealing with the rejected hunks (which typically means
> > finding the place in the target file where the changes should go and
> > then manually editing them in, while looking at the original patch).
> > 
> > Without this feature devtool is half as useful as it could be
> > particularly for recipe version updates.
> 
> "devtool upgrade" is designed specifically to handle the upgrade case and
> tries to rebase the old patches onto the new version, putting you into
> resolution mode with "git am" if it fails to apply a patch. I appreciate
> that you may now be working through sorting out all of the patches to
> reduce the fuzziness when applying, and that won't help in that scenario,
> but it would definitely be worth considering for upgrades.
> 
> I'm open to implementing better support for handling patch application
> failure for devtool modify - in fact there is a bug open for just that:
> 
>   https://bugzilla.yoctoproject.org/show_bug.cgi?id=8325

(Although admittedly that was mostly for an earlier issue - we ought to add a 
bit of description of where to go from here.)

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] version of gdb in morty

[Khem Raj]

> On Nov 3, 2016, at 7:06 AM, Burton, Ross  wrote:
> 
> 
> On 3 November 2016 at 13:32, Alexander Kanavin 
>  > wrote:
> Update to 7.12 for master branch please.
> 
> To ease backporting to morty, taking 7.11.1 and then 7.12 makes sense to me.

yep

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



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] using devtool for rebasing patches

[Paul Eggleton]

Hi Alex,

On Thu, 03 Nov 2016 18:01:27 Alexander Kanavin wrote:
> it would be very useful if devtool offered support for rebasing source
> patches when they fail to apply, but currently there does not seem to be
> any such feature:
> 
> ak@kanavin-desktop:~/development/poky/build$ devtool modify libksba
> Parsing recipes..done.
> NOTE: Fetching libksba...
> NOTE: Unpacking...
> NOTE: Patching...
> ERROR: Applying 'ksba-add-pkgconfig-support.patch' failed:
> checking file Makefile.am
> Hunk #1 FAILED at 21.
> 1 out of 1 hunk FAILED
> checking file configure.ac
> Hunk #1 succeeded at 414 (offset 14 lines).
> checking file ksba.pc.in
> checking file src/ksba.m4
> ERROR: Function failed: patch_do_patch
> ak@kanavin-desktop:~/development/poky/build$
> 
> What devtool could do here is apply the patches that can be applied and
> then partially apply the patches that fail. Then give the developer some
> kind of UI for dealing with the rejected hunks (which typically means
> finding the place in the target file where the changes should go and
> then manually editing them in, while looking at the original patch).
> 
> Without this feature devtool is half as useful as it could be
> particularly for recipe version updates.

"devtool upgrade" is designed specifically to handle the upgrade case and 
tries to rebase the old patches onto the new version, putting you into 
resolution mode with "git am" if it fails to apply a patch. I appreciate that 
you may now be working through sorting out all of the patches to reduce the 
fuzziness when applying, and that won't help in that scenario, but it would 
definitely be worth considering for upgrades.

I'm open to implementing better support for handling patch application failure 
for devtool modify - in fact there is a bug open for just that:

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

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] using devtool for rebasing patches

[Paul Eggleton]

On Thu, 03 Nov 2016 20:14:04 Patrick Ohly wrote:
> On Thu, 2016-11-03 at 10:14 -0700, Christopher Larson wrote:
> > On Thu, Nov 3, 2016 at 9:35 AM, Alexander Kanavin
> > 
> >  wrote:
> > What you need to do here is to use git am --reject, which
> > would partially apply the patch, then find all the *.rej files
> > and let the user manually edit them in, then complete the
> > patch application with git am --continue.
> > 
> > With -3, it’ll merge it into the file with conflict markers, which is
> > a lot more pleasant to deal with than .rej files, even without the
> > merge-base being available.
> 
> That's also what I would prefer.
> 
> To deal with recipes that have something other than git as source one
> could create a local git repo with a branch that contains two commits
> (old version and new version), apply the patches on a second branch on
> top of the old version, then do the normal rebase with conflictstyle =
> diff3. At least I find that configstyle useful and have it in my
> ~/.gitconfig.

FYI this is what "devtool upgrade" already does. It's just that it's geared 
towards upgrading so it expects the version to be changing at the same time.

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] using devtool for rebasing patches

[Patrick Ohly]

On Thu, 2016-11-03 at 10:14 -0700, Christopher Larson wrote:
> 
> On Thu, Nov 3, 2016 at 9:35 AM, Alexander Kanavin
>  wrote:
> 
> What you need to do here is to use git am --reject, which
> would partially apply the patch, then find all the *.rej files
> and let the user manually edit them in, then complete the
> patch application with git am --continue.
> 
> 
> With -3, it’ll merge it into the file with conflict markers, which is
> a lot more pleasant to deal with than .rej files, even without the
> merge-base being available.

That's also what I would prefer.

To deal with recipes that have something other than git as source one
could create a local git repo with a branch that contains two commits
(old version and new version), apply the patches on a second branch on
top of the old version, then do the normal rebase with conflictstyle =
diff3. At least I find that configstyle useful and have it in my
~/.gitconfig.

-- 
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] [master][morty][PATCH 2/2] hdparm: Fix QA warning

[Jagadeesh Krishnanjanappa]

It solves below QA issue WARNING while building hdparm, when
LICENSE_CREATE_PACKAGE is set to "1"

-- snip --
WARNING: hdparm-9.48-r0 do_package_qa: QA Issue: 
/usr/share/licenses/hdparm/wiper.sh contained in package hdparm-lic requires 
/bin/bash, but no providers found in RDEPENDS_hdparm-lic? [file-rdeps]
-- snip --

Signed-off-by: Jeremy Puhlman 
Signed-off-by: Jagadeesh Krishnanjanappa 
---
 meta/recipes-extended/hdparm/hdparm_9.48.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-extended/hdparm/hdparm_9.48.bb 
b/meta/recipes-extended/hdparm/hdparm_9.48.bb
index cd85776..2c1e77d 100644
--- a/meta/recipes-extended/hdparm/hdparm_9.48.bb
+++ b/meta/recipes-extended/hdparm/hdparm_9.48.bb
@@ -38,3 +38,5 @@ do_install () {
oe_runmake 'DESTDIR=${D}' 'sbindir=${base_sbindir}' install
cp ${S}/wiper/wiper.sh ${D}/${bindir}
 }
+
+RDEPENDS_${PN}-lic = "bash"
-- 
2.7.4

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

Re: [OE-core] version of gdb in morty

[Bas Mevissen]

On 03/11/16 16:29, Mark Hatle wrote:

On 11/3/16 9:06 AM, Burton, Ross wrote:


On 3 November 2016 at 13:32, Alexander Kanavin
>
wrote:

Update to 7.12 for master branch please.


To ease backporting to morty, taking 7.11.1 and then 7.12 makes sense to me.


I'm fine with this as well..  The third digit release is small enough of a
change, I don't think it will impact stability on such a new release.



+1

7.11.1 is bugfix only.

7.12 is removing some stuff that might cause breakage. The only new 
thing worth mentioning is Rust support.


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

[OE-core] [master][morty][PATCH 1/2] ltp: Fix QA warning

[Jagadeesh Krishnanjanappa]

It solves below QA issue WARNING while building ltp, when
LICENSE_CREATE_PACKAGE is set to "1"

-- snip --
WARNING: ltp-20160126-r0 do_package_qa: QA Issue: 
/opt/ltp/share/licenses/ltp/run_freezer.sh contained in package ltp-lic 
requires /bin/bash, but no providers found in RDEPENDS_ltp-lic? [file-rdeps]
-- snip --

Signed-off-by: Jeremy Puhlman 
Signed-off-by: Jagadeesh Krishnanjanappa 
---
 meta/recipes-extended/ltp/ltp_20160126.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-extended/ltp/ltp_20160126.bb 
b/meta/recipes-extended/ltp/ltp_20160126.bb
index 7631e0e..c731f42 100644
--- a/meta/recipes-extended/ltp/ltp_20160126.bb
+++ b/meta/recipes-extended/ltp/ltp_20160126.bb
@@ -105,6 +105,7 @@ do_install(){
 }
 
 RDEPENDS_${PN} = "perl e2fsprogs-mke2fs python-core libaio bash gawk expect 
ldd"
+RDEPENDS_${PN}-lic = "bash"
 
 FILES_${PN}-staticdev += "/opt/ltp/lib/libmem.a"
 
-- 
2.7.4

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

Re: [OE-core] [PATCH 1/3] linux-yocto/4.8: update to 4.8.6

[Bruce Ashfield]

On 2016-11-03 1:53 PM, Philip Balister wrote:

I'd go bug Bruce directly, but I think the answer is of general interest.

How do I review the actual changes the version update makes?


Sometimes I do a shortlog of the changes as part of my commit message.
It is sort of hit and miss .. i.e. when I think to do it.



At the moment, I'd like to look at the commits added to the kernel to
see if they are related to an issue I am having. I'm also wondering what
other stuff might change.


Outside of inspecting the tree, the best thing I Can think of
is that I can do a shortlog of all the commits since the last
update.

Thoughts ?

Bruce



Philip

On 11/03/2016 09:25 AM, Bruce Ashfield wrote:

Integrating the korg -stable release.

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb   |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_4.8.bb  | 20 ++--
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
index e51c9cdcca0e..26b309d8b8f4 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
@@ -11,13 +11,13 @@ python () {
 raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }

-SRCREV_machine ?= "4057556c041f6aac0d29aa3425587d414c9a0090"
-SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
+SRCREV_machine ?= "b99b6fac437104e206d30540a5cb12103049af1e"
+SRCREV_meta ?= "87e5fc8b7cb387f197cdd098cdde4e96e9e8ed0d"

 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.8.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=${KMETA}"

-LINUX_VERSION ?= "4.8.3"
+LINUX_VERSION ?= "4.8.6"

 PV = "${LINUX_VERSION}+git${SRCPV}"

diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
index c8ddbd93dc7f..63dd11baa19e 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
@@ -4,13 +4,13 @@ KCONFIG_MODE = "--allnoconfig"

 require recipes-kernel/linux/linux-yocto.inc

-LINUX_VERSION ?= "4.8.3"
+LINUX_VERSION ?= "4.8.6"

 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"

-SRCREV_machine ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
-SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
+SRCREV_machine ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
+SRCREV_meta ?= "87e5fc8b7cb387f197cdd098cdde4e96e9e8ed0d"

 PV = "${LINUX_VERSION}+git${SRCPV}"

diff --git a/meta/recipes-kernel/linux/linux-yocto_4.8.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
index 13778b9c4db6..03691982b1f0 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
@@ -11,20 +11,20 @@ KBRANCH_qemux86  ?= "standard/base"
 KBRANCH_qemux86-64 ?= "standard/base"
 KBRANCH_qemumips64 ?= "standard/mti-malta64"

-SRCREV_machine_qemuarm ?= "4cc544ad09ad704322cb66fe4ba197a6a05dc71f"
-SRCREV_machine_qemuarm64 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
-SRCREV_machine_qemumips ?= "c285969d4f9376a671167ecf397578c8ad3e6a75"
-SRCREV_machine_qemuppc ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
-SRCREV_machine_qemux86 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
-SRCREV_machine_qemux86-64 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
-SRCREV_machine_qemumips64 ?= "64f96ba530e58456070f26b0f3fcce3f64988b72"
-SRCREV_machine ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
-SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
+SRCREV_machine_qemuarm ?= "94d3e8675e2fcb09f29814a33ccf79df06149104"
+SRCREV_machine_qemuarm64 ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
+SRCREV_machine_qemumips ?= "046ff6344eee25dcc0eea1214e0ad8771ddfabfb"
+SRCREV_machine_qemuppc ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
+SRCREV_machine_qemux86 ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
+SRCREV_machine_qemux86-64 ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
+SRCREV_machine_qemumips64 ?= "edcb167f91abc071cc98cbd762418ff7ab9d839b"
+SRCREV_machine ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
+SRCREV_meta ?= "87e5fc8b7cb387f197cdd098cdde4e96e9e8ed0d"

 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.8.git;name=machine;branch=${KBRANCH}; 
\

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=${KMETA}"

-LINUX_VERSION ?= "4.8.3"
+LINUX_VERSION ?= "4.8.6"

 PV = "${LINUX_VERSION}+git${SRCPV}"




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

Re: [OE-core] [PATCH 1/3] linux-yocto/4.8: update to 4.8.6

[Philip Balister]

I'd go bug Bruce directly, but I think the answer is of general interest.

How do I review the actual changes the version update makes?

At the moment, I'd like to look at the commits added to the kernel to
see if they are related to an issue I am having. I'm also wondering what
other stuff might change.

Philip

On 11/03/2016 09:25 AM, Bruce Ashfield wrote:
> Integrating the korg -stable release.
> 
> Signed-off-by: Bruce Ashfield 
> ---
>  meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb   |  6 +++---
>  meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb |  6 +++---
>  meta/recipes-kernel/linux/linux-yocto_4.8.bb  | 20 ++--
>  3 files changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb 
> b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
> index e51c9cdcca0e..26b309d8b8f4 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
> @@ -11,13 +11,13 @@ python () {
>  raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to 
> linux-yocto-rt to enable it")
>  }
>  
> -SRCREV_machine ?= "4057556c041f6aac0d29aa3425587d414c9a0090"
> -SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
> +SRCREV_machine ?= "b99b6fac437104e206d30540a5cb12103049af1e"
> +SRCREV_meta ?= "87e5fc8b7cb387f197cdd098cdde4e96e9e8ed0d"
>  
>  SRC_URI = 
> "git://git.yoctoproject.org/linux-yocto-4.8.git;branch=${KBRANCH};name=machine
>  \
> 
> git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=${KMETA}"
>  
> -LINUX_VERSION ?= "4.8.3"
> +LINUX_VERSION ?= "4.8.6"
>  
>  PV = "${LINUX_VERSION}+git${SRCPV}"
>  
> diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb 
> b/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
> index c8ddbd93dc7f..63dd11baa19e 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
> @@ -4,13 +4,13 @@ KCONFIG_MODE = "--allnoconfig"
>  
>  require recipes-kernel/linux/linux-yocto.inc
>  
> -LINUX_VERSION ?= "4.8.3"
> +LINUX_VERSION ?= "4.8.6"
>  
>  KMETA = "kernel-meta"
>  KCONF_BSP_AUDIT_LEVEL = "2"
>  
> -SRCREV_machine ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
> -SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
> +SRCREV_machine ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
> +SRCREV_meta ?= "87e5fc8b7cb387f197cdd098cdde4e96e9e8ed0d"
>  
>  PV = "${LINUX_VERSION}+git${SRCPV}"
>  
> diff --git a/meta/recipes-kernel/linux/linux-yocto_4.8.bb 
> b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
> index 13778b9c4db6..03691982b1f0 100644
> --- a/meta/recipes-kernel/linux/linux-yocto_4.8.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
> @@ -11,20 +11,20 @@ KBRANCH_qemux86  ?= "standard/base"
>  KBRANCH_qemux86-64 ?= "standard/base"
>  KBRANCH_qemumips64 ?= "standard/mti-malta64"
>  
> -SRCREV_machine_qemuarm ?= "4cc544ad09ad704322cb66fe4ba197a6a05dc71f"
> -SRCREV_machine_qemuarm64 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
> -SRCREV_machine_qemumips ?= "c285969d4f9376a671167ecf397578c8ad3e6a75"
> -SRCREV_machine_qemuppc ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
> -SRCREV_machine_qemux86 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
> -SRCREV_machine_qemux86-64 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
> -SRCREV_machine_qemumips64 ?= "64f96ba530e58456070f26b0f3fcce3f64988b72"
> -SRCREV_machine ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
> -SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
> +SRCREV_machine_qemuarm ?= "94d3e8675e2fcb09f29814a33ccf79df06149104"
> +SRCREV_machine_qemuarm64 ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
> +SRCREV_machine_qemumips ?= "046ff6344eee25dcc0eea1214e0ad8771ddfabfb"
> +SRCREV_machine_qemuppc ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
> +SRCREV_machine_qemux86 ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
> +SRCREV_machine_qemux86-64 ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
> +SRCREV_machine_qemumips64 ?= "edcb167f91abc071cc98cbd762418ff7ab9d839b"
> +SRCREV_machine ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
> +SRCREV_meta ?= "87e5fc8b7cb387f197cdd098cdde4e96e9e8ed0d"
>  
>  SRC_URI = 
> "git://git.yoctoproject.org/linux-yocto-4.8.git;name=machine;branch=${KBRANCH};
>  \
> 
> git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=${KMETA}"
>  
> -LINUX_VERSION ?= "4.8.3"
> +LINUX_VERSION ?= "4.8.6"
>  
>  PV = "${LINUX_VERSION}+git${SRCPV}"
>  
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 00/43] Krogoth-next pull request

[Armin Kuster]

Please consider these changes for krogoth-next


The following changes since commit 40f4a6d075236265086cc79400dea3c14720383a:

  bsp-guide: Updated the yocto-bsp create selections in the example. 
(2016-10-13 23:16:56 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib akuster/krogoth-next
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akuster/krogoth-next

Aníbal Limón (1):
  bitbake: bb.event: fix infinite loop on print_ui_queue

Armin Kuster (2):
  meta-linux-yocto: update to 4.1.33
  meta-linux-yocto: update 4.4 to 4.4.26

Bruce Ashfield (7):
  linux-yocto/4.1: update to 4.1.33
  linux-yocto/4.4: update to v4.4.22
  linux-yocto/4.1/4.4: remove innappropriate standard/base patches
  linux-yocto/4.4/4.8: kernel config warning cleanups
  linux-yocto/4.4: update to v4.4.26
  linux-yocto/4.1: fix CVE-2016-5195 (dirtycow)
  perf: adapt to Makefile.config

California Sullivan (4):
  parselogs.py: Add amd_nb error to x86_common whitelist
  parselogs.py: Add dmi and ioremap errors to ignore list for core2
  parselogs.py: Ignore Skylake graphics firmware load errors on
genericx86-64
  parselogs.py: Add disabling eDP error to x86_common whitelist

Christopher Larson (1):
  perf: Fix to obey LD failure on qemux86-64

Ed Bartosh (1):
  bitbake: event.py: output errors and warnings to stderr

Enrico Scholz (1):
  bitbake: fetch: copy files with -H

Joshua Lock (1):
  bitbake: event: prevent unclosed file warning in print_ui_queue

Juro Bystricky (3):
  libgcc-common.inc: Fix broken symlinks for multilib SDK
  gcc-runtime.inc: add CPP support for mips64-n32 tune
  gcc-runtime.inc: Add CPP support for x86-64-x32 tune

Jussi Kukkonen (1):
  This is a backport from master of 2 consecutive fixes.

Khem Raj (1):
  binutils: Fix gas error with cfi_section inconsistencies

Markus Lehtonen (1):
  rpm: prevent race in tempdir creation

Ola x Nilsson (2):
  devtool: build_image: Fix recipe filter
  devtool: Use the wildcard flag in update_recipe_patch

Pascal Bach (1):
  glibc: fix CVE-2016-1234, CVE-2016-3075, CVE-2016-5417

Paul Eggleton (8):
  devtool: update-recipe: fix --initial-rev option
  devtool: reset: allow reset to work if the recipe file has been
deleted
  recipetool: create: fix handling of github URLs
  lib/oe/recipeutils: fix patch_recipe*() with empty input
  recipetool: create: fix greedy regex that broke support for github
tarballs
  oe-selftest: recipetool: add tests for git URL mangling
  devtool: add: fix error message when only specifying a recipe name
  classes/externalsrc: re-run do_configure when configure files change

Richard Purdie (3):
  parselogs: Ignore amb_nb warning messages under qemux86*
  parselogs: Ignore uvesafb timeouts
  oeqa/parselogs: Don't use cwd for file transfers

Saul Wold (1):
  archiver: fix gcc-source handling

Sona Sarmadi (2):
  dropbear: fix multiple CVEs
  bash: Security fix CVE-2016-0634

Sujith Haridasan (1):
  perf: Fix to obey LD failure

Zheng Ruoqin (1):
  bind: fix two CVEs

 bitbake/lib/bb/event.py|   17 +-
 bitbake/lib/bb/fetch2/__init__.py  |2 +-
 .../recipes-kernel/linux/linux-yocto_4.1.bbappend  |   17 +-
 .../recipes-kernel/linux/linux-yocto_4.4.bbappend  |   17 +-
 meta/classes/archiver.bbclass  |5 +-
 meta/classes/autotools.bbclass |2 +
 meta/classes/cmake.bbclass |2 +
 meta/classes/externalsrc.bbclass   |   22 +
 meta/lib/oe/recipeutils.py |2 +-
 meta/lib/oeqa/runtime/parselogs.py |   29 +-
 meta/lib/oeqa/selftest/recipetool.py   |   43 +
 .../bind/bind/CVE-2016-2775.patch  |   90 +
 .../bind/bind/CVE-2016-2776.patch  |  123 +
 meta/recipes-connectivity/bind/bind_9.10.3-P3.bb   |2 +
 meta/recipes-core/base-files/base-files/profile|6 +-
 meta/recipes-core/dropbear/dropbear.inc|4 +
 .../dropbear/dropbear/CVE-2016-7406.patch  |  102 +
 .../dropbear/dropbear/CVE-2016-7407.patch  | 2486 
 .../dropbear/dropbear/CVE-2016-7408.patch  |  101 +
 .../dropbear/dropbear/CVE-2016-7409.patch  |   27 +
 meta/recipes-core/glibc/glibc/CVE-2016-1234.patch  |  427 
 meta/recipes-core/glibc/glibc/CVE-2016-3075.patch  |   37 +
 meta/recipes-core/glibc/glibc/CVE-2016-5417.patch  |   28 +
 meta/recipes-core/glibc/glibc_2.23.bb  |3 +
 meta/recipes-devtools/binutils/binutils-2.26.inc   |1 +
 ..._sections-check-to-only-consider-compact-.patch |   97 +
 meta/recipes-devtools/gcc/gcc-runtime.inc  |   18 +
 meta/recipes-devtools/gcc/libgcc-common.inc|8 +-
 ...more-verbose-error-logging-in-rpmTempFile.patch |   26 +-
 .../rpmdb-prevent-race-in-tmpdir-creation.patch|   41 +
 meta/recipes-devtools/rpm/rpm_5.4.16.bb|1 +
 

Re: [OE-core] using devtool for rebasing patches

[Christopher Larson]

On Thu, Nov 3, 2016 at 9:35 AM, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> On 11/03/2016 06:29 PM, Christopher Larson wrote:
>
>> git already provides such a UI, afaik devtool just needs to use git-am
>> to apply the patches, ideally passing -3 to it, and let the user use git
>> am to resolve and continue applying patches.
>>
>
> I don't think git am has any UI that helps with rebasing the rejects, and
> -3 is often not useful here, as we don't have the commit history, if the
> source is coming from tarball.
>

Fairly sure that’s not actually correct. See below.


> What you need to do here is to use git am --reject, which would partially
> apply the patch, then find all the *.rej files and let the user manually
> edit them in, then complete the patch application with git am --continue.


With -3, it’ll merge it into the file with conflict markers, which is a lot
more pleasant to deal with than .rej files, even without the merge-base
being available.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] using devtool for rebasing patches

[Patrick Ohly]

On Thu, 2016-11-03 at 18:01 +0200, Alexander Kanavin wrote:
> Hello Paul,
> 
> it would be very useful if devtool offered support for rebasing source 
> patches when they fail to apply

+1 for that.

I tried it the other way around: first "devtool modify", then rebasing
using git (which only works when the recipe fetches from a git repo),
and finally changing the recipe such that it refers to the version I
rebased onto. But that version change in the recipe confused "devtool
update-recipe" considerably (as in "added all patches between the
version", if I remember correctly).

-- 
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] using devtool for rebasing patches

[Alexander Kanavin]

On 11/03/2016 06:29 PM, Christopher Larson wrote:

git already provides such a UI, afaik devtool just needs to use git-am
to apply the patches, ideally passing -3 to it, and let the user use git
am to resolve and continue applying patches.


I don't think git am has any UI that helps with rebasing the rejects, 
and -3 is often not useful here, as we don't have the commit history, if 
the source is coming from tarball.


What you need to do here is to use git am --reject, which would 
partially apply the patch, then find all the *.rej files and let the 
user manually edit them in, then complete the patch application with git 
am --continue.



Alex

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

Re: [OE-core] using devtool for rebasing patches

[Christopher Larson]

On Thu, Nov 3, 2016 at 9:01 AM, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> it would be very useful if devtool offered support for rebasing source
> patches when they fail to apply, but currently there does not seem to be
> any such feature:
>
> ak@kanavin-desktop:~/development/poky/build$ devtool modify libksba
> Parsing recipes..done.
> NOTE: Fetching libksba...
> NOTE: Unpacking...
> NOTE: Patching...
> ERROR: Applying 'ksba-add-pkgconfig-support.patch' failed:
> checking file Makefile.am
> Hunk #1 FAILED at 21.
> 1 out of 1 hunk FAILED
> checking file configure.ac
> Hunk #1 succeeded at 414 (offset 14 lines).
> checking file ksba.pc.in
> checking file src/ksba.m4
> ERROR: Function failed: patch_do_patch
> ak@kanavin-desktop:~/development/poky/build$
>
> What devtool could do here is apply the patches that can be applied and
> then partially apply the patches that fail. Then give the developer some
> kind of UI for dealing with the rejected hunks (which typically means
> finding the place in the target file where the changes should go and then
> manually editing them in, while looking at the original patch).
>
> Without this feature devtool is half as useful as it could be particularly
> for recipe version updates.
>

That would be useful, indeed.

git already provides such a UI, afaik devtool just needs to use git-am to
apply the patches, ideally passing -3 to it, and let the user use git am to
resolve and continue applying patches.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] using devtool for rebasing patches

[Alexander Kanavin]

Hello Paul,

it would be very useful if devtool offered support for rebasing source 
patches when they fail to apply, but currently there does not seem to be 
any such feature:


ak@kanavin-desktop:~/development/poky/build$ devtool modify libksba
Parsing recipes..done.
NOTE: Fetching libksba...
NOTE: Unpacking...
NOTE: Patching...
ERROR: Applying 'ksba-add-pkgconfig-support.patch' failed:
checking file Makefile.am
Hunk #1 FAILED at 21.
1 out of 1 hunk FAILED
checking file configure.ac
Hunk #1 succeeded at 414 (offset 14 lines).
checking file ksba.pc.in
checking file src/ksba.m4
ERROR: Function failed: patch_do_patch
ak@kanavin-desktop:~/development/poky/build$

What devtool could do here is apply the patches that can be applied and 
then partially apply the patches that fail. Then give the developer some 
kind of UI for dealing with the rejected hunks (which typically means 
finding the place in the target file where the changes should go and 
then manually editing them in, while looking at the original patch).


Without this feature devtool is half as useful as it could be 
particularly for recipe version updates.


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

[OE-core] [PATCH v2] serf: Update to version 1.3.9

[Fabio Berton]

Change SRC_URI and UPSTREAM_CHECK_URI to use APACHE_MIRROR to download
serf from apache project page.

Signed-off-by: Fabio Berton 
---
 meta/recipes-support/serf/{serf_1.3.8.bb => serf_1.3.9.bb} | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)
 rename meta/recipes-support/serf/{serf_1.3.8.bb => serf_1.3.9.bb} (68%)

diff --git a/meta/recipes-support/serf/serf_1.3.8.bb 
b/meta/recipes-support/serf/serf_1.3.9.bb
similarity index 68%
rename from meta/recipes-support/serf/serf_1.3.8.bb
rename to meta/recipes-support/serf/serf_1.3.9.bb
index c498d90..6ea14ac 100644
--- a/meta/recipes-support/serf/serf_1.3.8.bb
+++ b/meta/recipes-support/serf/serf_1.3.9.bb
@@ -1,12 +1,12 @@
 SUMMARY = "High-Performance Asynchronous HTTP Client Library"
-SRC_URI = 
"http://snapshot.debian.org/archive/debian/20160728T043443Z/pool/main/s/${BPN}/${BPN}_${PV}.orig.tar.gz
 \
+SRC_URI = "${APACHE_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
file://norpath.patch \
file://env.patch"
 
-SRC_URI[md5sum] = "713beaf05d7f3329de121e218e2fcb93"
-SRC_URI[sha256sum] = 
"77134cd5010664ca023585bce50978bd4005906ed280ff889f591f86df7c59e4"
+SRC_URI[md5sum] = "370a6340ff20366ab088012cd13f2b57"
+SRC_URI[sha256sum] = 
"549c2d21c577a8a9c0450facb5cca809f26591f048e466552240947bdf7a87cc"
 
-UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/s/serf/"
+UPSTREAM_CHECK_URI = "${APACHE_MIRROR}/${BPN}/"
 
 LICENSE = "Apache-2.0"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=86d3f3a95c324c9479bd8986968f4327"
-- 
2.1.4

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

Re: [OE-core] version of gdb in morty

[Mark Hatle]

On 11/3/16 9:06 AM, Burton, Ross wrote:
> 
> On 3 November 2016 at 13:32, Alexander Kanavin
> >
> wrote:
> 
> Update to 7.12 for master branch please.
> 
> 
> To ease backporting to morty, taking 7.11.1 and then 7.12 makes sense to me.

I'm fine with this as well..  The third digit release is small enough of a
change, I don't think it will impact stability on such a new release.

--Mark

> Ross
> 
> 

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

Re: [OE-core] version of gdb in morty

[Burton, Ross]

On 3 November 2016 at 13:32, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> Update to 7.12 for master branch please.
>

To ease backporting to morty, taking 7.11.1 and then 7.12 makes sense to me.

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

[OE-core] [krogoth][PATCH 1/2] qemu: Security fix CVE-2016-4439

[Adrian Dudau]

affects qemu < 2.7.0

Quick Emulator(Qemu) built with the ESP/NCR53C9x controller emulation
support is vulnerable to an OOB write access issue. The controller uses
16-byte FIFO buffer for command and data transfer. The OOB write occurs
while writing to this command buffer in routine get_cmd().

A privileged user inside guest could use this flaw to crash the Qemu
process resulting in DoS.

References:
--
http://www.openwall.com/lists/oss-security/2016/05/19/4
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-4441

Signed-off-by: Adrian Dudau 
---
 .../recipes-devtools/qemu/qemu/CVE-2016-4441.patch | 78 ++
 meta/recipes-devtools/qemu/qemu_2.5.0.bb   |  1 +
 2 files changed, 79 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-4441.patch

diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2016-4441.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2016-4441.patch
new file mode 100644
index 000..3cbe394
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2016-4441.patch
@@ -0,0 +1,78 @@
+From 6c1fef6b59563cc415f21e03f81539ed4b33ad90 Mon Sep 17 00:00:00 2001
+From: Prasad J Pandit 
+Date: Thu, 19 May 2016 16:09:31 +0530
+Subject: [PATCH] esp: check dma length before reading scsi 
command(CVE-2016-4441)
+
+The 53C9X Fast SCSI Controller(FSC) comes with an internal 16-byte
+FIFO buffer. It is used to handle command and data transfer.
+Routine get_cmd() uses DMA to read scsi commands into this buffer.
+Add check to validate DMA length against buffer size to avoid any
+overrun.
+
+Fixes CVE-2016-4441.
+
+Upstream-Status: Backport
+
+Reported-by: Li Qiang 
+Cc: qemu-sta...@nongnu.org
+Signed-off-by: Prasad J Pandit 
+Message-Id: <1463654371-11169-3-git-send-email-ppan...@redhat.com>
+Signed-off-by: Paolo Bonzini 
+Signed-off-by: Adrian Dudau 
+---
+ hw/scsi/esp.c |   11 +++
+ 1 files changed, 7 insertions(+), 4 deletions(-)
+
+diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
+index 01497e6..591c817 100644
+--- a/hw/scsi/esp.c
 b/hw/scsi/esp.c
+@@ -82,7 +82,7 @@ void esp_request_cancelled(SCSIRequest *req)
+ }
+ }
+ 
+-static uint32_t get_cmd(ESPState *s, uint8_t *buf)
++static uint32_t get_cmd(ESPState *s, uint8_t *buf, uint8_t buflen)
+ {
+ uint32_t dmalen;
+ int target;
+@@ -92,6 +92,9 @@ static uint32_t get_cmd(ESPState *s, uint8_t *buf)
+ dmalen = s->rregs[ESP_TCLO];
+ dmalen |= s->rregs[ESP_TCMID] << 8;
+ dmalen |= s->rregs[ESP_TCHI] << 16;
++if (dmalen > buflen) {
++return 0;
++}
+ s->dma_memory_read(s->dma_opaque, buf, dmalen);
+ } else {
+ dmalen = s->ti_size;
+@@ -166,7 +169,7 @@ static void handle_satn(ESPState *s)
+ s->dma_cb = handle_satn;
+ return;
+ }
+-len = get_cmd(s, buf);
++len = get_cmd(s, buf, sizeof(buf));
+ if (len)
+ do_cmd(s, buf);
+ }
+@@ -180,7 +183,7 @@ static void handle_s_without_atn(ESPState *s)
+ s->dma_cb = handle_s_without_atn;
+ return;
+ }
+-len = get_cmd(s, buf);
++len = get_cmd(s, buf, sizeof(buf));
+ if (len) {
+ do_busid_cmd(s, buf, 0);
+ }
+@@ -192,7 +195,7 @@ static void handle_satn_stop(ESPState *s)
+ s->dma_cb = handle_satn_stop;
+ return;
+ }
+-s->cmdlen = get_cmd(s, s->cmdbuf);
++s->cmdlen = get_cmd(s, s->cmdbuf, sizeof(s->cmdbuf));
+ if (s->cmdlen) {
+ trace_esp_handle_satn_stop(s->cmdlen);
+ s->do_cmd = 1;
+-- 
+1.7.0.4
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.5.0.bb 
b/meta/recipes-devtools/qemu/qemu_2.5.0.bb
index ed8d911..58902b1 100644
--- a/meta/recipes-devtools/qemu/qemu_2.5.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.5.0.bb
@@ -26,6 +26,7 @@ SRC_URI += 
"file://configure-fix-Darwin-target-detection.patch \
 file://CVE-2016-6351_p2.patch \
 file://CVE-2016-4002.patch \
 file://CVE-2016-5403.patch \
+file://CVE-2016-4441.patch \
"
 SRC_URI_prepend = "http://wiki.qemu-project.org/download/${BP}.tar.bz2;
 SRC_URI[md5sum] = "f469f2330bbe76e3e39db10e9ac4f8db"
-- 
1.9.1

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

Re: [OE-core] version of gdb in morty

[Alexander Kanavin]

On 11/03/2016 02:27 AM, Khem Raj wrote:

I think doing an upgrade to 7.11.1 and Backporting that to morty is a
reasonable option here


Update to 7.12 for master branch please.

Alex

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

Re: [OE-core] [PATCH] gdb: update 7.11+git1a982b689c -> 7.11.1

[Alexander Kanavin]

On 11/03/2016 12:57 AM, Andre McCurdy wrote:

  41d8236 Set GDB version number to 7.11.1.


Master branch of oe-core should be updated to the latest release of gdb, 
which is 7.12 at the moment. This patch is fine for morty though.


Alex

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

[OE-core] [PATCH 2/3] linux-yocto/4.4: update to v4.4.30

[Bruce Ashfield]

Updating to the korg -stable release.

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb   |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_4.4.bb  | 20 ++--
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
index 6c1138277e54..27a4fa36bcd3 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb
@@ -11,13 +11,13 @@ python () {
 raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "652b564985db555b549ef73405aea6c38919eefc"
-SRCREV_meta ?= "3030330b066a33ce21164a8b30d0503cf9f68e5b"
+SRCREV_machine ?= "634050bef6cb967f654a62557bc18dd620bf2e95"
+SRCREV_meta ?= "d2d1decbd11e8f78b1aee36605d3653015d710e5"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.4.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.4;destsuffix=${KMETA}"
 
-LINUX_VERSION ?= "4.4.26"
+LINUX_VERSION ?= "4.4.30"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
index 76c41639c0d2..7e4fca43f3e8 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb
@@ -4,13 +4,13 @@ KCONFIG_MODE = "--allnoconfig"
 
 require recipes-kernel/linux/linux-yocto.inc
 
-LINUX_VERSION ?= "4.4.26"
+LINUX_VERSION ?= "4.4.30"
 
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
-SRCREV_meta ?= "3030330b066a33ce21164a8b30d0503cf9f68e5b"
+SRCREV_machine ?= "3c15255fd62c2202d76b5c110265f16d33010b9d"
+SRCREV_meta ?= "d2d1decbd11e8f78b1aee36605d3653015d710e5"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.4.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.4.bb
index e3a3d901d1b2..0678448f054c 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.4.bb
@@ -11,20 +11,20 @@ KBRANCH_qemux86  ?= "standard/base"
 KBRANCH_qemux86-64 ?= "standard/base"
 KBRANCH_qemumips64 ?= "standard/mti-malta64"
 
-SRCREV_machine_qemuarm ?= "187bcc13f3023c3ae0a3ba5c69ae85c4e5e693ac"
-SRCREV_machine_qemuarm64 ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
-SRCREV_machine_qemumips ?= "2f273556495dd2871f08c73fc3f40d1ad546c638"
-SRCREV_machine_qemuppc ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
-SRCREV_machine_qemux86 ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
-SRCREV_machine_qemux86-64 ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
-SRCREV_machine_qemumips64 ?= "0a19cacf573887a4b530a9fa14f05b355299"
-SRCREV_machine ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
-SRCREV_meta ?= "3030330b066a33ce21164a8b30d0503cf9f68e5b"
+SRCREV_machine_qemuarm ?= "d752c82364bf890681c161d80717d174419e7512"
+SRCREV_machine_qemuarm64 ?= "3c15255fd62c2202d76b5c110265f16d33010b9d"
+SRCREV_machine_qemumips ?= "ebf27c56cf862b2d5fd08e229e027b5e4dff3609"
+SRCREV_machine_qemuppc ?= "3c15255fd62c2202d76b5c110265f16d33010b9d"
+SRCREV_machine_qemux86 ?= "3c15255fd62c2202d76b5c110265f16d33010b9d"
+SRCREV_machine_qemux86-64 ?= "3c15255fd62c2202d76b5c110265f16d33010b9d"
+SRCREV_machine_qemumips64 ?= "de5b483095712c0c347689ef98e2a9b95bed4c7a"
+SRCREV_machine ?= "3c15255fd62c2202d76b5c110265f16d33010b9d"
+SRCREV_meta ?= "d2d1decbd11e8f78b1aee36605d3653015d710e5"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.4.git;name=machine;branch=${KBRANCH}; 
\

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.4;destsuffix=${KMETA}"
 
-LINUX_VERSION ?= "4.4.26"
+LINUX_VERSION ?= "4.4.30"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
-- 
2.5.0

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

[OE-core] [PATCH 3/3] linux-yocto/4.1: update to v4.1.35

[Bruce Ashfield]

Updating to the korg -stable release.

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_4.1.bb  | 20 ++--
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
index b95fb5857725..d15a4dcb195d 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
@@ -11,13 +11,13 @@ python () {
 raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "966ddde490030166010c5770f8f86cdd0e961c76"
-SRCREV_meta ?= "3c3197e65b6f2f5514853c1fe78ae8ffc131b02c"
+SRCREV_machine ?= "5395c3b5960ec1b769c0716f2889ef1101b66588"
+SRCREV_meta ?= "89785d2b18fa49233046125fddee8e161c8bec4d"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.1.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
 
-LINUX_VERSION ?= "4.1.33"
+LINUX_VERSION ?= "4.1.35"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
index ba01702cb63e..5d5e1fa945b9 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
@@ -4,13 +4,13 @@ KCONFIG_MODE = "--allnoconfig"
 
 require recipes-kernel/linux/linux-yocto.inc
 
-LINUX_VERSION ?= "4.1.33"
+LINUX_VERSION ?= "4.1.35"
 
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
-SRCREV_meta ?= "3c3197e65b6f2f5514853c1fe78ae8ffc131b02c"
+SRCREV_machine ?= "f358ce2569953d18cf6bd91d0269076938e5b091"
+SRCREV_meta ?= "89785d2b18fa49233046125fddee8e161c8bec4d"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.1.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
index 788a8eaaa8be..529c20737238 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
@@ -11,20 +11,20 @@ KBRANCH_qemux86  ?= "standard/base"
 KBRANCH_qemux86-64 ?= "standard/base"
 KBRANCH_qemumips64 ?= "standard/mti-malta64"
 
-SRCREV_machine_qemuarm ?= "d67ef485ce1420df11bda2d9f6fb78ef50c1adff"
-SRCREV_machine_qemuarm64 ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
-SRCREV_machine_qemumips ?= "65116339cfd210990c9c4710cdfec3ebd59abb0e"
-SRCREV_machine_qemuppc ?= "30816907653b57f1f3d5f9a7a2f6339bab14a680"
-SRCREV_machine_qemux86 ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
-SRCREV_machine_qemux86-64 ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
-SRCREV_machine_qemumips64 ?= "f7a0b532b6ac81757d85b0c9a928f45a87c9e364"
-SRCREV_machine ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
-SRCREV_meta ?= "3c3197e65b6f2f5514853c1fe78ae8ffc131b02c"
+SRCREV_machine_qemuarm ?= "bb6c714397ab4c48f4fcc76c0a609afbb42dfa2a"
+SRCREV_machine_qemuarm64 ?= "f358ce2569953d18cf6bd91d0269076938e5b091"
+SRCREV_machine_qemumips ?= "4a42cbc6464c592a8ce81cf9aefb780df02e10ac"
+SRCREV_machine_qemuppc ?= "f0ecbfc7c5c24f0ecdd05e3304f0bea302ed116c"
+SRCREV_machine_qemux86 ?= "f358ce2569953d18cf6bd91d0269076938e5b091"
+SRCREV_machine_qemux86-64 ?= "f358ce2569953d18cf6bd91d0269076938e5b091"
+SRCREV_machine_qemumips64 ?= "9162b0e9523407b638a3f7e2ed26450334e24969"
+SRCREV_machine ?= "f358ce2569953d18cf6bd91d0269076938e5b091"
+SRCREV_meta ?= "89785d2b18fa49233046125fddee8e161c8bec4d"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.1.git;name=machine;branch=${KBRANCH}; 
\

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
 
-LINUX_VERSION ?= "4.1.33"
+LINUX_VERSION ?= "4.1.35"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
-- 
2.5.0

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

[OE-core] [krogoth][PATCH 2/2] qemu: Security fix CVE-2016-4952

[Adrian Dudau]

affects qemu < 2.7.0

Quick Emulator(Qemu) built with the VMWARE PVSCSI paravirtual SCSI bus
emulation support is vulnerable to an OOB r/w access issue. It could
occur while processing SCSI commands 'PVSCSI_CMD_SETUP_RINGS' or
'PVSCSI_CMD_SETUP_MSG_RING'.

A privileged user inside guest could use this flaw to crash the Qemu
process resulting in DoS.

References:
--
http://www.openwall.com/lists/oss-security/2016/05/23/1

Signed-off-by: Adrian Dudau 
---
 .../recipes-devtools/qemu/qemu/CVE-2016-4952.patch | 105 +
 meta/recipes-devtools/qemu/qemu_2.5.0.bb   |   1 +
 2 files changed, 106 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-4952.patch

diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2016-4952.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2016-4952.patch
new file mode 100644
index 000..52d2a1e
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2016-4952.patch
@@ -0,0 +1,105 @@
+From 3e831b40e015ba34dfb55ff11f767001839425ff Mon Sep 17 00:00:00 2001
+From: Prasad J Pandit 
+Date: Mon, 23 May 2016 16:18:05 +0530
+Subject: [PATCH] scsi: pvscsi: check command descriptor ring buffer size 
(CVE-2016-4952)
+
+Vmware Paravirtual SCSI emulation uses command descriptors to
+process SCSI commands. These descriptors come with their ring
+buffers. A guest could set the ring buffer size to an arbitrary
+value leading to OOB access issue. Add check to avoid it.
+
+Upstream-Status: Backported
+
+Reported-by: Li Qiang 
+Signed-off-by: Prasad J Pandit 
+Cc: qemu-sta...@nongnu.org
+Message-Id: <1464000485-27041-1-git-send-email-ppan...@redhat.com>
+Reviewed-by: Shmulik Ladkani 
+Reviewed-by: Dmitry Fleytman 
+Signed-off-by: Paolo Bonzini 
+Signed-off-by: Adrian Dudau 
+---
+ hw/scsi/vmw_pvscsi.c |   24 
+ 1 files changed, 20 insertions(+), 4 deletions(-)
+
+diff --git a/hw/scsi/vmw_pvscsi.c b/hw/scsi/vmw_pvscsi.c
+index f67b5bf..2d7528d 100644
+--- a/hw/scsi/vmw_pvscsi.c
 b/hw/scsi/vmw_pvscsi.c
+@@ -153,7 +153,7 @@ pvscsi_log2(uint32_t input)
+ return log;
+ }
+ 
+-static void
++static int
+ pvscsi_ring_init_data(PVSCSIRingInfo *m, PVSCSICmdDescSetupRings *ri)
+ {
+ int i;
+@@ -161,6 +161,10 @@ pvscsi_ring_init_data(PVSCSIRingInfo *m, 
PVSCSICmdDescSetupRings *ri)
+ uint32_t req_ring_size, cmp_ring_size;
+ m->rs_pa = ri->ringsStatePPN << VMW_PAGE_SHIFT;
+ 
++if ((ri->reqRingNumPages > PVSCSI_SETUP_RINGS_MAX_NUM_PAGES)
++|| (ri->cmpRingNumPages > PVSCSI_SETUP_RINGS_MAX_NUM_PAGES)) {
++return -1;
++}
+ req_ring_size = ri->reqRingNumPages * PVSCSI_MAX_NUM_REQ_ENTRIES_PER_PAGE;
+ cmp_ring_size = ri->cmpRingNumPages * PVSCSI_MAX_NUM_CMP_ENTRIES_PER_PAGE;
+ txr_len_log2 = pvscsi_log2(req_ring_size - 1);
+@@ -192,15 +196,20 @@ pvscsi_ring_init_data(PVSCSIRingInfo *m, 
PVSCSICmdDescSetupRings *ri)
+ 
+ /* Flush ring state page changes */
+ smp_wmb();
++
++return 0;
+ }
+ 
+-static void
++static int
+ pvscsi_ring_init_msg(PVSCSIRingInfo *m, PVSCSICmdDescSetupMsgRing *ri)
+ {
+ int i;
+ uint32_t len_log2;
+ uint32_t ring_size;
+ 
++if (ri->numPages > PVSCSI_SETUP_MSG_RING_MAX_NUM_PAGES) {
++return -1;
++}
+ ring_size = ri->numPages * PVSCSI_MAX_NUM_MSG_ENTRIES_PER_PAGE;
+ len_log2 = pvscsi_log2(ring_size - 1);
+ 
+@@ -220,6 +229,8 @@ pvscsi_ring_init_msg(PVSCSIRingInfo *m, 
PVSCSICmdDescSetupMsgRing *ri)
+ 
+ /* Flush ring state page changes */
+ smp_wmb();
++
++return 0;
+ }
+ 
+ static void
+@@ -770,7 +781,10 @@ pvscsi_on_cmd_setup_rings(PVSCSIState *s)
+ trace_pvscsi_on_cmd_arrived("PVSCSI_CMD_SETUP_RINGS");
+ 
+ pvscsi_dbg_dump_tx_rings_config(rc);
+-pvscsi_ring_init_data(>rings, rc);
++if (pvscsi_ring_init_data(>rings, rc) < 0) {
++return PVSCSI_COMMAND_PROCESSING_FAILED;
++}
++
+ s->rings_info_valid = TRUE;
+ return PVSCSI_COMMAND_PROCESSING_SUCCEEDED;
+ }
+@@ -850,7 +864,9 @@ pvscsi_on_cmd_setup_msg_ring(PVSCSIState *s)
+ }
+ 
+ if (s->rings_info_valid) {
+-pvscsi_ring_init_msg(>rings, rc);
++if (pvscsi_ring_init_msg(>rings, rc) < 0) {
++return PVSCSI_COMMAND_PROCESSING_FAILED;
++}
+ s->msg_ring_info_valid = TRUE;
+ }
+ return sizeof(PVSCSICmdDescSetupMsgRing) / sizeof(uint32_t);
+-- 
+1.7.0.4
+
diff --git a/meta/recipes-devtools/qemu/qemu_2.5.0.bb 
b/meta/recipes-devtools/qemu/qemu_2.5.0.bb
index 58902b1..b965f69 100644
--- a/meta/recipes-devtools/qemu/qemu_2.5.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_2.5.0.bb
@@ -27,6 +27,7 @@ SRC_URI += 
"file://configure-fix-Darwin-target-detection.patch \
 file://CVE-2016-4002.patch \
 file://CVE-2016-5403.patch \
 file://CVE-2016-4441.patch \
+

[OE-core] [PATCH 1/3] linux-yocto/4.8: update to 4.8.6

[Bruce Ashfield]

Integrating the korg -stable release.

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb   |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_4.8.bb  | 20 ++--
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
index e51c9cdcca0e..26b309d8b8f4 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
@@ -11,13 +11,13 @@ python () {
 raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "4057556c041f6aac0d29aa3425587d414c9a0090"
-SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
+SRCREV_machine ?= "b99b6fac437104e206d30540a5cb12103049af1e"
+SRCREV_meta ?= "87e5fc8b7cb387f197cdd098cdde4e96e9e8ed0d"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.8.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=${KMETA}"
 
-LINUX_VERSION ?= "4.8.3"
+LINUX_VERSION ?= "4.8.6"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
index c8ddbd93dc7f..63dd11baa19e 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
@@ -4,13 +4,13 @@ KCONFIG_MODE = "--allnoconfig"
 
 require recipes-kernel/linux/linux-yocto.inc
 
-LINUX_VERSION ?= "4.8.3"
+LINUX_VERSION ?= "4.8.6"
 
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
-SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
+SRCREV_machine ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
+SRCREV_meta ?= "87e5fc8b7cb387f197cdd098cdde4e96e9e8ed0d"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.8.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
index 13778b9c4db6..03691982b1f0 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
@@ -11,20 +11,20 @@ KBRANCH_qemux86  ?= "standard/base"
 KBRANCH_qemux86-64 ?= "standard/base"
 KBRANCH_qemumips64 ?= "standard/mti-malta64"
 
-SRCREV_machine_qemuarm ?= "4cc544ad09ad704322cb66fe4ba197a6a05dc71f"
-SRCREV_machine_qemuarm64 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
-SRCREV_machine_qemumips ?= "c285969d4f9376a671167ecf397578c8ad3e6a75"
-SRCREV_machine_qemuppc ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
-SRCREV_machine_qemux86 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
-SRCREV_machine_qemux86-64 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
-SRCREV_machine_qemumips64 ?= "64f96ba530e58456070f26b0f3fcce3f64988b72"
-SRCREV_machine ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
-SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
+SRCREV_machine_qemuarm ?= "94d3e8675e2fcb09f29814a33ccf79df06149104"
+SRCREV_machine_qemuarm64 ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
+SRCREV_machine_qemumips ?= "046ff6344eee25dcc0eea1214e0ad8771ddfabfb"
+SRCREV_machine_qemuppc ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
+SRCREV_machine_qemux86 ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
+SRCREV_machine_qemux86-64 ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
+SRCREV_machine_qemumips64 ?= "edcb167f91abc071cc98cbd762418ff7ab9d839b"
+SRCREV_machine ?= "9d5f74f941c3ca234f58ff8e539f5ca64458c0a7"
+SRCREV_meta ?= "87e5fc8b7cb387f197cdd098cdde4e96e9e8ed0d"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.8.git;name=machine;branch=${KBRANCH}; 
\

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=${KMETA}"
 
-LINUX_VERSION ?= "4.8.3"
+LINUX_VERSION ?= "4.8.6"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
-- 
2.5.0

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

[OE-core] [PATCH 0/3] linux-yocto: -stable updates

[Bruce Ashfield]

Hi all,

Here are some -stable updates to the 4.1, 4.4 and 4.8 kernel tree. I did build
and boot tests for the arches for the different version and also selected -rt
boot tests.

It is a lot of combinations to cover, but I don't expect any major issues.

Any of these SRCREV updates are good for backporting to the various release
branches, since they are bugfix only.

Cheers,

Bruce

The following changes since commit c3d2df883a9d6d5036277114339673656d89a728:

  oeqa/selftest/kernel.py: Add new file destined for kernel related tests 
(2016-11-01 10:05:46 +)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib zedd/kernel
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Bruce Ashfield (3):
  linux-yocto/4.8: update to 4.8.6
  linux-yocto/4.4: update to v4.4.30
  linux-yocto/4.1: update to v4.1.35

 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb   |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb   |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_4.1.bb  | 20 ++--
 meta/recipes-kernel/linux/linux-yocto_4.4.bb  | 20 ++--
 meta/recipes-kernel/linux/linux-yocto_4.8.bb  | 20 ++--
 9 files changed, 48 insertions(+), 48 deletions(-)

-- 
2.5.0

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

[OE-core] qemu woes on recent Fedora 24 kernels

[Krisztian Litkey]

  Hi,

I thought I share this with others in case I'm not the only one who
have been struggling with this recently. I've been running lately into
really bad (and non-deterministic) clock skew issues, often triggering
oopses, when testing images with qemu on fedora 24. I'm not sure what
has changed in the fedora kernels that triggered this behavior, but
switching the clock source from TSC to HPET (by appending
clocksource=hpet to the kernel command line in the generated qemu
config file) did the trick for me and got rid of the problems.

  Cheers,
    kli

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

Re: [OE-core] [PATCH v2 1/1] Make yocto-spdx support spdx2.0 SPEC

[Jan-Simon Möller]

Hi Lei, Maxin!

Where do we stand: 
- v1 of patch submitted
- comment to create/use dosocs-native tp avoid the separate install (well, +1)
- comment that "the following direct dependencies that not belong to oe-core"

Did I summarize that correctly ?

@Maxin: what would you propose, work on the dependencies or let the user 
install ?
@Lei: can you find where those dependencies are ?
  (https://layers.openembedded.org/layerindex/branch/morty/recipes/)

Best,
Jan-Simon

Am Donnerstag, 3. November 2016, 04:02:42 schrieb Lei, Maohui:
> Ping.
> 
> 
> 
> > -Original Message-
> > From: openembedded-core-boun...@lists.openembedded.org
> > [mailto:openembedded-
 core-boun...@lists.openembedded.org] On Behalf Of
> > Lei, Maohui
> > Sent: Monday, October 17, 2016 9:04 AM
> > To: Maxin B. John; Jan-Simon Möller
> > Cc: jsmoel...@linuxfoundation.org;
> > openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [PATCH
> > v2 1/1] Make yocto-spdx support spdx2.0 SPEC 
> > Hi Maxin, Simon
> > 
> > 
> > > > Instead of requesting the user to install the DoSOCSv2 from github
> > > > or other repos, can we make the spdx.bbclass depend on
> > > > "dosocs-native"
> > > 
> > > or
> > > 
> > > > similar and make that "DoSOCSv2" recipe available in oe-core ?
> > >
> > >
> > >
> > > That's a good idea. I will try.
> > 
> > 
> > I tried to make DoSOCSv2 recipe to oe-core, and find that there are at
> > least
 the following direct dependencies that not belong to oe-core.
> > 
> > PostgreSQL
> > python-psycopg2
> > jinja2
> > python-magic
> > docopt
> > SQLAlchemy
> > psycopg2
> > 
> > I think it difficult to add them all into oe-core and it's the reason that
> > why
 the original spdx module didn't add fossology into oe-core.
> > 
> > 
> > 
> > Best regards
> > Lei
> > 
> > 
> > 
> > > -Original Message-
> > > From: openembedded-core-boun...@lists.openembedded.org
> > > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> > > Lei, Maohui
> > > Sent: Thursday, September 22, 2016 10:19 AM
> > > To: Maxin B. John; Jan-Simon Möller
> > > Cc: jsmoel...@linuxfoundation.org; openembedded-
> > > c...@lists.openembedded.org
> > > Subject: Re: [OE-core] [PATCH v2 1/1] Make yocto-spdx support spdx2.0
> > > SPEC
> > >
> > >
> > >
> > > Hi Maxin, Simon
> > >
> > >
> > >
> > > > It would be nice to include the reason for change from fossology to
> > > > dosocs2 in the commit message too (from cover letter)
> > >
> > >
> > >
> > > OK, I will add the reasons into the commit message in v3.
> > >
> > >
> > >
> > > > Instead of requesting the user to install the DoSOCSv2 from github
> > > > or other repos, can we make the spdx.bbclass depend on
> > > > "dosocs-native"
> > > 
> > > or
> > > 
> > > > similar and make that "DoSOCSv2" recipe available in oe-core ?
> > >
> > >
> > >
> > > That's a good idea. I will try.
> > >
> > >
> > >
> > >
> > > Best Regards
> > > Lei
> > >
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Maxin B. John [mailto:maxin.j...@intel.com]
> > > > Sent: Monday, September 19, 2016 6:58 PM
> > > > To: Lei, Maohui
> > > > Cc: openembedded-core@lists.openembedded.org;
> > > > jsmoel...@linuxfoundation.org
> > > > Subject: Re: [OE-core] [PATCH v2 1/1] Make yocto-spdx support
> > > > spdx2.0 SPEC
> > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > >
> > > >
> > > > Please find my comments below:
> > > >
> > > >
> > > >
> > > > On Mon, Sep 19, 2016 at 04:39:50PM +0800, Lei Maohui wrote:
> > > > 
> > > > > More:
> > > > > - change spdx tool from fossology to dosocs2
> > > >
> > > >
> > > >
> > > > It would be nice to include the reason for change from fossology to
> > > > dosocs2 in the commit message too (from cover letter)
> > > >
> > > >
> > > >
> > > > > Signed-off-by: Lei Maohui 
> > > > > ---
> > > > > 
> > > > >  meta/classes/spdx.bbclass | 505
> > > > > 
> > > > > ++--
> > > > 
> > > > --
> > > > 
> > > > >  meta/conf/licenses.conf   |  67 +-
> > > > >  2 files changed, 198 insertions(+), 374 deletions(-)
> > > > >
> > > > >
> > > > >
> > > > > diff --git a/meta/classes/spdx.bbclass b/meta/classes/spdx.bbclass
> > > > > index 0c92765..27c0fa0 100644
> > > > > --- a/meta/classes/spdx.bbclass
> > > > > +++ b/meta/classes/spdx.bbclass
> > > > > @@ -1,365 +1,252 @@
> > > > > 
> > > > >  # This class integrates real-time license scanning, generation of
> > > > > 
> > > > > SPDX standard  # output and verifiying license info during the
> > > > 
> > > > building process.
> > > > 
> > > > > -# It is a combination of efforts from the OE-Core, SPDX and
> > > > 
> > > > Fossology projects.
> > > > 
> > > > > +# It is a combination of efforts from the OE-Core, SPDX and
> > > > > +DoSOCSv2
> > > > 
> > > > projects.
> > > > 
> > > > >  #
> > > > > 
> > > > > -# For more information on FOSSology:
> > > > > -#   http://www.fossology.org
> > > > > -#
> > > > > -# For more information on FOSSologySPDX 

Re: [OE-core] [PATCH 1/2] devtool: update-recipe: decode output before treating it as a string

[Paul Eggleton]

On Thu, 03 Nov 2016 15:53:53 Paul Eggleton wrote:
> When you receive output from subprocess, with Python 3 it's a stream of
> bytes so you need to decode it before you can start treating it as a
> string.
> 
> Fixes [YOCTO #10447].

Oops, that should have been 10563. I've corrected the branch.

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