Re: [OE-core] [PATCH V4] u-boot-fw-utils: Add support for libubootenv

[ChenQi]

On 01/09/2020 05:31 PM, Stefano Babic wrote:

Hi Chen,

On 09/01/20 02:29, ChenQi wrote:

Resend as previous email forgets to add Stefano.

In case of multilib, the do_package fails with

ERROR: libubootenv-0.2-r0 do_package: QA Issue: libubootenv:
Files/directories were installed but not shipped in any package:
   /usr/lib/libubootenv.so
   /usr/lib/libubootenv.so.0.2


Thanks for reporting this - I will take care of the error in next days.

Regards,
Stefano


I've just sent out a patch to fix this problem.

Regards,
Chen Qi


Regards,
Chen Qi

On 01/03/2020 08:33 PM, Stefano Babic wrote:

libubootenv is a replacement for u-boot-fw-utils. It is
hardware-independent and provides fw_printenv and fw_setenv tools that
are full compatible with the ones provided by U-Boot. A library is
provided to access the environment from an own application.
License is LGPL-2.1 and this allow to link the library to proprietary
code. The user of the tools should install the configuration file
"fw_env.config", as he is already used to with u-boot-fw-utils. The
configuration file is compatible with u-boot-fw-utils.
A full discussion about issues on current u-boot-fw-utils can be read on
U-Boot's ML at:

http://u-boot.10912.n7.nabble.com/SWUpdate-U-Boot-environment-library-dependency-tt340530.html#none


Signed-off-by: Stefano Babic 
---
Changes since V3:
 - Update maintainers.inc (R. Purdie)
 - Add link to U-Boot's ML in commit message (R. Purdie)
Changes since V2:
 - drop .inc file (R. Burton)
Changes since V1:
 - drop PACKAGE_ARCH (M. Jansa)

   meta/conf/distro/include/maintainers.inc   |  1 +
   meta/recipes-bsp/u-boot/libubootenv_0.2.bb | 26 ++
   2 files changed, 27 insertions(+)
   create mode 100644 meta/recipes-bsp/u-boot/libubootenv_0.2.bb

diff --git a/meta/conf/distro/include/maintainers.inc
b/meta/conf/distro/include/maintainers.inc
index 39eee9475c..09453e7343 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -398,6 +398,7 @@ RECIPE_MAINTAINER_pn-libunwind = "Bruce Ashfield
"
   RECIPE_MAINTAINER_pn-liburcu = "Alexander Kanavin
"
   RECIPE_MAINTAINER_pn-liburi-perl = "Tim Orling
"
   RECIPE_MAINTAINER_pn-libusb1 = "Anuj Mittal "
+RECIPE_MAINTAINER_pn-libubootenv = "Stefano Babic "
   RECIPE_MAINTAINER_pn-libva = "Anuj Mittal "
   RECIPE_MAINTAINER_pn-libva-utils = "Anuj Mittal
"
   RECIPE_MAINTAINER_pn-libvorbis = "Tanu Kaskinen "
diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
new file mode 100644
index 00..23230d132e
--- /dev/null
+++ b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
@@ -0,0 +1,26 @@
+SUMMARY = "U-Boot libraries and tools to access environment"
+DEPENDS += "mtd-utils"
+
+DESCRIPTION = "This package contains tools and libraries to read \
+and modify U-Boot environment. \
+It provides a hardware-independent replacement for fw_printenv/setenv
utilities \
+provided by U-Boot"
+
+HOMEPAGE = "https://github.com/sbabic/libubootenv";
+LICENSE = "LGPL-2.1"
+LIC_FILES_CHKSUM =
"file://Licenses/lgpl-2.1.txt;md5=4fbd65380cdd255951079008b364516c"
+SECTION = "libs"
+
+SRC_URI = "git://github.com/sbabic/libubootenv;protocol=https"
+SRCREV = "bf6ff631c0e38cede67268ceb8bf1383b5f8848e"
+
+S = "${WORKDIR}/git"
+
+inherit cmake
+
+EXTRA_OECMAKE = "-DCMAKE_BUILD_TYPE=Release"
+
+PROVIDES += "u-boot-fw-utils"
+RPROVIDES_${PN} += "u-boot-fw-utils"
+
+BBCLASSEXTEND = "native"






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

Re: [OE-core] [PATCH V4] u-boot-fw-utils: Add support for libubootenv

[ChenQi]

Resend as previous email forgets to add Stefano.

In case of multilib, the do_package fails with

ERROR: libubootenv-0.2-r0 do_package: QA Issue: libubootenv: 
Files/directories were installed but not shipped in any package:

  /usr/lib/libubootenv.so
  /usr/lib/libubootenv.so.0.2

Regards,
Chen Qi

On 01/03/2020 08:33 PM, Stefano Babic wrote:

libubootenv is a replacement for u-boot-fw-utils. It is
hardware-independent and provides fw_printenv and fw_setenv tools that
are full compatible with the ones provided by U-Boot. A library is
provided to access the environment from an own application.
License is LGPL-2.1 and this allow to link the library to proprietary
code. The user of the tools should install the configuration file
"fw_env.config", as he is already used to with u-boot-fw-utils. The
configuration file is compatible with u-boot-fw-utils.
A full discussion about issues on current u-boot-fw-utils can be read on
U-Boot's ML at:

http://u-boot.10912.n7.nabble.com/SWUpdate-U-Boot-environment-library-dependency-tt340530.html#none

Signed-off-by: Stefano Babic 
---
Changes since V3:
- Update maintainers.inc (R. Purdie)
- Add link to U-Boot's ML in commit message (R. Purdie)
Changes since V2:
- drop .inc file (R. Burton)
Changes since V1:
- drop PACKAGE_ARCH (M. Jansa)

  meta/conf/distro/include/maintainers.inc   |  1 +
  meta/recipes-bsp/u-boot/libubootenv_0.2.bb | 26 ++
  2 files changed, 27 insertions(+)
  create mode 100644 meta/recipes-bsp/u-boot/libubootenv_0.2.bb

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index 39eee9475c..09453e7343 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -398,6 +398,7 @@ RECIPE_MAINTAINER_pn-libunwind = "Bruce Ashfield 
"
  RECIPE_MAINTAINER_pn-liburcu = "Alexander Kanavin "
  RECIPE_MAINTAINER_pn-liburi-perl = "Tim Orling 
"
  RECIPE_MAINTAINER_pn-libusb1 = "Anuj Mittal "
+RECIPE_MAINTAINER_pn-libubootenv = "Stefano Babic "
  RECIPE_MAINTAINER_pn-libva = "Anuj Mittal "
  RECIPE_MAINTAINER_pn-libva-utils = "Anuj Mittal "
  RECIPE_MAINTAINER_pn-libvorbis = "Tanu Kaskinen "
diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb 
b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
new file mode 100644
index 00..23230d132e
--- /dev/null
+++ b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
@@ -0,0 +1,26 @@
+SUMMARY = "U-Boot libraries and tools to access environment"
+DEPENDS += "mtd-utils"
+
+DESCRIPTION = "This package contains tools and libraries to read \
+and modify U-Boot environment. \
+It provides a hardware-independent replacement for fw_printenv/setenv 
utilities \
+provided by U-Boot"
+
+HOMEPAGE = "https://github.com/sbabic/libubootenv";
+LICENSE = "LGPL-2.1"
+LIC_FILES_CHKSUM = 
"file://Licenses/lgpl-2.1.txt;md5=4fbd65380cdd255951079008b364516c"
+SECTION = "libs"
+
+SRC_URI = "git://github.com/sbabic/libubootenv;protocol=https"
+SRCREV = "bf6ff631c0e38cede67268ceb8bf1383b5f8848e"
+
+S = "${WORKDIR}/git"
+
+inherit cmake
+
+EXTRA_OECMAKE = "-DCMAKE_BUILD_TYPE=Release"
+
+PROVIDES += "u-boot-fw-utils"
+RPROVIDES_${PN} += "u-boot-fw-utils"
+
+BBCLASSEXTEND = "native"



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

Re: [OE-core] [PATCH V4] u-boot-fw-utils: Add support for libubootenv

[ChenQi]

In case of multilib, the do_package fails with

ERROR: libubootenv-0.2-r0 do_package: QA Issue: libubootenv: 
Files/directories were installed but not shipped in any package:

  /usr/lib/libubootenv.so
  /usr/lib/libubootenv.so.0.2

Regards,
Chen Qi

On 01/03/2020 08:33 PM, Stefano Babic wrote:

libubootenv is a replacement for u-boot-fw-utils. It is
hardware-independent and provides fw_printenv and fw_setenv tools that
are full compatible with the ones provided by U-Boot. A library is
provided to access the environment from an own application.
License is LGPL-2.1 and this allow to link the library to proprietary
code. The user of the tools should install the configuration file
"fw_env.config", as he is already used to with u-boot-fw-utils. The
configuration file is compatible with u-boot-fw-utils.
A full discussion about issues on current u-boot-fw-utils can be read on
U-Boot's ML at:

http://u-boot.10912.n7.nabble.com/SWUpdate-U-Boot-environment-library-dependency-tt340530.html#none

Signed-off-by: Stefano Babic 
---
Changes since V3:
- Update maintainers.inc (R. Purdie)
- Add link to U-Boot's ML in commit message (R. Purdie)
Changes since V2:
- drop .inc file (R. Burton)
Changes since V1:
- drop PACKAGE_ARCH (M. Jansa)

  meta/conf/distro/include/maintainers.inc   |  1 +
  meta/recipes-bsp/u-boot/libubootenv_0.2.bb | 26 ++
  2 files changed, 27 insertions(+)
  create mode 100644 meta/recipes-bsp/u-boot/libubootenv_0.2.bb

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index 39eee9475c..09453e7343 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -398,6 +398,7 @@ RECIPE_MAINTAINER_pn-libunwind = "Bruce Ashfield 
"
  RECIPE_MAINTAINER_pn-liburcu = "Alexander Kanavin "
  RECIPE_MAINTAINER_pn-liburi-perl = "Tim Orling 
"
  RECIPE_MAINTAINER_pn-libusb1 = "Anuj Mittal "
+RECIPE_MAINTAINER_pn-libubootenv = "Stefano Babic "
  RECIPE_MAINTAINER_pn-libva = "Anuj Mittal "
  RECIPE_MAINTAINER_pn-libva-utils = "Anuj Mittal "
  RECIPE_MAINTAINER_pn-libvorbis = "Tanu Kaskinen "
diff --git a/meta/recipes-bsp/u-boot/libubootenv_0.2.bb 
b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
new file mode 100644
index 00..23230d132e
--- /dev/null
+++ b/meta/recipes-bsp/u-boot/libubootenv_0.2.bb
@@ -0,0 +1,26 @@
+SUMMARY = "U-Boot libraries and tools to access environment"
+DEPENDS += "mtd-utils"
+
+DESCRIPTION = "This package contains tools and libraries to read \
+and modify U-Boot environment. \
+It provides a hardware-independent replacement for fw_printenv/setenv 
utilities \
+provided by U-Boot"
+
+HOMEPAGE = "https://github.com/sbabic/libubootenv";
+LICENSE = "LGPL-2.1"
+LIC_FILES_CHKSUM = 
"file://Licenses/lgpl-2.1.txt;md5=4fbd65380cdd255951079008b364516c"
+SECTION = "libs"
+
+SRC_URI = "git://github.com/sbabic/libubootenv;protocol=https"
+SRCREV = "bf6ff631c0e38cede67268ceb8bf1383b5f8848e"
+
+S = "${WORKDIR}/git"
+
+inherit cmake
+
+EXTRA_OECMAKE = "-DCMAKE_BUILD_TYPE=Release"
+
+PROVIDES += "u-boot-fw-utils"
+RPROVIDES_${PN} += "u-boot-fw-utils"
+
+BBCLASSEXTEND = "native"



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

Re: [OE-core] [PATCH] multilib.conf: Ensure that RECIPE_SYSROOT is unchanged for native

[ChenQi]

On 12/17/2019 09:55 PM, Mike Crowe wrote:

On Tuesday 17 December 2019 at 16:56:11 +0800, ChenQi wrote:

On 12/17/2019 04:02 PM, Mike Crowe via Openembedded-core wrote:

Ensure that RECIPE_SYSROOT is the same for -native recipes whether
multilib.conf is included or not.

Without this change task signatures for -native recipes change when
switching between MACHINEs that require multilib.conf and those that
don't.

This fix was one of the ones suggested by Khem Raj in
http://lists.openembedded.org/pipermail/openembedded-core/2019-December/290303.html

Add test_sstate_multilib_or_not_native_samesigs test case to
sstatetests.py to ensure that this stays fixed.

Signed-off-by: Mike Crowe 
---
   meta/conf/multilib.conf |  1 +
   meta/lib/oeqa/selftest/cases/sstatetests.py | 40 +
   2 files changed, 41 insertions(+)

diff --git a/meta/conf/multilib.conf b/meta/conf/multilib.conf
index cfed3fbbd0..58f2ac5c86 100644
--- a/meta/conf/multilib.conf
+++ b/meta/conf/multilib.conf
@@ -9,6 +9,7 @@ MULTILIBS ??= "multilib:lib32"
   STAGING_DIR_HOST = "${WORKDIR}/${MLPREFIX}recipe-sysroot"
   STAGING_DIR_TARGET = "${WORKDIR}/${MLPREFIX}recipe-sysroot"
   RECIPE_SYSROOT = "${WORKDIR}/${MLPREFIX}recipe-sysroot"
+RECIPE_SYSROOT_class-native = "${WORKDIR}/recipe-sysroot"

How about just removing MLPREFIX?

I'm afraid that I don't understand what you are suggesting. The above
change does remove MLPREFIX for -native only.

Thanks.

Mike.

I mean removing all these MLPREFIX, so that STAGING_DIR_HOST, 
STAGING_DIR_TARGET and RECIPE_SYSROOT will all be ${WORKDIR}/recipe-sysroot.


Best Regards,

Chen Qi

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

Re: [OE-core] [PATCH] multilib.conf: Ensure that RECIPE_SYSROOT is unchanged for native

[ChenQi]

On 12/17/2019 04:02 PM, Mike Crowe via Openembedded-core wrote:

Ensure that RECIPE_SYSROOT is the same for -native recipes whether
multilib.conf is included or not.

Without this change task signatures for -native recipes change when
switching between MACHINEs that require multilib.conf and those that
don't.

This fix was one of the ones suggested by Khem Raj in
http://lists.openembedded.org/pipermail/openembedded-core/2019-December/290303.html

Add test_sstate_multilib_or_not_native_samesigs test case to
sstatetests.py to ensure that this stays fixed.

Signed-off-by: Mike Crowe 
---
  meta/conf/multilib.conf |  1 +
  meta/lib/oeqa/selftest/cases/sstatetests.py | 40 +
  2 files changed, 41 insertions(+)

diff --git a/meta/conf/multilib.conf b/meta/conf/multilib.conf
index cfed3fbbd0..58f2ac5c86 100644
--- a/meta/conf/multilib.conf
+++ b/meta/conf/multilib.conf
@@ -9,6 +9,7 @@ MULTILIBS ??= "multilib:lib32"
  STAGING_DIR_HOST = "${WORKDIR}/${MLPREFIX}recipe-sysroot"
  STAGING_DIR_TARGET = "${WORKDIR}/${MLPREFIX}recipe-sysroot"
  RECIPE_SYSROOT = "${WORKDIR}/${MLPREFIX}recipe-sysroot"
+RECIPE_SYSROOT_class-native = "${WORKDIR}/recipe-sysroot"


How about just removing MLPREFIX?

Regards,
Chen Qi

  
  INHERIT += "multilib_global"
  
diff --git a/meta/lib/oeqa/selftest/cases/sstatetests.py b/meta/lib/oeqa/selftest/cases/sstatetests.py

index 6757a0ec68..9adb511960 100644
--- a/meta/lib/oeqa/selftest/cases/sstatetests.py
+++ b/meta/lib/oeqa/selftest/cases/sstatetests.py
@@ -446,6 +446,46 @@ BB_SIGNATURE_HANDLER = "OEBasicHash"
  self.assertCountEqual(files1, files2)
  
  
+def test_sstate_multilib_or_not_native_samesigs(self):

+"""The sstate checksums of two native recipes (and their dependencies)
+where the target is using multilib in one but not the other
+should be the same. We use the qemux86copy machine to test
+this.
+"""
+
+self.write_config("""
+TMPDIR = \"${TOPDIR}/tmp-sstatesamehash\"
+TCLIBCAPPEND = \"\"
+MACHINE = \"qemux86\"
+require conf/multilib.conf
+MULTILIBS = "multilib:lib32"
+DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
+BB_SIGNATURE_HANDLER = "OEBasicHash"
+""")
+self.track_for_cleanup(self.topdir + "/tmp-sstatesamehash")
+bitbake("binutils-native  -S none")
+self.write_config("""
+TMPDIR = \"${TOPDIR}/tmp-sstatesamehash2\"
+TCLIBCAPPEND = \"\"
+MACHINE = \"qemux86copy\"
+BB_SIGNATURE_HANDLER = "OEBasicHash"
+""")
+self.track_for_cleanup(self.topdir + "/tmp-sstatesamehash2")
+bitbake("binutils-native -S none")
+
+def get_files(d):
+f = []
+for root, dirs, files in os.walk(d):
+for name in files:
+f.append(os.path.join(root, name))
+return f
+files1 = get_files(self.topdir + "/tmp-sstatesamehash/stamps")
+files2 = get_files(self.topdir + "/tmp-sstatesamehash2/stamps")
+files2 = [x.replace("tmp-sstatesamehash2", "tmp-sstatesamehash") for x 
in files2]
+self.maxDiff = None
+self.assertCountEqual(files1, files2)
+
+
  def test_sstate_noop_samesigs(self):
  """
  The sstate checksums of two builds with these variables changed or



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

Re: [OE-core] [zeus][PATCH 1/2] python3: fix CVE-2019-16935

[ChenQi]

On 10/23/2019 06:59 PM, Ross Burton wrote:

Zeus and master I presume?

Ross

Yes. These two are for zeus. I will send out another two for master to 
avoid conflicts.


Best Regards,

Chen Qi

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

Re: [OE-core] [PATCH] sqlite3: fix CVE-2019-16168

[ChenQi]

On 10/15/2019 06:50 PM, Ross Burton wrote:
There's a queued upgrade to 3.30 for master, is this fixed in that 
release?


Ross


No such problem in 3.30.
I've sent out a new patch tagged with '[zeus]'.

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

Re: [OE-core] [PATCH V2 1/2] python3: CVE-2019-16056

[ChenQi]

Please help cherry pick these two CVE fixes into zeus branch if convenient.

Best Regards,
Chen Qi

On 10/09/2019 04:36 PM, Chen Qi wrote:

Signed-off-by: Chen Qi 
---
  ...nt-parse-domains-containing-GH-13079.patch | 132 ++
  meta/recipes-devtools/python/python3_3.7.4.bb |   5 +-
  2 files changed, 135 insertions(+), 2 deletions(-)
  create mode 100644 
meta/recipes-devtools/python/python3/0001-bpo-34155-Dont-parse-domains-containing-GH-13079.patch

diff --git 
a/meta/recipes-devtools/python/python3/0001-bpo-34155-Dont-parse-domains-containing-GH-13079.patch
 
b/meta/recipes-devtools/python/python3/0001-bpo-34155-Dont-parse-domains-containing-GH-13079.patch
new file mode 100644
index 00..319e7ed07e
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python3/0001-bpo-34155-Dont-parse-domains-containing-GH-13079.patch
@@ -0,0 +1,132 @@
+From 90d56127ae15b1e452755e62c77dc475dedf7161 Mon Sep 17 00:00:00 2001
+From: jpic 
+Date: Wed, 17 Jul 2019 23:54:25 +0200
+Subject: [PATCH] bpo-34155: Dont parse domains containing @ (GH-13079)
+
+Before:
+
+>>> email.message_from_string('From: 
a...@malicious.org@important.com', policy=email.policy.default)['from'].addresses
+(Address(display_name='', username='a', domain='malicious.org'),)
+
+>>> parseaddr('a...@malicious.org@important.com')
+('', 'a...@malicious.org')
+
+After:
+
+>>> email.message_from_string('From: 
a...@malicious.org@important.com', policy=email.policy.default)['from'].addresses
+(Address(display_name='', username='', domain=''),)
+
+>>> parseaddr('a...@malicious.org@important.com')
+('', 'a@')
+
+https://bugs.python.org/issue34155
+
+Upstream-Status: Backport 
[https://github.com/python/cpython/commit/8cb65d1381b027f0b09ee36bfed7f35bb4dec9a9]
+
+CVE: CVE-2019-16056
+
+Signed-off-by: Chen Qi 
+---
+ Lib/email/_header_value_parser.py  |  2 ++
+ Lib/email/_parseaddr.py| 11 ++-
+ Lib/test/test_email/test__header_value_parser.py   | 10 ++
+ Lib/test/test_email/test_email.py  | 14 ++
+ .../2019-05-04-13-33-37.bpo-34155.MJll68.rst   |  1 +
+ 5 files changed, 37 insertions(+), 1 deletion(-)
+ create mode 100644 
Misc/NEWS.d/next/Security/2019-05-04-13-33-37.bpo-34155.MJll68.rst
+
+diff --git a/Lib/email/_header_value_parser.py 
b/Lib/email/_header_value_parser.py
+index fc00b4a098..bbc026ec71 100644
+--- a/Lib/email/_header_value_parser.py
 b/Lib/email/_header_value_parser.py
+@@ -1582,6 +1582,8 @@ def get_domain(value):
+ token, value = get_dot_atom(value)
+ except errors.HeaderParseError:
+ token, value = get_atom(value)
++if value and value[0] == '@':
++raise errors.HeaderParseError('Invalid Domain')
+ if leader is not None:
+ token[:0] = [leader]
+ domain.append(token)
+diff --git a/Lib/email/_parseaddr.py b/Lib/email/_parseaddr.py
+index cdfa3729ad..41ff6f8c00 100644
+--- a/Lib/email/_parseaddr.py
 b/Lib/email/_parseaddr.py
+@@ -379,7 +379,12 @@ class AddrlistClass:
+ aslist.append('@')
+ self.pos += 1
+ self.gotonext()
+-return EMPTYSTRING.join(aslist) + self.getdomain()
++domain = self.getdomain()
++if not domain:
++# Invalid domain, return an empty address instead of returning a
++# local part to denote failed parsing.
++return EMPTYSTRING
++return EMPTYSTRING.join(aslist) + domain
+
+ def getdomain(self):
+ """Get the complete domain name from an address."""
+@@ -394,6 +399,10 @@ class AddrlistClass:
+ elif self.field[self.pos] == '.':
+ self.pos += 1
+ sdlist.append('.')
++elif self.field[self.pos] == '@':
++# bpo-34155: Don't parse domains with two `@` like
++# `a...@malicious.org@important.com`.
++return EMPTYSTRING
+ elif self.field[self.pos] in self.atomends:
+ break
+ else:
+diff --git a/Lib/test/test_email/test__header_value_parser.py 
b/Lib/test/test_email/test__header_value_parser.py
+index 693487bc96..7dc4de1b7b 100644
+--- a/Lib/test/test_email/test__header_value_parser.py
 b/Lib/test/test_email/test__header_value_parser.py
+@@ -1438,6 +1438,16 @@ class TestParser(TestParserMixin, TestEmailBase):
+ self.assertEqual(addr_spec.domain, 'example.com')
+ self.assertEqual(addr_spec.addr_spec, 'star.a.s...@example.com')
+
++def test_get_addr_spec_multiple_domains(self):
++with self.assertRaises(errors.HeaderParseError):
++parser.get_addr_spec('s...@a.star@example.com')
++
++with self.assertRaises(errors.HeaderParseError):
++parser.get_addr_spec('star@a...@example.com')
++
++with self.assertRaises(errors.HeaderParseError):
++parser.get_addr_spec('star@172.17@example.com')
++
+ #

Re: [OE-core] Yocto Project Status WW39’19

[ChenQi]

On 09/24/2019 10:50 PM, Stephen K Jolley wrote:


Current Dev Position: YP 2.8 M4 Feature Freeze

Next Deadline: YP 3.0 Final Release 25th Oct


SWAT Team Rotation:

 *

SWAT lead is currently: Amanda

 *

SWAT team rotation: Amanda -> Chen on Sept. 27, 2019

 *

SWAT team rotation: Chen -> Armin on Oct. 4, 2019

 *

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team




Hi Armin and Anju,

I want to switch the rotation with you two.
Because Oct. 1st is our National Day. We'll have a one-week holiday to 
celebrate it.


I've updated 
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team#Members 
for now.

If you have any concern, please let me know.
Thanks in advance.

Best Regards,
Chen Qi




Next Team Meetings:

 *

Bug Triage meeting Thursday Sept 26th at 7:30am PDT
(https://zoom.us/j/454367603)

 *

Monthly Project Meeting Tuesday Oct. 1st at 8am PDT
(https://zoom.us/j/990892712) 

 *

Weekly Engineering Sync Tuesday Sept. 24th at 8am PDT
(https://zoom.us/j/990892712) 

 *

Twitch - Next event is Tuesday Octt. 8th at 8am PDT
(https://www.twitch.tv/yocto_project)


Key Status/Updates:

 *

We’re now in feature freeze for 3.0 and working on bug fixing for
final release

 *

We have built M3 and this is due from QA on Thursday

 *

The main unresolved issue for 3.0 is with the hash equivalence
server causing problems with the eSDK and this issue is being
investigated but can’t be reproduced as yet.

 *

We also want to find a better solution to the systemd timeout
problem before final release.

 *

A significant performance problem has been found on the
autobuilder where some builds are scaling in time badly as the
sstate cache grows, taking 12 hours or more in some cases.
Unfortunately nobody seems motivated to help work on this kind of
issue.

 *

The plan for M4 is to resolve the above issues and any issues
raised from M3 QA, then proceed with the main release rc builds.
The first M4 build is scheduled for next week.

 *

If anyone has any status items for the project they’d like to add
to the weekly reports, please email Richard+Stephen.


Planned Releases for YP 3.0 {2.8}:

 *

M3 Release 6th Sept

 *

M4 Cutoff 30th Sept - this will be YP 3.0.

 *

YP 3.0 {2.8 (M4)} Final Release 25th Oct


Planned upcoming dot releases:

 *

YP 2.7.2 (Warrior) is planned for after YP 3.0 release.

 *

YP 2.6.4 (Thud) is planned for after YP 2.7.2  release.


Tracking Metrics:

 *

WDD 2505 (last week
2449)(https://wiki.yoctoproject.org/charts/combo.html)

 *

Poky Patch Metrics

 o

Total patches found: 1427 (last week 1424)

 o

Patches in the Pending State: 587 (41%) [last week 587 (41%)]


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.8_Features


The Yocto Project’s technical governance is through its Technical 
Steering Committee, more information is available at:


https://wiki.yoctoproject.org/wiki/TSC


The Status reports are now stored on the wiki at: 
https://wiki.yoctoproject.org/wiki/Weekly_Status



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



--

Thanks,

*/Stephen K. Jolley/*

*Yocto Project Program Manager*

*7867 SW Bayberry Dr., Beaverton, OR 97007*

(*Cell*: (208) 244-4460

* *Email*:_stephen.k.jol...@intel.com _





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

Re: [OE-core] [PATCH v3] systemd: upgrade to 243

[ChenQi]

Hi Scott,

This upgrade introduces a regression on NFS.
You boot with NFS, you don't get login from serial console. This is 
because units wanted by multi-user.target are not started, including 
getty.target.


To reproduce:
1. bitbake core-image-minimal
2. bitbake meta-ide-support
3. runqemu-extract-sdk path/to/image.tar.bz2 nfsroot
4. runqemu nfsroot serial nographic

I've also filed a bug for systemd upstream: 
https://github.com/systemd/systemd/issues/13628


Best Regards,
Chen Qi

On 09/14/2019 07:26 AM, Scott Murray wrote:

PATCH REBASED:
==
0001-binfmt-Don-t-install-dependency-links-at-install-tim.patch
0001-do-not-disable-buffer-in-writing-files.patch
0002-use-lnr-wrapper-instead-of-looking-for-relative-opti.patch
0004-add-fallback-parse_printf_format-implementation.patch
0004-rules-whitelist-hd-devices.patch
0005-rules-watch-metadata-changes-in-ide-devices.patch
0005-src-basic-missing.h-check-for-missing-strndupa.patch
0006-Include-netinet-if_ether.h.patch
0007-don-t-fail-if-GLOB_BRACE-and-GLOB_ALTDIRFUNC-is-not.patch
0017-Do-not-disable-buffering-when-writing-to-oom_score_a.patch

PATCH DROPPED:
==
0001-Replace-the-legacy-ULONG_LONG_MAX-with-the-C99-ULLON.patch
0001-src-udev-udev-event.c-must-include-sys-wait.h.patch
0023-socket-util.h-include-string.h.patch
0025-fs-utilh-add-missing-sys-stat-include.patch

PATCH ADDED:

0002-src-login-brightness.c-include-sys-wait.h.patch
0003-src-basic-copy.c-include-signal.h.patch
0004-src-shared-cpu-set-util.h-add-__cpu_mask-definition.patch

Also applied libc-glibc over-ride to pkg_postinst and pkg_prerm function
definitions, as musl does not provide nsswitch.conf.

Signed-off-by: Scott Murray 
---
  ...ystemd-boot_242.bb => systemd-boot_243.bb} |   0
  ...ystemd-conf_242.bb => systemd-conf_243.bb} |   0
  meta/recipes-core/systemd/systemd.inc |   4 +-
  ...cy-ULONG_LONG_MAX-with-the-C99-ULLON.patch |  50 -
  ...tall-dependency-links-at-install-tim.patch |  17 +-
  ...-not-disable-buffer-in-writing-files.patch | 148 ++---
  ...udev-event.c-must-include-sys-wait.h.patch |  35 
  ...ogin-brightness.c-include-sys-wait.h.patch |  25 +++
  ...instead-of-looking-for-relative-opti.patch |  23 +--
  ...03-src-basic-copy.c-include-signal.h.patch |  27 +++
  ...k-parse_printf_format-implementation.patch |  15 +-
  .../0004-rules-whitelist-hd-devices.patch |  11 +-
  ...set-util.h-add-__cpu_mask-definition.patch |  54 +
  ...atch-metadata-changes-in-ide-devices.patch |  16 +-
  ...missing.h-check-for-missing-strndupa.patch | 139 ++---
  .../0006-Include-netinet-if_ether.h.patch | 195 +++---
  ...LOB_BRACE-and-GLOB_ALTDIRFUNC-is-not.patch |  26 ++-
  ...uffering-when-writing-to-oom_score_a.patch |  12 +-
  .../0023-socket-util.h-include-string.h.patch |  30 ---
  ...s-utilh-add-missing-sys-stat-include.patch |  30 ---
  .../{systemd_242.bb => systemd_243.bb}|  11 +-
  21 files changed, 507 insertions(+), 361 deletions(-)
  rename meta/recipes-core/systemd/{systemd-boot_242.bb => systemd-boot_243.bb} 
(100%)
  rename meta/recipes-core/systemd/{systemd-conf_242.bb => systemd-conf_243.bb} 
(100%)
  delete mode 100644 
meta/recipes-core/systemd/systemd/0001-Replace-the-legacy-ULONG_LONG_MAX-with-the-C99-ULLON.patch
  delete mode 100644 
meta/recipes-core/systemd/systemd/0001-src-udev-udev-event.c-must-include-sys-wait.h.patch
  create mode 100644 
meta/recipes-core/systemd/systemd/0002-src-login-brightness.c-include-sys-wait.h.patch
  create mode 100644 
meta/recipes-core/systemd/systemd/0003-src-basic-copy.c-include-signal.h.patch
  create mode 100644 
meta/recipes-core/systemd/systemd/0004-src-shared-cpu-set-util.h-add-__cpu_mask-definition.patch
  delete mode 100644 
meta/recipes-core/systemd/systemd/0023-socket-util.h-include-string.h.patch
  delete mode 100644 
meta/recipes-core/systemd/systemd/0025-fs-utilh-add-missing-sys-stat-include.patch
  rename meta/recipes-core/systemd/{systemd_242.bb => systemd_243.bb} (98%)

diff --git a/meta/recipes-core/systemd/systemd-boot_242.bb 
b/meta/recipes-core/systemd/systemd-boot_243.bb
similarity index 100%
rename from meta/recipes-core/systemd/systemd-boot_242.bb
rename to meta/recipes-core/systemd/systemd-boot_243.bb
diff --git a/meta/recipes-core/systemd/systemd-conf_242.bb 
b/meta/recipes-core/systemd/systemd-conf_243.bb
similarity index 100%
rename from meta/recipes-core/systemd/systemd-conf_242.bb
rename to meta/recipes-core/systemd/systemd-conf_243.bb
diff --git a/meta/recipes-core/systemd/systemd.inc 
b/meta/recipes-core/systemd/systemd.inc
index 1912715617..7f3a59c208 100644
--- a/meta/recipes-core/systemd/systemd.inc
+++ b/meta/recipes-core/systemd/systemd.inc
@@ -14,8 +14,8 @@ LICENSE = "GPLv2 & LGPLv2.1"
  LIC_FILES_CHKSUM = "file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe \
  
file://LICENSE.LGPL2.1;md5=4fbd65380cdd255951079008b364516c"
  
-SRCREV = "f875dced33462641e1fb7875d2f9a8cd8e8c2fcc

Re: [OE-core] [PATCH] bind: fix build with python3 PACKAGECONFIG enabled

[ChenQi]

ping

On 08/23/2019 04:56 PM, Chen Qi wrote:

If the PACKAGECONFIG item, python3, is enabled, we get the following
QA issue when multilib is enabled.

   ERROR: bind-9.11.5-P4-r0 do_package: QA Issue: bind: Files/directories were 
installed but not shipped in any package:
   /usr/lib
   /usr/lib/python3.7
   /usr/lib/python3.7/site-packages
   /usr/lib/python3.7/site-packages/isc-2.0-py3.7.egg-info
   /usr/lib/python3.7/site-packages/isc
   /usr/lib/python3.7/site-packages/isc/policy.py
   [snip]

The thing is, when --with-python is specified with a path instead of 'yes',
the --with-python-install-dir is in fact ignored.

Fix this issue by specifying the correct arguments.

Signed-off-by: Chen Qi 
---
  meta/recipes-connectivity/bind/bind_9.11.5-P4.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/bind/bind_9.11.5-P4.bb 
b/meta/recipes-connectivity/bind/bind_9.11.5-P4.bb
index 93c406f778..69b1174073 100644
--- a/meta/recipes-connectivity/bind/bind_9.11.5-P4.bb
+++ b/meta/recipes-connectivity/bind/bind_9.11.5-P4.bb
@@ -39,7 +39,7 @@ PACKAGECONFIG[httpstats] = 
"--with-libxml2=${STAGING_DIR_HOST}${prefix},--withou
  PACKAGECONFIG[readline] = "--with-readline=-lreadline,,readline"
  PACKAGECONFIG[libedit] = "--with-readline=-ledit,,libedit"
  PACKAGECONFIG[urandom] = 
"--with-randomdev=/dev/urandom,--with-randomdev=/dev/random,,"
-PACKAGECONFIG[python3] = "--with-python=${PYTHON} 
--with-python-install-dir=${D}/${PYTHON_SITEPACKAGES_DIR} , --without-python, 
python3-ply-native,"
+PACKAGECONFIG[python3] = "--with-python=yes 
--with-python-install-dir=${PYTHON_SITEPACKAGES_DIR} , --without-python, 
python3-ply-native,"
  
  ENABLE_IPV6 = "--enable-ipv6=${@bb.utils.contains('DISTRO_FEATURES', 'ipv6', 'yes', 'no', d)}"

  EXTRA_OECONF = " ${ENABLE_IPV6} --with-libtool --enable-threads \



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

Re: [OE-core] [PATCH] core-image-sato-sdk: test image with 512M memory

[ChenQi]

On 08/16/2019 02:53 PM, Kang Kai wrote:

On 2019/8/12 下午4:57, Kang Kai wrote:

On 2019/7/27 下午4:42, Kang Kai wrote:

On 2019/7/27 上午5:40, richard.pur...@linuxfoundation.org wrote:

On Fri, 2019-07-26 at 05:23 -0400, kai.k...@windriver.com wrote:

From: Kai Kang 

When run do_testimage for core-image-sato-sdk, it fails to pass test
case:


RESULTS - systemd.SystemdBasicTests.test_systemd_failed: FAILED
(0.43s)

It is OOM issue and daemon rpc.statd is killed:


  [  531.306146] Out of memory: Kill process 193 (rpc.statd) score
200 or sacrifice child

Increase the memory of qemu to 512M to avoid such OOM issue.

Signed-off-by: Kai Kang 
---
  meta/recipes-sato/images/core-image-sato-sdk.bb | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/recipes-sato/images/core-image-sato-sdk.bb
b/meta/recipes-sato/images/core-image-sato-sdk.bb
index d7cc52b52b..f7963d018e 100644
--- a/meta/recipes-sato/images/core-image-sato-sdk.bb
+++ b/meta/recipes-sato/images/core-image-sato-sdk.bb
@@ -9,3 +9,4 @@ IMAGE_FEATURES += "dev-pkgs tools-sdk \
IMAGE_INSTALL += "kernel-devsrc"
  +TEST_QEMUPARAMS = "-m 512"

Any idea what is using so much memory in the image when this happens?

Its rather sad that we can't have NFS+systemd with 256MB memory...


It caused by stap test case. I minimized the test cases to

TEST_SUITES = "ping date ssh systemd stap kernelmodule gcc "

which could reproduce the error.

And it PASSes testimage that remove stap test from default TEST_SUITES:

TEST_SUITES_remove = 'stap'

But I can't reproduce the OOM failure to run stap tests manually.


Hi Richard,

The root cause of test case stap fails is available memory is too 
low. Compare systemd with sysvinit, memory status are listed:


systemd:
root@qemux86:~# free -h
  totalusedfree  shared buff/cache   
available

Mem:  239Mi   120Mi23Mi   8.0Mi 94Mi 100Mi
Swap:0B  0B  0B

sysvinit:
root@qemux86:~# free -h
  totalusedfree  shared buff/cache   
available

Mem:  239Mi45Mi   111Mi   0.0Ki 82Mi 184Mi
Swap:0B  0B  0B


With systemd, processes of rpc.statd and rpc.mountd take about less 
than 80M memories.

And I compared with Debian 10, they take similar size of memories.

PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND
464 rpcuser   20   0   56316  51336   2192 S   0.0  20.9 0:00.09 
rpc.statd
  186 root  20   0   30136  27024   2280 S   0.0  11.0 0:00.02 
rpc.mountd



Compare to sysvinit, they take only about 2M and 448K:

 PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND
  567 rpcuser   20   03444   2372   1792 S   0.0   1.0 0:00.00 
rpc.statd
  677 root  20   03700448  0 S   0.0   0.2 0:00.00 
rpc.mountd



I didn't figure out the differences between these 2 ways to start the 
commands:


ExecStart=/usr/sbin/rpc.statd -F $STATD_OPTS

Vs.

test -x "$NFS_STATD" || NFS_STATD=/usr/sbin/rpc.statd
start-stop-daemon --start --exec "$NFS_STATD" --pidfile "$STATD_PID"


Hi Richard,

Any more comment here please?

Regards,
Kai




Hi Richard,

Do you think it's acceptable to use swap as part of this test case? For 
example, enable 100M swap before running `stap' and disable it 
afterwards? This ensure no oom caused by other software using too much 
memory.


Best Regards,
Chen Qi






Regards,
Kai







Regards,
Kai



Cheers,

Richard










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

Re: [OE-core] [PATCHv3] mdadm:fix mdmonitor.service

[ChenQi]

On 07/31/2019 09:50 AM, Zang Ruochen wrote:

-The original file mdmonitor.service is as follows:
...
|[Service]
|Environment=  MDADM_MONITOR_ARGS=--scan
|EnvironmentFile=-/run/sysconfig/mdadm
|ExecStartPre=-/usr/lib/mdadm/mdadm_env.sh
|ExecStart=/sbin/mdadm --monitor -y $MDADM_MONITOR_ARGS
...
-It has a syntax error and it doesn't work properly,


What is the actual syntax error? Why does it not work properly?


  so add files/0001-Fix-file-mdmonitor.service-syntax-error.patch to fix it.

Signed-off-by: Zang Ruochen 
---
  ...-file-mdmonitor.service-syntax-error.patch | 49 +++
  meta/recipes-extended/mdadm/mdadm_4.1.bb  |  1 +
  2 files changed, 50 insertions(+)
  create mode 100644 
meta/recipes-extended/mdadm/files/0001-Fix-file-mdmonitor.service-syntax-error.patch

diff --git 
a/meta/recipes-extended/mdadm/files/0001-Fix-file-mdmonitor.service-syntax-error.patch
 
b/meta/recipes-extended/mdadm/files/0001-Fix-file-mdmonitor.service-syntax-error.patch
new file mode 100644
index 00..a36fed6f9f
--- /dev/null
+++ 
b/meta/recipes-extended/mdadm/files/0001-Fix-file-mdmonitor.service-syntax-error.patch
@@ -0,0 +1,49 @@
+From a4a37cc9d91d7129910360914b8b2060139c0307 Mon Sep 17 00:00:00 2001
+From: Zang Ruochen 
+Date: Tue, 30 Jul 2019 12:44:25 +0800
+Subject: [PATCH] Fix file mdmonitor.service syntax error
+
+-The original file mdmonitor.service is as follows:
+...
+|[Service]
+|Environment=  MDADM_MONITOR_ARGS=--scan
+|EnvironmentFile=-/run/sysconfig/mdadm
+|ExecStartPre=-/usr/lib/mdadm/mdadm_env.sh
+|ExecStart=/sbin/mdadm --monitor -y $MDADM_MONITOR_ARGS
+...
+-It has a syntax error and it doesn't work properly,
+ so add new file mdmonitor.service to overwrite it.
+
+Signed-off-by: Zang Ruochen 
+---
+ systemd/mdmonitor.service | 15 +--
+ 1 file changed, 9 insertions(+), 6 deletions(-)
+
+diff --git a/systemd/mdmonitor.service b/systemd/mdmonitor.service
+index 3fc4687..bd243b4 100644
+--- a/systemd/mdmonitor.service
 b/systemd/mdmonitor.service
+@@ -6,11 +6,14 @@
+ #  (at your option) any later version.
+
+ [Unit]
+-Description=MD array monitor
+-DefaultDependencies=no
++Description=Software RAID monitoring and management
++ConditionPathExists=/etc/mdadm.conf


Why do above changes? Also, isn't /etc/mdadm.conf always there?


+
+ [Service]
+-Environment=  MDADM_MONITOR_ARGS=--scan
+-EnvironmentFile=-/run/sysconfig/mdadm
+-ExecStartPre=-/usr/lib/mdadm/mdadm_env.sh
+-ExecStart=BINDIR/mdadm --monitor -y $MDADM_MONITOR_ARGS
++Type=forking
++PIDFile=/var/run/mdadm/mdadm.pid


Type=forking is not encouraged. Is there any reason we want to use it?
Also, PIDFile is recommended to locate under /run instead of /var/run. 
systemd actually automatically modifies the configuration to change 
/var/run to /run.


Regards,
Chen Qi


++EnvironmentFile=-/etc/sysconfig/mdmonitor
++ExecStart=/sbin/mdadm --monitor --scan -y -f 
--pid-file=/var/run/mdadm/mdadm.pid
++
++[Install]
++WantedBy=multi-user.target
+--
+2.20.1
+
diff --git a/meta/recipes-extended/mdadm/mdadm_4.1.bb 
b/meta/recipes-extended/mdadm/mdadm_4.1.bb
index 74c94f6ecb..c3e15adc71 100644
--- a/meta/recipes-extended/mdadm/mdadm_4.1.bb
+++ b/meta/recipes-extended/mdadm/mdadm_4.1.bb
@@ -22,6 +22,7 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.xz \
   file://mdadm.init \
   
file://0001-mdadm-add-option-y-for-use-syslog-to-recive-event-re.patch \
 file://include_sysmacros.patch \
+   file://0001-Fix-file-mdmonitor.service-syntax-error.patch \
 "
  SRC_URI[md5sum] = "51bf3651bd73a06c413a2f964f299598"
  SRC_URI[sha256sum] = 
"ab7688842908d3583a704d491956f31324c3a5fc9f6a04653cb75d19f1934f4a"



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

Re: [OE-core] [PATCH] container-image-busybox: add a reference container image

[ChenQi]

On 07/24/2019 08:27 PM, Bruce Ashfield wrote:

On Wed, Jul 24, 2019 at 6:00 AM ChenQi  wrote:

On 07/24/2019 05:38 PM, Burton, Ross wrote:

Are you aware of container-test-image.bb?  Curious what the point of this is.

Ross

Yes. It exists in meta-selftest, having an empty /usr/bin/theapp, for
the purpose of selftest.

I think we could have some reference image for container. So I added
this small reference image, from which users could create container and
use shell.


And you do realize that such references already exist in several other
layers ? So it would be best to do a study of those options, talk to the
interested folks and then we can propose something to oe-core.


I expect it to be like busybox:glibc or busybox:musl in Docker Hub, with
the major difference that we use symlinks to /bin/busybox.nosuid and
/bin/busybox.suid while official ones use separate binaries.

Have a look at the ELCe presentations from 2018, this has been covered
in great detail at those events.

We can't just drop an image into core without documentation, examples,
test cases, etc. That's what I'm talking about as points of collaboration.

Cheers,

Bruce


Hi Bruce,

Thanks for your info and advice.
I'll do more investigation.

Regards,
Chen Qi


Regards,
Chen Qi


On Wed, 24 Jul 2019 at 03:39, Chen Qi  wrote:

Add a small busybox based container image.

Signed-off-by: Chen Qi 
---
   meta/recipes-core/images/container-image-busybox.bb | 8 
   1 file changed, 8 insertions(+)
   create mode 100644 meta/recipes-core/images/container-image-busybox.bb

diff --git a/meta/recipes-core/images/container-image-busybox.bb 
b/meta/recipes-core/images/container-image-busybox.bb
new file mode 100644
index 00..a4d63b0eea
--- /dev/null
+++ b/meta/recipes-core/images/container-image-busybox.bb
@@ -0,0 +1,8 @@
+SUMMARY = "A small busybox based container image."
+LICENSE = "MIT"
+
+IMAGE_INSTALL = "busybox"
+IMAGE_LINGUAS = ""
+IMAGE_FSTYPES = "container"
+
+inherit core-image
--
2.17.1

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





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

Re: [OE-core] [PATCH] container-image-busybox: add a reference container image

[ChenQi]

On 07/24/2019 05:38 PM, Burton, Ross wrote:

Are you aware of container-test-image.bb?  Curious what the point of this is.

Ross


Yes. It exists in meta-selftest, having an empty /usr/bin/theapp, for 
the purpose of selftest.


I think we could have some reference image for container. So I added 
this small reference image, from which users could create container and 
use shell.


I expect it to be like busybox:glibc or busybox:musl in Docker Hub, with 
the major difference that we use symlinks to /bin/busybox.nosuid and 
/bin/busybox.suid while official ones use separate binaries.


Regards,
Chen Qi


On Wed, 24 Jul 2019 at 03:39, Chen Qi  wrote:

Add a small busybox based container image.

Signed-off-by: Chen Qi 
---
  meta/recipes-core/images/container-image-busybox.bb | 8 
  1 file changed, 8 insertions(+)
  create mode 100644 meta/recipes-core/images/container-image-busybox.bb

diff --git a/meta/recipes-core/images/container-image-busybox.bb 
b/meta/recipes-core/images/container-image-busybox.bb
new file mode 100644
index 00..a4d63b0eea
--- /dev/null
+++ b/meta/recipes-core/images/container-image-busybox.bb
@@ -0,0 +1,8 @@
+SUMMARY = "A small busybox based container image."
+LICENSE = "MIT"
+
+IMAGE_INSTALL = "busybox"
+IMAGE_LINGUAS = ""
+IMAGE_FSTYPES = "container"
+
+inherit core-image
--
2.17.1

--
___
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] [PATCH 1/1] msmtp: fix postinstall to avoid do_rootfs failure

[ChenQi]

On 07/15/2019 02:44 PM, Adrian Bunk wrote:

On Mon, Jul 15, 2019 at 02:40:28PM +0800, ChenQi wrote:

On 07/15/2019 02:17 PM, Adrian Bunk wrote:

On Mon, Jul 15, 2019 at 01:35:15PM +0800, Chen Qi wrote:

When lsb is enabled, that is, 'linuxstdbase' is in OVERRIDES,
do_rootfs would fail if both 'msmtp' and 'postfix' are installed.
This is because they both try to create /usr/lib/sendmail link if
it does not exist. So we need to fix the check to avoid non-zero
exit status.
...

This would make it random (depending on installation order) which is
linked to, and it could also make ${sbindir}/sendmail and
$D/usr/lib/sendmail point to different programs.

It would be better to make $D/usr/lib/sendmail also an alternative in
all packages that provide sendmail.

cu
Adrian


I don't think we should mix linuxstdbase and ALTERNATIVES setting. It makes
things complicated.
As ALTERNATIVES_PRIORITY is higher in postfix, I'll just remove the check in
postfix and use 'ln -sf' directly.
Can you accept this solution?

I do not see how this solves your problem if msmtp gets installed
after postfix.

Is it actually required to have these packages installed at the same
time in LSB?

If not, something like
   RCONFLICTS_linuxstdbase = "postfix"
might work. (untested)


Regards,
Chen Qi

cu
Adrian


Hi Adrian,

I've sent out V2 using alternatives.

Best Regards,

Chen Qi

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

Re: [OE-core] [PATCH 1/1] msmtp: fix postinstall to avoid do_rootfs failure

[ChenQi]

On 07/15/2019 02:17 PM, Adrian Bunk wrote:

On Mon, Jul 15, 2019 at 01:35:15PM +0800, Chen Qi wrote:

When lsb is enabled, that is, 'linuxstdbase' is in OVERRIDES,
do_rootfs would fail if both 'msmtp' and 'postfix' are installed.
This is because they both try to create /usr/lib/sendmail link if
it does not exist. So we need to fix the check to avoid non-zero
exit status.
...

This would make it random (depending on installation order) which is
linked to, and it could also make ${sbindir}/sendmail and
$D/usr/lib/sendmail point to different programs.

It would be better to make $D/usr/lib/sendmail also an alternative in
all packages that provide sendmail.

cu
Adrian

I don't think we should mix linuxstdbase and ALTERNATIVES setting. It 
makes things complicated.
As ALTERNATIVES_PRIORITY is higher in postfix, I'll just remove the 
check in postfix and use 'ln -sf' directly.

Can you accept this solution?

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

Re: [OE-core] sysstat no longer builds (was: [PATCH 0/1] sysstat: use service file from source codes)

[ChenQi]

On 07/12/2019 07:56 PM, Burton, Ross wrote:

On Fri, 12 Jul 2019 at 12:21, Peter Kjellerstedt
 wrote:


   ERROR: sysstat-12.1.3-r0 do_package: SYSTEMD_SERVICE_sysstat value 
sysstat.service does not exist
   ERROR: sysstat-12.1.3-r0 do_package:
   ERROR: sysstat-12.1.3-r0 do_package: Function failed: 
systemd_populate_packages

This is due to that the upstream package only installs the sysstat.service
file if cron support is enabled, which it isn't by default.

There was another patch by Haiqing Bai sent on July 2 that seemed to handle
this properly.

So the basic problem is that we don't do enough testing with systemd
enabled on the AB.

Thanks, I'll queue up a revert and pick of the other patch.

Ross

I thought I did the test but I actually did not due to PACKAGECONFIG 
setting in local.conf. Sorry about this.

Thanks to Ross for quickly resolving this regression.

Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V2] llvm: fix link error for powerpc

[ChenQi]

I'm recently getting llvm build failure on qemuppc. After reverting this 
patch, the build succeeds.

My host is ubuntu16.04.

I'm also wondering why autobuilder does not detect the build failure. No 
world build for qemuppc?


Best Regards,
Chen Qi

On 04/02/2019 08:43 AM, changqing...@windriver.com wrote:

From: Changqing Li 

fix below link error for powerpc

lib/libLLVMSupport.a(CommandLine.cpp.o): in function 
`llvm::cl::opt_storage<(anonymous namespace):
:HelpPrinterWrapper, true, true>::setLocation(llvm::cl::Option&, (anonymous 
namespace)::HelpPrinterWrapper&) [clone .isra.189]':
/usr/src/debug/llvm/8.0-r0/git/llvm/include/llvm/Support/CommandLine.h:1218:(.text.startup+0x5c):
relocation truncated to fit: R_PPC_PLTREL24 against symbol `llvm::errs()' 
defined in .text section in lib/libLLVMSupport.a(raw_ostream.cpp.o)+8000
lib/libLLVMSupport.a(CommandLine.cpp.o): in function `setLocation':

Signed-off-by: Changqing Li 
---
  meta/recipes-devtools/llvm/llvm_git.bb | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/llvm/llvm_git.bb 
b/meta/recipes-devtools/llvm/llvm_git.bb
index d2ea927..a35ea4a 100644
--- a/meta/recipes-devtools/llvm/llvm_git.bb
+++ b/meta/recipes-devtools/llvm/llvm_git.bb
@@ -88,6 +88,8 @@ EXTRA_OECMAKE_append_class-nativesdk = "\

-DLLVM_CONFIG_PATH=${STAGING_BINDIR_NATIVE}/llvm-config${PV} \
   "
  
+CXXFLAGS_append_class-target_powerpc = " -mlongcall"

+
  do_configure_prepend() {
  # Fix paths in llvm-config
sed -i 
"s|sys::path::parent_path(CurrentPath))\.str()|sys::path::parent_path(sys::path::parent_path(CurrentPath))).str()|g"
 ${S}/tools/llvm-config/llvm-config.cpp



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

Re: [OE-core] [PATCH 1/1] buildtools-tarball: add nativesdk-libxml2-utils

[ChenQi]

On 07/09/2019 06:18 PM, Richard Purdie wrote:

On Tue, 2019-07-09 at 17:36 +0800, ChenQi wrote:

On 07/09/2019 09:38 AM, ChenQi wrote:

On 07/09/2019 12:47 AM, Richard Purdie wrote:

On Mon, 2019-07-08 at 15:37 +0800, Chen Qi wrote:

For build-sysroots.bb, the xmlcatalog would not be in its
staging directory. Causing the following error for eSDK.

ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Command
'/PATH/TO/IMAGE/testsdkext/tmp/sysroots/x86_64/usr/bin/postinst
-
docbook-xml-dtd4-native-xmlcatalog' returned non-zero exit
status
127.
ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Function
failed: do_build_native_sysroot

The problem could be reproduced by the following steps.
1. Add in local.conf:
 IMAGE_INSTALL_append = " btrfs-tools"
 DISTRO_FEATURES_append = " api-documentation"
 INHERIT += "testsdk"
2. bitbake core-image-minimal -c populate_sdk_ext
3. bitbake core-image-minimal -c testsdkext

So we add nativesdk-libxml2-utils to buildtools-tarball
to ensure the existence of xmlcatalog. Also add it
to HOSTTOOLS_NONFATAL so it could be seen by bitbake.

Signed-off-by: Chen Qi 
---
   meta/conf/bitbake.conf   | 3 +++
   meta/recipes-core/meta/buildtools-tarball.bb | 1 +
   2 files changed, 4 insertions(+)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 5e93f5c..2f64eae 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -517,6 +517,9 @@ HOSTTOOLS_NONFATAL += "scp"
   # Link to git-lfs if present
   HOSTTOOLS_NONFATAL += "git-lfs"
   +# build-sysroot needs xmlcatalog in order for eSDK
installation
+HOSTTOOLS_NONFATAL += "xmlcatalog"

I don't mind the buildtools-tarball change but HOSTTOOLS is
starting to
grow to contain far too much random stuff which could impact
reproduciblity.

Is there some other way we could fix this? It still feels like a
dependency problem which we chould fix by adding a missing
dependency
although I appreciate its far from being that simple.

I wonder if there is a way we could teach build-sysroots to be
cleverer
about dependencies?

I'll try to implement it and send out a new patch.

Unfortunately I cannot figure out a good way to implement this.
Could you please help giving me some hints?

What happens if we add:

${@bb.utils.contains('DISTRO_FEATURES', 'api-documentation', 
'nativesdk-libxml2', '', d)} \

to
`
meta/recipes-core/packagegroups/nativesdk-packagegroup-sdk-host.bb

?


This does not work. Using nativesdk-libxml2-utils does not work too.
Both buildtools and eSDK do not use this packagegroup.

I've sent out a V2 of this patch, with change to put the 
'libxml2-native' dependency in xmlcatalog.bbclass.
In this way, we can ensure that the xmlcatalog is from our recipe. In 
normal build, it's from libxml2-native; in build-sysroots in eSDK, it's 
from nativesdk-libxml2-utils. Do you think this is acceptable?


Best Regards,
Chen Qi


Cheers,

Richard




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

Re: [OE-core] [PATCH 1/1] buildtools-tarball: add nativesdk-libxml2-utils

[ChenQi]

On 07/09/2019 09:38 AM, ChenQi wrote:

On 07/09/2019 12:47 AM, Richard Purdie wrote:

On Mon, 2019-07-08 at 15:37 +0800, Chen Qi wrote:

For build-sysroots.bb, the xmlcatalog would not be in its
staging directory. Causing the following error for eSDK.

ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Command
'/PATH/TO/IMAGE/testsdkext/tmp/sysroots/x86_64/usr/bin/postinst-
docbook-xml-dtd4-native-xmlcatalog' returned non-zero exit status
127.
ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Function
failed: do_build_native_sysroot

The problem could be reproduced by the following steps.
1. Add in local.conf:
IMAGE_INSTALL_append = " btrfs-tools"
DISTRO_FEATURES_append = " api-documentation"
INHERIT += "testsdk"
2. bitbake core-image-minimal -c populate_sdk_ext
3. bitbake core-image-minimal -c testsdkext

So we add nativesdk-libxml2-utils to buildtools-tarball
to ensure the existence of xmlcatalog. Also add it
to HOSTTOOLS_NONFATAL so it could be seen by bitbake.

Signed-off-by: Chen Qi 
---
  meta/conf/bitbake.conf   | 3 +++
  meta/recipes-core/meta/buildtools-tarball.bb | 1 +
  2 files changed, 4 insertions(+)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 5e93f5c..2f64eae 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -517,6 +517,9 @@ HOSTTOOLS_NONFATAL += "scp"
  # Link to git-lfs if present
  HOSTTOOLS_NONFATAL += "git-lfs"
  +# build-sysroot needs xmlcatalog in order for eSDK installation
+HOSTTOOLS_NONFATAL += "xmlcatalog"

I don't mind the buildtools-tarball change but HOSTTOOLS is starting to
grow to contain far too much random stuff which could impact
reproduciblity.

Is there some other way we could fix this? It still feels like a
dependency problem which we chould fix by adding a missing dependency
although I appreciate its far from being that simple.

I wonder if there is a way we could teach build-sysroots to be cleverer
about dependencies?


I'll try to implement it and send out a new patch.



Hi Richard and Ross,

Unfortunately I cannot figure out a good way to implement this.
Could you please help giving me some hints?

Best Regards,
Chen Qi


Regards,
Chen Qi


Cheers,

Richard






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

Re: [OE-core] [PATCH 1/1] buildtools-tarball: add nativesdk-libxml2-utils

[ChenQi]

On 07/09/2019 02:45 AM, Burton, Ross wrote:

Agreed, making it a non-fatal dependency just means that some eSDKs
break, not all.  There needs to be a better fix.


But it's already in buildtools, and eSDK installation process involves 
extracting buildtools and sourcing its script.

Under which circumstances will we break some eSDKs?
Anyway, I'm trying to do something about build-sysroots recipe and will 
send out a new patch.


Regards,
Chen Qi


Ross

On Mon, 8 Jul 2019 at 17:53, Richard Purdie
 wrote:

On Mon, 2019-07-08 at 15:37 +0800, Chen Qi wrote:

For build-sysroots.bb, the xmlcatalog would not be in its
staging directory. Causing the following error for eSDK.

ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Command
'/PATH/TO/IMAGE/testsdkext/tmp/sysroots/x86_64/usr/bin/postinst-
docbook-xml-dtd4-native-xmlcatalog' returned non-zero exit status
127.
ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Function
failed: do_build_native_sysroot

The problem could be reproduced by the following steps.
1. Add in local.conf:
IMAGE_INSTALL_append = " btrfs-tools"
DISTRO_FEATURES_append = " api-documentation"
INHERIT += "testsdk"
2. bitbake core-image-minimal -c populate_sdk_ext
3. bitbake core-image-minimal -c testsdkext

So we add nativesdk-libxml2-utils to buildtools-tarball
to ensure the existence of xmlcatalog. Also add it
to HOSTTOOLS_NONFATAL so it could be seen by bitbake.

Signed-off-by: Chen Qi 
---
  meta/conf/bitbake.conf   | 3 +++
  meta/recipes-core/meta/buildtools-tarball.bb | 1 +
  2 files changed, 4 insertions(+)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 5e93f5c..2f64eae 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -517,6 +517,9 @@ HOSTTOOLS_NONFATAL += "scp"
  # Link to git-lfs if present
  HOSTTOOLS_NONFATAL += "git-lfs"

+# build-sysroot needs xmlcatalog in order for eSDK installation
+HOSTTOOLS_NONFATAL += "xmlcatalog"

I don't mind the buildtools-tarball change but HOSTTOOLS is starting to
grow to contain far too much random stuff which could impact
reproduciblity.

Is there some other way we could fix this? It still feels like a
dependency problem which we chould fix by adding a missing dependency
although I appreciate its far from being that simple.

I wonder if there is a way we could teach build-sysroots to be cleverer
about dependencies?

Cheers,

Richard

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



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

Re: [OE-core] [PATCH 1/1] buildtools-tarball: add nativesdk-libxml2-utils

[ChenQi]

On 07/09/2019 12:47 AM, Richard Purdie wrote:

On Mon, 2019-07-08 at 15:37 +0800, Chen Qi wrote:

For build-sysroots.bb, the xmlcatalog would not be in its
staging directory. Causing the following error for eSDK.

ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Command
'/PATH/TO/IMAGE/testsdkext/tmp/sysroots/x86_64/usr/bin/postinst-
docbook-xml-dtd4-native-xmlcatalog' returned non-zero exit status
127.
ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Function
failed: do_build_native_sysroot

The problem could be reproduced by the following steps.
1. Add in local.conf:
IMAGE_INSTALL_append = " btrfs-tools"
DISTRO_FEATURES_append = " api-documentation"
INHERIT += "testsdk"
2. bitbake core-image-minimal -c populate_sdk_ext
3. bitbake core-image-minimal -c testsdkext

So we add nativesdk-libxml2-utils to buildtools-tarball
to ensure the existence of xmlcatalog. Also add it
to HOSTTOOLS_NONFATAL so it could be seen by bitbake.

Signed-off-by: Chen Qi 
---
  meta/conf/bitbake.conf   | 3 +++
  meta/recipes-core/meta/buildtools-tarball.bb | 1 +
  2 files changed, 4 insertions(+)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 5e93f5c..2f64eae 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -517,6 +517,9 @@ HOSTTOOLS_NONFATAL += "scp"
  # Link to git-lfs if present
  HOSTTOOLS_NONFATAL += "git-lfs"
  
+# build-sysroot needs xmlcatalog in order for eSDK installation

+HOSTTOOLS_NONFATAL += "xmlcatalog"

I don't mind the buildtools-tarball change but HOSTTOOLS is starting to
grow to contain far too much random stuff which could impact
reproduciblity.

Is there some other way we could fix this? It still feels like a
dependency problem which we chould fix by adding a missing dependency
although I appreciate its far from being that simple.

I wonder if there is a way we could teach build-sysroots to be cleverer
about dependencies?


I'll try to implement it and send out a new patch.

Regards,
Chen Qi


Cheers,

Richard




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

Re: [OE-core] [oe-core][PATCH 1/2] defaultsetup.conf: enable select init manager

[ChenQi]

On 07/06/2019 08:31 PM, richard.pur...@linuxfoundation.org wrote:

On Sat, 2019-07-06 at 12:53 +0300, Adrian Bunk wrote:

On Thu, Jul 04, 2019 at 09:45:19PM +0800, kai.k...@windriver.com
wrote:

From: Kai Kang 

Introduce a new variable INIT_MANAGER and create 3 init-manager-
*.inc
files to configure init manager settings. Available values of
INIT_MANAGER are sysvinit, systemd and mdev-busybox. 'sysvinit' is
set
by default for compatibility.
...
--- a/meta/conf/distro/defaultsetup.conf
+++ b/meta/conf/distro/defaultsetup.conf
@@ -23,3 +23,6 @@ PACKAGE_CLASSES ?= "package_ipk"
  INHERIT_BLACKLIST = "blacklist"
  INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
  INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
${INHERIT_BLACKLIST}"
+
+INIT_MANAGER ??= "sysvinit"
+require conf/distro/include/init-manager-${INIT_MANAGER}.inc
...
--- /dev/null
+++ b/meta/conf/distro/include/init-manager-sysvinit.inc
@@ -0,0 +1,6 @@
+# Use sysvinit for system initialization
+DISTRO_FEATURES_append = " sysvinit"
+DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " systemd"
+VIRTUAL-RUNTIME_init_manager = "sysvinit"
+VIRTUAL-RUNTIME_initscripts = "initscripts"
+VIRTUAL-RUNTIME_login_manager = "busybox"

I am not sure whether this can be fixed better, but this does break
existing configurations that use a non-default init system.

I just ran into a build issue with
   VIRTUAL-RUNTIME_init_manager = "systemd"
since this now resulted in both sysvinit and systemd being attempted
to
be installed to the image.

This was fixable in my configuration with
   -VIRTUAL-RUNTIME_init_manager = "systemd"
   +INIT_MANAGER = "systemd"

This at least needs to be properly documented as a breaking change.

This change also didn't quite work out for some of our selftests. I've
a patch in master-next which tried to improve things and that fixed the
selftests.

The only other way we could do this is to default INIT_MANAGER to say
"unset" and have an empty file for that. That will of course break my
patch and need the defaults adding back into the recipe. Unless we put
those defaults into the unset version.

Not sure quite what we should do here...

Cheers,

Richard


I'm also concerned about the '=' assignment. Before this patch, the 
VIRTUAL-RUNTIME_xxx are using '?='. Not sure if this would cause 
potential problem for users.
Also, if we are setting default values of VIRTUAL-RUNTIME_xxx in conf 
files, should we clean them up from recipes like packagegroup-core-boot?


Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] xmlcatalog.bbclass: execute xmlcatalog only if it's available

[ChenQi]

On 07/06/2019 12:38 AM, Burton, Ross wrote:

We could just always install libxml2 into the SDK...


Good idea. I'll send out a new patch.


On Fri, 5 Jul 2019 at 02:18, Chen Qi  wrote:

For build-sysroots.bb, the xmlcatalog would not be in its
staging directory. Causing the following error for eSDK.

ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Command 
'/PATH/TO/IMAGE/testsdkext/tmp/sysroots/x86_64/usr/bin/postinst-docbook-xml-dtd4-native-xmlcatalog'
 returned non-zero exit status 127.
ERROR: build-sysroots-1.0-r0 do_build_native_sysroot: Function failed: 
do_build_native_sysroot

The problem could be reproduced by the following steps.
1. Add in local.conf:
IMAGE_INSTALL_append = " btrfs-tools"
DISTRO_FEATURES_append = " api-documentation"
INHERIT += "testsdk"
2. bitbake core-image-minimal -c populate_sdk_ext
3. bitbake core-image-minimal -c testsdkext

Signed-off-by: Chen Qi 
---
  meta/classes/xmlcatalog.bbclass | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/meta/classes/xmlcatalog.bbclass b/meta/classes/xmlcatalog.bbclass
index 075aef8..e805e7b 100644
--- a/meta/classes/xmlcatalog.bbclass
+++ b/meta/classes/xmlcatalog.bbclass
@@ -5,6 +5,8 @@ XMLCATALOGS ?= ""
  SYSROOT_PREPROCESS_FUNCS_append = " xmlcatalog_sstate_postinst"

  xmlcatalog_complete() {
+   # In case of eSDK, build-sysroot does not have xmlcatalog in its 
staging directory.
+   [ "`which xmlcatalog`" = "" ] && exit 0
 ROOTCATALOG="${STAGING_ETCDIR_NATIVE}/xml/catalog"
 if [ ! -f $ROOTCATALOG ]; then
 mkdir --parents $(dirname $ROOTCATALOG)
--
1.9.1

--
___
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] [PATCH] shadow: update to 4.7

[ChenQi]

I guess it's related to host. Maybe you can reproduce it on Fedora.

I also checked the codes of the shadow repo and found the following commit.
"""
commit 4aaf05d72e9d6daf348cefb8a6ad35d2966cbe9b
Author: Jakub Hrozek 
Date:   Wed Sep 12 14:22:11 2018 +0200

Flush sssd caches in addition to nscd caches

Some distributions, notably Fedora, have the following order of 
nsswitch

modules by default:
passwd: sss files
group:  sss files

The advantage of serving local users through SSSD is that the nss_sss
module has a fast mmapped-cache that speeds up NSS lookups compared to
accessing the disk an opening the files on each NSS request.

Traditionally, this has been done with the help of nscd, but using nscd
in parallel with sssd is cumbersome, as both SSSD and nscd use 
their own

independent caching, so using nscd in setups where sssd is also serving
users from some remote domain (LDAP, AD, ...) can result in a bit of
unpredictability.

More details about why Fedora chose to use sss before files can be 
found

on e.g.:
https://fedoraproject.org//wiki/Changes/SSSDCacheForLocalUsers
or:
https://docs.pagure.org/SSSD.sssd/design_pages/files_provider.html

Now, even though sssd watches the passwd and group files with the help
of inotify, there can still be a small window where someone requests a
user or a group, finds that it doesn't exist, adds the entry and checks
again. Without some support in shadow-utils that would explicitly drop
the sssd caches, the inotify watch can fire a little late, so a
combination of commands like this:
getent passwd user || useradd user; getent passwd user
can result in the second getent passwd not finding the newly added user
as the racy behaviour might still return the cached negative hit from
the first getent passwd.
"""

Looking at the sssd.c codes, it's using /usr/sbin/sss_cache from host 
and I guess it's not suitable for cross-compilation environment. I'm not 
sure about it, you can investigate more.

Anyway, I think you can disable it via '--without-sssd' in recipe.

Best Regards,
Chen Qi

On 07/03/2019 10:46 AM, Oleksandr Kravchuk wrote:

Chen -

Absolutely. Just explain me how I can reproduce it, please.

On 03/07/2019 04:27, ChenQi wrote:

Could you please help check if the following failure is related to
this patch?
https://autobuilder.yoctoproject.org/typhoon/#/builders/57/builds/763/steps/7/logs/step1b


Best Regards,
Chen Qi

On 07/03/2019 04:52 AM, Oleksandr Kravchuk wrote:

Removed patches were upstreamed.

Signed-off-by: Oleksandr Kravchuk 
---
   ...chg-shadow-field-reproducible-re.-71.patch |  89 --
   ...te-parent-directories-when-necessary.patch | 116 --
   ...ettime-Use-secure_getenv-over-getenv.patch |  71 ---
   ...curetty_4.6.bb => shadow-securetty_4.7.bb} |   0
   ...w-sysroot_4.6.bb => shadow-sysroot_4.7.bb} |   0
   meta/recipes-extended/shadow/shadow.inc   |   7 +-
   .../shadow/{shadow_4.6.bb => shadow_4.7.bb}   |   0
   7 files changed, 2 insertions(+), 281 deletions(-)
   delete mode 100644
meta/recipes-extended/shadow/files/0001-Make-the-sp_lstchg-shadow-field-reproducible-re.-71.patch
   delete mode 100644
meta/recipes-extended/shadow/files/0001-useradd.c-create-parent-directories-when-necessary.patch
   delete mode 100644
meta/recipes-extended/shadow/files/0002-gettime-Use-secure_getenv-over-getenv.patch
   rename meta/recipes-extended/shadow/{shadow-securetty_4.6.bb =>
shadow-securetty_4.7.bb} (100%)
   rename meta/recipes-extended/shadow/{shadow-sysroot_4.6.bb =>
shadow-sysroot_4.7.bb} (100%)
   rename meta/recipes-extended/shadow/{shadow_4.6.bb =>
shadow_4.7.bb} (100%)

diff --git
a/meta/recipes-extended/shadow/files/0001-Make-the-sp_lstchg-shadow-field-reproducible-re.-71.patch
b/meta/recipes-extended/shadow/files/0001-Make-the-sp_lstchg-shadow-field-reproducible-re.-71.patch

deleted file mode 100644
index de0ba3ebb4..00
---
a/meta/recipes-extended/shadow/files/0001-Make-the-sp_lstchg-shadow-field-reproducible-re.-71.patch
+++ /dev/null
@@ -1,89 +0,0 @@
-From fe34a2a0e44bc80ff213bfd185046a5f10c94997 Mon Sep 17 00:00:00 2001
-From: Chris Lamb 
-Date: Wed, 2 Jan 2019 18:06:16 +
-Subject: [PATCH 1/2] Make the sp_lstchg shadow field reproducible
(re. #71)
-
-From <https://github.com/shadow-maint/shadow/pull/71>:
-
-```
-The third field in the /etc/shadow file (sp_lstchg) contains the
date of
-the last password change expressed as the number of days since Jan
1, 1970.
-As this is a relative time, creating a user today will result in:
-
-username:17238:0:9:7:::
-whilst creating the same user tomorrow will result in:
-
-username:17239:0:9:7:::
-This has an impact for the Reproducible Builds[0] project where we
aim to
-be independent of as many elements the build environment

Re: [OE-core] [PATCH] shadow: update to 4.7

[ChenQi]

Could you please help check if the following failure is related to this 
patch?

https://autobuilder.yoctoproject.org/typhoon/#/builders/57/builds/763/steps/7/logs/step1b

Best Regards,
Chen Qi

On 07/03/2019 04:52 AM, Oleksandr Kravchuk wrote:

Removed patches were upstreamed.

Signed-off-by: Oleksandr Kravchuk 
---
  ...chg-shadow-field-reproducible-re.-71.patch |  89 --
  ...te-parent-directories-when-necessary.patch | 116 --
  ...ettime-Use-secure_getenv-over-getenv.patch |  71 ---
  ...curetty_4.6.bb => shadow-securetty_4.7.bb} |   0
  ...w-sysroot_4.6.bb => shadow-sysroot_4.7.bb} |   0
  meta/recipes-extended/shadow/shadow.inc   |   7 +-
  .../shadow/{shadow_4.6.bb => shadow_4.7.bb}   |   0
  7 files changed, 2 insertions(+), 281 deletions(-)
  delete mode 100644 
meta/recipes-extended/shadow/files/0001-Make-the-sp_lstchg-shadow-field-reproducible-re.-71.patch
  delete mode 100644 
meta/recipes-extended/shadow/files/0001-useradd.c-create-parent-directories-when-necessary.patch
  delete mode 100644 
meta/recipes-extended/shadow/files/0002-gettime-Use-secure_getenv-over-getenv.patch
  rename meta/recipes-extended/shadow/{shadow-securetty_4.6.bb => 
shadow-securetty_4.7.bb} (100%)
  rename meta/recipes-extended/shadow/{shadow-sysroot_4.6.bb => 
shadow-sysroot_4.7.bb} (100%)
  rename meta/recipes-extended/shadow/{shadow_4.6.bb => shadow_4.7.bb} (100%)

diff --git 
a/meta/recipes-extended/shadow/files/0001-Make-the-sp_lstchg-shadow-field-reproducible-re.-71.patch
 
b/meta/recipes-extended/shadow/files/0001-Make-the-sp_lstchg-shadow-field-reproducible-re.-71.patch
deleted file mode 100644
index de0ba3ebb4..00
--- 
a/meta/recipes-extended/shadow/files/0001-Make-the-sp_lstchg-shadow-field-reproducible-re.-71.patch
+++ /dev/null
@@ -1,89 +0,0 @@
-From fe34a2a0e44bc80ff213bfd185046a5f10c94997 Mon Sep 17 00:00:00 2001
-From: Chris Lamb 
-Date: Wed, 2 Jan 2019 18:06:16 +
-Subject: [PATCH 1/2] Make the sp_lstchg shadow field reproducible (re. #71)
-
-From :
-
-```
-The third field in the /etc/shadow file (sp_lstchg) contains the date of
-the last password change expressed as the number of days since Jan 1, 1970.
-As this is a relative time, creating a user today will result in:
-
-username:17238:0:9:7:::
-whilst creating the same user tomorrow will result in:
-
-username:17239:0:9:7:::
-This has an impact for the Reproducible Builds[0] project where we aim to
-be independent of as many elements the build environment as possible,
-including the current date.
-
-This patch changes the behaviour to use the SOURCE_DATE_EPOCH[1]
-environment variable (instead of Jan 1, 1970) if valid.
-```
-
-This updated PR adds some missing calls to gettime (). This was originally
-filed by Johannes Schauer in Debian as #917773 [2].
-
-[0] https://reproducible-builds.org/
-[1] https://reproducible-builds.org/specs/source-date-epoch/
-[2] https://bugs.debian.org/917773
-
-Upstream-Status: Backport
-Signed-off-by: Alex Kiernan 

- libmisc/pwd2spwd.c | 3 +--
- src/pwck.c | 2 +-
- src/pwconv.c   | 2 +-
- 3 files changed, 3 insertions(+), 4 deletions(-)
-
-diff --git a/libmisc/pwd2spwd.c b/libmisc/pwd2spwd.c
-index c1b9b29ac873..6799dd50d490 100644
 a/libmisc/pwd2spwd.c
-+++ b/libmisc/pwd2spwd.c
-@@ -40,7 +40,6 @@
- #include "prototypes.h"
- #include "defines.h"
- #include 
--extern time_t time (time_t *);
-
- /*
-  * pwd_to_spwd - create entries for new spwd structure
-@@ -66,7 +65,7 @@ struct spwd *pwd_to_spwd (const struct passwd *pw)
-*/
-   sp.sp_min = 0;
-   sp.sp_max = (1L * DAY) / SCALE;
--  sp.sp_lstchg = (long) time ((time_t *) 0) / SCALE;
-+  sp.sp_lstchg = (long) gettime () / SCALE;
-   if (0 == sp.sp_lstchg) {
-   /* Better disable aging than requiring a password
-* change */
-diff --git a/src/pwck.c b/src/pwck.c
-index 0ffb711efb13..f70071b12500 100644
 a/src/pwck.c
-+++ b/src/pwck.c
-@@ -609,7 +609,7 @@ static void check_pw_file (int *errors, bool *changed)
-   sp.sp_inact  = -1;
-   sp.sp_expire = -1;
-   sp.sp_flag   = SHADOW_SP_FLAG_UNSET;
--  sp.sp_lstchg = (long) time ((time_t *) 
0) / SCALE;
-+  sp.sp_lstchg = (long) gettime () / 
SCALE;
-   if (0 == sp.sp_lstchg) {
-   /* Better disable aging than
-* requiring a password change
-diff --git a/src/pwconv.c b/src/pwconv.c
-index 9c69fa131d8e..f932f266c59c 100644
 a/src/pwconv.c
-+++ b/src/pwconv.c
-@@ -267,7 +267,7 @@ int main (int argc, char **argv)
-   spent.sp_flag   = SHADOW_SP_FLAG_UNSET

Re: [OE-core] [PATCHv3 1/3] runqemu: Allow to store more than one lock for network interfaces

[ChenQi]

Could you please help check if the following failures are related to 
this patch series?

https://autobuilder.yoctoproject.org/typhoon/#/builders/47/builds/785/steps/7/logs/step1c
https://autobuilder.yoctoproject.org/typhoon/#/builders/63/builds/766/steps/7/logs/step1c

Regards,
Chen Qi

On 07/02/2019 05:23 AM, Aníbal Limón wrote:

In order to support multiple tap devices in the same qemu virtual
machine.

Signed-off-by: Aníbal Limón 
---
  scripts/runqemu | 50 +
  1 file changed, 26 insertions(+), 24 deletions(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index 4079f2b17d..38dd1c30d9 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -181,8 +181,7 @@ class BaseConfig(object):
  self.audio_enabled = False
  self.tcpserial_portnum = ''
  self.custombiosdir = ''
-self.lock = ''
-self.lock_descriptor = None
+self.lock_descriptors = {}
  self.bitbake_e = ''
  self.snapshot = False
  self.wictypes = ('wic', 'wic.vmdk', 'wic.qcow2', 'wic.vdi')
@@ -204,30 +203,32 @@ class BaseConfig(object):
  # avoid cleanup twice
  self.cleaned = False
  
-def acquire_lock(self, error=True):

-logger.debug("Acquiring lockfile %s..." % self.lock)
+def acquire_lock(self, lock, error=True):
+logger.debug("Acquiring lockfile %s..." % lock)
+descriptor = None
  try:
-self.lock_descriptor = open(self.lock, 'w')
-fcntl.flock(self.lock_descriptor, fcntl.LOCK_EX|fcntl.LOCK_NB)
+descriptor = open(lock, 'w')
+fcntl.flock(descriptor, fcntl.LOCK_EX|fcntl.LOCK_NB)
  except Exception as e:
-msg = "Acquiring lockfile %s failed: %s" % (self.lock, e)
+msg = "Acquiring lockfile %s failed: %s" % (lock, e)
  if error:
  logger.error(msg)
  else:
  logger.info(msg)
-if self.lock_descriptor:
-self.lock_descriptor.close()
-self.lock_descriptor = None
+if descriptor:
+descriptor.close()
+descriptor = None
  return False
+self.lock_descriptors[lock] = descriptor
  return True
  
-def release_lock(self):

-if self.lock_descriptor:
-logger.debug("Releasing lockfile for tap device '%s'" % self.tap)
-fcntl.flock(self.lock_descriptor, fcntl.LOCK_UN)
-self.lock_descriptor.close()
-os.remove(self.lock)
-self.lock_descriptor = None
+def release_lock(self, lock):
+if self.lock_descriptors[lock]:
+logger.debug("Releasing lockfile for tap device '%s'" % lock)
+fcntl.flock(self.lock_descriptors[lock], fcntl.LOCK_UN)
+self.lock_descriptors[lock].close()
+os.remove(lock)
+self.lock_descriptors[lock] = None
  
  def get(self, key):

  if key in self.d:
@@ -1016,8 +1017,8 @@ class BaseConfig(object):
  if os.path.exists('%s.skip' % lockfile):
  logger.info('Found %s.skip, skipping %s' % (lockfile, p))
  continue
-self.lock = lockfile + '.lock'
-if self.acquire_lock(error=False):
+lock = lockfile + '.lock'
+if self.acquire_lock(lock, error=False):
  tap = p
  logger.info("Using preconfigured tap device %s" % tap)
  logger.info("If this is not intended, touch %s.skip to make 
runqemu skip %s." %(lockfile, tap))
@@ -1035,8 +1036,8 @@ class BaseConfig(object):
  cmd = ('sudo', self.qemuifup, str(uid), str(gid), 
self.bindir_native)
  tap = subprocess.check_output(cmd).decode('utf-8').strip()
  lockfile = os.path.join(lockdir, tap)
-self.lock = lockfile + '.lock'
-self.acquire_lock()
+lock = lockfile + '.lock'
+self.acquire_lock(lock)
  self.cleantap = True
  logger.debug('Created tap: %s' % tap)
  
@@ -1268,8 +1269,8 @@ class BaseConfig(object):

  cmds = shlex.split(cmd)
  logger.info('Running %s\n' % cmd)
  pass_fds = []
-if self.lock_descriptor:
-pass_fds = [self.lock_descriptor.fileno()]
+if self.lock_descriptors.keys():
+pass_fds = [self.lock_descriptors[lock].fileno() for lock in 
self.lock_descriptors.keys()]
  process = subprocess.Popen(cmds, stderr=subprocess.PIPE, 
pass_fds=pass_fds)
  self.qemupid = process.pid
  retcode = process.wait()
@@ -1291,7 +1292,8 @@ class BaseConfig(object):
  cmd = ('sudo', self.qemuifdown, self.tap, self.bindir_native)
  logger.debug('Running %s' % str(cmd))
  subprocess.check_call(cmd)
-self.release_lock()
+for lock in self.lock_descriptors.keys():
+self.relea

Re: [OE-core] [PATCH V2 1/1] image.bbclass: fix systemd_preset_all

[ChenQi]

On 07/03/2019 05:04 AM, Peter Kjellerstedt wrote:

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org  On Behalf Of ChenQi
Sent: den 2 juli 2019 03:39
To: Peter Kjellerstedt ; openembedded-
c...@lists.openembedded.org
Subject: Re: [OE-core] [PATCH V2 1/1] image.bbclass: fix
systemd_preset_all

On 07/02/2019 07:34 AM, Peter Kjellerstedt wrote:

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org


core-boun...@lists.openembedded.org> On Behalf Of Chen Qi
Sent: den 1 juli 2019 06:16
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH V2 1/1] image.bbclass: fix

systemd_preset_all

Check the existence of systemd before using systemctl to preset

units.

This is because even if 'systemd' is in DISTRO_FEATURES, it's

possible

that systemd is not even installed. e.g. container-test-image in
meta-selftest layer.

As systemd DEPENDS on systemd-systemctl-native, the existence of

systemd

also ensures the existence of systemd-systemctl-native.

This would fix the following test case when using systemd as the

init

manager.

containerimage.ContainerImageTests.test_expected_files

Also remove the IMAGE_EXTRADEPENDS setting, as nothing references

this

variable.

Signed-off-by: Chen Qi 
---
   meta/classes/image.bbclass | 5 +++--
   1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index d2b2fb9..7daa97e 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -666,10 +666,11 @@ reproducible_final_image_task () {
   }

   systemd_preset_all () {
-systemctl --root="${IMAGE_ROOTFS}" --preset-mode=enable-only

preset-all

+if [ -e ${IMAGE_ROOTFS}${root_prefix}/lib/systemd/systemd ];

then

^^
That should be ${systemd_system_unitdir}, which will also use the

correct path

(it is /lib/systemd/system, not /lib/systemd/systemd).

I'm checking the systemd binary under ${root_prefix}/lib/systemd, not
the directory holding units.

Right, my bad. Still, then the path above should be
"${IMAGE_ROOTFS}${systemd_unitdir}/systemd".


In current OE, ${systemd_unitdir} = ${root_prefix}/lib/systemd.
And in systemd recipe, we have:
[ ! -e ${D}/init ] && ln -s ${rootlibexecdir}/systemd/systemd ${D}/init
It does not write as `ln -s ${systemd_unitdir}/systemd/systemd'.
I don't want to use a directory whose name indicates 'unit' when 
checking a binary.


Regards,
Chen Qi


Regards,
Chen Qi


+   systemctl --root="${IMAGE_ROOTFS}" --preset-mode=enable-only

preset-all

+fi
   }

-IMAGE_EXTRADEPENDS += "${@ 'systemd-systemctl-native' if

bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d) and not
bb.utils.contains('IMAGE_FEATURES', 'stateless-rootfs', True, False, d)
else ''}"

   IMAGE_PREPROCESS_COMMAND_append = " ${@ 'systemd_preset_all;' if

bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d) and not
bb.utils.contains('IMAGE_FEATURES', 'stateless-rootfs', True, False, d)
else ''} reproducible_final_image_task; "

   CVE_PRODUCT = ""
--
1.9.1

//Peter

//Peter




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

Re: [OE-core] [PATCH] cve-update-db: Use std library instead of urllib3

[ChenQi]

I just tired to open the web but failed. The web seems down.

Regards,
Chen Qi

On 07/02/2019 03:39 PM, ChenQi wrote:

A recent do_populate_cve_db failure:
https://autobuilder.yoctoproject.org/typhoon/#/builders/23/builds/1005/steps/7/logs/errors 



Could you please help look at what's going on?

Regards,
Chen Qi

On 06/24/2019 05:44 PM, Pierre Le Magourou wrote:

From: Pierre Le Magourou 

urllib3 was used in this recipe but it was not set as a
dependency. As it is not specifically needed, rewrite the recipe with
urllib from the standard library.

Signed-off-by: Pierre Le Magourou 


---
  meta/recipes-core/meta/cve-update-db.bb | 10 --
  1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/meta/recipes-core/meta/cve-update-db.bb 
b/meta/recipes-core/meta/cve-update-db.bb

index 522fd23807..1f48820cc6 100644
--- a/meta/recipes-core/meta/cve-update-db.bb
+++ b/meta/recipes-core/meta/cve-update-db.bb
@@ -19,7 +19,7 @@ python do_populate_cve_db() {
  Update NVD database with json data feed
  """
  -import sqlite3, urllib3, shutil, gzip, re
+import sqlite3, urllib, shutil, gzip, re
  from datetime import date
BASE_URL = "https://nvd.nist.gov/feeds/json/cve/1.0/nvdcve-1.0-";
@@ -33,16 +33,14 @@ python do_populate_cve_db() {
initialize_db(c)
  -http = urllib3.PoolManager()
-
  for year in range(YEAR_START, date.today().year + 1):
  year_url = BASE_URL + str(year)
  meta_url = year_url + ".meta"
  json_url = year_url + ".json.gz"
# Retrieve meta last modified date
-with http.request('GET', meta_url, preload_content=False) as r:
-date_line = str(r.data.splitlines()[0])
+with urllib.request.urlopen(meta_url) as r:
+date_line = str(r.read().splitlines()[0])
  last_modified = re.search('lastModifiedDate:(.*)', 
date_line).group(1)

# Compare with current db last modified date
@@ -50,7 +48,7 @@ python do_populate_cve_db() {
  meta = c.fetchone()
  if not meta or meta[0] != last_modified:
  # Update db with current year json file
-with http.request('GET', json_url, 
preload_content=False) as r, open(JSON_TMPFILE, 'wb') as tmpfile:
+with urllib.request.urlopen(json_url) as r, 
open(JSON_TMPFILE, 'wb') as tmpfile:

  shutil.copyfileobj(r, tmpfile)
  with gzip.open(JSON_TMPFILE, 'rt') as jsonfile:
  update_db(c, jsonfile)





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

Re: [OE-core] [PATCH] cve-update-db: Use std library instead of urllib3

[ChenQi]

A recent do_populate_cve_db failure:
https://autobuilder.yoctoproject.org/typhoon/#/builders/23/builds/1005/steps/7/logs/errors

Could you please help look at what's going on?

Regards,
Chen Qi

On 06/24/2019 05:44 PM, Pierre Le Magourou wrote:

From: Pierre Le Magourou 

urllib3 was used in this recipe but it was not set as a
dependency. As it is not specifically needed, rewrite the recipe with
urllib from the standard library.

Signed-off-by: Pierre Le Magourou 
---
  meta/recipes-core/meta/cve-update-db.bb | 10 --
  1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/meta/recipes-core/meta/cve-update-db.bb 
b/meta/recipes-core/meta/cve-update-db.bb
index 522fd23807..1f48820cc6 100644
--- a/meta/recipes-core/meta/cve-update-db.bb
+++ b/meta/recipes-core/meta/cve-update-db.bb
@@ -19,7 +19,7 @@ python do_populate_cve_db() {
  Update NVD database with json data feed
  """
  
-import sqlite3, urllib3, shutil, gzip, re

+import sqlite3, urllib, shutil, gzip, re
  from datetime import date
  
  BASE_URL = "https://nvd.nist.gov/feeds/json/cve/1.0/nvdcve-1.0-";

@@ -33,16 +33,14 @@ python do_populate_cve_db() {
  
  initialize_db(c)
  
-http = urllib3.PoolManager()

-
  for year in range(YEAR_START, date.today().year + 1):
  year_url = BASE_URL + str(year)
  meta_url = year_url + ".meta"
  json_url = year_url + ".json.gz"
  
  # Retrieve meta last modified date

-with http.request('GET', meta_url, preload_content=False) as r:
-date_line = str(r.data.splitlines()[0])
+with urllib.request.urlopen(meta_url) as r:
+date_line = str(r.read().splitlines()[0])
  last_modified = re.search('lastModifiedDate:(.*)', 
date_line).group(1)
  
  # Compare with current db last modified date

@@ -50,7 +48,7 @@ python do_populate_cve_db() {
  meta = c.fetchone()
  if not meta or meta[0] != last_modified:
  # Update db with current year json file
-with http.request('GET', json_url, preload_content=False) as r, 
open(JSON_TMPFILE, 'wb') as tmpfile:
+with urllib.request.urlopen(json_url) as r, open(JSON_TMPFILE, 
'wb') as tmpfile:
  shutil.copyfileobj(r, tmpfile)
  with gzip.open(JSON_TMPFILE, 'rt') as jsonfile:
  update_db(c, jsonfile)



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

Re: [OE-core] [PATCH V2 1/1] image.bbclass: fix systemd_preset_all

[ChenQi]

On 07/02/2019 07:34 AM, Peter Kjellerstedt wrote:

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org  On Behalf Of Chen Qi
Sent: den 1 juli 2019 06:16
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH V2 1/1] image.bbclass: fix systemd_preset_all

Check the existence of systemd before using systemctl to preset units.
This is because even if 'systemd' is in DISTRO_FEATURES, it's possible
that systemd is not even installed. e.g. container-test-image in
meta-selftest layer.

As systemd DEPENDS on systemd-systemctl-native, the existence of systemd
also ensures the existence of systemd-systemctl-native.

This would fix the following test case when using systemd as the init
manager.

   containerimage.ContainerImageTests.test_expected_files

Also remove the IMAGE_EXTRADEPENDS setting, as nothing references this
variable.

Signed-off-by: Chen Qi 
---
  meta/classes/image.bbclass | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index d2b2fb9..7daa97e 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -666,10 +666,11 @@ reproducible_final_image_task () {
  }

  systemd_preset_all () {
-systemctl --root="${IMAGE_ROOTFS}" --preset-mode=enable-only preset-all
+if [ -e ${IMAGE_ROOTFS}${root_prefix}/lib/systemd/systemd ]; then

   ^^
That should be ${systemd_system_unitdir}, which will also use the correct path
(it is /lib/systemd/system, not /lib/systemd/systemd).


I'm checking the systemd binary under ${root_prefix}/lib/systemd, not 
the directory holding units.


Regards,
Chen Qi


+   systemctl --root="${IMAGE_ROOTFS}" --preset-mode=enable-only preset-all
+fi
  }

-IMAGE_EXTRADEPENDS += "${@ 'systemd-systemctl-native' if 
bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d) and not 
bb.utils.contains('IMAGE_FEATURES', 'stateless-rootfs', True, False, d) else ''}"
  IMAGE_PREPROCESS_COMMAND_append = " ${@ 'systemd_preset_all;' if 
bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d) and not 
bb.utils.contains('IMAGE_FEATURES', 'stateless-rootfs', True, False, d) else ''} 
reproducible_final_image_task; "

  CVE_PRODUCT = ""
--
1.9.1

//Peter




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

Re: [OE-core] [PATCH 1/1] devtool: warn user about multiple layer having the same base name

[ChenQi]

On 06/28/2019 07:25 AM, Paul Eggleton wrote:

On Thursday, 27 June 2019 3:14:55 PM NZST Chen Qi wrote:

Currently `devtool finish RECIPE meta' will silently succeed even
if there are multiple layers having the same base name of 'meta'.
e.g. meta layer from oe-core and meta layer from meta-secure-core.

Good catch!


We should at least give user a warning in such case. With the patch,
we will get warning like below.

WARNING: Multiple layers have the same base name 'meta', use the first one 
'/oe-core/meta'.
WARNING: Consider using path instead of base name to specify layer:
  /oe-core/meta
  /meta-secure-core/meta


"use the first one" -> "using the first one"

However I'm wondering if this is the right behaviour. What if the user realises 
they actually wanted the second one? Given it's a warning the finish operation 
would have proceeded and the user will have to clean things up manually. Rather 
than a warning, should we in fact be erroring out and requiring the user to be 
more specific in this case?

Cheers,
Paul


More reasonable. I'll send out V2.

Best Regards,

Chen Qi

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

Re: [OE-core] [PATCH v1] postinst-intercepts: check tool presence in intercept hooks

[ChenQi]

Under which circumstances will the tools be absent?
And why do you check the existence of files for some the the existence 
of directories for others?


Best Regards,
Chen Qi

On 06/26/2019 06:13 AM, Sinan Kaya wrote:

do_rootfs: The postinstall intercept hook 'update_udev_hwdb'
do_rootfs: The postinstall intercept hook 'update_gio_module_cache' failed
do_rootfs: The postinstall intercept hook 'update_icon_cache' failed
do_rootfs: The postinstall intercept hook 'update_icon_cache' failed

Signed-off-by: Sinan Kaya 
---
  scripts/postinst-intercepts/update_font_cache|  6 --
  .../postinst-intercepts/update_gio_module_cache  | 10 +++---
  scripts/postinst-intercepts/update_icon_cache| 16 +---
  scripts/postinst-intercepts/update_pixbuf_cache  |  5 -
  scripts/postinst-intercepts/update_udev_hwdb |  6 --
  5 files changed, 28 insertions(+), 15 deletions(-)

diff --git a/scripts/postinst-intercepts/update_font_cache 
b/scripts/postinst-intercepts/update_font_cache
index 3053c7065f4..954acbb41b2 100644
--- a/scripts/postinst-intercepts/update_font_cache
+++ b/scripts/postinst-intercepts/update_font_cache
@@ -5,5 +5,7 @@
  
  set -e
  
-PSEUDO_UNLOAD=1 ${binprefix}qemuwrapper -L $D -E ${fontconfigcacheenv} $D${libexecdir}/${binprefix}fc-cache --sysroot=$D --system-only ${fontconfigcacheparams}

-chown -R root:root $D${fontconfigcachedir}
+if [ -f $D${libexecdir}/${binprefix}fc-cache ]; then
+   PSEUDO_UNLOAD=1 ${binprefix}qemuwrapper -L $D -E ${fontconfigcacheenv} 
$D${libexecdir}/${binprefix}fc-cache --sysroot=$D --system-only 
${fontconfigcacheparams}
+   chown -R root:root $D${fontconfigcachedir}
+fi
diff --git a/scripts/postinst-intercepts/update_gio_module_cache 
b/scripts/postinst-intercepts/update_gio_module_cache
index c87fa85db9e..e8483cb0bf5 100644
--- a/scripts/postinst-intercepts/update_gio_module_cache
+++ b/scripts/postinst-intercepts/update_gio_module_cache
@@ -5,7 +5,11 @@
  
  set -e
  
-PSEUDO_UNLOAD=1 ${binprefix}qemuwrapper -L $D $D${libexecdir}/${binprefix}gio-querymodules $D${libdir}/gio/modules/

+if [ -f $D${libexecdir}/${binprefix}gio-querymodules ]; then
+
+   PSEUDO_UNLOAD=1 ${binprefix}qemuwrapper -L $D 
$D${libexecdir}/${binprefix}gio-querymodules $D${libdir}/gio/modules/
+
+   [ ! -e $D${libdir}/gio/modules/giomodule.cache ] ||
+   chown root:root $D${libdir}/gio/modules/giomodule.cache
+fi
  
-[ ! -e $D${libdir}/gio/modules/giomodule.cache ] ||

-   chown root:root $D${libdir}/gio/modules/giomodule.cache
diff --git a/scripts/postinst-intercepts/update_icon_cache 
b/scripts/postinst-intercepts/update_icon_cache
index 212209a9daf..a67ff7ef970 100644
--- a/scripts/postinst-intercepts/update_icon_cache
+++ b/scripts/postinst-intercepts/update_icon_cache
@@ -5,12 +5,14 @@
  
  set -e
  
-# update native pixbuf loaders

-$STAGING_DIR_NATIVE/${libdir_native}/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders 
--update-cache
+if [ -d $STAGING_DIR_NATIVE/${libdir_native}/gdk-pixbuf-2.0 ]; then
+   # update native pixbuf loaders
+   
$STAGING_DIR_NATIVE/${libdir_native}/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders 
--update-cache
  
-for icondir in $D/usr/share/icons/*/ ; do

-if [ -d $icondir ] ; then
-gtk-update-icon-cache -fqt  $icondir
-fi
-done
+   for icondir in $D/usr/share/icons/*/ ; do
+   if [ -d $icondir ] ; then
+   gtk-update-icon-cache -fqt  $icondir
+   fi
+   done
+fi
  
diff --git a/scripts/postinst-intercepts/update_pixbuf_cache b/scripts/postinst-intercepts/update_pixbuf_cache

index ea12814474e..166422e5c37 100644
--- a/scripts/postinst-intercepts/update_pixbuf_cache
+++ b/scripts/postinst-intercepts/update_pixbuf_cache
@@ -8,6 +8,9 @@ set -e
  export GDK_PIXBUF_MODULEDIR=$D${libdir}/gdk-pixbuf-2.0/2.10.0/loaders
  export GDK_PIXBUF_FATAL_LOADER=1
  
-PSEUDO_UNLOAD=1 ${binprefix}qemuwrapper -L $D $D${libdir}/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders \

+if [ -d $D${libdir}/gdk-pixbuf-2.0 ]; then
+   PSEUDO_UNLOAD=1 ${binprefix}qemuwrapper -L $D 
$D${libdir}/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders \
  >$GDK_PIXBUF_MODULEDIR/../loaders.cache && \
  sed -i -e "s:$D::g" $GDK_PIXBUF_MODULEDIR/../loaders.cache
+fi
+
diff --git a/scripts/postinst-intercepts/update_udev_hwdb 
b/scripts/postinst-intercepts/update_udev_hwdb
index c4fb2bffcbf..7b6e38338f3 100644
--- a/scripts/postinst-intercepts/update_udev_hwdb
+++ b/scripts/postinst-intercepts/update_udev_hwdb
@@ -5,5 +5,7 @@
  
  set -e
  
-PSEUDO_UNLOAD=1 ${binprefix}qemuwrapper -L $D $D${libexecdir}/${binprefix}udevadm hwdb --update --root $D

-chown root:root $D${sysconfdir}/udev/hwdb.bin
+if [ -d $D/lib/udev/hwdb.d ]; then
+   PSEUDO_UNLOAD=1 ${binprefix}qemuwrapper -L $D 
$D${libexecdir}/${binprefix}udevadm hwdb --update --root $D
+   chown root:root $D${sysconfdir}/udev/hwdb.bin
+fi



--
___
Openembedded-core mailing list
Openembedded-core@lists.o

Re: [OE-core] [PATCH 1/1] pkgdata: fix test_find_path to consider multilib

[ChenQi]

On 06/17/2019 11:51 PM, Richard Purdie wrote:

On Mon, 2019-06-17 at 16:32 +0800, Chen Qi wrote:

Fix test_find_path test case to take into consideration of multilib
being enabled. After this change, no matter multilib is enabled or
not, the test case should pass.

Signed-off-by: Chen Qi 
---
  meta/lib/oeqa/selftest/cases/pkgdata.py | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/pkgdata.py 
b/meta/lib/oeqa/selftest/cases/pkgdata.py
index 833a180..2bd15eb 100644
--- a/meta/lib/oeqa/selftest/cases/pkgdata.py
+++ b/meta/lib/oeqa/selftest/cases/pkgdata.py
@@ -47,10 +47,11 @@ class OePkgdataUtilTests(OESelftestTestCase):
  self.assertGreater(pkgsize, 1, "Size should be greater than 1. %s" % 
result.output)
  
  def test_find_path(self):

-result = runCmd('oe-pkgdata-util find-path /lib/libz.so.1')
-self.assertEqual(result.output, 'zlib: /lib/libz.so.1')
+base_libdir = get_bb_var('base_libdir')
+result = runCmd('oe-pkgdata-util find-path %s/libz.so.1' % base_libdir)
+self.assertEqual(result.output, 'zlib: %s/libz.so.1' % base_libdir)
  result = runCmd('oe-pkgdata-util find-path /usr/bin/m4')
-self.assertEqual(result.output, 'm4: /usr/bin/m4')
+self.assertTrue('m4: /usr/bin/m4' in result.output)
  result = runCmd('oe-pkgdata-util find-path /not/exist', 
ignore_status=True)
  self.assertEqual(result.status, 1, "Status different than 1. output: 
%s" % result.output)
  self.assertEqual(result.output, 'ERROR: Unable to find any package 
producing path /not/exist')

For selftest we really want a "known" configuration so I'm not sure we
want to go down this route as there are a lot of configurations which
could confuse the test results.

It would probably be better to have selftest only build a clean config
and accept a limited number of variables. The parallel execution code
did go a long way to getting us to the point where it would do that.

Cheers,

Richard





Got it, Thanks.

Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] manifest.py: fix test_SDK_manifest_entries

[ChenQi]

On 06/17/2019 11:54 PM, Richard Purdie wrote:

On Mon, 2019-06-17 at 17:24 +0800, Chen Qi wrote:

TOOLCHAIN_OUTPUTNAME could be overridden. So use this variable directly
instead of its default value ${SDK_NAME}-toolchain-${SDK_VERSION}.

Signed-off-by: Chen Qi 
---
  meta/lib/oeqa/selftest/cases/manifest.py | 7 ++-
  1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/manifest.py 
b/meta/lib/oeqa/selftest/cases/manifest.py
index c0b25ab..5d13f35 100644
--- a/meta/lib/oeqa/selftest/cases/manifest.py
+++ b/meta/lib/oeqa/selftest/cases/manifest.py
@@ -86,11 +86,8 @@ class VerifyManifest(OESelftestTestCase):
  try:
  mdir = self.get_dir_from_bb_var('SDK_DEPLOY', self.buildtarget)
  for k in d_target.keys():
-bb_vars = get_bb_vars(['SDK_NAME', 'SDK_VERSION'], 
self.buildtarget)
-mfilename[k] = "{}-toolchain-{}.{}.manifest".format(
-bb_vars['SDK_NAME'],
-bb_vars['SDK_VERSION'],
-k)
+toolchain_outputname = get_bb_var('TOOLCHAIN_OUTPUTNAME', 
self.buildtarget)
+mfilename[k] = "{}.{}.manifest".format(toolchain_outputname, k)

Whilst I agree there is a problem here, this code is iterating over
multiple targets. Isn't TOOLCHAIN_OUTPUTNAME only going to be correct
for one of them?

Cheers,

Richard




This code is iterating over d_target.keys(), which is 'target' and 
'host'. And the TOOLCHAIN_OUTPUTNAME is for self.buildtarget, which is 
core-image-minimal. Thus, we are basically checking 
${TOOLCHAIN_OUTPUTNAME}.target.manifest and 
${TOOLCHAIN_OUTPUTNAME}.host.target.

e.g.
tmp-glibc/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-qemux86-64-toolchain-2.7+snapshot.host.manifest
tmp-glibc/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-qemux86-64-toolchain-2.7+snapshot.target.manifest

So I think things are correct.

Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] openssl: Fix a build bug on aarch64BE.

[ChenQi]

On 06/06/2019 05:46 AM, Lei Maohui wrote:

Fix bug as following on aarch64BE:

Error: operand 1 must be an integer register -- `rev v31.16b,v31.16b'

https://github.com/openssl/openssl/pull/9151

Upstream-Status: Submitted

Signed-off-by: Lei Maohui 
---
  ...01-Fix-build-error-for-aarch64-big-endian.patch | 41 ++
  .../recipes-connectivity/openssl/openssl_1.1.1c.bb |  1 +
  2 files changed, 42 insertions(+)
  create mode 100644 
meta/recipes-connectivity/openssl/openssl/0001-Fix-build-error-for-aarch64-big-endian.patch

diff --git 
a/meta/recipes-connectivity/openssl/openssl/0001-Fix-build-error-for-aarch64-big-endian.patch
 
b/meta/recipes-connectivity/openssl/openssl/0001-Fix-build-error-for-aarch64-big-endian.patch
new file mode 100644
index 000..65ca02c
--- /dev/null
+++ 
b/meta/recipes-connectivity/openssl/openssl/0001-Fix-build-error-for-aarch64-big-endian.patch
@@ -0,0 +1,41 @@
+From 1f8c0f2feea5cdcae0bcd9dfc78198d9e2c4cf09 Mon Sep 17 00:00:00 2001
+From: Lei Maohui 
+Date: Thu, 13 Jun 2019 12:17:30 +0900
+Subject: [PATCH] Fix build error for aarch64 big endian.
+
+Modified rev to rev64, because rev only takes integer registers.
+https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90827
+Otherwise, the following error will occur.
+
+Error: operand 1 must be an integer register -- `rev v31.16b,v31.16b'
+


Put Upstream-Status here.

Best Regards,
Chen Qi


+Signed-off-by: Lei Maohui 
+---
+ crypto/sha/asm/keccak1600-armv8.pl | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/crypto/sha/asm/keccak1600-armv8.pl 
b/crypto/sha/asm/keccak1600-armv8.pl
+index dc72f18..6620690 100755
+--- a/crypto/sha/asm/keccak1600-armv8.pl
 b/crypto/sha/asm/keccak1600-armv8.pl
+@@ -731,7 +731,7 @@ $code.=<<___;
+   blo .Lprocess_block_ce
+   ldr d31,[$inp],#8   // *inp++
+ #ifdef__AARCH64EB__
+-  rev v31.16b,v31.16b
++  rev64   v31.16b,v31.16b
+ #endif
+   eor $A[$j/5][$j%5],$A[$j/5][$j%5],v31.16b
+   beq .Lprocess_block_ce
+@@ -740,7 +740,7 @@ ___
+ $code.=<<___;
+   ldr d31,[$inp],#8   // *inp++
+ #ifdef__AARCH64EB__
+-  rev v31.16b,v31.16b
++  rev64   v31.16b,v31.16b
+ #endif
+   eor $A[4][4],$A[4][4],v31.16b
+
+--
+2.7.4
+
diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1c.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1c.bb
index 669b1a1..ec85ccd 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1c.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1c.bb
@@ -16,6 +16,7 @@ SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz 
\
 file://0001-skip-test_symbol_presence.patch \
 
file://0001-buildinfo-strip-sysroot-and-debug-prefix-map-from-co.patch \
 file://afalg.patch \
+   file://0001-Fix-build-error-for-aarch64-big-endian.patch \
 "
  
  SRC_URI_append_class-nativesdk = " \



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

Re: [OE-core] [PATCH 1/1] util-linux: upgrade to 2.33.2

[ChenQi]

On 06/12/2019 01:43 PM, Adrian Bunk wrote:

On Wed, Jun 12, 2019 at 10:06:33AM +0800, Chen Qi wrote:

The license files' names are changed, but the contents remain the
same.

Signed-off-by: Chen Qi 
---
  meta/recipes-core/util-linux/util-linux.inc  | 16 
  .../{util-linux_2.32.1.bb => util-linux_2.33.2.bb}   |  4 ++--
  2 files changed, 10 insertions(+), 10 deletions(-)
  rename meta/recipes-core/util-linux/{util-linux_2.32.1.bb => 
util-linux_2.33.2.bb} (72%)

diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index 7b9b4d2..eaaf408 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -8,15 +8,15 @@ SECTION = "base"
  
  LICENSE = "GPLv2+ & LGPLv2.1+ & BSD"

...
-
file://Documentation/licenses/COPYING.UCB;md5=263860f8968d8bafa5392cab74285262 \
...
+
file://Documentation/licenses/COPYING.BSD-4-Clause-UC;md5=263860f8968d8bafa5392cab74285262
 \
...

Doesn't this mean that LICENSE is (and already was before) wrong?

meta/files/common-licenses/BSD is the 3 clause BSD licence,
but this is the 4 clause licence (with the advertising clause).

cu
Adrian


Thanks. I've changed this in V2.

Best Regards,

Chen Qi

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

Re: [OE-core] [PATCH v2 3/4] elfutils: Fix eu-* utils builds for musl

[ChenQi]

There's some musl elfutils failure about do_compile_ptest_base on 
autobuilder.

https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/645/steps/7/logs/step1b

I noticed that this patch is not yet in master-next. Can this patch 
solve the problem above?


Best Regards,
Chen Qi

On 05/23/2019 07:40 AM, Khem Raj wrote:

Re-organize the musl patches in three different areas namely
libs, utils and tests, this will help maintain them in future
version bumps

Add obstack dependency on musl targets which is needed for eu-*

PN and PN-binutils is not empty anymore on musl

Signed-off-by: Khem Raj 
Signed-off-by: Richard Purdie 
---
v2: Make FNM_EXTMATCH 0

  .../elfutils/elfutils_0.176.bb|  15 +-
  ...-err-variable-and-function-conflicts.patch |  91 
  ...ternatives-for-glibc-assumptions-hel.patch | 196 --
  .../elfutils/files/musl-libs.patch| 111 ++
  .../elfutils/files/musl-obstack-fts.patch | 105 ++
  .../files/{musl.patch => musl-tests.patch}|   0
  .../elfutils/files/musl-utils.patch   | 136 
  7 files changed, 359 insertions(+), 295 deletions(-)
  delete mode 100644 
meta/recipes-devtools/elfutils/files/0001-fix-err-variable-and-function-conflicts.patch
  delete mode 100644 
meta/recipes-devtools/elfutils/files/0008-build-Provide-alternatives-for-glibc-assumptions-hel.patch
  create mode 100644 meta/recipes-devtools/elfutils/files/musl-libs.patch
  create mode 100644 meta/recipes-devtools/elfutils/files/musl-obstack-fts.patch
  rename meta/recipes-devtools/elfutils/files/{musl.patch => musl-tests.patch} 
(100%)
  create mode 100644 meta/recipes-devtools/elfutils/files/musl-utils.patch

diff --git a/meta/recipes-devtools/elfutils/elfutils_0.176.bb 
b/meta/recipes-devtools/elfutils/elfutils_0.176.bb
index 85ff5f38d2..397723166c 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.176.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.176.bb
@@ -4,7 +4,7 @@ SECTION = "base"
  LICENSE = "GPLv2 & LGPLv3+ & GPLv3+"
  LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
  DEPENDS = "libtool bzip2 zlib virtual/libintl"
-DEPENDS_append_libc-musl = " argp-standalone fts "
+DEPENDS_append_libc-musl = " argp-standalone fts musl-obstack "
  # The Debian patches below are from:
  # 
http://ftp.de.debian.org/debian/pool/main/e/elfutils/elfutils_0.175-1.debian.tar.xz
  SRC_URI = "https://sourceware.org/elfutils/ftp/${PV}/${BP}.tar.bz2 \
@@ -31,12 +31,13 @@ SRC_URI = 
"https://sourceware.org/elfutils/ftp/${PV}/${BP}.tar.bz2 \
 file://0001-skip-the-test-when-gcc-not-deployed.patch \
 file://run-ptest \
 file://ptest.patch \
-   file://musl.patch \
 "
-SRC_URI_append_libc-musl = " 
file://0008-build-Provide-alternatives-for-glibc-assumptions-hel.patch \
- 
file://0001-fix-err-variable-and-function-conflicts.patch \
-"
-
+SRC_URI_append_libc-musl = " \
+   file://musl-obstack-fts.patch \
+   file://musl-libs.patch \
+   file://musl-utils.patch \
+   file://musl-tests.patch \
+   "
  SRC_URI[md5sum] = "077e4f49320cad82bf17a997068b1db9"
  SRC_URI[sha256sum] = 
"eb5747c371b0af0f71e86215a5ebb88728533c3a104a43d4231963f308cd1023"
  
@@ -75,8 +76,6 @@ do_install_ptest() {

  EXTRA_OEMAKE_class-native = ""
  EXTRA_OEMAKE_class-nativesdk = ""
  
-ALLOW_EMPTY_${PN}_libc-musl = "1"

-
  BBCLASSEXTEND = "native nativesdk"
  
  # Package utilities separately

diff --git 
a/meta/recipes-devtools/elfutils/files/0001-fix-err-variable-and-function-conflicts.patch
 
b/meta/recipes-devtools/elfutils/files/0001-fix-err-variable-and-function-conflicts.patch
deleted file mode 100644
index 433db133b2..00
--- 
a/meta/recipes-devtools/elfutils/files/0001-fix-err-variable-and-function-conflicts.patch
+++ /dev/null
@@ -1,91 +0,0 @@
-From 2c50fe7068bd6911958c6d851aef88179e73bb21 Mon Sep 17 00:00:00 2001
-From: Mingli Yu 
-Date: Tue, 16 Apr 2019 15:30:38 +0800
-Subject: [PATCH] fix err variable and function conflicts
-
-There comes below build failure with musl when
-ptest enabled.
-| In file included from ../../elfutils-0.176/tests/dwfl-proc-attach.c:33:
-| ../../elfutils-0.176/lib/system.h:63:35: error: called object 'err' is not a 
function or function pointer
-|  #define error(status, errno, ...) err(status, __VA_ARGS__)
-|^~~
-| ../../elfutils-0.176/tests/dwfl-proc-attach.c:92:5: note: in expansion of 
macro 'error'
-|  error (-1, 0, "dwfl_linux_proc_attach pid %d: %s", pid,
-|  ^
-| ../../elfutils-0.176/tests/dwfl-proc-attach.c:79:7: note: declared here
-|int err;
-|^~~
-
-It is because there is no error.h in musl and
-the patch 0008-build-Provide-alternatives-for-glibc-assumptions-hel.patch
-has updated to use err.h to replace error.h
-and also added macro definiton as below when
-use musl.
- #define error(status, errno, ...) err(sta

Re: [OE-core] Should systemd be marked as incompatible with musl?

[ChenQi]

On 05/23/2019 08:22 PM, Burton, Ross wrote:

On Thu, 23 May 2019 at 11:34, Adrian Bunk  wrote:

systemd is fundamentally Linux-only and not portable to other kernels.

systemd upstream is using glibc extensions not present in other
C libraries.

systemd upstream is accepting technically correct patches that help
building with musl, but there is no interest upstream in keeping systemd
working with non-glibc C libraries.

The way things currently go, systemd/musl will require an ever-growing
amount of not upstreamable patches - and this is not sustainable.

I think I have to agree with you: several of the extensions are for
security purposes, so we're potentially actively introducing issues.

Ross



I suggest we only apply these musl patches when the libc is musl.

SRC_URI += "${@d.getVar('SRC_URI_MUSL') if d.getVar('TCLIBC') == 'musl' 
else ''}"


In this way, these patches do not affect glibc users. People who 
actually use musl will test these patches and maybe improve them if they 
really care about it.


For example, the following patches are written by me.

0017-Do-not-disable-buffering-when-writing-to-oom_score_a.patch and
0001-do-not-disable-buffer-in-writing-files.patch

These two patches are to solve runtime problems in musl based system. I 
knew there's something different in buffering mechanism between glibc 
and musl that causes this problem, but I really did not want to spend 
time digging into it. And as systemd was using unbuffered way for 
writing files for a long time, I just disabled them.


As Adrian and Ross pointed out, these patches are introducing potential 
security problems. I agree that we should do something about it. At a 
minimum, the glibc based system should not be affected.


I'll send out patch and please help review it.

Best Regards,
Chen Qi

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

Re: [OE-core] "shutdown now" Hangs Since 1d453c9087f9 ("systemd: upgrade to 242")

[ChenQi]

I also just did a simple test, v242 without any oe patches has the same 
problem.

It seems that it's a change in systemd upstream.
I'm wondering why oe-selftest did not discover this problem.

Best Regards,
Chen Qi

On 05/09/2019 01:18 PM, He Zhe wrote:

Hi,


Since 1d453c9087f9 ("systemd: upgrade to 242"), "shutdown now" hangs like below 
where I enable systemd debug information print.

Any idea? Thanks.


[  OK  ] Stopped NFS status monitor for NFSv2/3 locking..
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1/unit/nfs_2dstatd_2eservice 
interface=org.freedesktop.DBusa
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1/unit/nfs_2dstatd_2eservice 
interface=org.freedesktop.DBusa
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager 
member=JobRemoa
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1/unit/nfs_2dstatd_2eservice 
interface=org.freedesktop.DBusa
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1/unit/nfs_2dstatd_2eservice 
interface=org.freedesktop.DBusa
Child 410 (sh) died (code=killed, status=1/HUP)
session-c1.scope: Child 410 belongs to session-c1.scope.
Child 299 (avahi-daemon) died (code=killed, status=15/TERM)
system.slice: Child 299 belongs to system.slice.
session-c1.scope: cgroup is empty
session-c1.scope: Succeeded.
session-c1.scope changed stop-sigterm -> dead
session-c1.scope: Job 277 session-c1.scope/stop finished, result=done
[  OK  ] Stopped Session c1 of user root.
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1/unit/session_2dc1_2escope 
interface=org.freedesktop.DBus.a
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1/unit/session_2dc1_2escope 
interface=org.freedesktop.DBus.a
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager 
member=JobRemoa
session-c1.scope: Collecting.
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1/unit/session_2dc1_2escope 
interface=org.freedesktop.DBus.a
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1/unit/session_2dc1_2escope 
interface=org.freedesktop.DBus.a
Sent message type=signal sender=n/a destination=n/a 
path=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager 
member=UnitRema
systemd-journald.service: Received EPOLLHUP on stored fd 56 (stored), closing.
systemd-journald.service: Received EPOLLHUP on stored fd 58 (stored), closing.
systemd-journald.service: Received EPOLLHUP on stored fd 65 (stored), closing.
Got message type=signal sender=org.freedesktop.DBus destination=n/a 
path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameOwna
avahi-daemon.service: D-Bus name org.freedesktop.Avahi no longer registered by 
:1.1
systemd-journald.service: Received EPOLLHUP on stored fd 55 (stored), closing.
syslog.socket: Incoming traffic
syslog.socket: Suppressing connection request since unit stop is scheduled.



Zhe



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

Re: [OE-core] [meta-oe][PATCH 1/3] systemd: remove 2 obsolete useradds

[ChenQi]

On 04/16/2019 05:49 AM, adrian.freiho...@gmail.com wrote:

On Mon, 2019-04-15 at 09:40 +0800, ChenQi wrote:

On 04/14/2019 09:24 PM, Adrian Freihofer wrote:

- Users systemd-journal-remote and systemd-journal-upload are not
used by

I guess you mean 'systemd-journal-gateway'?

You are right. I will send a V2 if I can convince you of this change
after all.

Anyway, I have some concern about this change.

Adding these users is not supposed to cause any runtime problem, as
if
the user has already exists, DynamicUser mechanism just does not try
to
create one.
I also can recall the systemd-timesync once had DynamicUser=yes, but
then removed such setting.
So if there is no compelling reason (security?) why we should use
DynamicUser, let's leave these two users there.

Best Regards,
Chen Qi

I agree with you, it works as it is. That's a strong argument.

However, traditional Unix user IDs are not ideal for embedded systems.
Especially with an image based firmware update and daemons writing to
persistent storage, traditional Unix user IDs are problematic.
With useradd-staticids enabled this problem can be addressed. But we
have to maintain static user IDs manually.
With this patch applied systemd would just generate the user IDs in any
case (static or dynamic users) without manual interaction.
Here we have the chance to get rid of two user IDs, which seems to me
to be an advantage anyway.

Another, weaker argument: Static user IDs are a rare ressource.

Are you still against this change or should I send V2 with fixed commit
comment of this third patch?


I'm not against this change.
I don't use journal-gateway/journal-upload, so I think you have more 
real-world experience.

V2 with the fixed commit is OK.

Best Regards,
Chen Qi



Best Regards,
Adrian

systemd anymore. Systemd creates dynamic users for services
without
persistent data.
- Fix start of journal-remote

Signed-off-by: Adrian Freihofer 
---
   meta/recipes-core/systemd/systemd_241.bb | 6 +-
   1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/meta/recipes-core/systemd/systemd_241.bb
b/meta/recipes-core/systemd/systemd_241.bb
index 3a58f44a3b..8e493d5b55 100644
--- a/meta/recipes-core/systemd/systemd_241.bb
+++ b/meta/recipes-core/systemd/systemd_241.bb
@@ -334,9 +334,7 @@ SYSTEMD_PACKAGES = "${@bb.utils.contains('PACKA
GECONFIG', 'binfmt', '${PN}-binfm
   SYSTEMD_SERVICE_${PN}-binfmt = "systemd-binfmt.service"
   
   USERADD_PACKAGES = "${PN} ${PN}-extra-utils \

-${@bb.utils.contains('PACKAGECONFIG',
'microhttpd', '${PN}-journal-gateway', '', d)} \
   ${@bb.utils.contains('PACKAGECONFIG',
'microhttpd', '${PN}-journal-remote', '', d)} \
-${@bb.utils.contains('PACKAGECONFIG',
'journal-upload', '${PN}-journal-upload', '', d)} \
   "
   GROUPADD_PARAM_${PN} = "-r systemd-journal"
   USERADD_PARAM_${PN} += "${@bb.utils.contains('PACKAGECONFIG',
'coredump', '--system -d / -M --shell /bin/nologin systemd-
coredump;', '', d)}"
@@ -345,9 +343,7 @@ USERADD_PARAM_${PN} += "${@bb.utils.contains('P
ACKAGECONFIG', 'polkit', '--syste
   USERADD_PARAM_${PN} += "${@bb.utils.contains('PACKAGECONFIG',
'resolved', '--system -d / -M --shell /bin/nologin systemd-
resolve;', '', d)}"
   USERADD_PARAM_${PN} += "${@bb.utils.contains('PACKAGECONFIG',
'timesyncd', '--system -d / -M --shell /bin/nologin systemd-
timesync;', '', d)}"
   USERADD_PARAM_${PN}-extra-utils = "--system -d / -M --shell
/bin/nologin systemd-bus-proxy"
-USERADD_PARAM_${PN}-journal-gateway = "--system -d / -M --shell
/bin/nologin systemd-journal-gateway"
   USERADD_PARAM_${PN}-journal-remote = "--system -d / -M --shell
/bin/nologin systemd-journal-remote"
-USERADD_PARAM_${PN}-journal-upload = "--system -d / -M --shell
/bin/nologin systemd-journal-upload"
   
   FILES_${PN}-analyze = "${bindir}/systemd-analyze"
   
@@ -401,7 +397,7 @@ FILES_${PN}-journal-remote =

"${rootlibexecdir}/systemd/systemd-journal-remote \
 ${systemd_system_unitdir}/systemd-
journal-remote.service \
 ${systemd_system_unitdir}/systemd-
journal-remote.socket \
"
-SYSTEMD_SERVICE_${PN}-remote = "systemd-journal-remote.socket"
+SYSTEMD_SERVICE_${PN}-journal-remote = "systemd-journal-
remote.socket"
   
   
   FILES_${PN}-container = "${sysconfdir}/dbus-

1/system.d/org.freedesktop.import1.conf \






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

Re: [OE-core] [meta-oe][PATCH 1/3] systemd: remove 2 obsolete useradds

[ChenQi]

On 04/14/2019 09:24 PM, Adrian Freihofer wrote:

- Users systemd-journal-remote and systemd-journal-upload are not used by


I guess you mean 'systemd-journal-gateway'?
Anyway, I have some concern about this change.

Adding these users is not supposed to cause any runtime problem, as if 
the user has already exists, DynamicUser mechanism just does not try to 
create one.
I also can recall the systemd-timesync once had DynamicUser=yes, but 
then removed such setting.
So if there is no compelling reason (security?) why we should use 
DynamicUser, let's leave these two users there.


Best Regards,
Chen Qi


   systemd anymore. Systemd creates dynamic users for services without
   persistent data.
- Fix start of journal-remote

Signed-off-by: Adrian Freihofer 
---
  meta/recipes-core/systemd/systemd_241.bb | 6 +-
  1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/meta/recipes-core/systemd/systemd_241.bb 
b/meta/recipes-core/systemd/systemd_241.bb
index 3a58f44a3b..8e493d5b55 100644
--- a/meta/recipes-core/systemd/systemd_241.bb
+++ b/meta/recipes-core/systemd/systemd_241.bb
@@ -334,9 +334,7 @@ SYSTEMD_PACKAGES = "${@bb.utils.contains('PACKAGECONFIG', 
'binfmt', '${PN}-binfm
  SYSTEMD_SERVICE_${PN}-binfmt = "systemd-binfmt.service"
  
  USERADD_PACKAGES = "${PN} ${PN}-extra-utils \

-${@bb.utils.contains('PACKAGECONFIG', 'microhttpd', 
'${PN}-journal-gateway', '', d)} \
  ${@bb.utils.contains('PACKAGECONFIG', 'microhttpd', 
'${PN}-journal-remote', '', d)} \
-${@bb.utils.contains('PACKAGECONFIG', 'journal-upload', 
'${PN}-journal-upload', '', d)} \
  "
  GROUPADD_PARAM_${PN} = "-r systemd-journal"
  USERADD_PARAM_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'coredump', 
'--system -d / -M --shell /bin/nologin systemd-coredump;', '', d)}"
@@ -345,9 +343,7 @@ USERADD_PARAM_${PN} += 
"${@bb.utils.contains('PACKAGECONFIG', 'polkit', '--syste
  USERADD_PARAM_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'resolved', 
'--system -d / -M --shell /bin/nologin systemd-resolve;', '', d)}"
  USERADD_PARAM_${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'timesyncd', 
'--system -d / -M --shell /bin/nologin systemd-timesync;', '', d)}"
  USERADD_PARAM_${PN}-extra-utils = "--system -d / -M --shell /bin/nologin 
systemd-bus-proxy"
-USERADD_PARAM_${PN}-journal-gateway = "--system -d / -M --shell /bin/nologin 
systemd-journal-gateway"
  USERADD_PARAM_${PN}-journal-remote = "--system -d / -M --shell /bin/nologin 
systemd-journal-remote"
-USERADD_PARAM_${PN}-journal-upload = "--system -d / -M --shell /bin/nologin 
systemd-journal-upload"
  
  FILES_${PN}-analyze = "${bindir}/systemd-analyze"
  
@@ -401,7 +397,7 @@ FILES_${PN}-journal-remote = "${rootlibexecdir}/systemd/systemd-journal-remote \


${systemd_system_unitdir}/systemd-journal-remote.service \

${systemd_system_unitdir}/systemd-journal-remote.socket \
   "
-SYSTEMD_SERVICE_${PN}-remote = "systemd-journal-remote.socket"
+SYSTEMD_SERVICE_${PN}-journal-remote = "systemd-journal-remote.socket"
  
  
  FILES_${PN}-container = "${sysconfdir}/dbus-1/system.d/org.freedesktop.import1.conf \



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

Re: [OE-core] [PATCH 1/1] runqemu: do not check return code of tput

[ChenQi]

ping

On 01/25/2019 11:18 AM, Chen Qi wrote:

The subprocess.run was replaced by subprocess.check_call because
of compatibility support down to python 3.4. But we really don't
care about whether that command succeeds. Some user reports that
in some tmux environment, this command fails and gives some
unpleasant traceback output. So we use 'call' instead of 'check_call'
to avoid such problem.

Signed-off-by: Chen Qi 
---
  scripts/runqemu | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index c4a0ca8..d3239ee 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -1318,7 +1318,7 @@ def main():
  logger.info("SIGTERM received")
  os.kill(config.qemupid, signal.SIGTERM)
  config.cleanup()
-subprocess.check_call(["tput", "smam"])
+subprocess.call(["tput", "smam"])
  signal.signal(signal.SIGTERM, sigterm_handler)
  
  config.check_args()

@@ -1340,7 +1340,7 @@ def main():
  return 1
  finally:
  config.cleanup()
-subprocess.check_call(["tput", "smam"])
+subprocess.call(["tput", "smam"])
  
  if __name__ == "__main__":

  sys.exit(main())



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

Re: [OE-core] [PATCH] libatomic-ops:upgrade 7.6.8 -> 7.6.10

[ChenQi]

It seems that you didn't remove the old version.

Best Regards,
Chen Qi

On 04/01/2019 09:44 AM, Zang Ruochen wrote:

-Upgrade from libatomic-ops_7.6.8.bb to libatomic-ops_7.6.10.bb.

Signed-off-by: Zang Ruochen 
---
  .../libatomic-ops/libatomic-ops_7.6.10.bb | 22 +++
  1 file changed, 22 insertions(+)
  create mode 100644 meta/recipes-support/libatomic-ops/libatomic-ops_7.6.10.bb

diff --git a/meta/recipes-support/libatomic-ops/libatomic-ops_7.6.10.bb 
b/meta/recipes-support/libatomic-ops/libatomic-ops_7.6.10.bb
new file mode 100644
index 00..7628eedb1b
--- /dev/null
+++ b/meta/recipes-support/libatomic-ops/libatomic-ops_7.6.10.bb
@@ -0,0 +1,22 @@
+SUMMARY = "A library for atomic integer operations"
+HOMEPAGE = "https://github.com/ivmai/libatomic_ops/";
+SECTION = "optional"
+PROVIDES += "libatomics-ops"
+LICENSE = "GPLv2 & MIT"
+LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
+
file://doc/LICENSING.txt;md5=e00dd5c8ac03a14c5ae5225a4525fa2d \
+"
+
+SRC_URI = 
"https://github.com/ivmai/libatomic_ops/releases/download/v${PV}/libatomic_ops-${PV}.tar.gz";
+UPSTREAM_CHECK_URI = "https://github.com/ivmai/libatomic_ops/releases";
+
+SRC_URI[md5sum] = "90a78a84d9c28ce11f331c25289bfbd0"
+SRC_URI[sha256sum] = 
"587edf60817f56daf1e1ab38a4b3c729b8e846ff67b4f62a6157183708f099af"
+
+S = "${WORKDIR}/libatomic_ops-${PV}"
+
+ALLOW_EMPTY_${PN} = "1"
+
+inherit autotools pkgconfig
+
+BBCLASSEXTEND = "native nativesdk"



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

Re: [OE-core] [PATCH 6/8] binutils: fix upstream version check

[ChenQi]

Hi Alexander,

I just sent out a patch to change the PV to "2.32".
If it's 2.32, does this var still needs to be set?

Best Regards,
Chen Qi

On 03/27/2019 10:09 PM, Alexander Kanavin wrote:

Signed-off-by: Alexander Kanavin 
---
  meta/recipes-devtools/binutils/binutils-2.32.inc | 5 +
  1 file changed, 5 insertions(+)

diff --git a/meta/recipes-devtools/binutils/binutils-2.32.inc 
b/meta/recipes-devtools/binutils/binutils-2.32.inc
index 74239868151..15406441241 100644
--- a/meta/recipes-devtools/binutils/binutils-2.32.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.32.inc
@@ -14,6 +14,11 @@ def binutils_branch_version(d):
  pvsplit = d.getVar('PV').split('.')
  return pvsplit[0] + "_" + pvsplit[1]
  
+# Actual upstream version is 2.32 (without the .0), so we have to set

+# UPSTREAM_VERSION_UNKNOWN to avoid the version check failure. The line can
+# be removed when a new version of binutils is released (if the PV is then
+# correctly set to match the upstream version tag).
+UPSTREAM_VERSION_UNKNOWN = "1"
  PV = "2.32.0"
  BINUPV = "${@binutils_branch_version(d)}"
  #BRANCH = "binutils-${BINUPV}-branch"



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

Re: [OE-core] [PATCH] libpcre2: fix CVE-2017-7186

[ChenQi]

This patch seems to cause 
https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/370/steps/7/logs/errors


Best Regards,
Chen Qi

On 03/07/2019 06:51 AM, Ross Burton wrote:

Signed-off-by: Ross Burton 
---
  .../libpcre/libpcre2/CVE-2017-7186.patch   | 83 ++
  meta/recipes-support/libpcre/libpcre2_10.32.bb |  1 +
  2 files changed, 84 insertions(+)
  create mode 100644 meta/recipes-support/libpcre/libpcre2/CVE-2017-7186.patch

diff --git a/meta/recipes-support/libpcre/libpcre2/CVE-2017-7186.patch 
b/meta/recipes-support/libpcre/libpcre2/CVE-2017-7186.patch
new file mode 100644
index 000..7cd7c27c6c0
--- /dev/null
+++ b/meta/recipes-support/libpcre/libpcre2/CVE-2017-7186.patch
@@ -0,0 +1,83 @@
+libpcre1 in PCRE 8.40 and libpcre2 in PCRE2 10.23 allow remote attackers to
+cause a denial of service (segmentation violation for read access, and
+application crash) by triggering an invalid Unicode property lookup.   
+
+CVE: CVE-2017-7186
+Upstream-Status: Backport
+Signed-off-by: Ross Burton 
+
+---
+ src/pcre2_internal.h | 15 ++-
+ src/pcre2_ucd.c  | 14 ++
+ 2 files changed, 28 insertions(+), 1 deletion(-)
+
+diff --git a/src/pcre2_internal.h b/src/pcre2_internal.h
+index 6a8774c..720bbc9 100644
+--- a/src/pcre2_internal.h
 b/src/pcre2_internal.h
+@@ -1774,10 +1774,17 @@ typedef struct {
+ /* UCD access macros */
+
+ #define UCD_BLOCK_SIZE 128
+-#define GET_UCD(ch) (PRIV(ucd_records) + \
++#define REAL_GET_UCD(ch) (PRIV(ucd_records) + \
+ PRIV(ucd_stage2)[PRIV(ucd_stage1)[(int)(ch) / UCD_BLOCK_SIZE] * \
+ UCD_BLOCK_SIZE + (int)(ch) % UCD_BLOCK_SIZE])
+
++#if PCRE2_CODE_UNIT_WIDTH == 32
++#define GET_UCD(ch) ((ch > MAX_UTF_CODE_POINT)? \
++  PRIV(dummy_ucd_record) : REAL_GET_UCD(ch))
++#else
++#define GET_UCD(ch) REAL_GET_UCD(ch)
++#endif
++
+ #define UCD_CHARTYPE(ch)GET_UCD(ch)->chartype
+ #define UCD_SCRIPT(ch)  GET_UCD(ch)->script
+ #define UCD_CATEGORY(ch)PRIV(ucp_gentype)[UCD_CHARTYPE(ch)]
+@@ -1834,6 +1841,9 @@ extern const uint8_t  PRIV(utf8_table4)[];
+ #define _pcre2_default_compile_context 
PCRE2_SUFFIX(_pcre2_default_compile_context_)
+ #define _pcre2_default_match_context   
PCRE2_SUFFIX(_pcre2_default_match_context_)
+ #define _pcre2_default_tables  PCRE2_SUFFIX(_pcre2_default_tables_)
++#if PCRE2_CODE_UNIT_WIDTH == 32
++#define _pcre2_dummy_ucd_recordPCRE2_SUFFIX(_pcre2_dummy_ucd_record_)
++#endif
+ #define _pcre2_hspace_list PCRE2_SUFFIX(_pcre2_hspace_list_)
+ #define _pcre2_vspace_list PCRE2_SUFFIX(_pcre2_vspace_list_)
+ #define _pcre2_ucd_caseless_sets   PCRE2_SUFFIX(_pcre2_ucd_caseless_sets_)
+@@ -1858,6 +1868,9 @@ extern const uint32_t  
PRIV(hspace_list)[];
+ extern const uint32_t  PRIV(vspace_list)[];
+ extern const uint32_t  PRIV(ucd_caseless_sets)[];
+ extern const ucd_recordPRIV(ucd_records)[];
++#if PCRE2_CODE_UNIT_WIDTH == 32
++extern const ucd_recordPRIV(dummy_ucd_record)[];
++#endif
+ extern const uint8_t   PRIV(ucd_stage1)[];
+ extern const uint16_t  PRIV(ucd_stage2)[];
+ extern const uint32_t  PRIV(ucp_gbtable)[];
+diff --git a/src/pcre2_ucd.c b/src/pcre2_ucd.c
+index 116f537..56aa29d 100644
+--- a/src/pcre2_ucd.c
 b/src/pcre2_ucd.c
+@@ -41,6 +41,20 @@ const uint32_t PRIV(ucd_caseless_sets)[] = {0};
+
+ const char *PRIV(unicode_version) = "8.0.0";
+
++/* If the 32-bit library is run in non-32-bit mode, character values
++greater than 0x10 may be encountered. For these we set up a
++special record. */
++
++#if PCRE2_CODE_UNIT_WIDTH == 32
++const ucd_record PRIV(dummy_ucd_record)[] = {{
++  ucp_Common,/* script */
++  ucp_Cn,/* type unassigned */
++  ucp_gbOther,   /* grapheme break property */
++  0, /* case set */
++  0, /* other case */
++  }};
++#endif
++
+ /* When recompiling tables with a new Unicode version, please check the
+ types in this structure definition from pcre2_internal.h (the actual
+ field names will be different):
+--
+2.12.1
diff --git a/meta/recipes-support/libpcre/libpcre2_10.32.bb 
b/meta/recipes-support/libpcre/libpcre2_10.32.bb
index 3a0aa53029f..59953626c74 100644
--- a/meta/recipes-support/libpcre/libpcre2_10.32.bb
+++ b/meta/recipes-support/libpcre/libpcre2_10.32.bb
@@ -12,6 +12,7 @@ LIC_FILES_CHKSUM = 
"file://LICENCE;md5=cf66d307bf03bae65d413eb7a8e603a0"
  
  SRC_URI = "https://ftp.pcre.org/pub/pcre/pcre2-${PV}.tar.bz2 \

 file://pcre-cross.patch \
+   file://CVE-2017-7186.patch \
  "
  
  SRC_URI[md5sum] = "8a096287153fb994970df3570e90fcb5"



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

Re: [OE-core] [PATCH 3/3] systemd-boot: upgrade to 241

[ChenQi]

On 03/01/2019 04:52 PM, Chen Qi wrote:

The following two patches are added because I cannot figure
out how to pass parameter to efi-cc if it's changed to be
an array value.

   systemd/0001-Revert-meson-print-EFI-CC-configuration-nicely.patch
   systemd/0001-Revert-meson-use-an-array-option-for-efi-cc.patch

Signed-off-by: Chen Qi 
---
  .../{systemd-boot_239.bb => systemd-boot_241.bb}   | 10 +--
  ...t-meson-print-EFI-CC-configuration-nicely.patch | 33 ++
  ...vert-meson-use-an-array-option-for-efi-cc.patch | 77 ++
  3 files changed, 116 insertions(+), 4 deletions(-)
  rename meta/recipes-core/systemd/{systemd-boot_239.bb => systemd-boot_241.bb} 
(85%)
  create mode 100644 
meta/recipes-core/systemd/systemd/0001-Revert-meson-print-EFI-CC-configuration-nicely.patch
  create mode 100644 
meta/recipes-core/systemd/systemd/0001-Revert-meson-use-an-array-option-for-efi-cc.patch

diff --git a/meta/recipes-core/systemd/systemd-boot_239.bb 
b/meta/recipes-core/systemd/systemd-boot_241.bb
similarity index 85%
rename from meta/recipes-core/systemd/systemd-boot_239.bb
rename to meta/recipes-core/systemd/systemd-boot_241.bb
index 2450d52..083a864 100644
--- a/meta/recipes-core/systemd/systemd-boot_239.bb
+++ b/meta/recipes-core/systemd/systemd-boot_241.bb
@@ -3,23 +3,25 @@ FILESEXTRAPATHS =. "${FILE_DIRNAME}/systemd:"
  
  DEPENDS = "intltool-native libcap util-linux gnu-efi gperf-native"
  
-SRC_URI += "file://0002-use-lnr-wrapper-instead-of-looking-for-relative-opti.patch \

-file://0006-remove-nobody-user-group-checking.patch \
+# NOTE: These three patches are in theory not needed, but we haven't
+#   figured out how to correctly pass efi-cc parameter if it's an array.
+SRC_URI += "file://0001-Revert-meson-use-an-array-option-for-efi-cc.patch \
+file://0001-Revert-meson-print-EFI-CC-configuration-nicely.patch \
  
file://0001-Fix-to-run-efi_cc-and-efi_ld-correctly-when-cross-co.patch \
-file://0001-meson-rename-Ddebug-to-Ddebug-extra.patch \
  "
  
  inherit meson pkgconfig gettext

  inherit deploy
  
  EFI_CC ?= "${CC}"

+
  EXTRA_OEMESON += "-Defi=true \
-Dgnu-efi=true \
-Defi-includedir=${STAGING_INCDIR}/efi \
-Defi-ldsdir=${STAGING_LIBDIR} \
-Defi-libdir=${STAGING_LIBDIR} \
-Dman=false \
-  -Defi-cc='${EFI_CC}' \
+  -Defi-cc='${CC}' \
-Defi-ld='${LD}' \
"
  


The above change is not needed.
I've fixed it and updated the remote branch.

  git://git.pokylinux.org/poky-contrib ChenQi/systemd-241
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/systemd-241


Best Regards,
Chen Qi


diff --git 
a/meta/recipes-core/systemd/systemd/0001-Revert-meson-print-EFI-CC-configuration-nicely.patch
 
b/meta/recipes-core/systemd/systemd/0001-Revert-meson-print-EFI-CC-configuration-nicely.patch
new file mode 100644
index 000..ed14e25
--- /dev/null
+++ 
b/meta/recipes-core/systemd/systemd/0001-Revert-meson-print-EFI-CC-configuration-nicely.patch
@@ -0,0 +1,33 @@
+From 0bf530aac152630500939db31f98d933158fdabd Mon Sep 17 00:00:00 2001
+From: Chen Qi 
+Date: Tue, 26 Feb 2019 14:27:49 +0800
+Subject: [PATCH] Revert "meson: print EFI CC configuration nicely"
+
+This reverts commit c512dfb9ac948ddb1ced0dab07b9dac88b198293.
+
+This patch is here because we haven't figured out how to pass
+parameter to efi-cc if it's an array in systemd-boot recipe.
+
+Upstream-Status: Inappropriate [OE specific]
+
+Signed-off-by: Chen Qi 
+---
+ meson.build | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/meson.build b/meson.build
+index 70fb218..30df834 100644
+--- a/meson.build
 b/meson.build
+@@ -3138,7 +3138,7 @@ if conf.get('ENABLE_EFI') == 1
+ if have_gnu_efi
+ status += [
+ 'EFI machine type:  
@0@'.format(EFI_MACHINE_TYPE_NAME),
+-'EFI CC @0@'.format(' 
'.join(efi_cc)),
++'EFI CC 
@0@'.format(efi_cc),
+ 'EFI lib directory: 
@0@'.format(efi_libdir),
+ 'EFI lds directory: 
@0@'.format(efi_ldsdir),
+ 'EFI include directory: 
@0@'.format(efi_incdir)]
+--
+2.7.4
+
diff --git 
a/meta/recipes-core/systemd/systemd/0001-Revert-meson-use-an-array-option-for-efi-cc.patch
 
b/meta/recipes-core/systemd/systemd/0001-Revert-meson-use-an-array-option-for-efi-cc.patch
new file mode 100644
index 000..0d2ebf6
--- /dev/null
+++ 
b/meta/recipes-core/systemd/systemd/0001

Re: [OE-core] [PATCH] glibc-locale: Rewrite do_install using install utility instead of cp

[ChenQi]

Just to provide some feedback.
Even with this patch, this annoying QA issue is still there.
WARNING: glibc-locale-2.29-r0 do_package_qa: QA Issue: glibc-locale: 
/glibc-binary-localedata-wo-sn/usr/lib/locale/wo_SN/LC_CTYPE is owned by 
uid 1001, which is the same as the user running bitbake. This may be due 
to host contamination [host-user-contaminated]


Best Regards,
Chen Qi

On 02/07/2019 08:35 AM, Khem Raj wrote:

This has been a constant source of trouble for build failures due to 
host-user-contaminated QA
errors of sort

ERROR: QA Issue: glibc-locale: 
/glibc-binary-localedata-ca-es+valencia/usr/lib/locale/ca_ES@valencia/LC_MONETARY
 is owned by uid 3004, which is the same as the user running bitbake. This may 
be due to host contamination [host-user-contaminated]

So far we have tried to mould cp command into not carrying the build
user permissions into install area but it is never entirely fixed since
the issue keeps popping up in various scenes

This patch replaces use of cp with install utility and specifies install
mode for files explcitly

Signed-off-by: Khem Raj 
---
  meta/recipes-core/glibc/glibc-locale.inc | 44 ++--
  1 file changed, 25 insertions(+), 19 deletions(-)

diff --git a/meta/recipes-core/glibc/glibc-locale.inc 
b/meta/recipes-core/glibc/glibc-locale.inc
index 6384f9cbf1..9b256a5108 100644
--- a/meta/recipes-core/glibc/glibc-locale.inc
+++ b/meta/recipes-core/glibc/glibc-locale.inc
@@ -72,27 +72,33 @@ FILES_localedef = "${bindir}/localedef"
  LOCALETREESRC = "${COMPONENTS_DIR}/${PACKAGE_ARCH}/glibc-stash-locale"
  
  do_install () {

-   mkdir -p ${D}${bindir} ${D}${datadir}
-   if [ -n "$(ls ${LOCALETREESRC}/${bindir})" ]; then
-   cp -R --no-dereference --preserve=mode,links 
${LOCALETREESRC}/${bindir}/* ${D}${bindir}
-   fi
-   if [ -n "$(ls ${LOCALETREESRC}/${localedir})" ]; then
-   mkdir -p ${D}${localedir}
-   cp -R --no-dereference --preserve=mode,links 
${LOCALETREESRC}/${localedir}/* ${D}${localedir}
-   fi
+install -d ${D}${bindir}
+find "${LOCALETREESRC}/${bindir}" -maxdepth 1 -type f \
+-exec install -m 0755 -t "${D}${bindir}" {} \;
+
+for d in . $(find "${LOCALETREESRC}/${localedir}" -type d -printf '%P 
') ; do
+install -d "${D}${localedir}/$d"
+find "${LOCALETREESRC}/${localedir}/$d" -maxdepth 1 -type f \
+-exec install -m 0644 -t "${D}${localedir}/$d" {} \;
+done
if [ ${@d.getVar('PACKAGE_NO_GCONV')} -eq 0 ]; then
-   mkdir -p ${D}${libdir}
-   if [ -e ${LOCALETREESRC}/${libdir}/gconv ]; then
-   cp -R --no-dereference --preserve=mode,links 
${LOCALETREESRC}/${libdir}/gconv ${D}${libdir}
-   fi
-   if [ -e ${LOCALETREESRC}/${datadir}/i18n ]; then
-   cp -R --no-dereference --preserve=mode,links 
${LOCALETREESRC}/${datadir}/i18n ${D}${datadir}
-   fi
-   fi
-   if [ -e ${LOCALETREESRC}/${datadir}/locale ]; then
-   cp -R --no-dereference --preserve=mode,links 
${LOCALETREESRC}/${datadir}/locale ${D}${datadir}
+for d in . $(find "${LOCALETREESRC}/${libdir}/gconv" -type d 
-printf '%P ') ; do
+install -d "${D}${libdir}/gconv/$d"
+find "${LOCALETREESRC}/${libdir}/gconv/$d" -maxdepth 1 
-type f \
+-exec install -m 0755 -t "${D}${libdir}/gconv/$d" {} \;
+done
+for d in . $(find "${LOCALETREESRC}/${datadir}/i18n" -type d 
-printf '%P ') ; do
+install -d "${D}${datadir}/i18n/$d"
+find "${LOCALETREESRC}/${datadir}/i18n/$d" -maxdepth 1 
-type f \
+-exec install -m 0644 -t "${D}${datadir}/i18n/$d" {} \;
+done
fi
-   cp -R --no-dereference --preserve=mode,links ${LOCALETREESRC}/SUPPORTED 
${WORKDIR}
+for d in . $(find "${LOCALETREESRC}/${datadir}/locale" -type d -printf 
'%P ') ; do
+install -d "${D}${datadir}/locale/$d"
+find "${LOCALETREESRC}/${datadir}/locale/$d" -maxdepth 1 -type 
f \
+-exec install -m 0644 -t "${D}${datadir}/locale/$d" {} \;
+done
+   install -m 0644 ${LOCALETREESRC}/SUPPORTED ${WORKDIR}/SUPPORTED
  }
  
  inherit libc-package



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

Re: [OE-core] [PATCH 1/1] devtool.py: remove fetch results from download directory to avoid failure

[ChenQi]

On 01/21/2019 05:53 PM, Richard Purdie wrote:

On Mon, 2019-01-21 at 17:29 +0800, Chen Qi wrote:

The fetch results need to be removed from the download directory to
avoid
failures like below.

   Submodule path 'doxyport': checked out
'db3e1a6eb8677d3166d90d82c3068689803ce547'

   fatal: reference is not a tree:
67cad692720982ac3cbd99bf1c3421edc69b08f9
   Unable to checkout '67cad692720982ac3cbd99bf1c3421edc69b08f9' in
submodule path 'doxygen2jsdoc'

   ERROR: Function failed: base_do_unpack

I'd like to understand the problem here a bit more. My worry is that
deleting files manually from DL_DIR is bad practise, particularly if
that directory is shared between builds like on our autobuilder.

We've had similar problems with cleansstate since that can also remove
artefacts from the sstate cache which another build may be using. We
can do this only when the sstate directory is not shared.

Cheers,

Richard


I just pulled to latest master and did the tests again. Things worked 
well. This patch is not needed.
It seems that Mark's commits regarding gitsm in bitbake has fixed the 
problem I met.


Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] ✗ patchtest: failure for target-sdk-provides-dummy: add more perl modules to avoid populate_sdk failure

[ChenQi]

Is this sanity check wrong? I'm pretty sure this patch applies to poky's 
latest master branch.

BTW, I cannot find this 65c419b8c4 commit in both poky and oe-core repo.

Best Regards,
Chen Qi

On 01/10/2019 10:33 AM, Patchwork wrote:

== Series Details ==

Series: target-sdk-provides-dummy: add more perl modules to avoid populate_sdk 
failure
Revision: 1
URL   : https://patchwork.openembedded.org/series/15588/
State : failure

== Summary ==


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



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



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

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe




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

Re: [OE-core] [PATCH 1/1] netbase/base-files: move /etc/hosts from netbase to base-files

[ChenQi]

On 01/08/2019 09:00 PM, Burton, Ross wrote:

On Tue, 8 Jan 2019 at 12:47,  wrote:

Not so good if hostname isn't set?

hostname = "${MACHINE}"

Hostname is always set. :)

Its the kind of thing people likely bbappend and change, or set from
overrides. Which was one of the reasons I'm nervous about moving hosts
to a different package in the first place...

In all those situation the hostname will be set, right?  Is anyone
actually going to bbappend/override the value to ""?

Ross



We did so maybe two or three years ago, via a distro configuration file. 
We later removed this override.

Also, the original codes in base-files are:
if [ "${hostname}" ]; then
echo ${hostname} > ${D}${sysconfdir}/hostname
fi
So I just put the line in the check.

Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] netbase: add entry to /etc/hosts according to /etc/hostname

[ChenQi]

On 01/07/2019 10:38 PM, Richard Purdie wrote:

On Fri, 2018-12-14 at 21:45 +, Burton, Ross wrote:

On Fri, 30 Nov 2018 at 02:18, Chen Qi  wrote:

We default hostname to ${MACHINE}, but it's not in /etc/hosts,
resulting in commands like `hostname -f' failing due to lack
of entry.

So add entry to /etc/hosts according to /etc/hostname. We do
this via pkg_postinst because hostname is set in base-files
recipe.

RP and myself are still arguing over this so I thought I'd make my
argument on the list for debate.

Updating /etc/hosts is being done with a postinst in netbase simply
because /etc/hostname is contained in the base-files recipe. I
advocate just moving the creation of /etc/hosts to base-files along
with /etc/hostname, then base-files can write both files at the same
time.  There's already a dependency on base-files from netbase so
there will be no change in the rootfs, a file will just move between
packages.

Coming back to this after the holidays, I agree with Ross, we should
move /etc/hostname to base-files and keep this simple. I'd like to get
this fixed, could you update the patch please?

Cheers,

Richard



Yes. I'll send out a new patch.

Best Regards,

Chen Qi

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

Re: [OE-core] gdb failure on simplest hello world program -- oe-selftest

[ChenQi]

Hi All,

I've filed a bug for this issue.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13123

I could spend time to work on it, but I really don't know how to start.
Hope some experts could help or give me some advice.

Best Regards,
Chen Qi

On 12/29/2018 11:26 AM, ChenQi wrote:

On 12/29/2018 01:09 AM, Khem Raj wrote:



On 12/28/18 8:31 AM, richard.pur...@linuxfoundation.org wrote:

On Fri, 2018-12-28 at 17:49 +0800, ChenQi wrote:

On 12/26/2018 07:06 PM, richard.pur...@linuxfoundation.org wrote:

On Wed, 2018-12-26 at 10:09 +0800, ChenQi wrote:

Hi All,

'oe-selftest -r package.PackageTests.test_gdb_hardlink_debug'
fails.
I did the tests on both my Fedora27 and ubuntu16.04 servers. They
both
failed.
I can also reproduce this issue manually.

I did some investigation. No clue how to fix this it. So I want
to seek
help from community.

Below is some output from oe-selftest.
[snip]
2018-12-26 09:27:58,440 - oe-selftest - INFO -
test_gdb_hardlink_debug
(package.PackageTests)
2018-12-26 09:37:55,333 - oe-selftest - INFO - gdbtest
/usr/bin/hello1
2018-12-26 09:37:59,904 - oe-selftest - ERROR - GDB result:
1: Reading symbols from /usr/bin/hello1...Reading symbols from
/usr/bin/.debug/hello4...done.
done.
(gdb) Breakpoint 1 at 0x1060: file /usr/include/bits/stdio2.h,
line 107.
(gdb) Starting program: /usr/bin/hello1

Breakpoint 1, main () at /usr/include/bits/stdio2.h:107
107/usr/include/bits/stdio2.h: No such file or directory.
(gdb) Continuing.
Hello World!
[Inferior 1 (process 312) exited normally]
(gdb)
2018-12-26 09:38:00,907 - oe-selftest - INFO -  ... FAIL
[snip]

The hello world problem is as follows.
$ cat
meta-selftest/recipes-test/selftest-hardlink/selftest-
hardlink/hello.c
#include 

int main() {
  printf("Hello World!\n");
}

Some extra information:
1. Remove '-O2' or '-D_FORTIFY_SOURCE=2', and it works correctly.
2. Adding some system call like daemon(0,0) before printf also
works.
3. Reverting poky repo to
1c048479af7cc98e30f9a33d1f3bef03711544aa,
which adds this selftest case, does not work. It still fails.
4. Hongxu confirms that things work on his host.
5. I also don't see failure about this test case on yocto's
autobuilder.

Could somebody help to provide some suggestions?


This is strange and there must be some difference between your
configuration and what what we test on the autobuilder or on
Hongxu's
setup.

  Hi Richard,

I have talked with Hongxu and we can now both confirm that there does
exist some problem.


Which DISTRO and MACHINE are you using?

  DISTRO is poky
MACHINE is qemux86.

It seems that if MACHINE is qemux86-64, the test case could pass. But
that's just because the test case only checks 'Breakpoint 1, main ()
at hello.c:4'. See the console output below.
(gdb) b main
Breakpoint 1 at 0x1050: file /usr/include/bits/stdio2.h, line 107.
(gdb) r
Starting program: /usr/bin/hello1

Breakpoint 1, main () at hello.c:4
4printf("Hello World!\n");
(gdb) c
Continuing.
Hello World!
[Inferior 1 (process 156) exited normally]
(gdb) q

Even in this case, the 'b main' does not give correct result. The
test case passes because 'Breakpoint 1, main () at hello.c:4' is
there.

On qemux86, we have:
(gdb) Breakpoint 1 at 0x1060: file /usr/include/bits/stdio2.h, line
107.
(gdb) Starting program: /usr/bin/hello1

Breakpoint 1, main () at /usr/include/bits/stdio2.h:107
107/usr/include/bits/stdio2.h: No such file or directory.
(gdb) Continuing.
Hello World!
[Inferior 1 (process 156) exited normally]
(gdb)


I think the key to resolving this is will be to understanding how
to
reproduce it...

  Two ways to reproduce the problem:

I) reproduce it via oe-selftest
1) . oe-init-build-env build-selftest
2) SANITY_TESTED_DISTROS = ""
3) oe-selftest -r package.PackageTests.test_gdb_hardlink_debug

II) reproduce it manually
1) add meta-selftest to bblayers.conf
2) IMAGE_INSTALL_append = " selftest-hardlink selftest-hardlink-dbg
selftest-hardlink-gdb"
3) bitbake core-image-minimal
4) On target:
  gdb /usr/bin/hello1
  (gdb) b main


I confirmed I could also reproduce it. We've just been lucky with the
configuration the autobuilder tests.

I think we need to improve the test case. Does installing the libc
headers/dev package so that stdio2.h is there help?


This is not exported API so libc headers may not work but installing 
libc dev package should help here.




Hi Richard and Khem,

Unfortunately installing libc-dev package does not help.

On qemux86:
1: Reading symbols from /usr/bin/hello1...Reading symbols from 
/usr/bin/.debug/hello4...done.

done.
*(gdb) Breakpoint 1 at 0x1060: file /usr/include/bits/stdio2.h, line 107.*
(gdb) Starting program: /usr/bin/hello1

*Breakpoint 1, main () at /usr/include/bits/stdio2.h:107**
**107  return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, 
__va_arg_pack ());*

(gdb) Continuing.
Hello World

Re: [OE-core] [PATCH 0/7] systemd patches

[ChenQi]

Hi Jonas,

I'd like to talk about this patchset from a non-technical view.
And to be brief, my conclusion is suggesting using some switch, e.g. 
DISTRO_FEATURE, to control this 'stateless' behavior.

Please see details below.

This patchset is based on two assumptions:
1) Users would generally want 'stateless' system. Or in other words, 
they would prefer 'stateless' more than 'stateful'.

2) Other softwares/upstreams are also working against this 'stateless' goal.

From the current situation, both are not that true. As your [PATCH 7/7] 
points out, even systemd defaults to install things under /etc.


Cleaning up systemd's /etc files while leaving other softwares requiring 
/etc files is not that pleasant. At a minimum, systemd users who are not 
aware of this 'stateless' concept would be confused. "Where's my 
/etc/systemd/system.conf file?!" They would ask.
So I'd suggest using something like 'stateless' DISTRO_FEATURE (just 
like 'usrmerge') to control each recipe's behavior.


Best Regards,
Chen Qi

On 12/31/2018 08:05 PM, Jonas Bonn wrote:

These patches make some modifications to systemd with the long-term goal
of being able to run OE in systemd's "stateless" configuration.
"Stateless" boils down to building an image with empty /etc and /var
directories so that volatile (tmpfs) filesystems can be mounted there;
this requires that the system subsequently be able to populate these
directories dynamically, which systemd mostly takes care of if things
are done right.

In these patches:
i)Don't include machine-id in writable images so that systemd can run
its first-boot machinery
ii)   Move systemd configuration files out of /etc
iii)  Allow systemd to dynamically enable services and populate
/etc/systemd/system via the presets mechanism

There's a long way to go to get to a working "stateless" configuration.
Getting to a "volatile" system (just empty /var) should be easier and
I'll post patches moving things in that direction shortly.

/Jonas

Jonas Bonn (7):
   systemd: do not create machine-id
   systemd-conf: simplify creation of configuration
   systemd: move additional conffiles to systemd-conf
   systemd: create preset files instead of installing in image
   systemd-systemctl-native: simplify and support preset-all
   rootfs-postcommands: call preset-all for read-only-rootfs
   systemd: do not pre-enable services, rely on presets

  meta/classes/rootfs-postcommands.bbclass  |  8 
  meta/classes/systemd.bbclass  | 33 +++---
  meta/recipes-core/systemd/systemd-conf.bb | 45 +++
  .../systemd/systemd-systemctl/systemctl   | 36 +++
  meta/recipes-core/systemd/systemd_239.bb  |  4 ++
  5 files changed, 52 insertions(+), 74 deletions(-)



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

Re: [OE-core] gdb failure on simplest hello world program -- oe-selftest

[ChenQi]

On 12/29/2018 01:09 AM, Khem Raj wrote:



On 12/28/18 8:31 AM, richard.pur...@linuxfoundation.org wrote:

On Fri, 2018-12-28 at 17:49 +0800, ChenQi wrote:

On 12/26/2018 07:06 PM, richard.pur...@linuxfoundation.org wrote:

On Wed, 2018-12-26 at 10:09 +0800, ChenQi wrote:

Hi All,

'oe-selftest -r package.PackageTests.test_gdb_hardlink_debug'
fails.
I did the tests on both my Fedora27 and ubuntu16.04 servers. They
both
failed.
I can also reproduce this issue manually.

I did some investigation. No clue how to fix this it. So I want
to seek
help from community.

Below is some output from oe-selftest.
[snip]
2018-12-26 09:27:58,440 - oe-selftest - INFO -
test_gdb_hardlink_debug
(package.PackageTests)
2018-12-26 09:37:55,333 - oe-selftest - INFO - gdbtest
/usr/bin/hello1
2018-12-26 09:37:59,904 - oe-selftest - ERROR - GDB result:
1: Reading symbols from /usr/bin/hello1...Reading symbols from
/usr/bin/.debug/hello4...done.
done.
(gdb) Breakpoint 1 at 0x1060: file /usr/include/bits/stdio2.h,
line 107.
(gdb) Starting program: /usr/bin/hello1

Breakpoint 1, main () at /usr/include/bits/stdio2.h:107
107/usr/include/bits/stdio2.h: No such file or directory.
(gdb) Continuing.
Hello World!
[Inferior 1 (process 312) exited normally]
(gdb)
2018-12-26 09:38:00,907 - oe-selftest - INFO -  ... FAIL
[snip]

The hello world problem is as follows.
$ cat
meta-selftest/recipes-test/selftest-hardlink/selftest-
hardlink/hello.c
#include 

int main() {
  printf("Hello World!\n");
}

Some extra information:
1. Remove '-O2' or '-D_FORTIFY_SOURCE=2', and it works correctly.
2. Adding some system call like daemon(0,0) before printf also
works.
3. Reverting poky repo to
1c048479af7cc98e30f9a33d1f3bef03711544aa,
which adds this selftest case, does not work. It still fails.
4. Hongxu confirms that things work on his host.
5. I also don't see failure about this test case on yocto's
autobuilder.

Could somebody help to provide some suggestions?


This is strange and there must be some difference between your
configuration and what what we test on the autobuilder or on
Hongxu's
setup.

  Hi Richard,

I have talked with Hongxu and we can now both confirm that there does
exist some problem.


Which DISTRO and MACHINE are you using?

  DISTRO is poky
MACHINE is qemux86.

It seems that if MACHINE is qemux86-64, the test case could pass. But
that's just because the test case only checks 'Breakpoint 1, main ()
at hello.c:4'. See the console output below.
(gdb) b main
Breakpoint 1 at 0x1050: file /usr/include/bits/stdio2.h, line 107.
(gdb) r
Starting program: /usr/bin/hello1

Breakpoint 1, main () at hello.c:4
4printf("Hello World!\n");
(gdb) c
Continuing.
Hello World!
[Inferior 1 (process 156) exited normally]
(gdb) q

Even in this case, the 'b main' does not give correct result. The
test case passes because 'Breakpoint 1, main () at hello.c:4' is
there.

On qemux86, we have:
(gdb) Breakpoint 1 at 0x1060: file /usr/include/bits/stdio2.h, line
107.
(gdb) Starting program: /usr/bin/hello1

Breakpoint 1, main () at /usr/include/bits/stdio2.h:107
107/usr/include/bits/stdio2.h: No such file or directory.
(gdb) Continuing.
Hello World!
[Inferior 1 (process 156) exited normally]
(gdb)


I think the key to resolving this is will be to understanding how
to
reproduce it...

  Two ways to reproduce the problem:

I) reproduce it via oe-selftest
1) . oe-init-build-env build-selftest
2) SANITY_TESTED_DISTROS = ""
3) oe-selftest -r package.PackageTests.test_gdb_hardlink_debug

II) reproduce it manually
1) add meta-selftest to bblayers.conf
2) IMAGE_INSTALL_append = " selftest-hardlink selftest-hardlink-dbg
selftest-hardlink-gdb"
3) bitbake core-image-minimal
4) On target:
  gdb /usr/bin/hello1
  (gdb) b main


I confirmed I could also reproduce it. We've just been lucky with the
configuration the autobuilder tests.

I think we need to improve the test case. Does installing the libc
headers/dev package so that stdio2.h is there help?


This is not exported API so libc headers may not work but installing 
libc dev package should help here.




Hi Richard and Khem,

Unfortunately installing libc-dev package does not help.

On qemux86:
1: Reading symbols from /usr/bin/hello1...Reading symbols from 
/usr/bin/.debug/hello4...done.

done.
*(gdb) Breakpoint 1 at 0x1060: file /usr/include/bits/stdio2.h, line 107.*
(gdb) Starting program: /usr/bin/hello1

*Breakpoint 1, main () at /usr/include/bits/stdio2.h:107**
**107  return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, 
__va_arg_pack ());*

(gdb) Continuing.
Hello World!
[Inferior 1 (process 309) exited normally]
(gdb)
2018-12-29 10:58:11,538 - oe-selftest - INFO -  ... FAIL

For qemux86-64, things are the same.

Best Regards,
Chen Qi



Cheers,

Richard





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

Re: [OE-core] gdb failure on simplest hello world program -- oe-selftest

[ChenQi]

On 12/26/2018 07:06 PM, richard.pur...@linuxfoundation.org wrote:

On Wed, 2018-12-26 at 10:09 +0800, ChenQi wrote:

Hi All,

'oe-selftest -r package.PackageTests.test_gdb_hardlink_debug' fails.
I did the tests on both my Fedora27 and ubuntu16.04 servers. They both
failed.
I can also reproduce this issue manually.

I did some investigation. No clue how to fix this it. So I want to seek
help from community.

Below is some output from oe-selftest.
[snip]
2018-12-26 09:27:58,440 - oe-selftest - INFO - test_gdb_hardlink_debug
(package.PackageTests)
2018-12-26 09:37:55,333 - oe-selftest - INFO - gdbtest /usr/bin/hello1
2018-12-26 09:37:59,904 - oe-selftest - ERROR - GDB result:
1: Reading symbols from /usr/bin/hello1...Reading symbols from
/usr/bin/.debug/hello4...done.
done.
(gdb) Breakpoint 1 at 0x1060: file /usr/include/bits/stdio2.h, line 107.
(gdb) Starting program: /usr/bin/hello1

Breakpoint 1, main () at /usr/include/bits/stdio2.h:107
107/usr/include/bits/stdio2.h: No such file or directory.
(gdb) Continuing.
Hello World!
[Inferior 1 (process 312) exited normally]
(gdb)
2018-12-26 09:38:00,907 - oe-selftest - INFO -  ... FAIL
[snip]

The hello world problem is as follows.
$ cat
meta-selftest/recipes-test/selftest-hardlink/selftest-hardlink/hello.c
#include 

int main() {
  printf("Hello World!\n");
}

Some extra information:
1. Remove '-O2' or '-D_FORTIFY_SOURCE=2', and it works correctly.
2. Adding some system call like daemon(0,0) before printf also works.
3. Reverting poky repo to 1c048479af7cc98e30f9a33d1f3bef03711544aa,
which adds this selftest case, does not work. It still fails.
4. Hongxu confirms that things work on his host.
5. I also don't see failure about this test case on yocto's autobuilder.

Could somebody help to provide some suggestions?

This is strange and there must be some difference between your
configuration and what what we test on the autobuilder or on Hongxu's
setup.


Hi Richard,

I have talked with Hongxu and we can now both confirm that there does 
exist some problem.



Which DISTRO and MACHINE are you using?


DISTRO is poky
MACHINE is qemux86.

It seems that if MACHINE is qemux86-64, the test case could pass. But 
that's just because the test case only checks 'Breakpoint 1, main () at 
hello.c:4'. See the console output below.

(gdb) b main
*Breakpoint 1 at 0x1050: file /usr/include/bits/stdio2.h, line 107.*
(gdb) r
Starting program: /usr/bin/hello1

*Breakpoint 1, main () at hello.c:4*
4printf("Hello World!\n");
(gdb) c
Continuing.
Hello World!
[Inferior 1 (process 156) exited normally]
(gdb) q

Even in this case, the 'b main' does not give correct result. The test 
case passes because 'Breakpoint 1, main () at hello.c:4' is there.


On qemux86, we have:
*(gdb) Breakpoint 1 at 0x1060: file /usr/include/bits/stdio2.h, line 107.*
(gdb) Starting program: /usr/bin/hello1

*Breakpoint 1, main () at /usr/include/bits/stdio2.h:107*
107/usr/include/bits/stdio2.h: No such file or directory.
(gdb) Continuing.
Hello World!
[Inferior 1 (process 156) exited normally]
(gdb)


I think the key to resolving this is will be to understanding how to
reproduce it...


Two ways to reproduce the problem:

I) reproduce it via oe-selftest
1) . oe-init-build-env build-selftest
2) SANITY_TESTED_DISTROS = ""
3) oe-selftest -r package.PackageTests.test_gdb_hardlink_debug

II) reproduce it manually
1) add meta-selftest to bblayers.conf
2) IMAGE_INSTALL_append = " selftest-hardlink selftest-hardlink-dbg 
selftest-hardlink-gdb"

3) bitbake core-image-minimal
4) On target:
 gdb /usr/bin/hello1
 (gdb) b main

Best Regards,
Chen Qi


I think its worth investigating and figuring out...

Cheers,

Richard






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

[OE-core] gdb failure on simplest hello world program -- oe-selftest

[ChenQi]

Hi All,

'oe-selftest -r package.PackageTests.test_gdb_hardlink_debug' fails.
I did the tests on both my Fedora27 and ubuntu16.04 servers. They both 
failed.

I can also reproduce this issue manually.

I did some investigation. No clue how to fix this it. So I want to seek 
help from community.


Below is some output from oe-selftest.
[snip]
2018-12-26 09:27:58,440 - oe-selftest - INFO - test_gdb_hardlink_debug 
(package.PackageTests)

2018-12-26 09:37:55,333 - oe-selftest - INFO - gdbtest /usr/bin/hello1
2018-12-26 09:37:59,904 - oe-selftest - ERROR - GDB result:
1: Reading symbols from /usr/bin/hello1...Reading symbols from 
/usr/bin/.debug/hello4...done.

done.
(gdb) Breakpoint 1 at 0x1060: file /usr/include/bits/stdio2.h, line 107.
(gdb) Starting program: /usr/bin/hello1

Breakpoint 1, main () at /usr/include/bits/stdio2.h:107
107/usr/include/bits/stdio2.h: No such file or directory.
(gdb) Continuing.
Hello World!
[Inferior 1 (process 312) exited normally]
(gdb)
2018-12-26 09:38:00,907 - oe-selftest - INFO -  ... FAIL
[snip]

The hello world problem is as follows.
$ cat 
meta-selftest/recipes-test/selftest-hardlink/selftest-hardlink/hello.c

#include 

int main() {
printf("Hello World!\n");
}

Some extra information:
1. Remove '-O2' or '-D_FORTIFY_SOURCE=2', and it works correctly.
2. Adding some system call like daemon(0,0) before printf also works.
3. Reverting poky repo to 1c048479af7cc98e30f9a33d1f3bef03711544aa, 
which adds this selftest case, does not work. It still fails.

4. Hongxu confirms that things work on his host.
5. I also don't see failure about this test case on yocto's autobuilder.

Could somebody help to provide some suggestions?

Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 4/4] oeqa/sdk: rewrite lzip test

[ChenQi]

There's a failure related to this patch.
https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/80/steps/7/logs/step1c

Best Regards,
Chen Qi

On 12/11/2018 01:11 AM, Ross Burton wrote:

Don't use the helper class as it gets in the way more than it helps, exercise
the out-of-tree paths, and verify the installed files match the expected
architecture.

Signed-off-by: Ross Burton 
---
  meta/lib/oeqa/sdk/cases/buildlzip.py | 46 +---
  1 file changed, 16 insertions(+), 30 deletions(-)

diff --git a/meta/lib/oeqa/sdk/cases/buildlzip.py 
b/meta/lib/oeqa/sdk/cases/buildlzip.py
index b57fbbece7f..d98e10fc37f 100644
--- a/meta/lib/oeqa/sdk/cases/buildlzip.py
+++ b/meta/lib/oeqa/sdk/cases/buildlzip.py
@@ -1,39 +1,25 @@
-import unittest
+import os, tempfile, subprocess, unittest
  from oeqa.sdk.case import OESDKTestCase
-from oeqa.sdk.utils.sdkbuildproject import SDKBuildProject
-
  from oeqa.utils.subprocesstweak import errors_have_output
  errors_have_output()
  
  class BuildLzipTest(OESDKTestCase):

-td_vars = ['DATETIME']
-
-@classmethod
-def setUpClass(self):
-dl_dir = self.td.get('DL_DIR', None)
-
-self.project = SDKBuildProject(self.tc.sdk_dir + "/lzip/", 
self.tc.sdk_env,
-
"http://downloads.yoctoproject.org/mirror/sources/lzip-1.19.tar.gz";,
-self.tc.sdk_dir, self.td['DATETIME'], dl_dir=dl_dir)
-self.project.download_archive()
-
-def setUp(self):
-machine = self.td.get("MACHINE")
-
-if not (self.tc.hasHostPackage("packagegroup-cross-canadian-%s" % 
machine) or
-self.tc.hasHostPackage("^gcc-", regex=True)):
-raise unittest.SkipTest("SDK doesn't contain a cross-canadian 
toolchain")
-
  def test_lzip(self):
-self.assertEqual(self.project.run_configure(), 0,
-msg="Running configure failed")
+with tempfile.TemporaryDirectory(prefix="lzip", dir=self.tc.sdk_dir) 
as testdir:
+dl_dir = self.td.get('DL_DIR', None)
+tarball = self.fetch(testdir, dl_dir, 
"http://downloads.yoctoproject.org/mirror/sources/lzip-1.19.tar.gz";)
+
+dirs = {}
+dirs["source"] = os.path.join(testdir, "lzip-1.19")
+dirs["build"] = os.path.join(testdir, "build")
+dirs["install"] = os.path.join(testdir, "install")
  
-self.assertEqual(self.project.run_make(), 0,

-msg="Running make failed")
+subprocess.check_output(["tar", "xf", tarball, "-C", testdir])
+self.assertTrue(os.path.isdir(dirs["source"]))
+os.makedirs(dirs["build"])
  
-self.assertEqual(self.project.run_install(), 0,

-msg="Running make install failed")
+self._run("cd {build} && {source}/configure --srcdir {source} 
$CONFIGURE_FLAGS".format(**dirs))
+self._run("cd {build} && make -j".format(**dirs))
+self._run("cd {build} && make install 
DESTDIR={install}".format(**dirs))
  
-@classmethod

-def tearDownClass(self):
-self.project.clean()
+self.check_elf(os.path.join(dirs["install"], "usr", "local", "bin", 
"lzip"))



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

Re: [OE-core] [PATCH 1/1] oeqa: drop support of listing machines in QEMU_USE_KVM

[ChenQi]

On 12/07/2018 07:02 PM, Richard Purdie wrote:

On Thu, 2018-12-06 at 14:30 +0800, Chen Qi wrote:

We want QEMU_USE_KVM to only set to some boolean value, with possible
MACHINE override. Drop the support of listing machines in this variable,
and give users error message if they still do so.

Error message below is an example.

ERROR: core-image-minimal-1.0-r0 do_testimage: Invalid boolean value 
'intel-corei7-64 intel-core2-32 qemux86 qemux86-64'
QEMU_USE_KVM needs to be set to a boolean value. It no longer supports 
accepting a list of machines.
   e.g.
   QEMU_USE_KVM_qemux86-64 = '1'
ERROR: core-image-minimal-1.0-r0 do_testimage: Function failed: do_testimage

QB_CPU_KVM is also checked to determine whether to enable kvm.

Signed-off-by: Chen Qi 
---
  meta/classes/testimage.bbclass | 12 +++-
  meta/lib/oeqa/targetcontrol.py | 12 +++-
  2 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index 82cbb06..3353d133 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -229,11 +229,13 @@ def testimage_main(d):
  
  # Get use_kvm

  qemu_use_kvm = d.getVar("QEMU_USE_KVM")
-if qemu_use_kvm and \
-   (d.getVar('MACHINE') in qemu_use_kvm.split() or \
-oe.types.boolean(qemu_use_kvm) and 'x86' in machine):
-kvm = True
-else:
+try:
+kvm = oe.types.boolean(qemu_use_kvm)
+except ValueError as e:
+bb.fatal("%s\nQEMU_USE_KVM needs to be set to a boolean value. It no longer 
supports accepting a list of machines.\n"
+ "  e.g.\n"
+ "  QEMU_USE_KVM_qemux86-64 = '1'" % e)
+if kvm and not d.getVar('QB_CPU_KVM'):
  kvm = False
  
  slirp = False

diff --git a/meta/lib/oeqa/targetcontrol.py b/meta/lib/oeqa/targetcontrol.py
index 59a9c35..d21823b 100644
--- a/meta/lib/oeqa/targetcontrol.py
+++ b/meta/lib/oeqa/targetcontrol.py
@@ -108,11 +108,13 @@ class QemuTarget(BaseTarget):
  dump_host_cmds = d.getVar("testimage_dump_host")
  dump_dir = d.getVar("TESTIMAGE_DUMP_DIR")
  qemu_use_kvm = d.getVar("QEMU_USE_KVM")
-if qemu_use_kvm and \
-   (oe.types.boolean(qemu_use_kvm) and "x86" in d.getVar("MACHINE") or 
\
-d.getVar("MACHINE") in qemu_use_kvm.split()):
-use_kvm = True
-else:
+try:
+use_kvm = oe.types.boolean(qemu_use_kvm)
+except ValueError as e:
+bb.fatal("%s\nQEMU_USE_KVM needs to be set to a boolean value. It no 
longer supports accepting a list of machines.\n"
+ "  e.g.\n"
+ "  QEMU_USE_KVM_qemux86-64 = '1'" % e)
+if use_kvm and not d.getVar('QB_CPU_KVM'):
  use_kvm = False
  
  # Log QemuRunner log output to a file

Unfortunately this still isn't going to work quite as I mentioned.

We've about to add an aarch64 server to our autobuilder infrastructure.
We need that to use kvm for arm targets but not x86 ones yet have x86
targets use kvm on x86 hardware too.

I appreciate that isn't how the code works now but we may as well fix
this properly once and for all.

Cheers,

Richard





How about setting QB_CPU_KVM to something like 
${@bb.utils.contains('BUILD_ARCH', 'x86_64', '-cpu core2duo', '', d)}?
In this way, we are actually doing BUILD_ARCH and TARGET_ARCH match 
manually, as we are setting QB_CPU_KVM in different conf files like 
qemuboot-x86.inc, qemuboot-intel.inc, which contain target information 
in their names.
When aarch64 server is supported, qemuarm and qemuarm64's configuration 
files could also be modified to add QB_CPU_KVM.


I'm thinking about a general matching function to check BUILD_ARCH and 
TARGET_ARCH, and getting rid of QB_CPU_KVM. But when checking 
qemuboot-intel.inc, I found the '-cpu' option is not the same when 
enabling and disabling kvm.

QB_CPU_intel-core2-32 = "-cpu coreduo"
QB_CPU_KVM_intel-core2-32 = "-cpu kvm32"

So it seems QB_CPU_KVM is still needed. One step further, if it's still 
needed, we could set it properly, doing arch matching manually.


Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] util-linux: split out blkdiscard into its own package

[ChenQi]

I think this is a good idea. I opened a new bug in bugzilla to track it, 
and assigned it to myself.

Ross, please check the bug description to see if that's what you want.
Andre, if you want to work on it, take the bug and let me know.

Best Regards,
Chen Qi

On 12/04/2018 12:40 AM, Burton, Ross wrote:

When do we just programatically split instead of doing it piece by piece? :)

Ross
On Mon, 3 Dec 2018 at 15:28, André Draszik  wrote:

From: André Draszik 

For systems that don't otherwise depend on the full
util-linux package, blkdiscard is a mere 18k (on
cortexa7t2hf-neon).

Signed-off-by: André Draszik 
---
  meta/recipes-core/util-linux/util-linux.inc | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index a05c1cabbe..b5f77f7b6b 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -27,7 +27,7 @@ DEPENDS_append_class-nativesdk = " lzo-native"
  SRC_URI = 
"${KERNELORG_MIRROR}/linux/utils/util-linux/v${MAJOR_VERSION}/util-linux-${PV}.tar.xz
 \
 "

-PACKAGES =+ "util-linux-agetty util-linux-fdisk util-linux-cfdisk 
util-linux-sfdisk \
+PACKAGES =+ "util-linux-agetty util-linux-blkdiscard util-linux-fdisk 
util-linux-cfdisk util-linux-sfdisk \
   util-linux-swaponoff util-linux-losetup util-linux-umount \
   util-linux-mount util-linux-readprofile util-linux-uuidd \
   util-linux-uuidgen util-linux-lscpu util-linux-fsck.cramfs 
util-linux-fsck \
@@ -74,6 +74,7 @@ FILES_${PN}-doc += "${datadir}/getopt/getopt-*.*"
  FILES_${PN}-dev += "${PYTHON_SITEPACKAGES_DIR}/libmount/pylibmount.la"

  FILES_util-linux-agetty = "${base_sbindir}/agetty"
+FILES_util-linux-blkdiscard = "${sbindir}/blkdiscard"
  FILES_util-linux-fdisk = "${base_sbindir}/fdisk.${BPN}"
  FILES_util-linux-fstrim = "${base_sbindir}/fstrim.${BPN}"
  FILES_util-linux-cfdisk = "${base_sbindir}/cfdisk"
@@ -126,7 +127,7 @@ RDEPENDS_util-linux-su += "libpam"
  RDEPENDS_${PN} = "util-linux-umount util-linux-swaponoff util-linux-losetup 
util-linux-sulogin util-linux-lsblk"
  RDEPENDS_${PN} += "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 
'util-linux-runuser util-linux-su', '', d)}"

-RRECOMMENDS_${PN} = "util-linux-fdisk util-linux-cfdisk util-linux-sfdisk 
util-linux-mount util-linux-readprofile util-linux-mkfs util-linux-mountpoint 
util-linux-prlimit util-linux-ionice util-linux-switch-root"
+RRECOMMENDS_${PN} = "util-linux-blkdiscard util-linux-fdisk util-linux-cfdisk 
util-linux-sfdisk util-linux-mount util-linux-readprofile util-linux-mkfs 
util-linux-mountpoint util-linux-prlimit util-linux-ionice util-linux-switch-root"

  RRECOMMENDS_${PN}_class-native = ""
  RRECOMMENDS_${PN}_class-nativesdk = ""
--
2.20.0.rc1

--
___
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] [PATCH 6/8] busybox: remove three hostname test cases

[ChenQi]

On 11/21/2018 08:16 PM, Burton, Ross wrote:

On Wed, 21 Nov 2018 at 05:35, Chen Qi  wrote:

These three test case are removed because of two reasons.
1) net-tools' hostname have different behaviour regarding some options
So when net-tools is installed, test cases may fail.
e.g.
test x$(hostname -i) = x$(busybox hostname -i)

This is just a specific instance of the problem where alternatives may
not be what you want.  The busybox test suite should be sure it's
running busybox tools.  Having spoken to a few people about this
already, maybe busybox-ptest should contain a symlink farm for all the
applets to the busybox binary that run-ptest can put at the front of
$PATH.


Very good idea! I'll try this out.


2) hostname may set to some value, e.g. qemux86-64, which is not an entry in 
/etc/hosts
This results in lookup failure when using `hostname -f' as there's no entry 
in /etc/hosts.

Let's fix the hostname setup so hosts is correct too.


OK.
Currently, we set hostname to ${MACHINE}. To ensure it's also an entry 
in /etc/hosts, it seems that we have to default it to 'localhost'. I'm 
going to test with this change. If you have other candidates, please let 
me know.


Best Regards,
Chen Qi


Ross



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

Re: [OE-core] [PATCH 5/8] busybox: use example.org instead of google.com in wget test case

[ChenQi]

On 11/16/2018 01:43 AM, Burton, Ross wrote:

On Thu, 15 Nov 2018 at 01:57, Chen Qi  wrote:

Use example.org to ensure it's always reachible.

Is this because of China's firewall?  You'd think that google.com
would have excellent uptime.

Ross



I guess so.
I agree that google.com has excellent uptime. However, I think 
example.org might be better for ptest.


Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 8/8] busybox: add coreutils to RDEPENDS of busybox-ptest

[ChenQi]

On 11/15/2018 05:23 PM, Richard Purdie wrote:

On Thu, 2018-11-15 at 10:02 +0800, Chen Qi wrote:

busybox's echo test cases needs 'od' command to have '-t' option
support. However, our busybox disable it by default by not setting
CONFIG_DESKTOP. CONFIG_DESKTOP affects many busybox utilities. So
add coreutils to RDEPENDS of busybox-ptest.

Signed-off-by: Chen Qi 
---
  meta/recipes-core/busybox/busybox.inc | 3 +++
  1 file changed, 3 insertions(+)

This means any build of busybox will now also build coreutils which
isn't really desirable.

If there any way to just enable the -t option to od without all the
other changes? Has this been mentioned to upstream busybox?

Cheers,

Richard




The current busybox codes are:
[snip]
#include "libbb.h"
#if ENABLE_DESKTOP
/* This one provides -t (busybox's own build script needs it) */
#include "od_bloaty.c"
#else
[snip]

So there's currently no way to just enable '-t' for 'od' without 
affecting other utilities.
I'll check with busybox upstream to see why they do so and if we could 
do some change.


Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] oeqa/runtime: Add tests for gstreamer CLI

[ChenQi]

Hi Peng,

Does it require some gstreamer packages to be available on target?
Maybe some @OEHasPackage decorator needs to be added?

Best Regards,
Chen Qi

On 11/08/2018 04:02 PM, Yeoh Ee Peng wrote:

We should not be finding GStreamer issues right around
release time but that's what we seem to do.

Port gstreamer tests from Intel Ref Kit.
https://github.com/intel/intel-iot-refkit/blob/master/meta-iotqa/
lib/oeqa/runtime/multimedia/gstreamer/gstreamer_cli.py

Add tests for gstreamer commandline tools (gst-inspect-1.0
& gst-launch-1.0).

[YOCTO #11418]

Signed-off-by: Yeoh Ee Peng 
---
  meta/lib/oeqa/runtime/cases/gstreamer.py | 11 +++
  1 file changed, 11 insertions(+)
  create mode 100644 meta/lib/oeqa/runtime/cases/gstreamer.py

diff --git a/meta/lib/oeqa/runtime/cases/gstreamer.py 
b/meta/lib/oeqa/runtime/cases/gstreamer.py
new file mode 100644
index 000..3adeeb5
--- /dev/null
+++ b/meta/lib/oeqa/runtime/cases/gstreamer.py
@@ -0,0 +1,11 @@
+from oeqa.runtime.case import OERuntimeTestCase
+
+class GstreamerCliTest(OERuntimeTestCase):
+
+def test_gst_inspect_can_list_all_plugins(self):
+status, output = self.target.run('gst-inspect-1.0')
+self.assertEqual(status, 0, 'gst-inspect-1.0 does not appear to be 
running.')
+
+def test_gst_launch_can_create_video_pipeline(self):
+status, output = self.target.run('gst-launch-1.0 -v fakesrc 
silent=false num-buffers=3 ! fakesink silent=false')
+self.assertEqual(status, 0, 'gst-launch-1.0 does not appear to be 
running.')



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

Re: [OE-core] [PATCH] ghostscript: Define COMPATIBLE_HOST with supported platforms

[ChenQi]

This patch causes the following failure on autobuilder.
https://autobuilder.yoctoproject.org/typhoon/#/builders/32/builds/183/steps/7/logs/step1c

Best Regards,
Chen Qi

On 11/07/2018 04:47 PM, Nathan Rossi wrote:

Setup the COMPATIBLE_HOST variable with all supported hosts based on the
provided objarch.h files. This inverts the existing pattern where
unsupported hosts (e.g. 'arc.*') are explicitly set.

This suppresses the warning message generated on hosts that are not
supported but were not listed explicitly.

   WARNING: .../ghostscript_9.25.bb: Unable to get checksum for
   ghostscript SRC_URI entry objarch.h: file could not be found

Signed-off-by: Nathan Rossi 
---
  meta/recipes-extended/ghostscript/ghostscript_9.25.bb | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/recipes-extended/ghostscript/ghostscript_9.25.bb 
b/meta/recipes-extended/ghostscript/ghostscript_9.25.bb
index 35eaaeb2fa..8b69170458 100644
--- a/meta/recipes-extended/ghostscript/ghostscript_9.25.bb
+++ b/meta/recipes-extended/ghostscript/ghostscript_9.25.bb
@@ -121,5 +121,4 @@ do_install_class-native () {
  
  BBCLASSEXTEND = "native"
  
-# ghostscript does not supports "arc"

-COMPATIBLE_HOST = "^(?!arc).*"
+COMPATIBLE_HOST = 
"(aarch64|arm|i586|i686|microblaze|mipsarch|nios2|powerpc|x86-64).*"
---
2.19.1



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

Re: [OE-core] [PATCH] shadow: improve reproducibility by hard-coding shell path

[ChenQi]

On 11/07/2018 04:00 PM, Martin Hundebøll wrote:

The shadow configure script tries really hard to detect the running
shell to make sure it doesn't do unsupported calls.

On my system the shell is detected as /bin/sh, while a build in an
ubuntu docker it resolves to /bin/bash. And since the shell path is
baked into the target binaries through config.h, the build becomes
inreproducible.

Fix reproducibility by hard-coding the shell to be /bin/bash

Signed-off-by: Martin Hundebøll 
---

I wasn't whether to use /bin/bash or /bin/sh; comments are welcome...

  meta/recipes-extended/shadow/shadow.inc | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/meta/recipes-extended/shadow/shadow.inc 
b/meta/recipes-extended/shadow/shadow.inc
index 0fa80a282a..8eacca6809 100644
--- a/meta/recipes-extended/shadow/shadow.inc
+++ b/meta/recipes-extended/shadow/shadow.inc
@@ -45,6 +45,8 @@ PAM_SRC_URI = "file://pam.d/chfn \
  
  inherit autotools gettext
  
+export CONFIG_SHELL="/bin/bash"

+
  EXTRA_OECONF += "--without-audit \
   --without-libcrack \
   --without-selinux \


I'd suggest we use '/bin/sh', as long as it does not bring in any problem.

I noticed that the recipe has substitution in do_install.
sed -i 's:/bin/bash:/bin/sh:g' ${D}${sysconfdir}/default/useradd

Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] ✗ patchtest: failure for systemd: backport patches to fix 3 CVEs (rev2)

[ChenQi]

Hi All,

I finally found out the problem. I think the cve tag checking logic in 
patchtest-oe has some problem.


The current logic errors out if and only if the patch has a line which 
begins with 'CVE--' and contains nothing else. It does not error 
out if the patch contains no CVE information, nor will it error out if 
the patch contains line like ' CVE--' (spaces followed by cve 
id). What's worse, if the backported patch itself contains a line 
'CVE--', this cve tag checking code errors out, and this is the 
error I got in this patch.


I've sent out a patch to yocto to fix this issue.
Title is: [yocto] [patchtest-oe][PATCH] test_patch_cve.py: fix cve tag 
checking logic


Do you think I need to tweak the patches according to the current cve 
tag checking rule and send out V3?


Best Regards,
Chen Qi

On 11/02/2018 01:03 PM, Patchwork wrote:

== Series Details ==

Series: systemd: backport patches to fix 3 CVEs (rev2)
Revision: 2
URL   : https://patchwork.openembedded.org/series/14759/
State : failure

== Summary ==


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



* Patch[1/3] systemd: fix CVE-2018-15686
  Issue Missing or incorrectly formatted CVE tag in included patch 
file [test_cve_tag_format]
   Suggested fixCorrect or include the CVE tag on cve patch with format: "CVE: 
CVE--"



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

---
Guidelines: 
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe




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

Re: [OE-core] [PATCH 1/2] go: Upgrade to 1.11.1

[ChenQi]

Hi Khem,

This patch seems to cause do_compile_ptest_base failure for go-dep 
recipe on qemumips and qemumips64.


Reproduce steps:
1. ensure ptest is in distro features
2. MACHINE=qemumips64 bitbake go-dep

I tried to look into the failure but I really do not know much about go.
Could you please help look into the issue when convenient?

Best Regards,
Chen Qi

On 10/19/2018 09:31 AM, Khem Raj wrote:

Drop 1.10 recipes in favor of 1.11
we have had reports of 1.10 not being quite
functional wth OE

Signed-off-by: Khem Raj 
---
  ...-to-be-overridden-in-the-environment.patch | 64 --
  ...-arm64-fix-branch-too-far-with-TBZ-l.patch | 58 
  .../go/{go-1.10.inc => go-1.11.inc}   |  9 ++-
  ...ow-CC-and-CXX-to-have-multiple-words.patch | 12 ++--
  ...ent-based-hash-generation-less-pedan.patch | 46 ++---
  ...-to-be-overridden-in-the-environment.patch | 48 +
  ...4-ld-add-soname-to-shareable-objects.patch | 16 ++---
  ...de-CC-when-building-dist-and-go_boot.patch | 15 ++---
  ...dist-separate-host-and-target-builds.patch | 67 ++-
  ...d-go-make-GOROOT-precious-by-default.patch | 50 +++---
  ...place-glibc-dynamic-linker-with-musl.patch | 24 +++
  ...dian_1.10.bb => go-cross-canadian_1.11.bb} |  0
  .../go/{go-cross_1.10.bb => go-cross_1.11.bb} |  0
  ...o-crosssdk_1.10.bb => go-crosssdk_1.11.bb} |  0
  .../{go-native_1.10.bb => go-native_1.11.bb}  |  0
  ...{go-runtime_1.10.bb => go-runtime_1.11.bb} |  0
  .../go/{go_1.10.bb => go_1.11.bb} |  0
  17 files changed, 163 insertions(+), 246 deletions(-)
  delete mode 100644 
meta/recipes-devtools/go/go-1.10/0003-allow-GOTOOLDIR-to-be-overridden-in-the-environment.patch
  delete mode 100644 
meta/recipes-devtools/go/go-1.10/0008-cmd-internal-obj-arm64-fix-branch-too-far-with-TBZ-l.patch
  rename meta/recipes-devtools/go/{go-1.10.inc => go-1.11.inc} (74%)
  rename meta/recipes-devtools/go/{go-1.10 => 
go-1.11}/0001-allow-CC-and-CXX-to-have-multiple-words.patch (79%)
  rename meta/recipes-devtools/go/{go-1.10 => 
go-1.11}/0002-cmd-go-make-content-based-hash-generation-less-pedan.patch (85%)
  create mode 100644 
meta/recipes-devtools/go/go-1.11/0003-allow-GOTOOLDIR-to-be-overridden-in-the-environment.patch
  rename meta/recipes-devtools/go/{go-1.10 => 
go-1.11}/0004-ld-add-soname-to-shareable-objects.patch (79%)
  rename meta/recipes-devtools/go/{go-1.10 => 
go-1.11}/0005-make.bash-override-CC-when-building-dist-and-go_boot.patch (80%)
  rename meta/recipes-devtools/go/{go-1.10 => 
go-1.11}/0006-cmd-dist-separate-host-and-target-builds.patch (88%)
  rename meta/recipes-devtools/go/{go-1.10 => 
go-1.11}/0007-cmd-go-make-GOROOT-precious-by-default.patch (64%)
  rename meta/recipes-devtools/go/{go-1.10 => 
go-1.11}/0009-ld-replace-glibc-dynamic-linker-with-musl.patch (91%)
  rename meta/recipes-devtools/go/{go-cross-canadian_1.10.bb => 
go-cross-canadian_1.11.bb} (100%)
  rename meta/recipes-devtools/go/{go-cross_1.10.bb => go-cross_1.11.bb} (100%)
  rename meta/recipes-devtools/go/{go-crosssdk_1.10.bb => go-crosssdk_1.11.bb} 
(100%)
  rename meta/recipes-devtools/go/{go-native_1.10.bb => go-native_1.11.bb} 
(100%)
  rename meta/recipes-devtools/go/{go-runtime_1.10.bb => go-runtime_1.11.bb} 
(100%)
  rename meta/recipes-devtools/go/{go_1.10.bb => go_1.11.bb} (100%)

diff --git 
a/meta/recipes-devtools/go/go-1.10/0003-allow-GOTOOLDIR-to-be-overridden-in-the-environment.patch
 
b/meta/recipes-devtools/go/go-1.10/0003-allow-GOTOOLDIR-to-be-overridden-in-the-environment.patch
deleted file mode 100644
index 818fe66700..00
--- 
a/meta/recipes-devtools/go/go-1.10/0003-allow-GOTOOLDIR-to-be-overridden-in-the-environment.patch
+++ /dev/null
@@ -1,64 +0,0 @@
-From acd179b49f1fc8d6f7f69e569fb4a56039c725a1 Mon Sep 17 00:00:00 2001
-From: Matt Madison 
-Date: Sat, 17 Feb 2018 05:24:20 -0800
-Subject: [PATCH 3/9] allow GOTOOLDIR to be overridden in the environment
-
-to allow for split host/target build roots
-
-Upstream-Status: Inappropriate [OE specific]
-
-Signed-off-by: Matt Madison 

- src/cmd/dist/build.go  | 4 +++-
- src/cmd/go/internal/cfg/cfg.go | 6 +-
- src/go/build/build.go  | 2 +-
- 3 files changed, 9 insertions(+), 3 deletions(-)
-
-diff --git a/src/cmd/dist/build.go b/src/cmd/dist/build.go
-index 49ed80033e..afc615b5c2 100644
 a/src/cmd/dist/build.go
-+++ b/src/cmd/dist/build.go
-@@ -220,7 +220,9 @@ func xinit() {
-   workdir = xworkdir()
-   xatexit(rmworkdir)
-
--  tooldir = pathf("%s/pkg/tool/%s_%s", goroot, gohostos, gohostarch)
-+  if tooldir = os.Getenv("GOTOOLDIR"); tooldir == "" {
-+  tooldir = pathf("%s/pkg/tool/%s_%s", goroot, gohostos, 
gohostarch)
-+  }
- }
-
- // compilerEnv returns a map from "goos/goarch" to the
-diff --git a/src/cmd/go/internal/cfg/cfg.go b/src/cmd/go/internal/cfg/cfg.go
-index 1de4f0dc79..4f6010d660 100644
 a/src/cmd/go/internal/cfg/cfg.go
-+++ b/src/cmd/go/internal/cfg/

Re: [OE-core] [meta-python][PATCHV2] Add recipes for django rest framework

[ChenQi]

Hi Joris,

I think this patch should be sent to 
openembedded-de...@lists.openembedded.org
Title should be "[oe][meta-python][PATCH] Add recipes for django rest 
framework"


Best Regards,
Chen Qi

On 10/26/2018 03:54 PM, Joris Offouga wrote:

For create a database with django

Signed-off-by: Joris Offouga 
---
  .../python/python-djangorestframework.inc| 16 
  .../python/python-djangorestframework_3.9.0.bb   |  2 ++
  .../python/python3-djangorestframework_3.9.0.bb  |  2 ++
  3 files changed, 20 insertions(+)
  create mode 100644 
meta-python/recipes-devtools/python/python-djangorestframework.inc
  create mode 100644 
meta-python/recipes-devtools/python/python-djangorestframework_3.9.0.bb
  create mode 100644 
meta-python/recipes-devtools/python/python3-djangorestframework_3.9.0.bb

diff --git a/meta-python/recipes-devtools/python/python-djangorestframework.inc 
b/meta-python/recipes-devtools/python/python-djangorestframework.inc
new file mode 100644
index 000..8551a83
--- /dev/null
+++ b/meta-python/recipes-devtools/python/python-djangorestframework.inc
@@ -0,0 +1,16 @@
+SUMMARY =  "djangorestframework"
+DESCRIPTION = "pip3 install djangorestframework"
+HOMEPAGE = "https://pypi.python.org/pypi/djangorestframework";
+
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://LICENSE.md;md5=7879a5a716147a784f7e524c9cf103c1"
+
+SRC_URI[md5sum] = "0d481bf8dbb87bb927b46798edc1a9bd"
+SRC_URI[sha256sum] = 
"607865b0bb1598b153793892101d881466bd5a991de12bd6229abb18b1c86136"
+PYPI_PACKAGE = "djangorestframework"
+
+inherit pypi
+
+RDEPENDS_${PN} += "\
+${PYTHON_PN}-django \
+"
\ No newline at end of file
diff --git 
a/meta-python/recipes-devtools/python/python-djangorestframework_3.9.0.bb 
b/meta-python/recipes-devtools/python/python-djangorestframework_3.9.0.bb
new file mode 100644
index 000..540d12d
--- /dev/null
+++ b/meta-python/recipes-devtools/python/python-djangorestframework_3.9.0.bb
@@ -0,0 +1,2 @@
+require python-djangorestframework.inc
+inherit setuptools
\ No newline at end of file
diff --git 
a/meta-python/recipes-devtools/python/python3-djangorestframework_3.9.0.bb 
b/meta-python/recipes-devtools/python/python3-djangorestframework_3.9.0.bb
new file mode 100644
index 000..9ed6d17
--- /dev/null
+++ b/meta-python/recipes-devtools/python/python3-djangorestframework_3.9.0.bb
@@ -0,0 +1,2 @@
+require python-djangorestframework.inc
+inherit setuptools3
\ No newline at end of file



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

Re: [OE-core] [PATCH] sysklogd: add alternatives for klogd and syslogd

[ChenQi]

On 10/26/2018 12:53 PM, Victor Kamensky via Openembedded-core wrote:

Otherwise when used in presense of busybox that provides
its own version of klogd and syslogd, image packaging
complains that klogd exists and it is not syymbolic link.
Failure happens only if image packaging script install
sysklogd package first followed by installtion of busybox
package.


Hi Victor,

I think this problem has been fixed by the following commit.

"""
commit ef11c54ba99af261a70ec31091216cdd1556da24
Author: Richard Purdie 
Date:   Wed Sep 5 17:39:31 2018 +0100

busybox: Put klogd/syslogd alternative links in syslog package

Currently these are in ${PN} and ${PN}-syslog may get replaced by
other packages but update-alternatives would error in the postinst
if other files were installed first. Avoid the problems by putting
the links in the correct package.

Signed-off-by: Richard Purdie 
"""

For the current status, the update-alternatives operations for syslogd 
and klogd should be in the busybox-syslog package, which conflicts with 
sysklogd package.


Could you please help check this?

Best Regards,
Chen Qi


  If during packaging reverse installtion order
happens, busybox first followed by sysklogd, packaging
succeed.

Note this fix along with recently committed
55ba9dc1f8 sysklogd: Re-enable alternatives for syslogd.8 man page
effectively reverts this commit
988aad01b2 sysklogd: don't use update-alternatives

Signed-off-by: Victor Kamensky 
---
Hi Guys,

Here is more details. Example of failure that I observe:

update-alternatives: Error: not linking 
/home/wd8/oe/20181021/build/tmp-glibc/work/intel_corei7_64-oe-linux/kdevel-console-devel-image/1.0-r0/rootfs/sbin/klogd
 to /usr/lib/busybox/sbin/klogd since 
/home/wd8/oe/20181021/build/tmp-glibc/work/intel_corei7_64-oe-linux/kdevel-console-devel-image/1.0-r0/rootfs/sbin/klogd
 exists and is not a link

Also 988aad01b2 says:


Using update-alternatives for managing init scripts has proved to be
problematic. And, sysklogd rconflicts with other syslog daemons so there
is no point in using update-alternatives from this perspective, either.

I am not sure why "managing init scripts has proved to be problematic" and
syslogd and klogd are not really init script per se, aren't they? Also
klogd and syslogd actually come from busybox, not busybox-syslog as listed
in sysklogd RCONFLICTS. Maybe it what has changed since 988aad01b2.
busybox-syslog now contains only init script for syslog and its
configuration.

Adding Markus for further comments.

  meta/recipes-extended/sysklogd/sysklogd.inc | 5 +
  1 file changed, 5 insertions(+)

diff --git a/meta/recipes-extended/sysklogd/sysklogd.inc 
b/meta/recipes-extended/sysklogd/sysklogd.inc
index f151dd87f7..4393a39180 100644
--- a/meta/recipes-extended/sysklogd/sysklogd.inc
+++ b/meta/recipes-extended/sysklogd/sysklogd.inc
@@ -60,9 +60,14 @@ FILES_${PN} += 
"${@bb.utils.contains('DISTRO_FEATURES','systemd','${exec_prefix}
  
  ALTERNATIVE_PRIORITY = "100"
  
+ALTERNATIVE_${PN} = "syslogd klogd"

+
  ALTERNATIVE_${PN}-doc = "syslogd.8"
  ALTERNATIVE_LINK_NAME[syslogd.8] = "${mandir}/man8/syslogd.8"
  
+ALTERNATIVE_LINK_NAME[syslogd] = "${base_sbindir}/syslogd"

+ALTERNATIVE_LINK_NAME[klogd] = "${base_sbindir}/klogd"
+
  pkg_prerm_${PN} () {
if test "x$D" = "x"; then
if test "$1" = "upgrade" -o "$1" = "remove"; then



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

[OE-core] About uninative-tarball update

[ChenQi]

Hi Richard,

We recently got the following warning when building on ubuntu 18.10.

 WARNING: Your host glibc verson (2.28) is newer than that
 in uninative (2.27). Disabling uninative so that sstate is
 not corrupted.

I checked the official uninative tarball on 
http://downloads.yoctoproject.org/releases/uninative/2.2/.

And yes it's using 2.27.

Our glibc has been updated to 2.28. Is there some plan about the 
official uninative-tarball update?


Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] systemd: add back alternatives for init utitilies

[ChenQi]

On 10/24/2018 05:48 AM, Richard Purdie wrote:

On Mon, 2018-10-22 at 15:03 +0800, Chen Qi wrote:

Add back alternatives for init utilities to avoid regression.

These alternatives were removed when upgradeing systemd to 239.
They were removed out of the logic that init utitilies should be
bound to init manager. However, it turned out that two use cases
were not covered.

1) initramfs using commands like 'reboot' from busybox.
2) Users use customized busybox defconfig which enables init
utilities.

The first use case caused a regression bug in yocto.
   https://bugzilla.yoctoproject.org/show_bug.cgi?id=12914
Patches were sent to fix the reboot problem.

But this is not enough. As we may have the second use case. In such
situation, users will find themselves having regression error when
using 'busybox + systemd' (and busybox is installed after systemd,
overriding the systemd symlinks).

So in order to avoid regression, add back these alternatives.

Signed-off-by: Chen Qi 

Sorry but this is still failing:


https://autobuilder.yoctoproject.org/typhoon/#/builders/35/builds/107/steps/7/logs/step7c

Cheers,

Richard



Hi Richard,

The failure is revealed by Kevin's patches regarding udev-extraconf. 
More particularly, it's the following patch that reveals the problem.

"udev-extraconf: Use the canonical file name of systemd"

I've sent out a patch to remove udev-extraconf from 
packagegroup-core-lsb/-x11-sato to fix this failure.
I tested 'testimage + core-image-sato/lsb' with the following 5 patches 
(3 from Kevin which are now on master-next, 2 from me) with master 
branch, and the tests passed.

 packagegroup-core-lsb/-x11-sato: no udev-extraconf in case of systemd
 systemd: add back alternatives for init utitilies
 udev-extraconf: Skip the entry in /etc/fstab when using the systemd-mount
 udev-extraconf: Fix the recursively dependency for the systemd-mount
 udev-extraconf: Use the canonical file name of systemd

P.S.
I chose to remove udev-extraconf from these two packagegroups because:
1) udev-extraconf is needed in live image, so the automount rule needs 
to be there in the final package, regardless of the init manager of the 
real rootfs.
2) It's not clear whether users need the automount feature in case of 
systemd. So I didn't choose to modify the mount.sh script to exit 
directly if init manager is systemd.
3) I think it's not easy to make mount.sh reliable in systemd. Kevin's 
patches are good and helpful, but still not solve all problems. e.g. The 
mount.sh still doesn't take into consideration of .mount and .automount 
units; and it does not consider this failure case, i.e. no medium found 
on /dev/hdc.


Best Regards,
Chen Qi

Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] systemd: add back alternatives for init utitilies

[ChenQi]

On 10/21/2018 05:37 AM, Richard Purdie wrote:

On Fri, 2018-10-19 at 13:19 +0800, Chen Qi wrote:

Add back alternatives for init utilities to avoid regression.

These alternatives were removed when upgradeing systemd to 239.
They were removed out of the logic that init utitilies should be
bound to init manager. However, it turned out that two use cases
were not covered.

1) initramfs using commands like 'reboot' from busybox.
2) Users use customized busybox defconfig which enables init
utilities.

The first use case caused a regression bug in yocto.
   https://bugzilla.yoctoproject.org/show_bug.cgi?id=12914
Patches were sent to fix the reboot problem.

But this is not enough. As we may have the second use case. In such
situation, users will find themselves having regression error when
using 'busybox + systemd' (and busybox is installed after systemd,
overriding the systemd symlinks).

So in order to avoid regression, add back these alternatives.

Signed-off-by

There is something odd going on which this change since it triggers:

https://autobuilder.yoctoproject.org/typhoon/#/builders/35/builds/95/steps/7/logs/step7c

I've isolated it to this change having initially thought it was Mark's
systemd change...

Cheers,

Richard



Hi Richard,

I saw all those reverts and tests about master-next on oe mailing list 
and I really feel sorry for causing autobuilder failures.
Before I sent out the patch, I did do testimage test with 
'core-image-minimal + systemd + ssh + package-management' and things 
were working well.


Back to this failure, after some investigation, I finally found the root 
cause. It's about udev-extraconf.
Before my patch, udev-extraconf actually does not work as originally 
designed. Check the following codes in mount.sh from udev-extraconf.

BASE_INIT="`readlink "/sbin/init"`"
INIT_SYSTEMD="/lib/systemd/systemd"

if [ "x$BASE_INIT" = "x$INIT_SYSTEMD" ];then
# systemd as init uses systemd-mount to mount block devices
MOUNT="/usr/bin/systemd-mount"
UMOUNT="/usr/bin/systemd-umount"
[snip]

In our system, what we have is:
root@qemux86-64:~# ls -l /sbin/init
lrwxrwxrwx1 root root22 Oct 22 04:00 /sbin/init -> 
../lib/systemd/systemd


As '../lib/systemd/systemd' does not equal to '/lib/systemd/systemd', 
the mount.sh is not using systemd-mount.


When checking links, we should use `readlnk -f' instead of just 
'readlink'. In other words, things happen to succeed for core-image-sato 
because of some error in the mount.sh script from udev-extraconf.


My patch links /sbin/init to /lib/systemd/systemd and that makes the 
mount.sh start to work, thus revealing the error.
In fact, besides the dev-vda.mount problem, I also got 
media-run-hdc.mount failure on core-image-sato. They are both caused by 
the udev-extraconf.


I'm going to remove the 'init' from alternatives and send out V2. But 
udev-extraconf also needs to be fixed.

(CC Hongzhi who did the change.)

Richard, what do you think we should do about the automount udev rule 
from udev-extraconf?
I'd suggest that we do not install the automount udev rule in case of 
systemd. I think the mount.sh script is likely to cause conflicts and 
failures unless it's constructed very carefully in case of systemd. 
Unfortunately, I don't think that script could be easily made reliable, 
considering all the possible .mount and .automount units that users may 
add as custom configuration.

Hongzhi, what's your opinion?

Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] os-release: move to nonarch_libdir

[ChenQi]

I suspect this is the correct fix for multilib conflict of os-release 
after the allarch/multilib change.
Kai, could you please verify if the following patch could be dropped 
with this patch applied?


commit 591a11ba58ce3c2c147bb1f8202bc6a0092b70eb
Author: Kai Kang 
Date:   Wed Oct 3 00:27:14 2018 +0800

os-release: avoid multilib expand

Add os-release to NON_MULTILIB_RECIPES in multilib.conf that do not do
multilib expand for os-release.

(From OE-Core rev: 361382ca16c276e1e404eab58c0956a2b6d23d7e)

Signed-off-by: Kai Kang 
Signed-off-by: Richard Purdie 

Best Regards,
Chen Qi

On 10/18/2018 11:24 PM, Dan McGregor wrote:

From: Dan McGregor 

Even on multilib systems, /usr/lib is where systemd expects the
os-release file to live.

Signed-off-by: Dan McGregor 
---
  meta/recipes-core/os-release/os-release.bb | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-core/os-release/os-release.bb 
b/meta/recipes-core/os-release/os-release.bb
index bf4f815a10d..7f3d9cba00c 100644
--- a/meta/recipes-core/os-release/os-release.bb
+++ b/meta/recipes-core/os-release/os-release.bb
@@ -42,9 +42,9 @@ python do_compile () {
  do_compile[vardeps] += "${OS_RELEASE_FIELDS}"
  
  do_install () {

-install -d ${D}${libdir} ${D}${sysconfdir}
-install -m 0644 os-release ${D}${libdir}/
-lnr ${D}${libdir}/os-release ${D}${sysconfdir}/os-release
+install -d ${D}${nonarch_libdir} ${D}${sysconfdir}
+install -m 0644 os-release ${D}${nonarch_libdir}/
+lnr ${D}${nonarch_libdir}/os-release ${D}${sysconfdir}/os-release
  }
  
-FILES_${PN} += "${libdir}/os-release"

+FILES_${PN} += "${nonarch_libdir}/os-release"



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

Re: [OE-core] [PATCH 1/4] systemd: Remove items that made this machine (qemu) specific

[ChenQi]

On 10/18/2018 12:43 AM, Mark Hatle wrote:

Create a new systemd-conf recipe to contain the specific system/machine
configuration items.  This new package is now machine specific.

Without doing this trying to create a single system with multiple BSPs,
one of which was qemu based, would result in the systemd -and- everything that
dependend upon systemd to have their hash changed.  The hash changing means
lots of rebuilds, but worse if it's a package based system each different
machine ends with a new PR value and a newly generated package.

Signed-off-by: Mark Hatle 
---
  meta/recipes-core/systemd/systemd-conf.bb | 51 +++
  ...ange-the-default-device-timeout-to-2.patch | 35 -
  meta/recipes-core/systemd/systemd_239.bb  | 28 --
  3 files changed, 60 insertions(+), 54 deletions(-)
  create mode 100644 meta/recipes-core/systemd/systemd-conf.bb
  delete mode 100644 
meta/recipes-core/systemd/systemd/0001-core-device.c-Change-the-default-device-timeout-to-2.patch

diff --git a/meta/recipes-core/systemd/systemd-conf.bb 
b/meta/recipes-core/systemd/systemd-conf.bb
new file mode 100644
index 00..d39742b3a8
--- /dev/null
+++ b/meta/recipes-core/systemd/systemd-conf.bb
@@ -0,0 +1,51 @@
+require systemd.inc
+
+SUMMARY = "Systemd system configuration"
+DESCRIPTION = "Systemd may require slightly different configuration for \
+different machines.  For example, qemu machines require a longer \
+DefaultTimeoutStartSec setting."
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+CONFFILES_${PN} = "${sysconfdir}/machine-id \
+${sysconfdir}/systemd/coredump.conf \
+${sysconfdir}/systemd/journald.conf \
+${sysconfdir}/systemd/logind.conf \
+${sysconfdir}/systemd/system.conf \
+${sysconfdir}/systemd/user.conf"
+
+FILES_${PN} = "${sysconfdir}/machine-id ${sysconfdir}/systemd"
+
+do_compile[noexec] = '1'
+
+do_install() {
+   install -d ${D}/${sysconfdir}/systemd
+
+   # Create machine-id
+   # 20:12 < mezcalero> koen: you have three options: a) run 
systemd-machine-id-setup at install time, b) have / read-only and an empty file there 
(for stateless) and c) boot with / writable
+   touch ${D}${sysconfdir}/machine-id
+
+   install -m 0644 ${S}/src/coredump/coredump.conf 
${D}${sysconfdir}/systemd/coredump.conf
+
+   install -m 0644 ${S}/src/journal/journald.conf 
${D}${sysconfdir}/systemd/journald.conf
+   # Enable journal to forward message to syslog daemon
+   sed -i -e 's/.*ForwardToSyslog.*/ForwardToSyslog=yes/' 
${D}${sysconfdir}/systemd/journald.conf
+   # Set the maximium size of runtime journal to 64M as default
+   sed -i -e 's/.*RuntimeMaxUse.*/RuntimeMaxUse=64M/' 
${D}${sysconfdir}/systemd/journald.conf
+
+   install -m 0644 ${S}/src/login/logind.conf.in 
${D}${sysconfdir}/systemd/logind.conf
+   # Set KILL_USER_PROCESSES to yes
+   sed -i -e 's/@KILL_USER_PROCESSES@/yes/' 
${D}${sysconfdir}/systemd/logind.conf
+
+   install -m 0644 ${S}/src/core/system.conf.in 
${D}${sysconfdir}/systemd/system.conf
+   # Set MEMORY_ACCOUNTING_DEFAULT to yes
+   sed -i -e 's/@MEMORY_ACCOUNTING_DEFAULT@/yes/' 
${D}${sysconfdir}/systemd/system.conf
+
+   install -m 0644 ${S}/src/core/user.conf 
${D}${sysconfdir}/systemd/user.conf
+}
+
+# Based on change from YP bug 8141, OE commit 
5196d7bacaef1076c361adaa2867be31759c1b52
+do_install_append_qemuall() {
+   # Change DefaultTimeoutStartSec from 90s to 240s
+echo "DefaultTimeoutStartSec = 240s"
+}


Seems to miss something like ">> ${D}${sysconfdir}/systemd/system.conf" ?

Best Regards,
Chen Qi


diff --git 
a/meta/recipes-core/systemd/systemd/0001-core-device.c-Change-the-default-device-timeout-to-2.patch
 
b/meta/recipes-core/systemd/systemd/0001-core-device.c-Change-the-default-device-timeout-to-2.patch
deleted file mode 100644
index fd7bf3fcf6..00
--- 
a/meta/recipes-core/systemd/systemd/0001-core-device.c-Change-the-default-device-timeout-to-2.patch
+++ /dev/null
@@ -1,35 +0,0 @@
-From 2925c0c3b6ce4056622b86c1c61ee14add430790 Mon Sep 17 00:00:00 2001
-From: Chen Qi 
-Date: Thu, 28 Jun 2018 10:56:29 +0800
-Subject: [PATCH] core/device.c: Change the default device timeout to 240 sec.
- MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8
- Content-Transfer-Encoding: 8bit
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-Upstream-Status: Inappropriate [Specific case QEMU/AB]
-
-Signed-off-by: Aníbal Limón 
-Signed-off-by: Khem Raj 
-Signed-off-by: Chen Qi 

- src/core/device.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/src/core/device.c b/src/core/device.c
-index a2d00a0fb..f26e55ebb 100644
 a/src/core/device.c
-+++ b/src/core/device.c
-@@ -95,7 +95,7 @@ static void device_init(Unit *u) {
-  * indefinitely for plugged in devices, something which cannot
-  * happen for the other units since their operations time out
-  * anyway. */
--u->job_run

Re: [OE-core] [PATCH] util-linux: Fix unshare alternative package

[ChenQi]

I sent a similar patch which, in addition to changes in this patch, also 
removes 'unshare' from ALTERNATIVE_${PN}.

The title is "util-linux: fix alternatives setting for unshare".

Best Regards,
Chen Qi

On 10/11/2018 09:44 PM, Otavio Salvador wrote:

The link was not being generated for the
sub-package (util-linux-unshare).

Signed-off-by: Otavio Salvador 
---

  meta/recipes-core/util-linux/util-linux.inc | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index 45e2203a64..c694bf013f 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -220,7 +220,6 @@ ALTERNATIVE_LINK_NAME[blockdev] = "${base_sbindir}/blockdev"
  ALTERNATIVE_LINK_NAME[pivot_root] = "${base_sbindir}/pivot_root"
  ALTERNATIVE_LINK_NAME[switch_root] = "${base_sbindir}/switch_root"
  ALTERNATIVE_LINK_NAME[eject] = "${bindir}/eject"
-ALTERNATIVE_LINK_NAME[unshare] = "${bindir}/unshare"
  ALTERNATIVE_LINK_NAME[fallocate] = "${bindir}/fallocate"
  ALTERNATIVE_LINK_NAME[fsfreeze] = "${sbindir}/fsfreeze"
  ALTERNATIVE_LINK_NAME[nologin] = "${base_sbindir}/nologin"
@@ -292,6 +291,9 @@ ALTERNATIVE_LINK_NAME[sulogin] = "${base_sbindir}/sulogin"
  ALTERNATIVE_util-linux-mountpoint = "mountpoint"
  ALTERNATIVE_LINK_NAME[mountpoint] = "${base_bindir}/mountpoint"
  
+ALTERNATIVE_util-linux-unshare = "unshare"

+ALTERNATIVE_LINK_NAME[unshare] = "${bindir}/unshare"
+
  BBCLASSEXTEND = "native nativesdk"
  
  python do_package_prepend () {



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

Re: [OE-core] [PATCH 1/1] glibc: refresh patch to also fix qemuppc

[ChenQi]

Richard, I'll consider more about maintenance issue next time.
Martin, thanks for taking care of this.

Best Regards,
Chen Qi

On 09/29/2018 08:55 PM, Martin Jansa wrote:
I'm refreshing the patch based on feedback from upstream, I'll 
integrate the changes for ppc as well.


On Sat, Sep 29, 2018 at 2:26 PM Richard Purdie 
> wrote:


On Sat, 2018-09-29 at 10:58 +0800, Chen Qi wrote:
> The patch 0031-sysdeps-ieee754-prevent-maybe-uninitialized-
> errors.patch
> did not take into consideration of qemuppc. Refresh it to also fix
> building for qemuppc.
>
> The related error message is like below:
>
>   ../sysdeps/ieee754/ldbl-128ibm/e_jnl.c:153:20: error: 'temp'
may be
> used uninitialized in this function [-Werror=maybe-uninitialized]
>
> Signed-off-by: Chen Qi mailto:qi.c...@windriver.com>>
> ---
>  ...eee754-prevent-maybe-uninitialized-errors.patch | 41
> +-
>  1 file changed, 32 insertions(+), 9 deletions(-)
>
> diff --git a/meta/recipes-core/glibc/glibc/0031-sysdeps-ieee754-
> prevent-maybe-uninitialized-errors.patch b/meta/recipes-
> core/glibc/glibc/0031-sysdeps-ieee754-prevent-maybe-uninitialized-
> errors.patch
> index b02c4ec..1c5b254 100644
> --- a/meta/recipes-core/glibc/glibc/0031-sysdeps-ieee754-prevent-
> maybe-uninitialized-errors.patch
> +++ b/meta/recipes-core/glibc/glibc/0031-sysdeps-ieee754-prevent-
> maybe-uninitialized-errors.patch
> @@ -1,4 +1,4 @@
> -From c6cc5a6ef46837e341fe271b5ffa6def23810082 Mon Sep 17 00:00:00
> 2001
> +From 113241a738662854256c5e2e415397721b842862 Mon Sep 17 00:00:00
> 2001
>  From: Martin Jansa mailto:martin.ja...@gmail.com>>
>  Date: Fri, 14 Sep 2018 23:23:03 +
>  Subject: [PATCH] sysdeps/ieee754: prevent maybe-uninitialized
errors
> @@ -21,13 +21,14 @@ Upstream-Status: Submitted
[https://www.sourcewar
> e.org/ml/libc-alpha/2018-09/msg


I get nervous when we modify a patch submitted upstream. Was the patch
submitted accepted? Do we need to send this other piece upstream?

Cheers,

Richard

-- 
___

Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

http://lists.openembedded.org/mailman/listinfo/openembedded-core



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

Re: [OE-core] [PATCH 2/2] webkitgtk: fix to build without opengl

[ChenQi]

On 10/01/2018 07:11 PM, Burton, Ross wrote:

>From the libepoxy web site:

"Epoxy is a library for handling OpenGL function pointer management for you"

libepoxy is essentially a glorified wrapper around dlopen()/dlsym().
Are you simply moving the failure from build time to run time?
libepoxy should be pulling in a GL implementation because that's what
it does.

Ross


Thanks for pointing out the problem.
I think we can now conclude that 'opengl' is necessary for webkitgtk?
I've pinged a patch which Hongxu sent some time ago.

Best Regards,
Chen Qi


On Sat, 29 Sep 2018 at 10:34, Chen Qi  wrote:

Currently, webkitgtk cannot be built if 'opengl' is not in distro
feature. The error message is like below:

   OpenGLShims.h:23:10: fatal error: GL/gl.h: No such file or directory

The required distro feature for webkitgtk is only 'x11'.

 From its source codes, libepoxy is an alternative option to build webkitgtk.
So fix to use it. In this way, we can successfully build out
webkitgtk if 'opengl' is not in distro features.

Signed-off-by: Chen Qi 
---
  .../0001-fix-to-build-with-libepoxy.patch  | 35 ++
  meta/recipes-sato/webkit/webkitgtk_2.20.5.bb   |  4 ++-
  2 files changed, 38 insertions(+), 1 deletion(-)
  create mode 100644 
meta/recipes-sato/webkit/webkitgtk/0001-fix-to-build-with-libepoxy.patch

diff --git 
a/meta/recipes-sato/webkit/webkitgtk/0001-fix-to-build-with-libepoxy.patch 
b/meta/recipes-sato/webkit/webkitgtk/0001-fix-to-build-with-libepoxy.patch
new file mode 100644
index 000..72ccef4
--- /dev/null
+++ b/meta/recipes-sato/webkit/webkitgtk/0001-fix-to-build-with-libepoxy.patch
@@ -0,0 +1,35 @@
+From 59c04daa31f8083bf4eff8304b13f34dd79d00a3 Mon Sep 17 00:00:00 2001
+From: Chen Qi 
+Date: Sat, 29 Sep 2018 16:32:57 +0800
+Subject: [PATCH] fix to build with libepoxy
+
+In source codes, there are places checking USE(LIBEPOXY), but
+in cmake files, there's nowhere to handle it.
+
+Fix to define USE_LIBEPOXY to 1 if ENABLE_LIBEPOXY is turned on.
+
+Upstream-Status: Pending
+
+Signed-off-by: Chen Qi 
+---
+ Source/cmake/OptionsGTK.cmake | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/Source/cmake/OptionsGTK.cmake b/Source/cmake/OptionsGTK.cmake
+index 386fa1d..6e86257 100644
+--- a/Source/cmake/OptionsGTK.cmake
 b/Source/cmake/OptionsGTK.cmake
+@@ -240,6 +240,10 @@ endif ()
+
+ SET_AND_EXPOSE_TO_BUILD(USE_TEXTURE_MAPPER TRUE)
+
++if (ENABLE_LIBEPOXY)
++SET_AND_EXPOSE_TO_BUILD(USE_LIBEPOXY TRUE)
++endif ()
++
+ if (ENABLE_OPENGL)
+ # ENABLE_OPENGL is true if either USE_OPENGL or ENABLE_GLES2 is true.
+ # But USE_OPENGL is the opposite of ENABLE_GLES2.
+--
+2.7.4
+
diff --git a/meta/recipes-sato/webkit/webkitgtk_2.20.5.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.20.5.bb
index c8d4f94..24d10a2 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.20.5.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.20.5.bb
@@ -23,6 +23,7 @@ SRC_URI = 
"http://www.webkitgtk.org/releases/${BPN}-${PV}.tar.xz \
 file://0012-soup-Forward-declare-URL-class.patch \
 
file://0001-Fix-PaintingData-has-no-member-named-lightVector-on-.patch \
 file://0001-webkitgtk-fix-CVE-2017-17821.patch \
+   file://0001-fix-to-build-with-libepoxy.patch \
 "

  SRC_URI[md5sum] = "72a05f6a4dc1c78b079590a8fd280401"
@@ -42,7 +43,7 @@ DEPENDS = "zlib libsoup-2.4 curl libxml2 cairo libxslt libxt 
libidn libgcrypt \
"

  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', 
'wayland' ,d)} \
-   ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'webgl 
opengl', '' ,d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'webgl 
opengl', 'libepoxy' ,d)} \
 enchant \
 libsecret \
"
@@ -52,6 +53,7 @@ PACKAGECONFIG[x11] = 
"-DENABLE_X11_TARGET=ON,-DENABLE_X11_TARGET=OFF,virtual/lib
  PACKAGECONFIG[geoclue] = 
"-DENABLE_GEOLOCATION=ON,-DENABLE_GEOLOCATION=OFF,geoclue"
  PACKAGECONFIG[enchant] = 
"-DENABLE_SPELLCHECK=ON,-DENABLE_SPELLCHECK=OFF,enchant"
  PACKAGECONFIG[gtk2] = 
"-DENABLE_PLUGIN_PROCESS_GTK2=ON,-DENABLE_PLUGIN_PROCESS_GTK2=OFF,gtk+"
+PACKAGECONFIG[libepoxy] = "-DENABLE_LIBEPOXY=ON,-DENABLE_LIBEPOXY=OFF,libepoxy"
  PACKAGECONFIG[gles2] = "-DENABLE_GLES2=ON,-DENABLE_GLES2=OFF,virtual/libgles2"
  PACKAGECONFIG[webgl] = "-DENABLE_WEBGL=ON,-DENABLE_WEBGL=OFF,virtual/libgl"
  PACKAGECONFIG[opengl] = "-DENABLE_OPENGL=ON,-DENABLE_OPENGL=OFF,virtual/libgl"
--
1.9.1

--
___
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] [PATCH 1/2] webkitgtk: add opengl to REQUIRED_DISTRO_FEATURES

[ChenQi]

ping

I think webkitgtk does require the 'opengl' distro feature.

We have in mesa.inc:
PACKAGECONFIG ??= " \
   ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 
'opengl egl gles gbm dri', '', d)} \

   ..."

PROVIDES = " \
${@bb.utils.contains('PACKAGECONFIG', 'opengl', 'virtual/libgl', 
'', d)} \
${@bb.utils.contains('PACKAGECONFIG', 'gles', 'virtual/libgles1 
virtual/libgles2', '', d)} \

..."

And webkitgtk's source codes are like:
#if USE(LIBEPOXY)
// libepoxy headers have to be included before  in 
order to avoid

// picking up khrplatform.h inclusion that's done in ANGLE.
#include 
#endif

#include 
#include 

#if PLATFORM(IOS)
#import 
#elif PLATFORM(MAC)
#include 
#elif PLATFORM(WIN)
#include "OpenGLESShims.h"
#elif USE(LIBEPOXY)
//  already included above.
#elif USE(OPENGL_ES_2)
#include 
#else
#include "OpenGLShims.h"
#endif

And libepoxy is wrapper around libgl.

So I think we can conclude 'opengl' is required distro feature for 
webkitgkt? At least this is the current situation in OE.


Best Regards,
Chen Qi

On 09/03/2018 05:35 PM, Hongxu Jia wrote:

They can't be built without opengl in DISTRO_FEATURES.
[snip]
|webkitgtk-2.20.3/Source/WebCore/platform/graphics/OpenGLShims.h:23:10:
fatal error: GL/gl.h: No such file or directory
[snip]

Signed-off-by: Hongxu Jia 
---
  meta/recipes-sato/webkit/webkitgtk_2.20.3.bb | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.20.3.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.20.3.bb
index a528c5d..93d74bb 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.20.3.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.20.3.bb
@@ -29,8 +29,7 @@ SRC_URI[sha256sum] = 
"579b307d78fa16a73f112790178022166d7ad17d4147492ced9b9fba48
  
  inherit cmake pkgconfig gobject-introspection perlnative distro_features_check upstream-version-is-even gtk-doc
  
-# depends on libxt

-REQUIRED_DISTRO_FEATURES = "x11"
+REQUIRED_DISTRO_FEATURES = "x11 opengl"
  
  DEPENDS = "zlib libsoup-2.4 curl libxml2 cairo libxslt libxt libidn libgcrypt \

 gtk+3 gstreamer1.0 gstreamer1.0-plugins-base flex-native 
gperf-native sqlite3 \



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

Re: [OE-core] [PATCH 1/2] webkitgtk: add opengl to REQUIRED_DISTRO_FEATURES

[ChenQi]

ping

I think webkitgtk does require the 'opengl' distro feature.

Best Regards,
Chen Qi

On 09/03/2018 05:35 PM, Hongxu Jia wrote:

They can't be built without opengl in DISTRO_FEATURES.
[snip]
|webkitgtk-2.20.3/Source/WebCore/platform/graphics/OpenGLShims.h:23:10:
fatal error: GL/gl.h: No such file or directory
[snip]

Signed-off-by: Hongxu Jia 
---
  meta/recipes-sato/webkit/webkitgtk_2.20.3.bb | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.20.3.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.20.3.bb
index a528c5d..93d74bb 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.20.3.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.20.3.bb
@@ -29,8 +29,7 @@ SRC_URI[sha256sum] = 
"579b307d78fa16a73f112790178022166d7ad17d4147492ced9b9fba48
  
  inherit cmake pkgconfig gobject-introspection perlnative distro_features_check upstream-version-is-even gtk-doc
  
-# depends on libxt

-REQUIRED_DISTRO_FEATURES = "x11"
+REQUIRED_DISTRO_FEATURES = "x11 opengl"
  
  DEPENDS = "zlib libsoup-2.4 curl libxml2 cairo libxslt libxt libidn libgcrypt \

 gtk+3 gstreamer1.0 gstreamer1.0-plugins-base flex-native 
gperf-native sqlite3 \



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

Re: [OE-core] [PATCH 1/1] runqemu: fix handling of SIGTERM and the problem of line wrapping

[ChenQi]

On 09/21/2018 11:05 PM, Burton, Ross wrote:

Is there a good reason why shell=True is used in the first place?
Just change the cmd to a list, stop passing shell=True, and you don't
need to dance around process groups.


Thanks for your suggestion. I'll send out V2 if all things go well with 
my local testings.


Best Regards,
Chen Qi


Ross
On Fri, 21 Sep 2018 at 03:30, Chen Qi  wrote:

The current handling of SIGTERM is incorrect as the process pid returned
by Popen call with shell setting to True is actualy the shell instead of
the qemu binary. So fix to send SIGTERM to the process group of runqemu.
This ensures that all processes in the same process group, including the
shell and the qemu process, will receive SIGTERM.

Also, as we install a SIGTERM handler, we need handle the situation of
qemu terminated by SIGTERM, otherwise we will get ERROR message in such
case.

Besides, we have a problem that after running qemu, the terminal's behavior
is incorrect regarding long lines or long commands. Long commands or long
outputs should appear in multiple lines, but they appear in the same line,
overriding previous output. Use `tput smam' to fix this problem.

Signed-off-by: Chen Qi 
---
  scripts/runqemu | 14 ++
  1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index 409d17c..bc2aba5 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -1213,9 +1213,12 @@ class BaseConfig(object):
  cmd = "%s %s" % (self.qemu_opt, kernel_opts)
  logger.info('Running %s\n' % cmd)
  process = subprocess.Popen(cmd, shell=True, stderr=subprocess.PIPE)
-self.qemupid = process.pid
-if process.wait():
-logger.error("Failed to run qemu: %s", 
process.stderr.read().decode())
+retcode = process.wait()
+if retcode:
+if retcode == -signal.SIGTERM:
+logger.info("Qemu terminated by SIGTERM")
+else:
+logger.error("Failed to run qemu: %s", 
process.stderr.read().decode())

  def cleanup(self):
  if self.cleaned:
@@ -1308,8 +1311,10 @@ def main():

  def sigterm_handler(signum, frame):
  logger.info("SIGTERM received")
-os.kill(config.qemupid, signal.SIGTERM)
+signal.signal(signal.SIGTERM, signal.SIG_IGN)
+os.kill(0, signal.SIGTERM)
  config.cleanup()
+subprocess.run(["tput", "smam"])
  signal.signal(signal.SIGTERM, sigterm_handler)

  config.check_args()
@@ -1331,6 +1336,7 @@ def main():
  return 1
  finally:
  config.cleanup()
+subprocess.run(["tput", "smam"])

  if __name__ == "__main__":
  sys.exit(main())
--
1.9.1

--
___
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] [PATCH 1/1] autotools: do more cleanup when in do_configure

[ChenQi]

On 09/10/2018 06:24 PM, Burton, Ross wrote:

On 10 September 2018 at 11:02, Chen Qi  wrote:

I met the following error when compiling some projects.

| configure: error: `LDFLAGS' has changed since the previous run:
| configure:   former value:  `-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed'
| configure:   current value: `-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed 
-fstack-protector-strong -Wl,-z,relro,-z,now'
[snip]
| configure: error: changes in the environment can compromise the build
| configure: error: run `make distclean' and/or `rm .././config.cache' and 
start over

I think when some recipe inherits autotools-brokensep, it should try to
do more cleanups before configure. So also do 'make distclean' and remove
config.cache just as what the error message told us.

Does just removing config.cache work for your problem?

I guess it should, but I haven't checked.

   I'm concerned
about running a distclean because some upstreams abuse that target and
then can't rebuild.

Hmm... I hold the opposite opinion.
I suspect that just doing a `make clean' is more likely to break rebuild 
while doing a `make distclean' should reduce the possibility.


Conceptually, `make clean' is followed by `make' while `make distclean' 
is followed by `configure & make'.
At rebuild, we are doing `configure & make'; so we should use `make 
distclean', in theory.


I'll revisit this issue later and do more investigation.

Also obviously the proper fix is to not use autotools-brokensep in the
recipe in the first place.

You are right.
The recipe is cyrus-sasl and the newly updated version has fixed to use 
autotools instead of autotools-brokensep.


To summarize, ideally we should have no recipe inheriting 
autotools-brokensep. But in reality, it's almost not possible.
I sent out this patch because I thought it would be helpful for such 
recipes.


Best Regards,
Chen Qi


Ross



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

Re: [OE-core] [PATCH] systemd: set split-bin to true by default

[ChenQi]

Thanks for fixing this error.

I saw you were sending this patch to the yocto mailing list. That's not 
necessary.

This mailing list is the correct place to send patch.
Please wait for merge.

Best Regards,
Chen Qi

On 09/07/2018 11:41 PM, Anton Gerasimov wrote:

Not doing so will make meson chose where to install init binary
based on irrelevant features of the build machine.

PACKAGECONFIG option is defined to override this behavior.

Signed-off-by: Anton Gerasimov 
---
  meta/recipes-core/systemd/systemd_239.bb | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/systemd/systemd_239.bb 
b/meta/recipes-core/systemd/systemd_239.bb
index 84906f97b7..55e3986935 100644
--- a/meta/recipes-core/systemd/systemd_239.bb
+++ b/meta/recipes-core/systemd/systemd_239.bb
@@ -168,6 +168,7 @@ PACKAGECONFIG[time-epoch] = "-Dtime-epoch=0,,"
  PACKAGECONFIG[timedated] = "-Dtimedated=true,-Dtimedated=false"
  PACKAGECONFIG[timesyncd] = "-Dtimesyncd=true,-Dtimesyncd=false"
  PACKAGECONFIG[usrmerge] = "-Dsplit-usr=false,-Dsplit-usr=true"
+PACKAGECONFIG[sbinmerge] = "-Dsplit-bin=false,-Dsplit-bin=true"
  PACKAGECONFIG[utmp] = "-Dutmp=true,-Dutmp=false"
  PACKAGECONFIG[valgrind] = "-DVALGRIND=1,,valgrind"
  PACKAGECONFIG[vconsole] = 
"-Dvconsole=true,-Dvconsole=false,,${PN}-vconsole-setup"



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

Re: [OE-core] [PATCH 7/8] busybox: Put klogd/syslogd alternative links in syslog package

[ChenQi]

On 09/06/2018 04:19 PM, richard.pur...@linuxfoundation.org wrote:

On Thu, 2018-09-06 at 10:11 +0800, ChenQi wrote:

Hi Richard,

I think my previous patch has covered this case.

git://git.pokylinux.org/poky-contrib ChenQi/busybox-alternatives
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/busyb
ox-alternatives

Chen Qi (1):
busybox: fix the alternatives logic


Is there some problem with the patch?

Sorry, I thought I'd replied about this. There were build failures from
this patch and I had to drop it from the test branch. I'm afraid with
all the build failures we're had recently I'm struggling to find which
failures those were...

I merged my simpler but less complete fix simply to get patches moving
as I'd assumed this one was being debugged. I guess we need the
failures for that though...

Cheers,

Richard


Got it.
I just looked at some build failures, the ones that might be related are 
those of testimage failures complaining 'No syslog daemon'.

I'll check things locally first.

Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Dependency loops when enabling ptest with Ångström

[ChenQi]

On 09/06/2018 02:52 PM, Steffen Sledz wrote:

After some hours of analysis I could identify the following commit in 
meta-angstrom introducing the loops.

---> snip <--
commit c94ca0759c34e637b725f648a1925e007bbe60e9 (HEAD -> work, 
m/angstrom-v2017.12-rocko, github/angstrom-v2017.12-rocko)
Author: Koen Kooi 
Date:   Sat Jul 7 09:23:11 2018 +0200

 systemd bbappend: enable importd

 Signed-off-by: Koen Kooi 
---> snap <--

This one adds

   DEPENDS += "glib-2.0"

to recipes-core/systemd/systemd_%.bbappend. :(

However, I am not sufficiently involved in the subject matter to propose a 
solution.

Koen?


Hi Steffen,

I tried to find your repo but failed. The meta-angstrom layer in 
meta-opembedded's layer index does not have this commit.


Anyway, I checked the current codes of systemd. glib is only used for tests.
$ grep -r HAVE_GLIB src/
src/libsystemd/sd-bus/test-bus-marshal.c:#if HAVE_GLIB
src/libsystemd/sd-bus/test-bus-marshal.c:#if HAVE_GLIB
src/libsystemd/sd-bus/test-bus-gvariant.c:#if HAVE_GLIB
src/libsystemd/sd-bus/test-bus-gvariant.c:#if HAVE_GLIB
src/libsystemd/sd-bus/test-bus-gvariant.c:#if HAVE_GLIB

Also, the meson_options.txt states:
option('glib', type : 'combo', choices : ['auto', 'true', 'false'],
   description : 'libglib support (for tests only)')

So I guess you can just remove such dependency.

Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] staging.bbclass: avoid staging native components for target sysroot

[ChenQi]

ping

On 08/27/2018 04:46 PM, Chen Qi wrote:

In the staging_populate_sysroot_dir function, components are staged
by pkgarch matching. In case of x86-64 targets, it's possible that
the native components are also matched, and thus are expectedly installed.

The negative effect is at least unnecessary installation, and in some
cases is compilation error. For example, when using eSDK and we are trying
to cross compile some project in lib32 environment, the compilation will
fail.

Signed-off-by: Chen Qi 
---
  meta/classes/staging.bbclass | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index 27b012e..1b9803a 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -198,6 +198,9 @@ def staging_populate_sysroot_dir(targetsysroot, 
nativesysroot, native, d):
  if manifest.endswith("-initial.populate_sysroot"):
  # skip glibc-initial and libgcc-initial due to file overlap
  continue
+if not native and manifest.endswith("-native.populate_sysroot"):
+# avoid native components to be installed into target sysroot
+continue
  tmanifest = targetdir + "/" + os.path.basename(manifest)
  if os.path.exists(tmanifest):
  continue



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

Re: [OE-core] [PATCH 7/8] busybox: Put klogd/syslogd alternative links in syslog package

[ChenQi]

Hi Richard,

I think my previous patch has covered this case.

  git://git.pokylinux.org/poky-contrib ChenQi/busybox-alternatives
  
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/busybox-alternatives

Chen Qi (1):
  busybox: fix the alternatives logic


Is there some problem with the patch?

Best Regards,
Chen Qi

On 09/06/2018 12:52 AM, Richard Purdie wrote:

Currently these are in ${PN} and ${PN}-syslog may get replaced by
other packages but update-alternatives would error in the postinst
if other files were installed first. Avoid the problems by putting
the links in the correct package.

Signed-off-by: Richard Purdie 
---
  meta/recipes-core/busybox/busybox.inc | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/busybox/busybox.inc 
b/meta/recipes-core/busybox/busybox.inc
index 586d5342e60..c26ef56bf78 100644
--- a/meta/recipes-core/busybox/busybox.inc
+++ b/meta/recipes-core/busybox/busybox.inc
@@ -367,7 +367,10 @@ python do_package_prepend () {
  # Match coreutils
  if alt_name == '[':
  alt_name = 'lbracket'
-d.appendVar('ALTERNATIVE_%s' % (pn), ' ' + alt_name)
+if alt_name == 'klogd' or alt_name == 'syslogd':
+d.appendVar('ALTERNATIVE_%s-syslog' % (pn), ' ' + alt_name)
+else:
+d.appendVar('ALTERNATIVE_%s' % (pn), ' ' + alt_name)
  d.setVarFlag('ALTERNATIVE_LINK_NAME', alt_name, alt_link_name)
  if os.path.exists('%s%s' % (dvar, target)):
  d.setVarFlag('ALTERNATIVE_TARGET', alt_name, target)



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

Re: [OE-core] [PATCH 3/7] sysklogd: Use update-alternatives

[ChenQi]

On 08/30/2018 03:44 PM, Peter Kjellerstedt wrote:

-Original Message-
From: openembedded-core-boun...@lists.openembedded.org  On Behalf Of Khem Raj
Sent: den 30 augusti 2018 05:56
To: openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH 3/7] sysklogd: Use update-alternatives

busybox also provides klogd and syslogd, this change makes it coexist
peacefully. Currently rootfs fails in situations where both of them are
providing these binaries and busybox postinsts fail

update-alternatives: Error: not linking
/mnt/a/oe/build/tmp/work/qemuriscv64-bec-linux/core-image-full-
cmdline/1.0-r0/rootfs/sbin/klogd
to /bin/busybox.nosuid since
/mnt/a/oe/build/tmp/work/qemuriscv64-bec-linux/core-image-full-
cmdline/1.0-r0/rootfs/sbin/klogd
exists and is not a link

Signed-off-by: Khem Raj 
---
  meta/recipes-extended/sysklogd/sysklogd.inc | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-extended/sysklogd/sysklogd.inc
b/meta/recipes-extended/sysklogd/sysklogd.inc
index fc4e67c18e..2a8bed00f3 100644
--- a/meta/recipes-extended/sysklogd/sysklogd.inc
+++ b/meta/recipes-extended/sysklogd/sysklogd.inc
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b \
  
file://klogd.c;beginline=2;endline=19;md5=7e87ed0ae6142de079bce738c10c899d \
 "

-inherit update-rc.d systemd
+inherit update-rc.d systemd update-alternatives

  SRC_URI = 
"http://www.infodrom.org/projects/sysklogd/download/sysklogd-${PV}.tar.gz \
 file://no-strip-install.patch \
@@ -70,3 +70,9 @@ python () {
  if not bb.utils.contains('DISTRO_FEATURES', 'sysvinit', True, False, d):
  d.setVar("INHIBIT_UPDATERCD_BBCLASS", "1")
  }
+
+ALTERNATIVE_PRIORITY = "100"
+ALTERNATIVE_${PN} = "klogd syslogd"
+ALTERNATIVE_LINK_NAME[klogd] = "${base_sbindir}/klogd"
+ALTERNATIVE_LINK_NAME[syslogd] = "${base_sbindir}/syslogd"
+
--
2.18.0

This is a (partial) revert of commit 988aad01b2 (sysklogd: don't use
update-alternatives). Can you come to an agreement regarding which is
the correct solution?

//Peter




I think the previous commit (syslogd: don't use update-alternatives) is 
made because syslog daemon conflict with each other. I guess the author 
assumed that the 'syslogd' and 'klogd' alternatives entries are handled 
by busybox-syslog package.


On the other hand, I think the patch is trying to solve the problem of 
busybox being installed after sysklogd.
We are currently not seeing errors because busybox is likely to be 
installed before sysklogd. Even in this situation, the result is not all 
correct, because the links busybox's postinstall creates are covered by 
the real binaries from sysklogd.


I think the problem is about busybox's handling of alternatives.

Khem, I've sent out a patch to fix busybox's alternatives logic. Could 
you please help review it?


Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] testsdkext: remove workspace/sources to avoid failure in case of multilib

[ChenQi]

ping

On 05/08/2018 04:07 PM, Chen Qi wrote:

When multilib is enabled, there are multiple environment scripts, and the
test cases for eSDK are executed for each environment script.

And we will have the following problem when executing test cases for the
second environment script.

   ERROR: Source tree path /.../workspace/sources/librdfa already exists and is 
not empty

So after executing test cases for one environment, we clean up the sources
diretory to avoid such failure.

Signed-off-by: Chen Qi 
---
  meta/classes/testsdk.bbclass | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/meta/classes/testsdk.bbclass b/meta/classes/testsdk.bbclass
index 2e43343..54719a1 100644
--- a/meta/classes/testsdk.bbclass
+++ b/meta/classes/testsdk.bbclass
@@ -183,6 +183,9 @@ def testsdkext_main(d):
  if not result.wasSuccessful():
  fail = True
  
+# Clean the workspace/sources to avoid `devtool add' failure because of non-empty source directory

+bb.utils.remove(sdk_dir+'workspace/sources', True)
+
  if fail:
  bb.fatal("%s - FAILED - check the task log and the commands log" % pn)
  



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

Re: [OE-core] [V2][PATCH 0/3] allarch: disable allarch when multilib is used

[ChenQi]

And also a few other failures:

https://autobuilder.yocto.io/builders/nightly-qa-extras/builds/1242/steps/BuildImages_7/logs/stdio
https://autobuilder.yocto.io/builders/nightly-multilib/builds/1255/steps/BuildImages_3/logs/stdio

Best Regards,
Chen Qi

On 08/22/2018 10:36 AM, ChenQi wrote:

There's some oe-selftest failures on autobuiler.

https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/1300/steps/Running%20oe-selftest/logs/stdio 



Best Regards,
Chen Qi

On 08/21/2018 02:36 PM, kai.k...@windriver.com wrote:

From: Kai Kang 

V2:
* move content of allarch.bbclass to allarch-enabled.bbclass and only
   inherit allarch-enabled when multilib is not used
* update SSTATE_DUPWHITELIST

Build pass for following targets on qemux86-64 and qemuarm64 for rpm,
ipk and deb.

* core-image-sato
* core-image-sato -c populate_sdk
* world
* buildtools-tarball

Known issues:
There are 2 *existing* multilib related issues which are not caused by
this serial of patches:

1 QA warnings of lib32-meta-ide-support and lib32-perf

WARNING: lib32-meta-ide-support-1.0-r3 do_configure: Manifest
/buildarea1/jkang-taf/WRL1018/OV/0730/host/build/tmp-glibc/sstate-control/manifest-x86_64_x86_64-nativesdk-ncurses.populate_sysroot 


not found in intel_x86_64 corei7-32 core2-32 i686 i586 x86 allarch
x86_64_x86_64-nativesdk (variant '')?

WARNING: lib32-perf-1.0-r9 do_install: Manifest
/buildarea1/jkang-taf/WRL1018/OV/0730/host/build/tmp-glibc/sstate-control/manifest-x86_64_i686-binutils-cross-x86_64.populate_sysroot 


not found in x86_64_i686 (variant '')?

2 fails to build lib32-buildtools-tarball

ERROR: lib32-buildtools-tarball-1.0-r0 do_populate_sdk: No manifest
generated from: qemuwrapper-cross in
/buildarea3/kkang/poky-2014/poky/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb 



I am working on them.


The following changes since commit 
99506b0017bdf8dbf42ec5dc048d91a5609dabe3:


   weston-init: run login before start weston.service (2018-08-20 
17:38:23 +0100)


are available in the Git repository at:

   git://git.pokylinux.org/poky-contrib kangkai/allarch-enabled
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/allarch-enabled

Kai Kang (3):
   cmake.bbclass: fix wrong toolchain flags of nativesdk package
   allarch: disable allarch when multilib is used
   sstate.bbclass: update SSTATE_DUPWHITELIST

  meta/classes/allarch-enabled.bbclass | 52 
  meta/classes/allarch.bbclass | 51 ++-
  meta/classes/cmake.bbclass   |  1 +
  meta/classes/icecc.bbclass   |  2 +-
  meta/classes/multilib.bbclass|  2 +-
  meta/classes/multilib_global.bbclass |  2 +-
  meta/classes/package.bbclass |  6 ++--
  meta/classes/sstate.bbclass  |  4 ++-
  8 files changed, 64 insertions(+), 56 deletions(-)
  create mode 100644 meta/classes/allarch-enabled.bbclass





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

Re: [OE-core] [V2][PATCH 0/3] allarch: disable allarch when multilib is used

[ChenQi]

There's some oe-selftest failures on autobuiler.

https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/1300/steps/Running%20oe-selftest/logs/stdio

Best Regards,
Chen Qi

On 08/21/2018 02:36 PM, kai.k...@windriver.com wrote:

From: Kai Kang 

V2:
* move content of allarch.bbclass to allarch-enabled.bbclass and only
   inherit allarch-enabled when multilib is not used
* update SSTATE_DUPWHITELIST

Build pass for following targets on qemux86-64 and qemuarm64 for rpm,
ipk and deb.

* core-image-sato
* core-image-sato -c populate_sdk
* world
* buildtools-tarball

Known issues:
There are 2 *existing* multilib related issues which are not caused by
this serial of patches:

1 QA warnings of lib32-meta-ide-support and lib32-perf

WARNING: lib32-meta-ide-support-1.0-r3 do_configure: Manifest
/buildarea1/jkang-taf/WRL1018/OV/0730/host/build/tmp-glibc/sstate-control/manifest-x86_64_x86_64-nativesdk-ncurses.populate_sysroot
not found in intel_x86_64 corei7-32 core2-32 i686 i586 x86 allarch
x86_64_x86_64-nativesdk (variant '')?

WARNING: lib32-perf-1.0-r9 do_install: Manifest
/buildarea1/jkang-taf/WRL1018/OV/0730/host/build/tmp-glibc/sstate-control/manifest-x86_64_i686-binutils-cross-x86_64.populate_sysroot
not found in x86_64_i686 (variant '')?

2 fails to build lib32-buildtools-tarball

ERROR: lib32-buildtools-tarball-1.0-r0 do_populate_sdk: No manifest
generated from: qemuwrapper-cross in
/buildarea3/kkang/poky-2014/poky/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb

I am working on them.


The following changes since commit 99506b0017bdf8dbf42ec5dc048d91a5609dabe3:

   weston-init: run login before start weston.service (2018-08-20 17:38:23 
+0100)

are available in the Git repository at:

   git://git.pokylinux.org/poky-contrib kangkai/allarch-enabled
   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/allarch-enabled

Kai Kang (3):
   cmake.bbclass: fix wrong toolchain flags of nativesdk package
   allarch: disable allarch when multilib is used
   sstate.bbclass: update SSTATE_DUPWHITELIST

  meta/classes/allarch-enabled.bbclass | 52 
  meta/classes/allarch.bbclass | 51 ++-
  meta/classes/cmake.bbclass   |  1 +
  meta/classes/icecc.bbclass   |  2 +-
  meta/classes/multilib.bbclass|  2 +-
  meta/classes/multilib_global.bbclass |  2 +-
  meta/classes/package.bbclass |  6 ++--
  meta/classes/sstate.bbclass  |  4 ++-
  8 files changed, 64 insertions(+), 56 deletions(-)
  create mode 100644 meta/classes/allarch-enabled.bbclass



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

Re: [OE-core] [PATCH V2] nasm: fix CVE-2018-8883 & CVE-2018-8882 & CVE-2018-10016 & CVE-2018-10316

[ChenQi]

Caused ovmf do_compile failure.
https://autobuilder.yocto.io/builders/nightly-musl/builds/1254/steps/BuildImages/logs/stdio 



Best Regards,
Chen Qi

On 08/20/2018 09:23 AM, Hongxu Jia wrote:

Signed-off-by: Hongxu Jia 
---
  ...t-we-are-not-reading-past-end-of-a-buffer.patch | 65 ++
  ...001-asm-eval.c-Avoid-possible-divide-by-0.patch | 40 +
  .../0001-assemble-Check-global-line-limit.patch| 50 +
  .../nasm/nasm/0001-fix-CVE-2018-8882.patch | 30 ++
  meta/recipes-devtools/nasm/nasm_2.13.03.bb |  4 ++
  5 files changed, 189 insertions(+)
  create mode 100644 
meta/recipes-devtools/nasm/nasm/0001-Verify-that-we-are-not-reading-past-end-of-a-buffer.patch
  create mode 100644 
meta/recipes-devtools/nasm/nasm/0001-asm-eval.c-Avoid-possible-divide-by-0.patch
  create mode 100644 
meta/recipes-devtools/nasm/nasm/0001-assemble-Check-global-line-limit.patch
  create mode 100644 
meta/recipes-devtools/nasm/nasm/0001-fix-CVE-2018-8882.patch

diff --git 
a/meta/recipes-devtools/nasm/nasm/0001-Verify-that-we-are-not-reading-past-end-of-a-buffer.patch
 
b/meta/recipes-devtools/nasm/nasm/0001-Verify-that-we-are-not-reading-past-end-of-a-buffer.patch
new file mode 100644
index 000..a56a08b
--- /dev/null
+++ 
b/meta/recipes-devtools/nasm/nasm/0001-Verify-that-we-are-not-reading-past-end-of-a-buffer.patch
@@ -0,0 +1,65 @@
+From c5785fdf1d660eaefb9711284414262d0cfe8843 Mon Sep 17 00:00:00 2001
+From: Adam Majer 
+Date: Fri, 17 Aug 2018 14:48:17 +0800
+Subject: [PATCH] Verify that we are not reading past end of a buffer
+
+Simple reproducer is just,
+
+ret &d:ep
+
+which triggers a buffer overread due to parsing of an invalid
+segment override.
+
+Signed-off-by: Adam Majer 
+
+Upstream-Status: Submitted [https://bugzilla.nasm.us/show_bug.cgi?id=3392447]
+CVE: CVE-2018-8883
+Signed-off-by: Hongxu Jia 
+---
+ include/opflags.h | 2 +-
+ include/tables.h  | 1 +
+ x86/regs.pl   | 3 ++-
+ 3 files changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/include/opflags.h b/include/opflags.h
+index ef2838c1..8d4b6b1e 100644
+--- a/include/opflags.h
 b/include/opflags.h
+@@ -166,7 +166,7 @@
+ #define REG_CLASS_BND   GEN_REG_CLASS(9)
+
+ #define is_class(class, op) (!((opflags_t)(class) & ~(opflags_t)(op)))
+-#define is_reg_class(class, reg)is_class((class), nasm_reg_flags[(reg)])
++#define is_reg_class(class, reg)is_class((class), ((reg) < 
nasm_reg_flags_size ? nasm_reg_flags[(reg)] : 0))
+
+ #define IS_SREG(reg)is_reg_class(REG_SREG, (reg))
+ #define IS_FSGS(reg)is_reg_class(REG_FSGS, (reg))
+diff --git a/include/tables.h b/include/tables.h
+index 24a665e2..458752ce 100644
+--- a/include/tables.h
 b/include/tables.h
+@@ -64,6 +64,7 @@ extern const char * const nasm_reg_names[];
+ typedef uint64_t opflags_t;
+ typedef uint16_t  decoflags_t;
+ extern const opflags_t nasm_reg_flags[];
++extern const size_t nasm_reg_flags_size;
+ /* regvals.c */
+ extern const int nasm_regvals[];
+
+diff --git a/x86/regs.pl b/x86/regs.pl
+index 3a1b56f5..cb5cea68 100755
+--- a/x86/regs.pl
 b/x86/regs.pl
+@@ -158,7 +158,8 @@ if ( $fmt eq 'h' ) {
+   printf "%-15s /* %-5s */\n",
+   $regs{$reg}.',', $reg;
+ }
+-print "};\n";
++print "};\n\n";
++print "const size_t nasm_reg_flags_size = sizeof(nasm_reg_flags) / 
sizeof(opflags_t);\n";
+ } elsif ( $fmt eq 'vc' ) {
+ # Output regvals.c
+ print "/* automatically generated from $file - do not edit */\n\n";
+--
+2.17.1
+
diff --git 
a/meta/recipes-devtools/nasm/nasm/0001-asm-eval.c-Avoid-possible-divide-by-0.patch
 
b/meta/recipes-devtools/nasm/nasm/0001-asm-eval.c-Avoid-possible-divide-by-0.patch
new file mode 100644
index 000..6ceeca0
--- /dev/null
+++ 
b/meta/recipes-devtools/nasm/nasm/0001-asm-eval.c-Avoid-possible-divide-by-0.patch
@@ -0,0 +1,40 @@
+From 8ad049cf9ccda2a5133a97506011862bcfc4a0c0 Mon Sep 17 00:00:00 2001
+From: Adam Majer 
+Date: Fri, 17 Aug 2018 14:15:35 +0800
+Subject: [PATCH] asm/eval.c: Avoid possible divide by 0
+
+During a divide operation, we already tested that the
+divisor has is_simple, but then when testing it for 0,
+we again verify that it does not contain any unknown parts.
+This extra check prevents detection of cases when
+reloc_value returns 0.
+
+Use reloc_value instead in detection of 0 divisor.
+
+https://bugzilla.nasm.us/show_bug.cgi?id=3392473
+
+Signed-off-by: Adam Majer 
+
+Upstream-Status: Submitted [https://bugzilla.nasm.us/show_bug.cgi?id=3392473]
+CVE: CVE-2018-10016
+Signed-off-by: Hongxu Jia 
+---
+ asm/eval.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/asm/eval.c b/asm/eval.c
+index 816983b9..57c598c5 100644
+--- a/asm/eval.c
 b/asm/eval.c
+@@ -585,7 +585,7 @@ static expr *expr5(int critical)
+   " scalar values");
+ return NULL;
+ }
+-if (j != '*' && !is_unknown(f) && reloc_value(f) 

Re: [OE-core] [PATCH 1/1] assimp.py: fix AttributeError in tearDownClass

[ChenQi]

On 08/21/2018 12:53 AM, Richard Purdie wrote:

On Fri, 2018-08-17 at 17:17 +0800, Chen Qi wrote:

When running this test case, we will see the following error.

   AttributeError: type object 'BuildAssimp' has no attribute
'project'

assimp.py test case does not make use of SDKBuildProject, so remove
the import statement and the tearDownClass.

Signed-off-by: Chen Qi 
---
  meta/lib/oeqa/sdk/cases/assimp.py | 5 -
  1 file changed, 5 deletions(-)

I'm not seeing this error when I run the test and I can't see it on the
autobuilders. Why are you seeing this and we're not?

I'm trying to understand some other odd behaviour in SDK tests and am
wondering if this is related or not.

(e.g. https://autobuilder.yocto.io/builders/nightly-mips/builds/1221/st
eps/Running%20SDK%20Sanity%20Tests/logs/stdio)

Cheers,

Richard

I did a quick search and found this one: 
https://github.com/pexpect/pexpect/pull/31

"""
|sys.stdout.buffer| is not guaranteed to exist - e.g. if |sys.stdout| 
has been reassigned to an |io.StringIO| instance, it won't.

"""

And we have in ConcurrencyTestSuite:
process_result._stdout_buffer = io.StringIO()

Best Regards,
Chen Qi
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 8/9] gdb: Upgrade to 8.1.1

[ChenQi]

There's a build failure on autobuilder.

https://autobuilder.yocto.io/builders/nightly-musl-x86-64/builds/700/steps/BuildImages/logs/stdio

| x86_64-poky-linux-musl-g++ -m64 -march=core2 -mtune=core2 -msse3 
-mfpmath=sse 
--sysroot=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl-x86-64/build/build/tmp/work/core2-64-poky-linux-musl/gdb/8.1.1-r0/recipe-sysroot 
-shared -fPIC -Wl,--soname=libinproctrace.so -Wl,--no-undefined -O2 
-pipe -g -feliminate-unused-debug-types 
-fdebug-prefix-map=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl-x86-64/build/build/tmp/work/core2-64-poky-linux-musl/gdb/8.1.1-r0=/usr/src/debug/gdb/8.1.1-r0 
-fdebug-prefix-map=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl-x86-64/build/build/tmp/work/core2-64-poky-linux-musl/gdb/8.1.1-r0/recipe-sysroot= 
-fdebug-prefix-map=/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl-x86-64/build/build/tmp/work/core2-64-poky-linux-musl/gdb/8.1.1-r0/recipe-sysroot-native= 
-fvisibility-inlines-hidden -I. -I../../../gdb-8.1.1/gdb/gdbserver 
-I../../../gdb-8.1.1/gdb/gdbserver/../common 
-I../../../gdb-8.1.1/gdb/gdbserver/../regformats 
-I../../../gdb-8.1.1/gdb/gdbserver/.. 
-I../../../gdb-8.1.1/gdb/gdbserver/../../include 
-I../../../gdb-8.1.1/gdb/gdbserver/../gnulib/import 
-Ibuild-gnulib-gdbserver/import -Wall -Wpointer-arith -Wno-unused 
-Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts 
-Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable 
-Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized 
-DGDBSERVER \ | -static-libstdc++ -static-libgcc -Wl,-O1 
-Wl,--hash-style=gnu -Wl,--as-needed 
-Wl,--dynamic-list=../../../gdb-8.1.1/gdb/gdbserver/proc-service.list -o 
libinproctrace.so ax-ipa.o common-utils-ipa.o errors-ipa.o format-ipa.o 
print-utils-ipa.o regcache-ipa.o remote-utils-ipa.o rsp-low-ipa.o 
tdesc-ipa.o tracepoint-ipa.o utils-ipa.o vec-ipaERROR: Task 
(/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl-x86-64/build/meta/recipes-devtools/gdb/gdb_8.1.1.bb:do_compile) 
failed with exit code '1' .o linux-amd64-ipa.o linux-x86-tdesc-ipa.o 
arch/amd64-ipa.o -ldl -pthread | 
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl-x86-64/build/build/tmp/work/core2-64-poky-linux-musl/gdb/8.1.1-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux-musl/../../libexec/x86_64-poky-linux-musl/gcc/x86_64-poky-linux-musl/8.2.0/ld: 
common-utils-ipa.o: in function `is_regular_file(char const*, int*)': | 
/usr/src/debug/gdb/8.1.1-r0/build-x86_64-poky-linux-musl/gdb/gdbserver/../../../gdb-8.1.1/gdb/gdbserver/../common/common-utils.c:419: 
undefined reference to `rpl_stat' | collect2: error: ld returned 1 exit 
status | make[4]: *** [Makefile:414: libinproctrace.so] Error 1 | 
make[4]: *** Waiting for unfinished jobs | make[4]: Leaving 
directory 
'/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl-x86-64/build/build/tmp/work/core2-64-poky-linux-musl/gdb/8.1.1-r0/build-x86_64-poky-linux-musl/gdb/gdbserver' 
| make[3]: *** [Makefile:2027: subdir_do] Error 1 | make[3]: Leaving 
directory 
'/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl-x86-64/build/build/tmp/work/core2-64-poky-linux-musl/gdb/8.1.1-r0/build-x86_64-poky-linux-musl/gdb' 
| make[2]: *** [Makefile:1621: all] Error 2 | make[2]: Leaving directory 
'/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl-x86-64/build/build/tmp/work/core2-64-poky-linux-musl/gdb/8.1.1-r0/build-x86_64-poky-linux-musl/gdb' 
| make[1]: *** [Makefile:8793: all-gdb] Error 2 | make[1]: Leaving 
directory 
'/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl-x86-64/build/build/tmp/work/core2-64-poky-linux-musl/gdb/8.1.1-r0/build-x86_64-poky-linux-musl' 
| make: *** [Makefile:850: all] Error 2 | ERROR: oe_runmake failed



Best Regards,
Chen Qi

On 08/20/2018 01:23 AM, Khem Raj wrote:

Signed-off-by: Khem Raj 
---
  meta/recipes-devtools/gdb/{gdb-8.1.inc => gdb-8.1.1.inc}  | 4 ++--
  ...{gdb-cross-canadian_8.1.bb => gdb-cross-canadian_8.1.1.bb} | 0
  .../gdb/{gdb-cross_8.1.bb => gdb-cross_8.1.1.bb}  | 0
  meta/recipes-devtools/gdb/{gdb_8.1.bb => gdb_8.1.1.bb}| 0
  4 files changed, 2 insertions(+), 2 deletions(-)
  rename meta/recipes-devtools/gdb/{gdb-8.1.inc => gdb-8.1.1.inc} (89%)
  rename meta/recipes-devtools/gdb/{gdb-cross-canadian_8.1.bb => 
gdb-cross-canadian_8.1.1.bb} (100%)
  rename meta/recipes-devtools/gdb/{gdb-cross_8.1.bb => gdb-cross_8.1.1.bb} 
(100%)
  rename meta/recipes-devtools/gdb/{gdb_8.1.bb => gdb_8.1.1.bb} (100%)

diff --git a/meta/recipes-devtools/gdb/gdb-8.1.inc 
b/meta/recipes-devtools/gdb/gdb-8.1.1.inc
similarity index 89%
rename from meta/recipes-devtools/gdb/gdb-8.1.inc
rename to meta/recipes-devtools/gdb/gdb-8.1.1.inc
index 4d9faa2d4b..ad80dd3e4d 100644
--- a/meta/recipes-devtools/gdb/gdb-8.1.inc
+++ b/meta/recipes-devtools/gdb/gdb-8.1.1.inc
@@ -18,6 +18,6 @@ SRC_URI = "http://ftp.gnu.org/gnu/gdb/gdb-${PV}.tar.xz \
 
file://package_deve

Re: [OE-core] [oe-core][rocko][sumo][master][PATCH 1/2] bitbake.conf: add PERSISTENT_LOG_DIR variable

[ChenQi]

The requirement is to put logs into directories other than /var/log.
Could it be achieved by modifying the syslog daemon configuration file 
(e.g. /etc/syslog.conf) to replace /var/log with the specified 
directory. Maybe the corresponding logrotate configuration file also 
needs to be modified.


Best Regards,
Chen Qi

On 08/18/2018 08:59 AM, Ankur Tyagi wrote:

This variable is only respected when VOLATILE_LOG_DIR is "no".

The default value is "" which results in the /var/log being log directory.

The user could override this value to a path e.g "/home/root/log" which
results /var/log being a link pointing to /home/root/log directory on
persistent storage.

Signed-off-by: Ankur Tyagi 
---
  meta/conf/bitbake.conf | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index e5dc1ac..9db22c8 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -88,6 +88,8 @@ ROOT_HOME ??= "/home/root"
  # If set to boolean true ('yes', 'y', 'true', 't', '1'), /var/log links to 
/var/volatile/log.
  # If set to boolean false ('no', 'n', 'false', 'f', '0'), /var/log is on 
persistent storage.
  VOLATILE_LOG_DIR ?= "yes"
+# If VOLATILE_LOG_DIR is false and PERSISTENT_LOG_DIR is set, /var/log links 
to PERSISTENT_LOG_DIR
+PERSISTENT_LOG_DIR ??= ""
  
  ##

  # Architecture-dependent build variables.



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

Re: [OE-core] [PATCH 1/1] glibc: re-package for libnss-db

[ChenQi]

On 08/16/2018 04:41 AM, Randy MacLeod wrote:

On 08/15/2018 10:02 AM, Richard Purdie wrote:

On Wed, 2018-08-15 at 15:00 +0800, Chen Qi wrote:

From: Jackie Huang 

On other distros like ubuntu/centos, libnss-db usually provides:
- The libraries
- The Makefile to create database
   (in /var/db for centos, /var/lib/misc/ for ubuntu)
- The makedb command (it's in glibc-common for centos7)

What we had is:
- The libraries are in glibc-extra-nss
- The Makefile is removed
- The makedb command is in glibc-utils (lack of dependency)

So when glibc-extra-nss is installed but glibc-utils is not,
we see error like:
nscd[165]: 165 checking for monitored file `/var/db/group.db': No
such file or directory
nscd[165]: 165 checking for monitored file `/var/db/passwd.db': No
such file or directory

And there is not an easy way to create these databases.

To fix the issue:
- Re-package the libraries into libnss-db
- Don't remove the Makefile and add it in libnss-db
- Add RDEPENDS for libnss-db on glibc-utils and make

Notes:
For external toolchain, an extra package 'libnss-db' need to be
provided
If replacing glibc from core.

Signed-off-by: Jackie Huang 
Signed-off-by: Chen Qi 
---
  meta/recipes-core/glibc/glibc-package.inc | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)


This breaks on the autobuilder in oe-selftest:

2018-08-15 13:09:15,551 - oe-selftest - INFO - 
==



...


NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'make' (but 
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/recipes-core/glibc/glibc_2.28.bb 
RDEPENDS on or otherwise requires it)

make was skipped: it has an incompatible license: GPLv3 & LGPLv2
NOTE: Runtime target 'make' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['make']
ERROR: Required build target 'selftest-ed' has no buildable providers.
Missing or unbuildable dependency chain was: ['selftest-ed', 
'virtual/libc', 'make']


Summary: There were 2 ERROR messages shown, returning a non-zero exit 
code.


https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/1281/steps/Running%20oe-selftest/logs/stdio 



We really don't want a make dependency in glibc :(


Switching from RDEPENDS to RSUGGESTS  seems like a
reasonable solution. The GPLv2 build would work but
libnss-db would fail unless meta-gplv2 were used to
get an old version of make.

One way to avoid needing make is to demand that the bdb
files are generated during the build. That would be nice
but it shouldn't be a requirement since it's not the
typical workflow and since the db will usually be dynamic.

History and more details below.

../Randy

To support on target generation of the bdb files that
libnss-db uses then we need to:
 - separate the libnss-db files into a libnss-db pkg
 - *suggest* a 'make' as described below:

Back in January, Jackie had replied to:
   [OE-core] [PATCH 0/2 v2] glibc: fixes for nscd and libnss-db

with:


Sorry, I didn't noticed that make is gplv3. I change the dependency to
RSUGGESTS and the test passed:

$ oe-selftest -r bbtests.BitbakeTests.test_non_gplv3
...
2018-01-16 21:46:22,540 - oe-selftest - INFO - oe-selftest - OK - All 
required tests passed


but of course that papers over the failure by allowing the build to
pass even though runtime needs to include make to be able to
rebuild the db(s). And of course libnss-db isn't even being tested yet
so once we add that to oeqa, the test will fail for GPLv2-only images
where meta-gplv2 isn't added to the list of layers. I'm fine with
such oeqa failing when meta-gplv2 isn't around.


Qi, if no one comes up with a better idea,
please test that as well as:
  $ oe-selftest -r bbtests.BitbakeTests.test_non_gplv3
so that Richard doesn't burn another build cycle on it.

This isn't urgent but it would be nice to resolve the
issue properly for M3 without driving Richard around the bend!

Thanks,
../Randy




Cheers,

Richard





Sorry for breaking the autobuilder.

I checked the Makefile and found that it's a bunch of `awd [expression] 
/etc/xxx | makedb -o /var/db/xxx.db -'.
I also checked the glibc repo and this Makefile is quite stable. So I 
think we can use a shell script to get rid of the make dependency. And 
it should not create maintenance problem.


I'll send out V2.
I've tested it locally and it should pass the oe-selftest.

Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] base-files: fix handling of resize

[ChenQi]

ping

On 08/01/2018 01:25 PM, Chen Qi wrote:

The current handling of resize is incorrect. Using `resize > /dev/null
2>&1 && resize > /dev/null' will cause the second resize command to not
execute because 'resize > /dev/null 2>&1' will fail for resize utility
from busybox.

What we really should do is just to check whether ${bindir}/resize
is executable and execute it if so. Using '-x' is sufficient.

Signed-off-by: Chen Qi 
---
  meta/recipes-core/base-files/base-files/profile   | 6 +-
  meta/recipes-core/base-files/base-files_3.0.14.bb | 1 +
  2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-core/base-files/base-files/profile 
b/meta/recipes-core/base-files/base-files/profile
index e14cb2d..9e4283e 100644
--- a/meta/recipes-core/base-files/base-files/profile
+++ b/meta/recipes-core/base-files/base-files/profile
@@ -24,11 +24,7 @@ fi
  # /dev/tty[A-z]), otherwise we confuse e.g. the eclipse launcher which tries 
do
  # use ssh
  case $(tty 2>/dev/null) in
-   # The first invocation of resize verifies that it exists, the second
-   # does the actual resizing. This is due to that resize uses stderr to
-   # determine the size of the tty, which does not work if it is redirected
-   # to /dev/null.
-   /dev/tty[A-z]*) resize >/dev/null 2>&1 && resize >/dev/null;;
+   /dev/tty[A-z]*) [ -x @BINDIR@/resize ] && @BINDIR@/resize >/dev/null;;
  esac
  
  export PATH PS1 OPIEDIR QPEDIR QTDIR EDITOR TERM

diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb 
b/meta/recipes-core/base-files/base-files_3.0.14.bb
index 1c0863b..05c0562 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -121,6 +121,7 @@ do_install () {
install -m 0644 ${WORKDIR}/usbd ${D}${sysconfdir}/default/usbd
install -m 0644 ${WORKDIR}/profile ${D}${sysconfdir}/profile
sed -i 's#ROOTHOME#${ROOT_HOME}#' ${D}${sysconfdir}/profile
+sed -i 's#@BINDIR@#${bindir}#g' ${D}${sysconfdir}/profile
install -m 0644 ${WORKDIR}/shells ${D}${sysconfdir}/shells
install -m 0755 ${WORKDIR}/share/dot.profile 
${D}${sysconfdir}/skel/.profile
install -m 0755 ${WORKDIR}/share/dot.bashrc 
${D}${sysconfdir}/skel/.bashrc



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

Re: [OE-core] Why do we use sysklogd as the default syslog?

[ChenQi]

On 07/30/2018 08:58 PM, Alexander Kanavin wrote:

2018-07-30 8:48 GMT+02:00 ChenQi :

I just noticed that we are using sysklogd as the default syslog.
meta/recipes-extended/packagegroups/packagegroup-core-full-cmdline.bb:VIRTUAL-RUNTIME_syslog
?= "sysklogd"

sysklogd has stopped development for about 4 years, and as far as I can see,
nobody is maintaining it.
Is there some specific reason why we want to keep it as the default syslog
for our reference images? small size?


You are welcome to improve this. Quite often the answer to such
questions is 'because no one is aware of the situation'.

Alex

In case someone is also interested in this topic, I'll add some more 
information here.


rsyslog is GPLv3 and syslog-ng uses a very different configuration style 
from traditional sysklogd.

So I guess I'll just leave things as they are now.

Best Regards,
Chen Qi
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] busybox: move init related configs to init.cfg

[ChenQi]

ping

On 07/30/2018 05:41 PM, Chen Qi wrote:

Move init related configs to init.cfg.

These config items do not make much sense unless busybox is selected
as the init manager. They should belong to init.cfg.

Signed-off-by: Chen Qi 
---
  meta/recipes-core/busybox/busybox/defconfig | 12 ++--
  meta/recipes-core/busybox/busybox/init.cfg  |  7 ++-
  2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-core/busybox/busybox/defconfig 
b/meta/recipes-core/busybox/busybox/defconfig
index fbb5fd8..59d93c7 100644
--- a/meta/recipes-core/busybox/busybox/defconfig
+++ b/meta/recipes-core/busybox/busybox/defconfig
@@ -468,21 +468,21 @@ CONFIG_FEATURE_XARGS_SUPPORT_REPL_STR=y
  # CONFIG_BOOTCHARTD is not set
  # CONFIG_FEATURE_BOOTCHARTD_BLOATED_HEADER is not set
  # CONFIG_FEATURE_BOOTCHARTD_CONFIG_FILE is not set
-CONFIG_HALT=y
-CONFIG_POWEROFF=y
-CONFIG_REBOOT=y
+# CONFIG_HALT is not set
+# CONFIG_POWEROFF is not set
+# CONFIG_REBOOT is not set
  # CONFIG_FEATURE_CALL_TELINIT is not set
-CONFIG_TELINIT_PATH=""
+# CONFIG_TELINIT_PATH is not set
  # CONFIG_INIT is not set
  # CONFIG_LINUXRC is not set
  # CONFIG_FEATURE_USE_INITTAB is not set
  # CONFIG_FEATURE_KILL_REMOVED is not set
-CONFIG_FEATURE_KILL_DELAY=0
+# CONFIG_FEATURE_KILL_DELAY is not set
  # CONFIG_FEATURE_INIT_SCTTY is not set
  # CONFIG_FEATURE_INIT_SYSLOG is not set
  # CONFIG_FEATURE_INIT_QUIET is not set
  # CONFIG_FEATURE_INIT_COREDUMPS is not set
-CONFIG_INIT_TERMINAL_TYPE=""
+# CONFIG_INIT_TERMINAL_TYPE is not set
  # CONFIG_FEATURE_INIT_MODIFY_CMDLINE is not set
  
  #

diff --git a/meta/recipes-core/busybox/busybox/init.cfg 
b/meta/recipes-core/busybox/busybox/init.cfg
index 006d4c6..3c1fdd4 100644
--- a/meta/recipes-core/busybox/busybox/init.cfg
+++ b/meta/recipes-core/busybox/busybox/init.cfg
@@ -1,3 +1,8 @@
  CONFIG_INIT=y
  CONFIG_FEATURE_USE_INITTAB=y
-
+CONFIG_HALT=y
+CONFIG_POWEROFF=y
+CONFIG_REBOOT=y
+CONFIG_FEATURE_KILL_DELAY=0
+CONFIG_TELINIT_PATH=""
+CONFIG_INIT_TERMINAL_TYPE=""



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