Re: [OE-core] [PATCH] glibc-package.inc: fix multilib headers conflict

[Kang Kai]

On 2020/2/18 上午10:55, Kang Kai wrote:

On 2020/2/11 下午11:07, kai.k...@windriver.com wrote:

From: Kai Kang 

Pass bits/endianness.h and bits/struct_rwlock.h to oe_multilib_header in
glibc-package.inc to fix files conflict:

| Error: Transaction check error:
|   file /usr/include/bits/endianness.h conflicts between attempted 
installs of lib32-libc6-dev-2.31-r0.armv7vet2hf_vfp and 
libc6-dev-2.31-r0.aarch64
|   file /usr/include/bits/struct_rwlock.h conflicts between 
attempted installs of lib32-libc6-dev-2.31-r0.armv7vet2hf_vfp and 
libc6-dev-2.31-r0.aarch64


Ping.

Could reproduce with config

require conf/multilib.conf
MACHINE = "qemuarm64"
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7vethf"


And

IMAGE_INSTALL_append = " lib32-libc6-dev libc6-dev"

of course.




Regards,
Kai




Signed-off-by: Kai Kang 
---
  meta/recipes-core/glibc/glibc-package.inc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/glibc/glibc-package.inc 
b/meta/recipes-core/glibc/glibc-package.inc

index 3aed7be4f8..285a9aa2f5 100644
--- a/meta/recipes-core/glibc/glibc-package.inc
+++ b/meta/recipes-core/glibc/glibc-package.inc
@@ -87,7 +87,7 @@ do_install() {
  rmdir --ignore-fail-on-non-empty ${D}${libexecdir}
  fi
  -    oe_multilib_header bits/syscall.h bits/long-double.h 
bits/floatn.h
+    oe_multilib_header bits/syscall.h bits/long-double.h 
bits/floatn.h bits/endianness.h bits/struct_rwlock.h

    if [ -f ${D}${bindir}/mtrace ]; then
  sed -i -e '1s,#!.*perl,#! ${USRBINPATH}/env perl,' -e 
'2s,exec.*perl,exec ${USRBINPATH}/env perl,' ${D}${bindir}/mtrace





--
Kai Kang

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

Re: [OE-core] [PATCH] glibc-package.inc: fix multilib headers conflict

[Kang Kai]

On 2020/2/11 下午11:07, kai.k...@windriver.com wrote:

From: Kai Kang 

Pass bits/endianness.h and bits/struct_rwlock.h to oe_multilib_header in
glibc-package.inc to fix files conflict:

| Error: Transaction check error:
|   file /usr/include/bits/endianness.h conflicts between attempted installs of 
lib32-libc6-dev-2.31-r0.armv7vet2hf_vfp and libc6-dev-2.31-r0.aarch64
|   file /usr/include/bits/struct_rwlock.h conflicts between attempted installs 
of lib32-libc6-dev-2.31-r0.armv7vet2hf_vfp and libc6-dev-2.31-r0.aarch64


Ping.

Could reproduce with config

require conf/multilib.conf
MACHINE = "qemuarm64"
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7vethf"

Regards,
Kai




Signed-off-by: Kai Kang 
---
  meta/recipes-core/glibc/glibc-package.inc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/glibc/glibc-package.inc 
b/meta/recipes-core/glibc/glibc-package.inc
index 3aed7be4f8..285a9aa2f5 100644
--- a/meta/recipes-core/glibc/glibc-package.inc
+++ b/meta/recipes-core/glibc/glibc-package.inc
@@ -87,7 +87,7 @@ do_install() {
rmdir --ignore-fail-on-non-empty ${D}${libexecdir}
fi
  
-	oe_multilib_header bits/syscall.h bits/long-double.h bits/floatn.h

+   oe_multilib_header bits/syscall.h bits/long-double.h bits/floatn.h 
bits/endianness.h bits/struct_rwlock.h
  
  	if [ -f ${D}${bindir}/mtrace ]; then

sed -i -e '1s,#!.*perl,#! ${USRBINPATH}/env perl,' -e 
'2s,exec.*perl,exec ${USRBINPATH}/env perl,' ${D}${bindir}/mtrace



--
Kai Kang

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

Re: [OE-core] [PATCH] ifupdown: add ptest

[Kang Kai]

On 2020/2/3 下午8:50, Alexander Kanavin wrote:

I think a build configuration for this also needs to be enabled and tested as 
explained in the email thread from the bug (in magefeatures.py from selftest I 
think). Otherwise this wouldn’t be built or checked anywhere.


Hi Alex,

In imagefeatures.py, it just run 'bitbake -g core-image-sato' and 
doesn't really build and test RDEPENDS packages of 
packagegroup-core-base-utils.


So for the packages in the RDEPENDS packages of 
packagegroup-core-base-utils but not in any image, they all are not be 
tested.


I didn't find a proper recipe to place these recipes. Maybe a new image 
recipe need to be created.


Regards,
Kai





Alex


On 3 Feb 2020, at 10.14,   
wrote:

From: Kai Kang 

Add ptest for ifupdown with its own test cases.

[Yocto #13736]

Signed-off-by: Kai Kang 
---
meta/recipes-core/ifupdown/files/run-ptest|  4 ++
.../ifupdown/files/tweak-ptest-script.patch   | 49 +++
meta/recipes-core/ifupdown/ifupdown_0.8.35.bb | 10 +++-
3 files changed, 62 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-core/ifupdown/files/run-ptest
create mode 100644 meta/recipes-core/ifupdown/files/tweak-ptest-script.patch

diff --git a/meta/recipes-core/ifupdown/files/run-ptest 
b/meta/recipes-core/ifupdown/files/run-ptest
new file mode 100644
index 00..8694042392
--- /dev/null
+++ b/meta/recipes-core/ifupdown/files/run-ptest
@@ -0,0 +1,4 @@
+#!/bin/sh
+
+CURDIR=$(dirname `readlink -f $0`)
+cd $CURDIR/tests && ./testbuild-linux
diff --git a/meta/recipes-core/ifupdown/files/tweak-ptest-script.patch 
b/meta/recipes-core/ifupdown/files/tweak-ptest-script.patch
new file mode 100644
index 00..d7600cf243
--- /dev/null
+++ b/meta/recipes-core/ifupdown/files/tweak-ptest-script.patch
@@ -0,0 +1,49 @@
+Tweak tests of ifupdown to make it work with oe-core ptest framework.
+
+Upstream-Status: Inappropriate [oe-core specific]
+
+Signed-off-by: Kai Kang 
+
+diff --git a/tests/testbuild-linux b/tests/testbuild-linux
+index 1181ea0..d5c1814 100755
+--- a/tests/testbuild-linux
 b/tests/testbuild-linux
+@@ -1,6 +1,7 @@
+ #!/bin/sh -e
+
+-dir=tests/linux
++curdir=$(dirname `readlink -f $0`)
++dir=$curdir/linux
+
+ result=true
+ for test in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18; do
+@@ -12,7 +13,7 @@ for test in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18; do
+ echo "Testcase $test: $args"
+
+exitcode=0
+-./ifup -v --no-act-commands --force -i $dir/testcase.$test 
--state-dir=$dir/state.$test $args \
++ifup -v --no-act-commands --force -i $dir/testcase.$test 
--state-dir=$dir/state.$test $args \
+ >$dir/up-res-out.$test 2>$dir/up-res-err.$test || exitcode=$?
+
+ (echo "exit code: $exitcode";
+@@ -20,7 +21,7 @@ for test in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18; do
+  echo "stderr"; cat $dir/up-res-err.$test) > $dir/up-res.$test
+
+exitcode=0
+-./ifdown -v --no-act-commands --force -i $dir/testcase.$test 
--state-dir=$dir/state.$test $args \
++ifdown -v --no-act-commands --force -i $dir/testcase.$test 
--state-dir=$dir/state.$test $args \
+>$dir/down-res-out.$test 2>$dir/down-res-err.$test || 
exitcode=$?
+
+ (echo "exit code: $exitcode";
+@@ -28,9 +29,9 @@ for test in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18; do
+  echo "stderr"; cat $dir/down-res-err.$test) > 
$dir/down-res.$test
+
+ if diff -ub $dir/up.$test $dir/up-res.$test && diff -ub 
$dir/down.$test $dir/down-res.$test; then
+-echo "(okay)"
++echo "PASS: $test"
+ else
+-echo "(failed)"
++echo "FAIL: $test"
+ result=false
+ fi
+ echo "=="
diff --git a/meta/recipes-core/ifupdown/ifupdown_0.8.35.bb 
b/meta/recipes-core/ifupdown/ifupdown_0.8.35.bb
index 0de97fe372..53cb971d33 100644
--- a/meta/recipes-core/ifupdown/ifupdown_0.8.35.bb
+++ b/meta/recipes-core/ifupdown/ifupdown_0.8.35.bb
@@ -11,13 +11,15 @@ SRC_URI = 
"git://salsa.debian.org/debian/ifupdown.git;protocol=https \
file://99_network \
file://0001-Define-FNM_EXTMATCH-for-musl.patch \
file://0001-Makefile-do-not-use-dpkg-for-determining-OS-type.patch \
+   file://run-ptest \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'ptest', 
'file://tweak-ptest-script.patch', '', d)} \
"
SRCREV = "4af76318cfc57f8e4a44d357104188666213bd4b"

S = "${WORKDIR}/git"


-inherit update-alternatives
+inherit ptest update-alternatives

do_compile () {
chmod a+rx *.pl *.sh
@@ -40,6 +42,12 @@ do_install () {
cd ${D}${mandir}/man8 && ln -s ifup.8 ifdown.8
}

+do_install_ptest () {
+install -d ${D}${PTEST_PATH}/tests
+cp -r ${S}/tests/testbuild-linux ${D}${PTEST_PATH}/tests/
+cp -r ${S}/tests/linux ${D}${PTEST_PATH}/tests/
+}
+
ALTERNATIVE_PRIORITY = "100"
ALTERNATIVE_${PN} = "ifup ifdown"

--
2.17.1

--

Re: [OE-core] [PATCH 06/14] dummy-sdk-package.inc: do not include files into RREPLACES

[Kang Kai]

On 2020/1/6 下午7:34, Alexander Kanavin wrote:
I made a couple of patches for this, they seem to fix the issues. 
Please test:

http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=akanavin/package-version-updates=a695bd5a8951b640add0cbc3e8171da7f58982b6
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=akanavin/package-version-updates=6574516432dec7e5a716ff7c17c1bcaea06a3fb7


It works to run populate_sdk tasks with these 2 patches. Thanks.

Kai




Alex

On Fri, 3 Jan 2020 at 01:49, Kang Kai <mailto:kai.k...@windriver.com>> wrote:


On 2020/1/3 上午2:06, Alexander Kanavin wrote:

On Thu, 2 Jan 2020 at 11:18, Kang Kai mailto:kai.k...@windriver.com>> wrote:

On 2019/11/28 上午12:39, Alexander Kanavin wrote:
> rpm 4.15 no longer allows it, which makes sense.
>
> Signed-off-by: Alexander Kanavin mailto:alex.kana...@gmail.com>>

Hi Alex,

I tried this patch with rpm 4.15 and it fails to run task
populate_sdk
when multilib is enabled and lib32-perl is installed.

IMAGE_INSTALL_append = " lib32-perl "


I believe this is due to DUMMYPROVIDES_PACKAGES needing the same
multilib expansion as:

DUMMYPROVIDES += "${@' '.join([multilib_pkg_extend(d, pkg) for
pkg in d.getVar('DUMMYPROVIDES_PACKAGES').split()])}"

<mailto:$%7B@''.join([multilib_pkg_extend(d,pkg)forpkgind.getVar('DUMMYPROVIDES_PACKAGES').split()])%7D>

So that RREPLACES has all the multilib variants included.

However, there is also a different issue, that looks similar, but
actually pre-dates this patch, and rpm 4.15 update:

if you do
IMAGE_INSTALL_append = " perl "

(with multilib enabled), a similar error will happen:

Problem: package
target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target
conflicts with perl provided by perl-5.30.1-r0.core2_32
  - package
target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target
conflicts with perl-module-strict provided by perl-5.30.1-r0.core2_32
  - package
target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target
conflicts with perl-module-warnings provided by
perl-5.30.1-r0.core2_32
  - package
target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target
conflicts with perl-module-vars provided by perl-5.30.1-r0.core2_32
  - package
target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target
conflicts with perl-module-config provided by perl-5.30.1-r0.core2_32
  - package
target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target
conflicts with perl-module-warnings-register provided by
perl-5.30.1-r0.core2_32
  - package
target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target
conflicts with /usr/bin/perl provided by perl-5.30.1-r0.core2_32
  - package
target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target
conflicts with libperl.so.5 provided by perl-5.30.1-r0.core2_32
  - package
target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target
obsoletes perl provided by perl-5.30.1-r0.core2_32
  - cannot install the best candidate for the job
  - conflicting requests

Inspecting

/home/alexander/development/poky/build-multilib/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/sdk/image/opt/poky/3.0/sysroots/core2-32-poky-linux/etc/dnf/vars/arch,
I see:

core2_32:i686:i586:x86:sdk_provides_dummy_target:qemux86:x86_64

Even though sdk_provides_dummy_target should be up-front, rather
than in the middle (so that it takes priority over other
architectures).

I could not figure out a good way to fix this, but I think this
issue should be addressed first, and then we can fix the
lib32/64-perl issue.



Thanks for your detailed reply. I'll try to figure a way out.

    Regards,
Kai




Alex



-- 
Kai Kang




--
Kai Kang

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

Re: [OE-core] [PATCH 06/14] dummy-sdk-package.inc: do not include files into RREPLACES

[Kang Kai]

On 2020/1/3 上午2:06, Alexander Kanavin wrote:
On Thu, 2 Jan 2020 at 11:18, Kang Kai <mailto:kai.k...@windriver.com>> wrote:


On 2019/11/28 上午12:39, Alexander Kanavin wrote:
> rpm 4.15 no longer allows it, which makes sense.
>
> Signed-off-by: Alexander Kanavin mailto:alex.kana...@gmail.com>>

Hi Alex,

I tried this patch with rpm 4.15 and it fails to run task
populate_sdk
when multilib is enabled and lib32-perl is installed.

IMAGE_INSTALL_append = " lib32-perl "


I believe this is due to DUMMYPROVIDES_PACKAGES needing the same 
multilib expansion as:


DUMMYPROVIDES += "${@' '.join([multilib_pkg_extend(d, pkg) for pkg in 
d.getVar('DUMMYPROVIDES_PACKAGES').split()])}"


So that RREPLACES has all the multilib variants included.

However, there is also a different issue, that looks similar, but 
actually pre-dates this patch, and rpm 4.15 update:


if you do
IMAGE_INSTALL_append = " perl "

(with multilib enabled), a similar error will happen:

Problem: package 
target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target conflicts 
with perl provided by perl-5.30.1-r0.core2_32
  - package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target 
conflicts with perl-module-strict provided by perl-5.30.1-r0.core2_32
  - package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target 
conflicts with perl-module-warnings provided by perl-5.30.1-r0.core2_32
  - package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target 
conflicts with perl-module-vars provided by perl-5.30.1-r0.core2_32
  - package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target 
conflicts with perl-module-config provided by perl-5.30.1-r0.core2_32
  - package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target 
conflicts with perl-module-warnings-register provided by 
perl-5.30.1-r0.core2_32
  - package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target 
conflicts with /usr/bin/perl provided by perl-5.30.1-r0.core2_32
  - package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target 
conflicts with libperl.so.5 provided by perl-5.30.1-r0.core2_32
  - package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target 
obsoletes perl provided by perl-5.30.1-r0.core2_32

  - cannot install the best candidate for the job
  - conflicting requests

Inspecting 
/home/alexander/development/poky/build-multilib/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/sdk/image/opt/poky/3.0/sysroots/core2-32-poky-linux/etc/dnf/vars/arch, 
I see:


core2_32:i686:i586:x86:sdk_provides_dummy_target:qemux86:x86_64

Even though sdk_provides_dummy_target should be up-front, rather than 
in the middle (so that it takes priority over other architectures).


I could not figure out a good way to fix this, but I think this issue 
should be addressed first, and then we can fix the lib32/64-perl issue.



Thanks for your detailed reply. I'll try to figure a way out.

Regards,
Kai




Alex



--
Kai Kang

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

Re: [OE-core] [PATCH 06/14] dummy-sdk-package.inc: do not include files into RREPLACES

[Kang Kai]

On 2019/11/28 上午12:39, Alexander Kanavin wrote:

rpm 4.15 no longer allows it, which makes sense.

Signed-off-by: Alexander Kanavin 


Hi Alex,

I tried this patch with rpm 4.15 and it fails to run task populate_sdk 
when multilib is enabled and lib32-perl is installed.


IMAGE_INSTALL_append = " lib32-perl "

It fails with:

No module defaults found
--> Starting dependency resolution
--> Finished dependency resolution
Error:
 Problem: package 
target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target conflicts 
with lib32-perl provided by lib32-perl-5.30.1-r0.i586
  - package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target 
conflicts with lib32-perl-module-strict provided by 
lib32-perl-5.30.1-r0.i586
  - package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target 
conflicts with lib32-perl-module-warnings provided by 
lib32-perl-5.30.1-r0.i586
  - package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target 
conflicts with lib32-perl-module-vars provided by lib32-perl-5.30.1-r0.i586
  - package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target 
conflicts with lib32-perl-module-config provided by 
lib32-perl-5.30.1-r0.i586
  - package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target 
conflicts with lib32-perl-module-warnings-register provided by 
lib32-perl-5.30.1-r0.i586
  - package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target 
conflicts with /usr/bin/perl provided by lib32-perl-5.30.1-r0.i586
  - package target-sdk-provides-dummy-1.0-r0.sdk_provides_dummy_target 
conflicts with libperl.so.5 provided by lib32-perl-5.30.1-r0.i586

  - conflicting requests
(try to add '--allowerasing' to command line to replace conflicting 
packages or '--skip-broken' to skip uninstallable packages or '--nobest' 
to use not only best candidate packages)


Any suggestion about it, please?

Regards,
Kai



---
  meta/recipes-core/meta/dummy-sdk-package.inc | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/meta/dummy-sdk-package.inc 
b/meta/recipes-core/meta/dummy-sdk-package.inc
index 4d653706b13..58b0482eca5 100644
--- a/meta/recipes-core/meta/dummy-sdk-package.inc
+++ b/meta/recipes-core/meta/dummy-sdk-package.inc
@@ -16,11 +16,12 @@ python() {
  ALLOW_EMPTY_${PN} = "1"
  
  PR[vardeps] += "DUMMYPROVIDES"

+PR[vardeps] += "DUMMYPROVIDES_PACKAGES"
  
  python populate_packages_prepend() {

  p = d.getVar("PN")
  d.appendVar("RPROVIDES_%s" % p, "${DUMMYPROVIDES}")
  d.appendVar("RCONFLICTS_%s" % p, "${DUMMYPROVIDES}")
-d.appendVar("RREPLACES_%s" % p, "${DUMMYPROVIDES}")
+d.appendVar("RREPLACES_%s" % p, "${DUMMYPROVIDES_PACKAGES}")
  }
  



--
Kai Kang

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

Re: [OE-core] [PATCH 1/2] base.bbclass: extend PACKAGECONFIG for conflict package configs

[Kang Kai]

On 2019/12/10 下午5:35, kai.k...@windriver.com wrote:

From: Kai Kang 

There are mutually exclusive PACKAGECONFIGs in recipes. Though it
declares that package configs are exclusive, it can't prevent users to
set them at same time. Extend PACKAGECONFIG to support specifying
conflicted package configs.


Ping.




Signed-off-by: Kai Kang 
---
  meta/classes/base.bbclass | 20 +---
  1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 31457f9f12..ef3afdf964 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -390,7 +390,7 @@ python () {
  # These take the form:
  #
  # PACKAGECONFIG ??= ""
-# PACKAGECONFIG[foo] = 
"--enable-foo,--disable-foo,foo_depends,foo_runtime_depends,foo_runtime_recommends"
+# PACKAGECONFIG[foo] = 
"--enable-foo,--disable-foo,foo_depends,foo_runtime_depends,foo_runtime_recommends,foo_conflict_packageconfig"
  pkgconfigflags = d.getVarFlags("PACKAGECONFIG") or {}
  if pkgconfigflags:
  pkgconfig = (d.getVar('PACKAGECONFIG') or "").split()
@@ -437,8 +437,8 @@ python () {
  for flag, flagval in sorted(pkgconfigflags.items()):
  items = flagval.split(",")
  num = len(items)
-if num > 5:
-bb.error("%s: PACKAGECONFIG[%s] Only 
enable,disable,depend,rdepend,rrecommend can be specified!"
+if num > 6:
+bb.error("%s: PACKAGECONFIG[%s] Only 
enable,disable,depend,rdepend,rrecommend,conflict_packageconfig can be specified!"
  % (d.getVar('PN'), flag))
  
  if flag in pkgconfig:

@@ -452,6 +452,20 @@ python () {
  extraconf.append(items[0])
  elif num >= 2 and items[1]:
  extraconf.append(items[1])
+
+if num >= 6 and items[5]:
+conflicts = set(items[5].split())
+invalid = conflicts.difference(set(pkgconfigflags.keys()))
+if invalid:
+bb.error("%s: PACKAGECONFIG[%s] Invalid conflict package 
config%s '%s' specified."
+% (d.getVar('PN'), flag, 's' if len(invalid) > 1 else 
'', ' '.join(invalid)))
+
+if flag in pkgconfig:
+intersec = conflicts.intersection(set(pkgconfig))
+if intersec:
+bb.fatal("%s: PACKAGECONFIG[%s] Conflict package config%s 
'%s' set in PACKAGECONFIG."
+% (d.getVar('PN'), flag, 's' if len(intersec) > 1 
else '', ' '.join(intersec)))
+
  appendVar('DEPENDS', extradeps)
  appendVar('RDEPENDS_${PN}', extrardeps)
  appendVar('RRECOMMENDS_${PN}', extrarrecs)



--
Kai Kang

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

Re: [OE-core] [PATCH] multilib.bbclass: fix qa warning of kernel-devicetree

[Kang Kai]

On 2019/11/19 上午11:15, kai.k...@windriver.com wrote:

From: Kai Kang 

When kernel-devicetree is in RRECOMMENDS such as via variable
MACHINE_EXTRA_RRECOMMENDS for some bsp, it shows QA warning of multilib:

| WARNING: lib32-packagegroup-base-1.0-r83 do_package: QA Issue:
| lib32-packagegroup-base package lib32-packagegroup-machine-base
| - suspicious values 'kernel-devicetree' in RRECOMMENDS [multilib]

Add kernel-devicetree to exceptions to fix the QA issue. Because there
are already 3 kernel related criteria, simplify them by judging package
names whether start with 'kernel-'. And also refactor to remove
duplicate 'not'.


Any comment please?

Regards,
Kai




Signed-off-by: Kai Kang 
---
  meta/classes/multilib.bbclass | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 1a9295d36f..ee677da1e2 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -184,11 +184,12 @@ python do_package_qa_multilib() {
  for i in values:
  if i.startswith('virtual/'):
  i = i[len('virtual/'):]
-if (not i.startswith('kernel-module')) and (not 
i.startswith(mlprefix)) and \
-(not 'cross-canadian' in i) and (not 
i.startswith("nativesdk-")) and \
-(not i.startswith("rtld")) and (not 
i.startswith('kernel-vmlinux')) \
-and (not i.startswith("kernel-image")) and (not 
i.startswith("/")):
+
+if (not (i.startswith(mlprefix) or i.startswith("kernel-") \
+or ('cross-canadian' in i) or i.startswith("nativesdk-") \
+or i.startswith("rtld") or i.startswith("/"))):
  candidates.append(i)
+
  if len(candidates) > 0:
  msg = "%s package %s - suspicious values '%s' in %s" \
 % (d.getVar('PN'), pkg, ' '.join(candidates), var)



--
Kai Kang

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

Re: [OE-core] [PATCH] systemd: provides ${base_sbindir}/udevadm for backward compatible

[Kang Kai]

On 2019/9/2 下午9:16, kai.k...@windriver.com wrote:

From: Kai Kang 

Create link file ${base_sbindir}/udevadm for backward compatible that
some existing udev rules require it. eudev has the link file already.


Ping.




Signed-off-by: Kai Kang 
---
  meta/recipes-core/systemd/systemd_242.bb | 4 
  1 file changed, 4 insertions(+)

diff --git a/meta/recipes-core/systemd/systemd_242.bb 
b/meta/recipes-core/systemd/systemd_242.bb
index 6fbb854886..55661cdf7a 100644
--- a/meta/recipes-core/systemd/systemd_242.bb
+++ b/meta/recipes-core/systemd/systemd_242.bb
@@ -281,6 +281,9 @@ do_install() {
fi
fi
  
+	# create link for existing udev rules

+   ln -s ${base_bindir}/udevadm ${D}${base_sbindir}/udevadm
+
# duplicate udevadm for postinst script
install -d ${D}${libexecdir}
ln ${D}${base_bindir}/udevadm ${D}${libexecdir}/${MLPREFIX}udevadm
@@ -598,6 +601,7 @@ FILES_udev += "${base_sbindir}/udevd \
 ${systemd_unitdir}/system/*udev* \
 ${systemd_unitdir}/system/*.wants/*udev* \
 ${base_bindir}/udevadm \
+   ${base_sbindir}/udevadm \
 ${libexecdir}/${MLPREFIX}udevadm \
 ${datadir}/bash-completion/completions/udevadm \
"



--
Kai Kang

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

Re: [OE-core] [PATCH 3/3] sysstat: 12.1.3 -> 12.1.6

[Kang Kai]

On 2019/9/4 下午5:01, kai.k...@windriver.com wrote:

From: Kai Kang 

Update sysstat from 12.1.3 to 12.1.6.

* remove sysstat.service and use the one from sysstat itself


After Qi's reminder, I checked the history that sysstat.service should 
not be removed.


v2 will be sent.

Regards,
Kai



* make sa_lib_dir refer to ${libexecdir}/sa to fix conflictions when
   multilib is enabled

Signed-off-by: Kai Kang 
---
  meta/recipes-extended/sysstat/sysstat.inc|  5 ++---
  .../recipes-extended/sysstat/sysstat/sysstat.service | 12 
  .../sysstat/{sysstat_12.1.3.bb => sysstat_12.1.6.bb} |  4 ++--
  3 files changed, 4 insertions(+), 17 deletions(-)
  delete mode 100644 meta/recipes-extended/sysstat/sysstat/sysstat.service
  rename meta/recipes-extended/sysstat/{sysstat_12.1.3.bb => sysstat_12.1.6.bb} 
(53%)

diff --git a/meta/recipes-extended/sysstat/sysstat.inc 
b/meta/recipes-extended/sysstat/sysstat.inc
index 592cbf4574..c3cc2c3374 100644
--- a/meta/recipes-extended/sysstat/sysstat.inc
+++ b/meta/recipes-extended/sysstat/sysstat.inc
@@ -4,9 +4,8 @@ HOMEPAGE = "http://sebastien.godard.pagesperso-orange.fr/;
  LICENSE = "GPLv2+"
  SECTION = "console/utils"
  
-SRC_URI = "http://pagesperso-orange.fr/sebastien.godard/sysstat-${PV}.tar.xz \

+SRC_URI = "http://pagesperso-orange.fr/sebastien.godard/${BP}.tar.xz \
 file://99_sysstat \
-   file://sysstat.service \
"
  
  UPSTREAM_CHECK_URI = "http://sebastien.godard.pagesperso-orange.fr/download.html;

@@ -29,7 +28,7 @@ SYSTEMD_SERVICE_${PN} = "sysstat.service"
  SYSTEMD_AUTO_ENABLE = "enable"
  
  do_configure_prepend() {

-export sa_lib_dir=${libdir}/sa
+export sa_lib_dir=${libexecdir}/sa
  }
  
  do_install() {

diff --git a/meta/recipes-extended/sysstat/sysstat/sysstat.service 
b/meta/recipes-extended/sysstat/sysstat/sysstat.service
deleted file mode 100644
index aff07109f5..00
--- a/meta/recipes-extended/sysstat/sysstat/sysstat.service
+++ /dev/null
@@ -1,12 +0,0 @@
-[Unit]
-Description=Resets System Activity Logs
-
-[Service]
-Type=oneshot
-RemainAfterExit=yes
-User=root
-ExecStart=@LIBDIR@/sa/sa1 --boot
-
-[Install]
-WantedBy=multi-user.target
-
diff --git a/meta/recipes-extended/sysstat/sysstat_12.1.3.bb 
b/meta/recipes-extended/sysstat/sysstat_12.1.6.bb
similarity index 53%
rename from meta/recipes-extended/sysstat/sysstat_12.1.3.bb
rename to meta/recipes-extended/sysstat/sysstat_12.1.6.bb
index 5daf3f45f5..8cf8c36d9b 100644
--- a/meta/recipes-extended/sysstat/sysstat_12.1.3.bb
+++ b/meta/recipes-extended/sysstat/sysstat_12.1.6.bb
@@ -4,5 +4,5 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=a23a74b3f4caf9616230789d94217acb"
  
  SRC_URI += "file://0001-Include-needed-headers-explicitly.patch"
  
-SRC_URI[md5sum] = "0f9b73f60aba6fd49de346bc384902c3"

-SRC_URI[sha256sum] = 
"55498bf82755ba9fed3e7df61fd26f8f50dd3e7b3b229c731029a4c8ab51a1aa"
+SRC_URI[md5sum] = "d8e3bbb9c873dd370f6d33664e326570"
+SRC_URI[sha256sum] = 
"f752f3c406153a6fc446496f1102872505ace3f0931d975c1d664c81ec09f129"



--
Kai Kang

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

Re: [OE-core] [PATCH V3] nfs-utils: decrease RLIMIT_NOFILE to 4k for systemd

[Kang Kai]

On 2019/8/28 上午7:29, richard.pur...@linuxfoundation.org wrote:

On Tue, 2019-08-27 at 17:43 +0800, Kang Kai wrote:

Hi Richard,

This patch could fix the test_image failure with systemd. Would like
to
try systemd as default init manager on yocto build again
to check whether any more blocking issues?


There is at least one issue:

https://autobuilder.yoctoproject.org/typhoon/#/builders/67/builds/967

Please monitor this build which should show up any other issues:


Got it. Thanks.




https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/645

(master-next was looking green other than this change).


It fails with libedit-native do fetch errors. I'll check it but it seems 
not systemd related at first sight.


Regards,
Kai




Cheers,

Richard




--
Kai Kang

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

Re: [OE-core] [PATCH V3] nfs-utils: decrease RLIMIT_NOFILE to 4k for systemd

[Kang Kai]

On 2019/8/20 下午1:45, Hongxu Jia wrote:

On systemd, it set RLIMIT_NOFILE to 512k, since do_testimage
for core-image-sato-sdk has memory limitation (256Mib) which
caused rpc.statd failed with out of memory.
[  531.306146] Out of memory: Kill process 193 (rpc.statd) score 200 or 
sacrifice child

The rpc.statd and rpc.mountd allocates memory according to
RLIMIT_NOFILE, so decrease it to 4k to keep sync with sysvinit


Hi Richard,

This patch could fix the test_image failure with systemd. Would like to 
try systemd as default init manager on yocto build again

to check whether any more blocking issues?

Thanks,
Kai




After applying the patch, the memory cost is the same with sysvinit:

root@qemux86-64:~# systemctl status nfs-statd
* nfs-statd.service - NFS status monitor for NFSv2/3 locking.
Loaded: loaded (/lib/systemd/system/nfs-statd.service; enabled; vendor 
preset: enabled)
Active: active (running) since Tue 2019-08-20 03:16:18 UTC; 3min 26s ago
  Main PID: 343 (rpc.statd)
 Tasks: 1 (limit: 271)
Memory: 1.0M

root@qemux86-64:~# systemctl status nfs-mountd
* nfs-mountd.service - NFS Mount Daemon
Loaded: loaded (/etc/systemd/system/nfs-mountd.service; enabled; vendor 
preset: enabled)
Active: active (running) since Tue 2019-08-20 03:19:01 UTC; 1min 21s ago
  Main PID: 451 (rpc.mountd)
 Tasks: 1 (limit: 271)
Memory: 736.0K

Suggested-by: Chen Qi 
Signed-off-by: Hongxu Jia 
---
  meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service | 1 +
  meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-statd.service  | 1 +
  meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb   | 4 
  3 files changed, 6 insertions(+)

diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service
index 3c3a802..c01415d 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-mountd.service
@@ -11,6 +11,7 @@ ConditionPathExists=@SYSCONFDIR@/exports
  [Service]
  EnvironmentFile=-@SYSCONFDIR@/nfs-utils.conf
  ExecStart=@SBINDIR@/rpc.mountd -F $MOUNTD_OPTS
+LimitNOFILE=@HIGH_RLIMIT_NOFILE@
  
  [Install]

  WantedBy=multi-user.target
diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-statd.service 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-statd.service
index 6e196b8..4fa64e1 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-statd.service
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils/nfs-statd.service
@@ -8,6 +8,7 @@ After=network.target nss-lookup.target rpcbind.service
  [Service]
  EnvironmentFile=-@SYSCONFDIR@/nfs-utils.conf
  ExecStart=@SBINDIR@/rpc.statd -F $STATD_OPTS
+LimitNOFILE=@HIGH_RLIMIT_NOFILE@
  
  [Install]

  WantedBy=multi-user.target
diff --git a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb 
b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb
index ac4437b..28f9898 100644
--- a/meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb
+++ b/meta/recipes-connectivity/nfs-utils/nfs-utils_2.3.3.bb
@@ -119,6 +119,9 @@ do_compile_prepend() {
make clean
  }
  
+# Works on systemd only

+HIGH_RLIMIT_NOFILE ??= "4096"
+
  do_install_append () {
install -d ${D}${sysconfdir}/init.d
install -m 0755 ${WORKDIR}/nfsserver ${D}${sysconfdir}/init.d/nfsserver
@@ -133,6 +136,7 @@ do_install_append () {
install -m 0644 ${WORKDIR}/nfs-statd.service 
${D}${systemd_unitdir}/system/
sed -i -e 's,@SBINDIR@,${sbindir},g' \
-e 's,@SYSCONFDIR@,${sysconfdir},g' \
+   -e 's,@HIGH_RLIMIT_NOFILE@,${HIGH_RLIMIT_NOFILE},g' \
${D}${systemd_unitdir}/system/*.service
if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; 
then
install -m 0644 ${WORKDIR}/proc-fs-nfsd.mount 
${D}${systemd_unitdir}/system/



--
Kai Kang

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

Re: [OE-core] [PATCH] libwacom: add recipe

[Kang Kai]

On 2019/8/26 上午10:54, Khem Raj wrote:

On Sun, Aug 25, 2019 at 6:29 PM Kang Kai  wrote:

On 2019/8/23 下午6:21, Alexander Kanavin wrote:

On Fri, 23 Aug 2019 at 10:20,  wrote:

Package libinput has a package config 'libwacom'. When it is set,
package libwacom is required. So add the recipe of libwacom.


This recipe probably needs to go to meta-oe? Why oe-core?

Because libinput is in 
openembedded-core/meta/recipes-graphics/wayland/libinput_1.13.4.bb.
If package config 'libwacom' is enabled and libwacom belongs to meta-oe, then 
oe-core may need meta-oe.


there are many packageconfig options like that in oe-core, the key is
they are disabled by default.
idea is not to provide all the extended features with in oe-core


OK. I'll sent it to meta-oe.

Regards,
Kai




Regards,
Kai



Alex


--
Kai Kang

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



--
Kai Kang

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

Re: [OE-core] [PATCH] libwacom: add recipe

[Kang Kai]

On 2019/8/23 下午6:21, Alexander Kanavin wrote:
On Fri, 23 Aug 2019 at 10:20, > wrote:


Package libinput has a package config 'libwacom'. When it is set,
package libwacom is required. So add the recipe of libwacom.


This recipe probably needs to go to meta-oe? Why oe-core?


Because libinput is in 
openembedded-core/meta/recipes-graphics/wayland/libinput_1.13.4.bb.
If package config 'libwacom' is enabled and libwacom belongs to meta-oe, 
then oe-core may need meta-oe.


Regards,
Kai




Alex



--
Kai Kang

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

Re: [OE-core] [PATCH 1/1] adwaita-icon-theme: workaround for do_populate_sysroot failure

[Kang Kai]

On 2019/8/21 上午3:19, Alexander Kanavin wrote:
On Tue, 20 Aug 2019 at 20:42, Ross Burton > wrote:


> It fails to run task do_populate_sysroot of adwaita-icon-theme
rarely:
>
> | DEBUG: Executing shell function sysroot_stage_all
> | cpio: ./icons/Adwaita/16x16/legacy/_inst.21134_: Cannot stat:
No such
>    file or directory
>
> In script ${S}/install-sh, temporary files _inst.* are created
and will be
> removed by shell builtin command trap when the script exits:
>
>      # Make a couple of temp file names in the proper directory.
>      dsttmp=${dstdirslash}_inst.$$_
>      rmtmp=${dstdirslash}_rm.$$_
>
>      # Trap to clean up those temp files at exit.
>      trap 'ret=$?; rm -f "$dsttmp" "$rmtmp" && exit $ret' 0
>
> The temporary files should be deleted already after task
do_install. But
> somehow they are still exist until the gap between commands find and
> cpio in populate_sysroot function sysroot_stage_dir().

So does this only happen to adwaita-icon-theme?  Is it a bug in
install-sh, so impacts almost every automake-using package?  Or is
it a
bug in how adwaita-icon-theme is using install-sh?


This might actually be caused by my glorious hack:
https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-gnome/gnome/adwaita-icon-theme/0001-Run-installation-commands-as-shell-jobs.patch?h=master-next

There is a 'wait' after every '&', so not sure what goes wrong here.


Hi Alex,

Thanks. I'll revert this commit locally. And if it is the root cause, 
I'll try to figure out what's going on here.


Kai




Alex



--
Kai Kang

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

Re: [OE-core] Conflict of systemd and sysvinit

[Kang Kai]

On 2019/8/18 上午3:27, Otavio Salvador wrote:

Hello,

I found a build error at master.

Collected errors:
  * check_data_file_clashes: Package systemd wants to install file
.../rootfs/sbin/telinit
 But that file is already provided by package  * sysvinit

Can someone take a look?


Hi Otavio,

Would you like to give more detailed steps how the error occurred? And 
what's extra settings in you local.conf please?


Thanks,
Kai





--
Kai Kang

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

[Kang Kai]

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
  total    used    free  shared buff/cache   
available

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

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

Mem:  239Mi    45Mi   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  NI    VIRT    RES    SHR 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  NI    VIRT    RES    SHR S  %CPU  %MEM TIME+ COMMAND
  567 rpcuser   20   0    3444   2372   1792 S   0.0   1.0 0:00.00 
rpc.statd
  677 root  20   0    3700    448  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






Regards,
Kai







Regards,
Kai



Cheers,

Richard








--
Kai Kang

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

[Kang Kai]

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
  total    used    free  shared buff/cache   
available

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

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

Mem:  239Mi    45Mi   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  NI    VIRT    RES    SHR 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  NI    VIRT    RES    SHR S  %CPU  %MEM TIME+ COMMAND
  567 rpcuser   20   0    3444   2372   1792 S   0.0   1.0 0:00.00 
rpc.statd
  677 root  20   0    3700    448  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"


Regards,
Kai







Regards,
Kai



Cheers,

Richard






--
Kai Kang

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

Re: [OE-core] [PATCH] webkitgtk: Reenable on mips

[Kang Kai]

On 2019/7/29 下午7:37, Adrian Bunk wrote:

It builds using the generic C_LOOP code.

Signed-off-by: Adrian Bunk 
---
  meta/recipes-gnome/epiphany/epiphany_3.32.3.bb | 3 ---
  meta/recipes-sato/webkit/webkitgtk_2.24.2.bb   | 4 +---
  2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/meta/recipes-gnome/epiphany/epiphany_3.32.3.bb 
b/meta/recipes-gnome/epiphany/epiphany_3.32.3.bb
index d1c6af52ed..de1b6e2f84 100644
--- a/meta/recipes-gnome/epiphany/epiphany_3.32.3.bb
+++ b/meta/recipes-gnome/epiphany/epiphany_3.32.3.bb
@@ -16,8 +16,5 @@ SRC_URI = 
"${GNOME_MIRROR}/${GNOMEBN}/${@gnome_verdir("${PV}")}/${GNOMEBN}-${PV}
  SRC_URI[archive.md5sum] = "c4976507bf3de69f27a050ad09531f5a"
  SRC_URI[archive.sha256sum] = 
"3ccb6859a43b839b714aa425cb185056f1e8604adbaab6a1bc179d1ba641a33f"
  
-# webkitgtk doesn't work with tune 'mips'

-COMPATIBLE_HOST_mipsarch = "${@bb.utils.contains('DEFAULTTUNE', 'mips', 'null', 
'mips.*-linux', d)}"
-
  FILES_${PN} += "${datadir}/dbus-1 ${datadir}/gnome-shell/search-providers 
${datadir}/metainfo"
  RDEPENDS_${PN} = "iso-codes adwaita-icon-theme gsettings-desktop-schemas"
diff --git a/meta/recipes-sato/webkit/webkitgtk_2.24.2.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.24.2.bb
index 891266b220..7f01c4e26d 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.24.2.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.24.2.bb
@@ -43,8 +43,6 @@ DEPENDS = "zlib libsoup-2.4 curl libxml2 cairo libxslt libxt 
libidn libgcrypt \
   gettext-native glib-2.0 glib-2.0-native libtasn1 \
"
  
-COMPATIBLE_HOST_mipsarch = "${@bb.utils.contains('DEFAULTTUNE', 'mips', 'null', 'mips.*-linux', d)}"

-
  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', 
'wayland' ,d)} \
 ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'webgl 
opengl', '' ,d)} \
 enchant \
@@ -97,7 +95,7 @@ EXTRA_OECMAKE_append_mipsarch = " -DUSE_LD_GOLD=OFF "
  EXTRA_OECMAKE_append_powerpc = " -DUSE_LD_GOLD=OFF "
  
  # JIT not supported on MIPS either

-EXTRA_OECMAKE_append_mipsarch = " -DENABLE_JIT=OFF "
+EXTRA_OECMAKE_append_mipsarch = " -DENABLE_JIT=OFF -DENABLE_C_LOOP=ON "



Thanks. It works for me.

Regards,
Kai

  
  # JIT not supported on X32

  # An attempt was made to upstream JIT support for x32 in



--
Kai Kang

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

[Kang Kai]

On 2019/7/27 下午4:35, Alexander Kanavin wrote:
I think you need to re-generate the image first (it goes to qemuboot 
config file). It is already used in ptest images, so it’s good to be 
consistent.


Thank. It works for testimage with setting QB_MEM. For the other 2 
images which has been set QB_MEM are ptest images just as you said
(core-image-sato-ptest-fast and core-image-sato-sdk-ptest). But for 
core-image-sato-sdk, it affects runqemu beyond testiamge. I just wonder

is that acceptable?

Regards,
Kai



Alex

On 27 Jul 2019, at 4.35, Kang Kai <mailto:kai.k...@windriver.com>> wrote:



On 2019/7/26 下午6:11, Alexander Kanavin wrote:

I think you need to use QB_MEM here.


Used TEST_QEMUPARAMS because I found the following line in 
testimage.bbclass:


# TEST_QEMUPARAMS can be used to pass extra parameters to qemu, e.g. 
"-m 1024" for setting the amount o f ram to 1 GB.



And it seems QB_MEM is not used when boot the qemu during testimage.




Also, maybe we should just bump the 256M default?


I hope so.


Regards,
Kai




Alex

On Fri, 26 Jul 2019 at 12:24, <mailto:kai.k...@windriver.com>> wrote:


From: Kai Kang mailto:kai.k...@windriver.com>>

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 mailto:kai.k...@windriver.com>>
---
 meta/recipes-sato/images/core-image-sato-sdk.bb
<http://core-image-sato-sdk.bb> | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-sato/images/core-image-sato-sdk.bb
<http://core-image-sato-sdk.bb>
b/meta/recipes-sato/images/core-image-sato-sdk.bb
<http://core-image-sato-sdk.bb>
index d7cc52b52b..f7963d018e 100644
--- a/meta/recipes-sato/images/core-image-sato-sdk.bb
<http://core-image-sato-sdk.bb>
+++ b/meta/recipes-sato/images/core-image-sato-sdk.bb
<http://core-image-sato-sdk.bb>
@@ -9,3 +9,4 @@ IMAGE_FEATURES += "dev-pkgs tools-sdk \

 IMAGE_INSTALL += "kernel-devsrc"

+TEST_QEMUPARAMS = "-m 512"
-- 
2.20.0


-- 
___

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



--
Kai Kang



--
Kai Kang

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

[Kang Kai]

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.


Regards,
Kai



Cheers,

Richard




--
Kai Kang

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

[Kang Kai]

On 2019/7/26 下午6:11, Alexander Kanavin wrote:

I think you need to use QB_MEM here.


Used TEST_QEMUPARAMS because I found the following line in 
testimage.bbclass:


# TEST_QEMUPARAMS can be used to pass extra parameters to qemu, e.g. "-m 
1024" for setting the amount o f ram to 1 GB.



And it seems QB_MEM is not used when boot the qemu during testimage.




Also, maybe we should just bump the 256M default?


I hope so.


Regards,
Kai




Alex

On Fri, 26 Jul 2019 at 12:24, > wrote:


From: Kai Kang mailto:kai.k...@windriver.com>>

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 mailto:kai.k...@windriver.com>>
---
 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"
-- 
2.20.0


-- 
___

Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

http://lists.openembedded.org/mailman/listinfo/openembedded-core



--
Kai Kang

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

Re: [OE-core] [PATCH 2/2] epiphany: set imcompatible with tune mips

[Kang Kai]

On 2019/7/26 下午6:09, Alexander Kanavin wrote:
Wait, does this mean that the line must be inserted into all of the 
recipes that depend on webkitgtk (wihch is very awkward)? Shouldn't 
just the webkitgtk recipe fix be enough?


Unfortunately, yes. But there is only one recipe epiphany in oe-core. I 
think it doesn't need to pay too much attention for mips arch too.


Kai



Alex

On Fri, 26 Jul 2019 at 12:35, > wrote:


From: Kai Kang mailto:kai.k...@windriver.com>>

webkitgtk doesn't work with tune mips and set imcompatible with it.
epiphany depends on webkitgtk and mask it too.

Signed-off-by: Kai Kang mailto:kai.k...@windriver.com>>
---
 meta/recipes-gnome/epiphany/epiphany_3.32.3.bb
 | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-gnome/epiphany/epiphany_3.32.3.bb

b/meta/recipes-gnome/epiphany/epiphany_3.32.3.bb

index de1b6e2f84..d1c6af52ed 100644
--- a/meta/recipes-gnome/epiphany/epiphany_3.32.3.bb

+++ b/meta/recipes-gnome/epiphany/epiphany_3.32.3.bb

@@ -16,5 +16,8 @@ SRC_URI =
"${GNOME_MIRROR}/${GNOMEBN}/${@gnome_verdir("${PV}")}/${GNOMEBN}-${PV}
 SRC_URI[archive.md5sum] = "c4976507bf3de69f27a050ad09531f5a"
 SRC_URI[archive.sha256sum] =
"3ccb6859a43b839b714aa425cb185056f1e8604adbaab6a1bc179d1ba641a33f"

+# webkitgtk doesn't work with tune 'mips'
+COMPATIBLE_HOST_mipsarch = "${@bb.utils.contains('DEFAULTTUNE',
'mips', 'null', 'mips.*-linux', d)}"
+
 FILES_${PN} += "${datadir}/dbus-1
${datadir}/gnome-shell/search-providers ${datadir}/metainfo"
 RDEPENDS_${PN} = "iso-codes adwaita-icon-theme
gsettings-desktop-schemas"
-- 
2.20.0


-- 
___

Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

http://lists.openembedded.org/mailman/listinfo/openembedded-core



--
Kai Kang

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

[Kang Kai]

On 2019/7/24 上午3:30, richard.pur...@linuxfoundation.org wrote:

On Mon, 2019-07-22 at 23:26 +, Mittal, Anuj wrote:

On Mon, 2019-07-22 at 09:37 +0800, Kang Kai wrote:

I just run oe-selftest -a with this patch after you updated the
patch
in
oe-core. But I met some (>15) errors

ERROR: Unable to start bitbake server (None)

But I think it should not be related with init manager changes and
will
change a build machine to test.
Do you have test it again in autobuilder and any failure found?
Thanks.

Not sure if these have been reported but there are some failures in
runtime tests which look related to this change:

https://autobuilder.yoctoproject.org/typhoon/#/builders/38/builds/855/steps/8/logs/step1c

https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/852/steps/8/logs/step1c

https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/856/steps/8/logs/step2c

I did a back to back build comparision with and without the init system
change.

Basically every failure in:

https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/297



It fails with

$ bitbake core-image-sato-sdk -c testimage

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

It checks failed systemd services and got one:

UNIT  LOAD   ACTIVE SUB DESCRIPTION
● nfs-statd.service loaded failed failed NFS status monitor for NFSv2/3 
locking.



But when boot the qemu image or only run systemd testcases( with its 
dependenies), no such failure.

I doubt it may be affected by other test cases.

Regards,
Kai



seems to be due to the init system default change so we have some
issues in there to resolve before we can change the default.

Cheers,

Richard




--
Kai Kang

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

[Kang Kai]

On 2019/7/20 上午6:28, richard.pur...@linuxfoundation.org wrote:

On Fri, 2019-07-19 at 22:35 +0100, Burton, Ross wrote:

On Thu, 4 Jul 2019 at 15:40,  wrote:

+++ b/meta/conf/distro/include/init-manager-systemd.inc
@@ -0,0 +1,6 @@
+# Use systemd for system initialization
+DISTRO_FEATURES_append = " systemd"
+DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " sysvinit"
+VIRTUAL-RUNTIME_init_manager = "systemd"
+VIRTUAL-RUNTIME_initscripts = "systemd-compat-units"
+VIRTUAL-RUNTIME_login_manager = "shadow-base"
diff --git a/meta/conf/distro/include/init-manager-sysvinit.inc
b/meta/conf/distro/include/init-manager-sysvinit.inc
new file mode 100644
index 00..7725b30e1e
--- /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"

Back when I integrated systemd into oe-core one of the use cases was
a single distro that builds a main image using systemd, and a
rescue/update image using sysv/busybox.  How is this possible with
this system?



Hi Richard,


We're still missing one or two init system setup variants,


What kind of missing variants do you mean?



I was
planning to add those and convert our autobuilder tests over to use
them rather than the fragements that are currently coded into
autobuilder-helper.



I just run oe-selftest -a with this patch after you updated the patch in 
oe-core. But I met some (>15) errors


ERROR: Unable to start bitbake server (None)

But I think it should not be related with init manager changes and will 
change a build machine to test.

Do you have test it again in autobuilder and any failure found? Thanks.

Regards,
Kai





Personally, I'd prefer to see the DISTRO_FEATURE wrangling left out
of those files, and let the user ensure the right features are set.
After all, systemd will refuse to build unless the systemd feature is
enabled.

With the addition of the "none" default, users aren't being forced to
use them so that can do something custom or use a precanned default
which I think gives the best of both worlds?

Cheers,

Richard




--
Kai Kang

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

Re: [OE-core] [PATCH] cogl-1.0.inc: set RDEPENDS_${PN}-dev = ""

[Kang Kai]

On 2019/7/17 下午6:46, Adrian Ratiu wrote:

On Wed, 17 Jul 2019, Kang Kai  wrote:
Hi


On 2019/7/17 下午3:48, Adrian Ratiu wrote:
${PN}-dev by default depends on ${PN} but in this case ${PN} is 
empty by design (FILES_${PN} = "") and is not created, leading to 
installation dependency errors like the following:
Collected errors:   * Solver encountered 1 problem(s): * Problem 
1/1: *   -   nothing provides cogl-1.0 = 1.22.2-r0 needed by   
cogl-1.0-dev-1.22.2-r0.armv7at2hf-neon-imx * * Solution 1: *   - do 
not ask to install a package providing cogl-1.0-dev 


I think what you need is
ALLOW_EMPTY_${PN} = "1"


Why is creating and depending on an empty package better than not 
creating and depending on it at all?


I thought it is conventional way to solve such dependency issue. After I 
grepped recipes, there are similar solutions there.

So fine with your patch.

Kai





From what I can see in other recipes both methods are used.





Regards,
Kai




Signed-off-by: Adrian Ratiu 
---
  meta/recipes-graphics/cogl/cogl-1.0.inc | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/meta/recipes-graphics/cogl/cogl-1.0.inc 
b/meta/recipes-graphics/cogl/cogl-1.0.inc

index 3e392fa5ec..a388023a03 100644
--- a/meta/recipes-graphics/cogl/cogl-1.0.inc
+++ b/meta/recipes-graphics/cogl/cogl-1.0.inc
@@ -75,4 +75,6 @@ RPROVIDES_libcogl = "cogl-1.0"
  RCONFLICTS_libcogl = "cogl-1.0"
  RREPLACES_libcogl = "cogl-1.0"
  +RDEPENDS_${PN}-dev = ""
+
  COMPATIBLE_HOST_armv4 = 'null'



--
Kai Kang




--
Kai Kang

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

Re: [OE-core] [PATCH] webkitgtk: set incomptible with tune mips

[Kang Kai]

On 2019/7/17 下午4:18, Khem Raj wrote:

oh COMPATIBLE_HOST_mipsarch threw me off. do we need to use the
override when the specific check
is done on right hand side?


I didn't figure out a better way to reset COMPATIBLE_HOST only for 
default tune 'mips'.  Without override _mipsarch,
I need to list all the COMPATIBLE_HOSTs such as 
"(i.86|x86_64|arm|aarch64|mips|powerpc|powerpc64).*-linux'" in the *else*

part of bb.utils.contains().

Regards,
Kai




On Tue, Jul 16, 2019 at 11:51 PM Kang Kai  wrote:

On 2019/7/17 下午2:20, Khem Raj wrote:

Right so we should only disable the tunes which don’t have clz and not all mips 
as this patch is doing

The patch only set COMPATILE_HOST to null  only when default tune is 'mips' 
which causes webkitgtk fails.
And for other conditions, it doesn't block to build that the COMPATILE_HOST is 
'mips.*-linux'.  Such as the
default bsps qemumips(default tune mips32r2) and qemumips64(mips64r2), it 
doesn't affect them.

Kai



On Tue, Jul 16, 2019 at 10:42 PM Kang Kai  wrote:

On 2019/7/16 下午11:33, Khem Raj wrote:



On Tue, Jul 16, 2019 at 2:33 AM Kang Kai  wrote:

On 2019/7/16 下午3:19, Khem Raj wrote:

On Mon, Jul 15, 2019 at 3:21 AM  wrote:

From: Kai Kang 

It fails to compile webkit when default tune is 'mips':

| .../tmp-glibc/work/mips-wrs-linux/webkitgtk/2.24.2-r0/webkitgtk-2.24.2
| /Source/JavaScriptCore/assembler/MacroAssemblerMIPS.h:418:23:
| error: static assertion failed: CLZ opcode is not available for this ISA

So don't build webkit when default tune is mips.

Signed-off-by: Kai Kang 
---
   meta/recipes-sato/webkit/webkitgtk_2.24.2.bb | 2 ++
   1 file changed, 2 insertions(+)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.24.2.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.24.2.bb
index 056334fff5..891266b220 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.24.2.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.24.2.bb
@@ -43,6 +43,8 @@ DEPENDS = "zlib libsoup-2.4 curl libxml2 cairo libxslt libxt 
libidn libgcrypt \
 gettext-native glib-2.0 glib-2.0-native libtasn1 \
 "

+COMPATIBLE_HOST_mipsarch = "${@bb.utils.contains('DEFAULTTUNE', 'mips', 'null', 
'mips.*-linux', d)}"
+

this disables is for all kind of mips. I think thats a broad set, it
would be best to narrow it to what you saw it failing for
e.g. it should work for mips32 and mips64 so maybe mips1 is what you
want to disable for

I tested with qemumips and qemumips64. When set

DEFAULTTUNE= "mips"


How about using mips32 and mips64 for default tune and retest


It build webkitgtk successfully on qemumips and qemumips64 with default tune 
mips32 and mips64.




It fails with the error.

Regards,
Kai




   PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', 
'wayland' ,d)} \
  ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'webgl 
opengl', '' ,d)} \
  enchant \
--
2.20.0

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


--
Kai Kang


--
Kai Kang


--
Kai Kang



--
Kai Kang

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

Re: [OE-core] [PATCH] cogl-1.0.inc: set RDEPENDS_${PN}-dev = ""

[Kang Kai]

On 2019/7/17 下午3:48, Adrian Ratiu wrote:

${PN}-dev by default depends on ${PN} but in this case ${PN} is empty
by design (FILES_${PN} = "") and is not created, leading to
installation dependency errors like the following:

Collected errors:
  * Solver encountered 1 problem(s):
  * Problem 1/1:
  *   - nothing provides cogl-1.0 = 1.22.2-r0 needed by 
cogl-1.0-dev-1.22.2-r0.armv7at2hf-neon-imx
  *
  * Solution 1:
  *   - do not ask to install a package providing cogl-1.0-dev



I think what you need is

ALLOW_EMPTY_${PN} = "1"


Regards,
Kai




Signed-off-by: Adrian Ratiu 
---
  meta/recipes-graphics/cogl/cogl-1.0.inc | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/meta/recipes-graphics/cogl/cogl-1.0.inc 
b/meta/recipes-graphics/cogl/cogl-1.0.inc
index 3e392fa5ec..a388023a03 100644
--- a/meta/recipes-graphics/cogl/cogl-1.0.inc
+++ b/meta/recipes-graphics/cogl/cogl-1.0.inc
@@ -75,4 +75,6 @@ RPROVIDES_libcogl = "cogl-1.0"
  RCONFLICTS_libcogl = "cogl-1.0"
  RREPLACES_libcogl = "cogl-1.0"
  
+RDEPENDS_${PN}-dev = ""

+
  COMPATIBLE_HOST_armv4 = 'null'



--
Kai Kang

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

Re: [OE-core] [PATCH] webkitgtk: set incomptible with tune mips

[Kang Kai]

On 2019/7/17 下午2:20, Khem Raj wrote:
Right so we should only disable the tunes which don’t have clz and not 
all mips as this patch is doing


The patch only set COMPATILE_HOST to null  only when default tune is 
'mips' which causes webkitgtk fails.
And for other conditions, it doesn't block to build that the 
COMPATILE_HOST is 'mips.*-linux'. 
<mailto:$%7B@bb.utils.contains('DEFAULTTUNE','mips','null','mips.*-linux',d)%7D>Such 
as the
default bsps qemumips(default tune mips32r2) and qemumips64(mips64r2), 
it doesn't affect them.


Kai




On Tue, Jul 16, 2019 at 10:42 PM Kang Kai <mailto:kai.k...@windriver.com>> wrote:


On 2019/7/16 下午11:33, Khem Raj wrote:



On Tue, Jul 16, 2019 at 2:33 AM Kang Kai mailto:kai.k...@windriver.com>> wrote:

On 2019/7/16 下午3:19, Khem Raj wrote:
> On Mon, Jul 15, 2019 at 3:21 AM mailto:kai.k...@windriver.com>> wrote:
>> From: Kai Kang mailto:kai.k...@windriver.com>>
>>
>> It fails to compile webkit when default tune is 'mips':
>>
>> |
.../tmp-glibc/work/mips-wrs-linux/webkitgtk/2.24.2-r0/webkitgtk-2.24.2
>> |
/Source/JavaScriptCore/assembler/MacroAssemblerMIPS.h:418:23:
>> | error: static assertion failed: CLZ opcode is not
available for this ISA
>>
>> So don't build webkit when default tune is mips.
>>
>> Signed-off-by: Kai Kang mailto:kai.k...@windriver.com>>
>> ---
>>   meta/recipes-sato/webkit/webkitgtk_2.24.2.bb
<http://webkitgtk_2.24.2.bb> | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/meta/recipes-sato/webkit/webkitgtk_2.24.2.bb
<http://webkitgtk_2.24.2.bb>
b/meta/recipes-sato/webkit/webkitgtk_2.24.2.bb
<http://webkitgtk_2.24.2.bb>
>> index 056334fff5..891266b220 100644
>> --- a/meta/recipes-sato/webkit/webkitgtk_2.24.2.bb
<http://webkitgtk_2.24.2.bb>
>> +++ b/meta/recipes-sato/webkit/webkitgtk_2.24.2.bb
<http://webkitgtk_2.24.2.bb>
>> @@ -43,6 +43,8 @@ DEPENDS = "zlib libsoup-2.4 curl libxml2
cairo libxslt libxt libidn libgcrypt \
>>             gettext-native glib-2.0 glib-2.0-native libtasn1 \
>>             "
>>
>> +COMPATIBLE_HOST_mipsarch =
"${@bb.utils.contains('DEFAULTTUNE', 'mips', 'null',
'mips.*-linux', d)}"

<mailto:$%7B@bb.utils.contains('DEFAULTTUNE','mips','null','mips.*-linux',d)%7D>
>> +
> this disables is for all kind of mips. I think thats a
broad set, it
> would be best to narrow it to what you saw it failing for
> e.g. it should work for mips32 and mips64 so maybe mips1 is
what you
> want to disable for

I tested with qemumips and qemumips64. When set

DEFAULTTUNE= "mips"


How about using mips32 and mips64 for default tune and retest



It build webkitgtk successfully on qemumips and qemumips64 with
default tune mips32 and mips64.





It fails with the error.

Regards,
Kai

>
>
>>   PACKAGECONFIG ??=
"${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11',
'wayland' ,d)} \
>> ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'webgl
opengl', '' ,d)} \
>>                      enchant \
>> --
>> 2.20.0
>>
>> --
    >> ___________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
<mailto:Openembedded-core@lists.openembedded.org>
>>
http://lists.openembedded.org/mailman/listinfo/openembedded-core


-- 
Kai Kang




-- 
Kai Kang




--
Kai Kang

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

Re: [OE-core] [PATCH] webkitgtk: set incomptible with tune mips

[Kang Kai]

On 2019/7/16 下午11:33, Khem Raj wrote:



On Tue, Jul 16, 2019 at 2:33 AM Kang Kai <mailto:kai.k...@windriver.com>> wrote:


On 2019/7/16 下午3:19, Khem Raj wrote:
> On Mon, Jul 15, 2019 at 3:21 AM mailto:kai.k...@windriver.com>> wrote:
>> From: Kai Kang mailto:kai.k...@windriver.com>>
>>
>> It fails to compile webkit when default tune is 'mips':
>>
>> |
.../tmp-glibc/work/mips-wrs-linux/webkitgtk/2.24.2-r0/webkitgtk-2.24.2
>> | /Source/JavaScriptCore/assembler/MacroAssemblerMIPS.h:418:23:
>> | error: static assertion failed: CLZ opcode is not available
for this ISA
>>
>> So don't build webkit when default tune is mips.
>>
>> Signed-off-by: Kai Kang mailto:kai.k...@windriver.com>>
>> ---
>>   meta/recipes-sato/webkit/webkitgtk_2.24.2.bb
<http://webkitgtk_2.24.2.bb> | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/meta/recipes-sato/webkit/webkitgtk_2.24.2.bb
<http://webkitgtk_2.24.2.bb>
b/meta/recipes-sato/webkit/webkitgtk_2.24.2.bb
<http://webkitgtk_2.24.2.bb>
>> index 056334fff5..891266b220 100644
>> --- a/meta/recipes-sato/webkit/webkitgtk_2.24.2.bb
<http://webkitgtk_2.24.2.bb>
>> +++ b/meta/recipes-sato/webkit/webkitgtk_2.24.2.bb
<http://webkitgtk_2.24.2.bb>
>> @@ -43,6 +43,8 @@ DEPENDS = "zlib libsoup-2.4 curl libxml2
cairo libxslt libxt libidn libgcrypt \
>>             gettext-native glib-2.0 glib-2.0-native libtasn1 \
>>             "
>>
>> +COMPATIBLE_HOST_mipsarch =
"${@bb.utils.contains('DEFAULTTUNE', 'mips', 'null',
'mips.*-linux', d)}"
>> +
> this disables is for all kind of mips. I think thats a broad set, it
> would be best to narrow it to what you saw it failing for
> e.g. it should work for mips32 and mips64 so maybe mips1 is what you
> want to disable for

I tested with qemumips and qemumips64. When set

DEFAULTTUNE= "mips"


How about using mips32 and mips64 for default tune and retest



It build webkitgtk successfully on qemumips and qemumips64 with default 
tune mips32 and mips64.






It fails with the error.

Regards,
Kai

>
>
>>   PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES',
'x11', 'x11', 'wayland' ,d)} \
>> ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'webgl
opengl', '' ,d)} \
>>                      enchant \
>> --
>> 2.20.0
>>
>> --
>> ___
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
<mailto:Openembedded-core@lists.openembedded.org>
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core


-- 
Kai Kang




--
Kai Kang

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

Re: [OE-core] [PATCH] webkitgtk: set incomptible with tune mips

[Kang Kai]

On 2019/7/16 下午3:19, Khem Raj wrote:

On Mon, Jul 15, 2019 at 3:21 AM  wrote:

From: Kai Kang 

It fails to compile webkit when default tune is 'mips':

| .../tmp-glibc/work/mips-wrs-linux/webkitgtk/2.24.2-r0/webkitgtk-2.24.2
| /Source/JavaScriptCore/assembler/MacroAssemblerMIPS.h:418:23:
| error: static assertion failed: CLZ opcode is not available for this ISA

So don't build webkit when default tune is mips.

Signed-off-by: Kai Kang 
---
  meta/recipes-sato/webkit/webkitgtk_2.24.2.bb | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.24.2.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.24.2.bb
index 056334fff5..891266b220 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.24.2.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.24.2.bb
@@ -43,6 +43,8 @@ DEPENDS = "zlib libsoup-2.4 curl libxml2 cairo libxslt libxt 
libidn libgcrypt \
gettext-native glib-2.0 glib-2.0-native libtasn1 \
"

+COMPATIBLE_HOST_mipsarch = "${@bb.utils.contains('DEFAULTTUNE', 'mips', 'null', 
'mips.*-linux', d)}"
+

this disables is for all kind of mips. I think thats a broad set, it
would be best to narrow it to what you saw it failing for
e.g. it should work for mips32 and mips64 so maybe mips1 is what you
want to disable for


I tested with qemumips and qemumips64. When set

DEFAULTTUNE= "mips"

It fails with the error.

Regards,
Kai





  PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', 
'wayland' ,d)} \
 ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'webgl 
opengl', '' ,d)} \
 enchant \
--
2.20.0

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



--
Kai Kang

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

[Kang Kai]

On 2019/7/6 下午8:31, 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.


How about keep a empty INIT_MANAGER by default, and check if 
INIT_MANAGER is set, then overwrite other configs such as
VIRTUAL-RUNTIME_init_manager whether is from user config or predefined 
value from config files or recipes? It could be done

in a anonymous function.

Regards,
Kai




Not sure quite what we should do here...

Cheers,

Richard





--
Kai Kang

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

[Kang Kai]

On 2019/7/8 上午10:01, Kang Kai wrote:

On 2019/7/6 下午5:53, 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.


It is a little weird. NO sysvinit in DISTRO_FEATURES. I'll check 
what's wrong with it w/o the VIRTUAL-RUNTIME patch.



I misunderstood your config. It is a problem when user wants to set 
init_manager directly.  Thanks for your trying.


Regards,
Kai




Regards,
Kai




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.

cu
Adrian





--
Kai Kang

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

[Kang Kai]

On 2019/7/6 下午5:53, 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.


It is a little weird. NO sysvinit in DISTRO_FEATURES. I'll check what's 
wrong with it w/o the VIRTUAL-RUNTIME patch.


Regards,
Kai




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.

cu
Adrian



--
Kai Kang

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

Re: [OE-core] [PATCH] gnome.bbclass: inherit upstream-version-is-even

[Kang Kai]

On 2019/6/11 下午4:41, Richard Purdie wrote:

On Tue, 2019-06-11 at 04:37 -0400, kai.k...@windriver.com wrote:

From: Kai Kang 

According to gnome versioning policy, "Even/odd minor package
versions
can be used respectively for stable/unstable releases.". Make
gnome.bbclass inherit upstream-version-is-even to comply with the
policy.

Ref:
https://developer.gnome.org/programming-guidelines/stable/versioning.html.en#stable-unstable-versions

Signed-off-by: Kai Kang 
---
  meta/classes/gnome.bbclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

The question is whether all recipes using the gnome class use the gnome
version policy? I'm not sure that is true?


My thought was gnome.bbclass inherits gnonebase.bbclass which means the 
sources from gnome and should comply the version policy of gnome.
But I check it again and find that some packages override the SRC_URI 
such as pavucontrol which doesn't obey the policy. Please ignore it.



Thanks,
Kai




Cheers,

Richard






--
Kai Kang

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

Re: [OE-core] [PATCH] json-c: update to current upstream head, with --disable-werror

[Kang Kai]

On 2019/6/11 上午11:04, Douglas Royds wrote:

On 11/06/19 2:46 PM, Kang Kai wrote:


On 2019/6/11 上午9:57, Douglas Royds via Openembedded-core wrote:

Upstream json-c haven't made a release since March 2018.
Adopt the current HEAD revision, pulling it directly from git.

icecc preprocesses source files locally before shipping them off to 
be compiled
on remote hosts. This preprocessing removes comments, including /* 
fallthough */
comments in switch statements that normally prevent an 
implicit-fallthrough

warning, see https://github.com/icecc/icecream/issues/419

Rather than turning off -Werror by patching configure.ac, the 
upstream project
has implemented a configure option, --disable-werror, in response to 
Ross's

https://github.com/json-c/json-c/issues/489

Signed-off-by: Douglas Royds 
---
  meta/recipes-devtools/json-c/json-c_0.13.1.bb | 30 
---

  meta/recipes-devtools/json-c/json-c_git.bb    | 19 


Use option '-M' of git format-patch may make the patch more clear. 
And why not just backport the 'disable-werror' commit?



Re '-M': True, fair point.

Re the backport: There hasn't been a release in over a year, they 
don't seem to have any plans to do so (see 
https://github.com/json-c/json-c/issues/487), and this was easier. If 
you have a substantial objection, yes, I could submit it again with a 
patch instead of the update.


Just consider footprint, git repo will take more space than tar ball. 
But no substantial objection.


Kai






Regards,
Kai



  2 files changed, 19 insertions(+), 30 deletions(-)
  delete mode 100644 meta/recipes-devtools/json-c/json-c_0.13.1.bb
  create mode 100644 meta/recipes-devtools/json-c/json-c_git.bb

diff --git a/meta/recipes-devtools/json-c/json-c_0.13.1.bb 
b/meta/recipes-devtools/json-c/json-c_0.13.1.bb

deleted file mode 100644
index 5b10e68297..00
--- a/meta/recipes-devtools/json-c/json-c_0.13.1.bb
+++ /dev/null
@@ -1,30 +0,0 @@
-SUMMARY = "C bindings for apps which will manipulate JSON data"
-DESCRIPTION = "JSON-C implements a reference counting object model 
that allows you to easily construct JSON objects in C."

-HOMEPAGE = "https://github.com/json-c/json-c/wiki;
-LICENSE = "MIT"
-LIC_FILES_CHKSUM = 
"file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2"

-
-SRC_URI = 
"https://s3.amazonaws.com/json-c_releases/releases/${BP}.tar.gz;

-SRC_URI[md5sum] = "04969ad59cc37bddd83741a08b98f350"
-SRC_URI[sha256sum] = 
"b87e608d4d3f7bfdd36ef78d56d53c74e66ab278d318b71e6002a369d36f4873"

-
-UPSTREAM_CHECK_REGEX = "json-c-(?P\d+(\.\d+)+).tar"
-# json-c releases page is fetching the list of releases in some 
weird XML format
-# from https://s3.amazonaws.com/json-c_releases and processes it 
with javascript :-/
-#UPSTREAM_CHECK_URI = 
"https://s3.amazonaws.com/json-c_releases/releases/index.html;

-RECIPE_UPSTREAM_VERSION = "0.13.1"
-RECIPE_UPSTREAM_DATE = "Mar 04, 2018"
-CHECK_DATE = "May 02, 2018"
-
-RPROVIDES_${PN} = "libjson"
-
-inherit autotools
-
-EXTRA_OECONF = "--enable-rdrand"
-
-do_configure_prepend() {
-    # Clean up autoconf cruft that should not be in the tarball
-    rm -f ${S}/config.status
-}
-
-BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-devtools/json-c/json-c_git.bb 
b/meta/recipes-devtools/json-c/json-c_git.bb

new file mode 100644
index 00..07daa5ba11
--- /dev/null
+++ b/meta/recipes-devtools/json-c/json-c_git.bb
@@ -0,0 +1,19 @@
+SUMMARY = "C bindings for apps which will manipulate JSON data"
+DESCRIPTION = "JSON-C implements a reference counting object model 
that allows you to easily construct JSON objects in C."

+HOMEPAGE = "https://github.com/json-c/json-c/wiki;
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = 
"file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2"

+
+SRC_URI = "git://github.com/json-c/json-c.git"
+SRCREV = "07ea04e65193c3e5c902c5b79421d5fa48ff67c7"
+S = "${WORKDIR}/git"
+
+RPROVIDES_${PN} = "libjson"
+
+inherit autotools
+
+EXTRA_OECONF = "--disable-werror \
+    --enable-rdrand \
+    "
+
+BBCLASSEXTEND = "native nativesdk"








--
Kai Kang

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

Re: [OE-core] [PATCH] json-c: update to current upstream head, with --disable-werror

[Kang Kai]

On 2019/6/11 上午9:57, Douglas Royds via Openembedded-core wrote:

Upstream json-c haven't made a release since March 2018.
Adopt the current HEAD revision, pulling it directly from git.

icecc preprocesses source files locally before shipping them off to be compiled
on remote hosts. This preprocessing removes comments, including /* fallthough */
comments in switch statements that normally prevent an implicit-fallthrough
warning, see https://github.com/icecc/icecream/issues/419

Rather than turning off -Werror by patching configure.ac, the upstream project
has implemented a configure option, --disable-werror, in response to Ross's
https://github.com/json-c/json-c/issues/489

Signed-off-by: Douglas Royds 
---
  meta/recipes-devtools/json-c/json-c_0.13.1.bb | 30 ---
  meta/recipes-devtools/json-c/json-c_git.bb| 19 


Use option '-M' of git format-patch may make the patch more clear. And 
why not just backport the 'disable-werror' commit?


Regards,
Kai



  2 files changed, 19 insertions(+), 30 deletions(-)
  delete mode 100644 meta/recipes-devtools/json-c/json-c_0.13.1.bb
  create mode 100644 meta/recipes-devtools/json-c/json-c_git.bb

diff --git a/meta/recipes-devtools/json-c/json-c_0.13.1.bb 
b/meta/recipes-devtools/json-c/json-c_0.13.1.bb
deleted file mode 100644
index 5b10e68297..00
--- a/meta/recipes-devtools/json-c/json-c_0.13.1.bb
+++ /dev/null
@@ -1,30 +0,0 @@
-SUMMARY = "C bindings for apps which will manipulate JSON data"
-DESCRIPTION = "JSON-C implements a reference counting object model that allows you 
to easily construct JSON objects in C."
-HOMEPAGE = "https://github.com/json-c/json-c/wiki;
-LICENSE = "MIT"
-LIC_FILES_CHKSUM = "file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2"
-
-SRC_URI = "https://s3.amazonaws.com/json-c_releases/releases/${BP}.tar.gz;
-SRC_URI[md5sum] = "04969ad59cc37bddd83741a08b98f350"
-SRC_URI[sha256sum] = 
"b87e608d4d3f7bfdd36ef78d56d53c74e66ab278d318b71e6002a369d36f4873"
-
-UPSTREAM_CHECK_REGEX = "json-c-(?P\d+(\.\d+)+).tar"
-# json-c releases page is fetching the list of releases in some weird XML 
format
-# from https://s3.amazonaws.com/json-c_releases and processes it with 
javascript :-/
-#UPSTREAM_CHECK_URI = 
"https://s3.amazonaws.com/json-c_releases/releases/index.html;
-RECIPE_UPSTREAM_VERSION = "0.13.1"
-RECIPE_UPSTREAM_DATE = "Mar 04, 2018"
-CHECK_DATE = "May 02, 2018"
-
-RPROVIDES_${PN} = "libjson"
-
-inherit autotools
-
-EXTRA_OECONF = "--enable-rdrand"
-
-do_configure_prepend() {
-# Clean up autoconf cruft that should not be in the tarball
-rm -f ${S}/config.status
-}
-
-BBCLASSEXTEND = "native nativesdk"
diff --git a/meta/recipes-devtools/json-c/json-c_git.bb 
b/meta/recipes-devtools/json-c/json-c_git.bb
new file mode 100644
index 00..07daa5ba11
--- /dev/null
+++ b/meta/recipes-devtools/json-c/json-c_git.bb
@@ -0,0 +1,19 @@
+SUMMARY = "C bindings for apps which will manipulate JSON data"
+DESCRIPTION = "JSON-C implements a reference counting object model that allows you 
to easily construct JSON objects in C."
+HOMEPAGE = "https://github.com/json-c/json-c/wiki;
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://COPYING;md5=de54b60fbbc35123ba193fea8ee216f2"
+
+SRC_URI = "git://github.com/json-c/json-c.git"
+SRCREV = "07ea04e65193c3e5c902c5b79421d5fa48ff67c7"
+S = "${WORKDIR}/git"
+
+RPROVIDES_${PN} = "libjson"
+
+inherit autotools
+
+EXTRA_OECONF = "--disable-werror \
+--enable-rdrand \
+"
+
+BBCLASSEXTEND = "native nativesdk"



--
Kai Kang

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

Re: [OE-core] [meta-poky][PATCH v6 0/2] Make systemd as default init manager and configure wired network

[Kang Kai]

On 2019/6/3 下午8:30, richard.pur...@linuxfoundation.org wrote:

On Sun, 2019-06-02 at 10:55 -0400, kai.k...@windriver.com wrote:

From: Kai Kang 

v6:
* create .inc files as Richard suggested, and include them according
to POKY_INIT_MANAGER

Kai Kang (2):
   poky.conf: make systemd as default init manager
   systemd-conf: configure wired network with dhcp

This is looking good, I do agree with Peter about the file naming.



OK.



I
ran it through the autobuilder to see where we are at runtime and the
results were not so good:

https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/484

We may need to reduce some of the free space in the ptest image and it
looks like there is an NFS startup failure issue in the sdk images.
There may be other issues in there too but those were the two I
immediately saw.


I'll check the issues one by one.

Regards,
Kai



Cheers,

Richard




--
Kai Kang

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

Re: [OE-core] [meta-poky][PATCH v4 1/3] poky.conf: make systemd as default init manager

[Kang Kai]

On 2019/5/31 下午5:00, richard.pur...@linuxfoundation.org wrote:

On Fri, 2019-05-31 at 10:07 +0800, Kang Kai wrote:

On 2019/5/30 下午7:44, richard.pur...@linuxfoundation.org wrote:

On Thu, 2019-05-30 at 05:22 -0400, kai.k...@windriver.com wrote:

From: Kai Kang 

Move configurations from local.conf.sample.extended to poky.conf
to
make
systemd as default init manager for poky. Introduce a new
variable
'POKY_INIT_MANAGER' whose value should be either 'systemd' or
'sysvinit'
to configure the init manager setting.

For users who still want to use sysvinit, set in local.conf or
any
other
configure file with:

POKY_INIT_MANAGER = "sysvinit"

[YOCTO #13031]

Signed-off-by: Kai Kang 
---
   meta-poky/conf/distro/poky.conf   | 10 ++
   meta-poky/conf/local.conf.sample.extended |  9 -
   2 files changed, 10 insertions(+), 9 deletions(-)

Thanks for working on this patchset, I think its nearly there. I'm
wondering if we should set

POKY_INIT_MANAGER_libc-musl = "sysvinit"

since I am worried about what I read about musl and systemd from a
security perspective.

OK. I'll add it.



I'm also wondering what we need to do with the autobuilder init
system
tests, I think those may need rewriting to add some sysvinit tests.

Something likes meta/lib/oeqa/runtime/cases/systemd.py? I think it
is better to do in next milestone and create a defect to address it.
If it is ok, I'll create one.

No, I mean:

http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/tree/config.json#n813

which corresponds to steps 5-7 of 'qa-extras2' on the autobuilder.

We're going to need to update the test configuration on master to cover
the things we no longer test and remove the duplication.


Does POKY_INIT_MANAGER = "sysvinit systemd" work for the mode where
we allow old sysvinit scripts for compatibility?

I am afraid only one value could be set for POKY_INIT_MANAGER. And I
believe that most packages have been supporting systemd. If there is,
we can add a systemd service file for it.

This isn't the point, we support 3 different configurations of this and
the variable needs to reflect that.

How about a slightly different approach. We define POKY_INIT_MANAGER to
take three different values, sysvinit, systemd and systemd-compat.

We do something like:

require conf/distro/include/init-template-${POKY_INIT_MANAGER}.inc

and then put the appropriate configuration in each .inc file?


BTW, POKY_INIT_MANAGER doesn't consider the case of mdev/busybox. If
want to use mdev/busybox for init, just set DISTRO with poky-tiny and
everything have been set properly in poky-tiny.conf.

This might be an opportunity to have another setting for
POKY_INIT_MANAGER which covers this too through an additional .inc?


Got it.

Regards,
Kai




Cheers,

Richard





--
Kai Kang

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

Re: [OE-core] [meta-poky][PATCH v4 1/3] poky.conf: make systemd as default init manager

[Kang Kai]

On 2019/5/30 下午7:44, richard.pur...@linuxfoundation.org wrote:

On Thu, 2019-05-30 at 05:22 -0400, kai.k...@windriver.com wrote:

From: Kai Kang 

Move configurations from local.conf.sample.extended to poky.conf to
make
systemd as default init manager for poky. Introduce a new variable
'POKY_INIT_MANAGER' whose value should be either 'systemd' or
'sysvinit'
to configure the init manager setting.

For users who still want to use sysvinit, set in local.conf or any
other
configure file with:

   POKY_INIT_MANAGER = "sysvinit"

[YOCTO #13031]

Signed-off-by: Kai Kang 
---
  meta-poky/conf/distro/poky.conf   | 10 ++
  meta-poky/conf/local.conf.sample.extended |  9 -
  2 files changed, 10 insertions(+), 9 deletions(-)

Thanks for working on this patchset, I think its nearly there. I'm
wondering if we should set

POKY_INIT_MANAGER_libc-musl = "sysvinit"

since I am worried about what I read about musl and systemd from a
security perspective.


OK. I'll add it.




I'm also wondering what we need to do with the autobuilder init system
tests, I think those may need rewriting to add some sysvinit tests.


Something likes meta/lib/oeqa/runtime/cases/systemd.py? I think it is 
better to do in next milestone and create a defect to address it.

If it is ok, I'll create one.




Does POKY_INIT_MANAGER = "sysvinit systemd" work for the mode where we
allow old sysvinit scripts for compatibility?


 I am afraid only one value could be set for POKY_INIT_MANAGER. And I 
believe that most packages have been supporting systemd. If there is,

we can add a systemd service file for it.

BTW, POKY_INIT_MANAGER doesn't consider the case of mdev/busybox. If 
want to use mdev/busybox for init, just set DISTRO with poky-tiny and

everything have been set properly in poky-tiny.conf.

Regards,
Kai




Cheers,

Richard




--
Kai Kang

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

Re: [OE-core] [PATCH v3 1/2] local.conf.sample: make systemd as default init manager

[Kang Kai]

On 2019/5/28 下午5:28, Paul Barker wrote:



On 27/05/2019 02:49, Kang Kai wrote:

On 2019/5/25 上午3:23, Peter Kjellerstedt wrote:

-Original Message-
From: Khem Raj 
Sent: den 23 maj 2019 22:59
To: Peter Kjellerstedt 
Cc: kai.k...@windriver.com; 
openembedded-core@lists.openembedded.org; 
richard.pur...@linuxfoundation.org
Subject: Re: [OE-core] [PATCH v3 1/2] local.conf.sample: make 
systemd as default init manager


On Thu, May 23, 2019 at 1:41 PM Peter Kjellerstedt 
<mailto:peter.kjellerst...@axis.com> wrote:

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

mailto:core-boun...@lists.openembedded.org> On Behalf Of
mailto:kai.k...@windriver.com
Sent: den 23 maj 2019 10:26
To: mailto:richard.pur...@linuxfoundation.org
Cc: mailto:openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH v3 1/2] local.conf.sample: make systemd as
default init manager

From: Kai Kang <mailto:kai.k...@windriver.com>

Move configurations from local.conf.sample.extended to 
local.conf.sample

to make systemd as default init manager for poky.
If we're going to change the default init manager to be systemd, 
wouldn't
it be more appropriate to change the real default values in 
bitbake.conf

and http://packagegroup-core-boot.bb? And then include an example in
local.conf.sample.extended to show how to configure sysvinit as init
manager?

That would change it for Oe-core and other distributions as well which
is not the intention
Ok, then I'd say the change belongs in poky.conf. Doing this kind of 
changes

in local.conf.sample seems very wrong to me. Why? Because if I have an
existing build tree it will not be affected, but if I setup a new 
tree with
oe-init-build-env it will all of a sudden behave differently from 
the old
tree. In my mind, local.conf.sample should only be used for things 
the user
are likely to want to configure to adapt the build for his/her 
environment,

not to define the distribution (that's what poky.conf is for).



If put the settings to poky.conf, it is complicated to override the 
settings and hard for users to turn back to sysvinit when he/she wants.


If you want to make this override-able you could do something like 
this (forgive any mistakes or bad wrapping I'm just writing this in my 
email client without testing):


POKY_USE_SYSTEMD ?= "1"
DISTRO_FEATURES_append = "${@bb.utils.conditional("POKY_USE_SYSTEMD", 
"1", "systemd", "", d)}"

... etc ...

That would allow someone to set `POKY_USE_SYSTEMD = "0"` in their 
local.conf.


There may be more elegant ways to do this as well, but we the default 
can certainly be set in the distro config in a way that can be 
overridden in local.conf.


OK. I'll move them to poky.conf.

Thanks.

Kai




Thanks,



--
Kai Kang

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

Re: [OE-core] [PATCH v3 1/2] local.conf.sample: make systemd as default init manager

[Kang Kai]

On 2019/5/25 上午3:23, Peter Kjellerstedt wrote:

-Original Message-
From: Khem Raj 
Sent: den 23 maj 2019 22:59
To: Peter Kjellerstedt 
Cc: kai.k...@windriver.com; openembedded-core@lists.openembedded.org; 
richard.pur...@linuxfoundation.org
Subject: Re: [OE-core] [PATCH v3 1/2] local.conf.sample: make systemd as 
default init manager

On Thu, May 23, 2019 at 1:41 PM Peter Kjellerstedt 
 wrote:

-Original Message-
From: mailto:openembedded-core-boun...@lists.openembedded.org mailto:core-boun...@lists.openembedded.org> On Behalf Of
mailto:kai.k...@windriver.com
Sent: den 23 maj 2019 10:26
To: mailto:richard.pur...@linuxfoundation.org
Cc: mailto:openembedded-core@lists.openembedded.org
Subject: [OE-core] [PATCH v3 1/2] local.conf.sample: make systemd as
default init manager

From: Kai Kang 

Move configurations from local.conf.sample.extended to local.conf.sample
to make systemd as default init manager for poky.

If we're going to change the default init manager to be systemd, wouldn't
it be more appropriate to change the real default values in bitbake.conf
and http://packagegroup-core-boot.bb? And then include an example in
local.conf.sample.extended to show how to configure sysvinit as init
manager?

That would change it for Oe-core and other distributions as well which
is not the intention

Ok, then I'd say the change belongs in poky.conf. Doing this kind of changes
in local.conf.sample seems very wrong to me. Why? Because if I have an
existing build tree it will not be affected, but if I setup a new tree with
oe-init-build-env it will all of a sudden behave differently from the old
tree. In my mind, local.conf.sample should only be used for things the user
are likely to want to configure to adapt the build for his/her environment,
not to define the distribution (that's what poky.conf is for).



If put the settings to poky.conf, it is complicated to override the 
settings and hard for users to turn back to sysvinit when he/she wants.
And every time updates local.conf.sample which is not just update 
comments, the old build and new build are differently, such as


commit 18bead102afabffcf3842ee099dcd22b8a598b8d
Author: Alexander Kanavin 
Date:   Wed Feb 27 18:47:33 2019 +0100

    local.conf.sample: adjust the qemu configuration to refer to 
qemu-system-native


    (From meta-yocto rev: aa16ed1b2c0f358d244a50a41be19d80935d3cc8)

    Signed-off-by: Alexander Kanavin 
    Signed-off-by: Richard Purdie 

diff --git a/meta-poky/conf/local.conf.sample 
b/meta-poky/conf/local.conf.sample

index 267108d685..9068e567dc 100644
--- a/meta-poky/conf/local.conf.sample
+++ b/meta-poky/conf/local.conf.sample
@@ -241,7 +241,7 @@ BB_DISKMON_DIRS ??= "\
 # seen. The two lines below enable the SDL backend too. By default 
libsdl2-native will
 # be built, if you want to use your host's libSDL instead of the 
minimal libsdl built

 # by libsdl2-native then uncomment the ASSUME_PROVIDED line below.
-PACKAGECONFIG_append_pn-qemu-native = " sdl"
+PACKAGECONFIG_append_pn-qemu-system-native = " sdl"
 PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
 #ASSUME_PROVIDED += "libsdl2-native"


and more earlier:

commit 63dcfa8f1394475073f6dbb5f3f6ede284d5a305
Author: Mark Hatle 
Date:   Mon Aug 15 16:29:34 2016 -0500

    Revert "local.conf.sample: Disable prelink by default"

    This reverts commit 300f858ba07c938427ccd05a3d7220027a03d461.

    Reenable prelink

    (From meta-yocto rev: 91705d8ae9f56d1de4f0fdcd6a9654b75921aa8c)

    Signed-off-by: Mark Hatle 
    Signed-off-by: Richard Purdie 

diff --git a/meta-poky/conf/local.conf.sample 
b/meta-poky/conf/local.conf.sample

index a7b2d8065d..365b6eb20c 100644
--- a/meta-poky/conf/local.conf.sample
+++ b/meta-poky/conf/local.conf.sample
@@ -152,8 +152,7 @@ EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
 #   - 'image-swab' to perform host system intrusion detection
 # NOTE: if listing mklibs & prelink both, then make sure mklibs is 
before prelink
 # NOTE: mklibs also needs to be explicitly enabled for a given image, 
see local.conf.extended

-# image-prelink disabled for now due to issues with IFUNC symbol relocation
-USER_CLASSES ?= "buildstats image-mklibs"
+USER_CLASSES ?= "buildstats image-mklibs image-prelink"

 #
 # Runtime testing of images


Regards,
Kai



//Peter



--
Kai Kang

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

Re: [OE-core] [PATCH v2 1/1] systemd-conf: configure wired network with dhcp

[Kang Kai]

On 2019/5/21 下午8:09, Richard Purdie wrote:

On Tue, 2019-05-21 at 05:22 -0400, kai.k...@windriver.com wrote:

From: Kai Kang 

Add a configure file for systemd.networkd to configure wired network
interfaces with dhcp. It works with common network interfaces such
eth0
and eno1.

Refer to
https://github.com/YoeDistro/meta-yoe/tree/master/recipes-core/systemd

[YOCTO #13057]

Signed-off-by: Kai Kang 
---
  meta/recipes-core/systemd/systemd-conf/dhcp.network | 9 +
  meta/recipes-core/systemd/systemd-conf_242.bb   | 5 +
  2 files changed, 14 insertions(+)
  create mode 100644 meta/recipes-core/systemd/systemd-
conf/dhcp.network

This seems to result in the failures in:

https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/617


Sorry, there was something wrong during my verify build and test. v3 
will be sent.


Regards,
Kai




Cheers,

Richard




--
Kai Kang

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

Re: [OE-core] [PATCH v2 1/1] systemd-conf: configure wired network with dhcp

[Kang Kai]

On 2019/5/22 上午1:37, Khem Raj wrote:

just copy paste from meta-yoe, that has been long working.

On Tue, May 21, 2019 at 2:23 AM  wrote:

From: Kai Kang 

Add a configure file for systemd.networkd to configure wired network
interfaces with dhcp. It works with common network interfaces such eth0
and eno1.

Refer to
https://github.com/YoeDistro/meta-yoe/tree/master/recipes-core/systemd

[YOCTO #13057]

Signed-off-by: Kai Kang 
---
  meta/recipes-core/systemd/systemd-conf/dhcp.network | 9 +
  meta/recipes-core/systemd/systemd-conf_242.bb   | 5 +
  2 files changed, 14 insertions(+)
  create mode 100644 meta/recipes-core/systemd/systemd-conf/dhcp.network

diff --git a/meta/recipes-core/systemd/systemd-conf/dhcp.network 
b/meta/recipes-core/systemd/systemd-conf/dhcp.network
new file mode 100644
index 00..253aee9382
--- /dev/null
+++ b/meta/recipes-core/systemd/systemd-conf/dhcp.network
@@ -0,0 +1,9 @@
+[Match]
+Name=en* eth*

I think this is better put
Name=en*
Name=eth*


Accodring to systemd.network(5),

   Name=
   A whitespace-separated list of shell-style globs matching 
the device name, as exposed by the udev property "INTERFACE".


It also says:

   A network file is said to match a device if each of the entries 
in the "[Match]" section matches, or if the section is empty.


So I perfer to use put them in one line "Name=en* eth*".

Also check systemd source code,

neil@pek-kkang-d1:/mnt/sda4/git/systemd
$ find . -name *.network -exec grep -H -c ^Name= {} \; | grep -v 1$
neil@pek-kkang-d1:/mnt/sda4/git/systemd
$ find . -name *.network -exec grep -H 'Name=\S\+\s\S' {} \;
./test/test-network/conf/25-tunnel-remote-any.network:Name=*tun97 ip6tnl97
./test/test-network/conf/bond-slave.network:Name=dummy98 test1
./test/test-network/conf/25-tunnel.network:Name=*tun99 *tap99 ip6tnl99 
erspan99
./test/test-network/conf/25-tunnel-local-any.network:Name=*tun98 *tap98 
ip6tnl98 erspan98




+
+[Network]
+DHCP=yes
+
+[DHCP]
+RouteMetric=10
+ClientIdentifier=mac
diff --git a/meta/recipes-core/systemd/systemd-conf_242.bb 
b/meta/recipes-core/systemd/systemd-conf_242.bb
index 96beea53a7..105ee3ceed 100644
--- a/meta/recipes-core/systemd/systemd-conf_242.bb
+++ b/meta/recipes-core/systemd/systemd-conf_242.bb
@@ -10,12 +10,16 @@ SRC_URI = "\
  file://logind.conf \
  file://system.conf \
  file://system.conf-qemuall \
+file://dhcp.network \

better to call it wired or something


OK. Will install as 80-wired.network.

Regards,
Kai





  "

  do_install() {
 install -D -m0644 ${WORKDIR}/journald.conf 
${D}${systemd_unitdir}/journald.conf.d/00-${PN}.conf
 install -D -m0644 ${WORKDIR}/logind.conf 
${D}${systemd_unitdir}/logind.conf.d/00-${PN}.conf
 install -D -m0644 ${WORKDIR}/system.conf 
${D}${systemd_unitdir}/system.conf.d/00-${PN}.conf
+   if ${@bb.utils.contains('OVERRIDES', 'qemuall', 'false', 'true', d)}; 
then
+   install -D -m0644 ${WORKDIR}/dhcp.network 
${D}${systemd_unitdir}/network/80-dhcp.network
+   fi
  }

  # Based on change from YP bug 8141, OE commit 
5196d7bacaef1076c361adaa2867be31759c1b52
@@ -29,4 +33,5 @@ FILES_${PN} = "\
  ${systemd_unitdir}/journald.conf.d/ \
  ${systemd_unitdir}/logind.conf.d/ \
  ${systemd_unitdir}/system.conf.d/ \
+${systemd_unitdir}/network/ \
  "
--
2.20.0



--
Kai Kang

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

Re: [OE-core] [PATCH 1/1] systemd-conf: configure wired network with dhcp

[Kang Kai]

On 2019/5/21 下午12:49, Alex Kiernan wrote:

On Tue, May 21, 2019 at 2:34 AM Kang Kai  wrote:

On 2019/5/21 上午1:45, Alex Kiernan wrote:

On Mon, May 20, 2019 at 10:47 AM  wrote:

From: Kai Kang 

Add a configure file for systemd.networkd to configure wired network
interfaces with dhcp. It works with common network interfaces such eth0
and eno1.

[YOCTO #13057]


I'm really not convinced about this - yes it's initially surprising,
but should base packages have this kind of assumptions/policy baked
into them?

I have considered whether systemd or systemd-conf should contain such
configure file. Compare to Fedora and Debian,
no such kind of pre-configured network setting provided by systemd, so I
added the configure file to systemd-config.

If systemd should be preferred, I'll update in v2.


No, systemd-conf is the right place for it, since this is machine
specific configuration. My question is really if this piece of
configuration should exist at all in OE-Core; but I'm not totally
opposed to it.

I could live with the kind of construction in meta-yoe (but with the
files added to systemd-conf as you already have)



The original requirement is from [Bug 13057 - No default network 
configuration for systemd-networkd ] which blocks to make systemd as
default init manager. If add this to meta-yoe, it still no working 
network if no connman/networkmanager installed(but this is same as

Fedora 29 and Debian 9).


Regards,
Kai






--
Kai Kang

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

Re: [OE-core] [PATCH 1/1] systemd-conf: configure wired network with dhcp

[Kang Kai]

On 2019/5/21 上午10:54, Kang Kai wrote:

On 2019/5/21 上午2:05, Khem Raj wrote:



On 5/20/19 2:46 AM, kai.k...@windriver.com wrote:

From: Kai Kang 

Add a configure file for systemd.networkd to configure wired network
interfaces with dhcp. It works with common network interfaces such eth0
and eno1.

[YOCTO #13057]

Signed-off-by: Kai Kang 
---
  meta/recipes-core/systemd/systemd-conf/dhcp.network | 5 +
  meta/recipes-core/systemd/systemd-conf_242.bb   | 3 +++
  2 files changed, 8 insertions(+)
  create mode 100644 
meta/recipes-core/systemd/systemd-conf/dhcp.network


diff --git a/meta/recipes-core/systemd/systemd-conf/dhcp.network 
b/meta/recipes-core/systemd/systemd-conf/dhcp.network

new file mode 100644
index 00..81f36ebaa5
--- /dev/null
+++ b/meta/recipes-core/systemd/systemd-conf/dhcp.network
@@ -0,0 +1,5 @@
+[Match]
+Name=en* eth*
+
+[Network]
+DHCP=yes
diff --git a/meta/recipes-core/systemd/systemd-conf_242.bb 
b/meta/recipes-core/systemd/systemd-conf_242.bb

index 96beea53a7..094f03e195 100644
--- a/meta/recipes-core/systemd/systemd-conf_242.bb
+++ b/meta/recipes-core/systemd/systemd-conf_242.bb
@@ -10,12 +10,14 @@ SRC_URI = "\
  file://logind.conf \
  file://system.conf \
  file://system.conf-qemuall \
+    file://dhcp.network \
  "
    do_install() {
  install -D -m0644 ${WORKDIR}/journald.conf 
${D}${systemd_unitdir}/journald.conf.d/00-${PN}.conf
  install -D -m0644 ${WORKDIR}/logind.conf 
${D}${systemd_unitdir}/logind.conf.d/00-${PN}.conf
  install -D -m0644 ${WORKDIR}/system.conf 
${D}${systemd_unitdir}/system.conf.d/00-${PN}.conf
+    install -D -m0644 ${WORKDIR}/dhcp.network 
${D}${systemd_unitdir}/network/80-dhcp.network

  }
    # Based on change from YP bug 8141, OE commit 
5196d7bacaef1076c361adaa2867be31759c1b52

@@ -29,4 +31,5 @@ FILES_${PN} = "\
  ${systemd_unitdir}/journald.conf.d/ \
  ${systemd_unitdir}/logind.conf.d/ \
  ${systemd_unitdir}/system.conf.d/ \
+    ${systemd_unitdir}/network/ \
  "



Please look into

https://github.com/YoeDistro/meta-yoe/tree/master/recipes-core/systemd

this also means we need to enable networkd and resolved for this to work



I checked the repo you post,

1) package config 'networkd' and 'resolved' have been involved in 
default package config in systemd_242.bb


2) I suspect wireless.network is not necessary. Unlike wired network, 
we can't predict the ap name and connect it automatically.


3) the configure file doesn't work with qemu tap mode. I'll update 
with it.






4) Do the configure of section [DHCP] in wired.network necessary?

[DHCP]
RouteMetric=10
ClientIdentifier=mac


Ignore 4). I have checked the commit message and know why.

Regards,
Kai




Thanks.




--
Kai Kang

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

Re: [OE-core] [PATCH 1/1] systemd-conf: configure wired network with dhcp

[Kang Kai]

On 2019/5/21 上午2:05, Khem Raj wrote:



On 5/20/19 2:46 AM, kai.k...@windriver.com wrote:

From: Kai Kang 

Add a configure file for systemd.networkd to configure wired network
interfaces with dhcp. It works with common network interfaces such eth0
and eno1.

[YOCTO #13057]

Signed-off-by: Kai Kang 
---
  meta/recipes-core/systemd/systemd-conf/dhcp.network | 5 +
  meta/recipes-core/systemd/systemd-conf_242.bb   | 3 +++
  2 files changed, 8 insertions(+)
  create mode 100644 meta/recipes-core/systemd/systemd-conf/dhcp.network

diff --git a/meta/recipes-core/systemd/systemd-conf/dhcp.network 
b/meta/recipes-core/systemd/systemd-conf/dhcp.network

new file mode 100644
index 00..81f36ebaa5
--- /dev/null
+++ b/meta/recipes-core/systemd/systemd-conf/dhcp.network
@@ -0,0 +1,5 @@
+[Match]
+Name=en* eth*
+
+[Network]
+DHCP=yes
diff --git a/meta/recipes-core/systemd/systemd-conf_242.bb 
b/meta/recipes-core/systemd/systemd-conf_242.bb

index 96beea53a7..094f03e195 100644
--- a/meta/recipes-core/systemd/systemd-conf_242.bb
+++ b/meta/recipes-core/systemd/systemd-conf_242.bb
@@ -10,12 +10,14 @@ SRC_URI = "\
  file://logind.conf \
  file://system.conf \
  file://system.conf-qemuall \
+    file://dhcp.network \
  "
    do_install() {
  install -D -m0644 ${WORKDIR}/journald.conf 
${D}${systemd_unitdir}/journald.conf.d/00-${PN}.conf
  install -D -m0644 ${WORKDIR}/logind.conf 
${D}${systemd_unitdir}/logind.conf.d/00-${PN}.conf
  install -D -m0644 ${WORKDIR}/system.conf 
${D}${systemd_unitdir}/system.conf.d/00-${PN}.conf
+    install -D -m0644 ${WORKDIR}/dhcp.network 
${D}${systemd_unitdir}/network/80-dhcp.network

  }
    # Based on change from YP bug 8141, OE commit 
5196d7bacaef1076c361adaa2867be31759c1b52

@@ -29,4 +31,5 @@ FILES_${PN} = "\
  ${systemd_unitdir}/journald.conf.d/ \
  ${systemd_unitdir}/logind.conf.d/ \
  ${systemd_unitdir}/system.conf.d/ \
+    ${systemd_unitdir}/network/ \
  "



Please look into

https://github.com/YoeDistro/meta-yoe/tree/master/recipes-core/systemd

this also means we need to enable networkd and resolved for this to work



I checked the repo you post,

1) package config 'networkd' and 'resolved' have been involved in 
default package config in systemd_242.bb


2) I suspect wireless.network is not necessary. Unlike wired network, we 
can't predict the ap name and connect it automatically.


3) the configure file doesn't work with qemu tap mode. I'll update with it.

4) Do the configure of section [DHCP] in wired.network necessary?

[DHCP]
RouteMetric=10
ClientIdentifier=mac


Thanks.


--
Kai Kang

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

Re: [OE-core] [PATCH 1/1] systemd-conf: configure wired network with dhcp

[Kang Kai]

On 2019/5/21 上午1:45, Alex Kiernan wrote:

On Mon, May 20, 2019 at 10:47 AM  wrote:

From: Kai Kang 

Add a configure file for systemd.networkd to configure wired network
interfaces with dhcp. It works with common network interfaces such eth0
and eno1.

[YOCTO #13057]


I'm really not convinced about this - yes it's initially surprising,
but should base packages have this kind of assumptions/policy baked
into them?


I have considered whether systemd or systemd-conf should contain such 
configure file. Compare to Fedora and Debian,
no such kind of pre-configured network setting provided by systemd, so I 
added the configure file to systemd-config.


If systemd should be preferred, I'll update in v2.

Kai






--
Alex Kiernan



--
Kai Kang

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

Re: [OE-core] [PATCH 1/1] webkitgtk: fix compile error for arm64

[Kang Kai]

On 2019/5/13 下午11:43, Khem Raj wrote:

Can you test this on say rpi3 in 64bit mode and see all is ok ?


It is ok to build 64-bit rpi3 from layer 
git://git.yoctoproject.org/meta-raspberrypi

with configurations:

MACHINE = "raspberrypi3-64"
LICENSE_FLAGS_WHITELIST_append = " commercial"

Regards,
Kai




On Mon, May 13, 2019 at 2:53 AM > wrote:


From: Kai Kang mailto:kai.k...@windriver.com>>

It removes function JSC::AssemblerBuffer::data() for ARM64 in commit
https://trac.webkit.org/changeset/236589/webkit. But the function is
still required by Cortex A53 and fails to compile for arm64:

|

.../tmp/work/aarch64-poky-linux/webkitgtk/2.24.1-r0/webkitgtk-2.24.1/Source/JavaScriptCore/assembler/ARM64Assembler.h:3769:100:
error: 'class JSC::AssemblerBuffer' has no member named 'data'
|     if

(UNLIKELY((*reinterpret_cast_ptr(reinterpret_cast_ptr(m_buffer.data())
+ m_buffer.codeSize() - sizeof(int32_t)) & 0x0a00) == 0x0800))

Not set WTF_CPU_ARM64_CORTEXA53 for arm64 to fix the failure.

Signed-off-by: Kai Kang mailto:kai.k...@windriver.com>>
---
 meta/recipes-sato/webkit/webkitgtk_2.24.1.bb
 | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.24.1.bb

b/meta/recipes-sato/webkit/webkitgtk_2.24.1.bb

index 771a893a6b..a57a3c058c 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.24.1.bb

+++ b/meta/recipes-sato/webkit/webkitgtk_2.24.1.bb

@@ -98,8 +98,6 @@ EXTRA_OECMAKE_append_aarch64 = " -DUSE_LD_GOLD=OFF "
 EXTRA_OECMAKE_append_mipsarch = " -DUSE_LD_GOLD=OFF "
 EXTRA_OECMAKE_append_powerpc = " -DUSE_LD_GOLD=OFF "

-EXTRA_OECMAKE_append_aarch64 = " -DWTF_CPU_ARM64_CORTEXA53=ON"
-
 # JIT not supported on MIPS either
 EXTRA_OECMAKE_append_mipsarch = " -DENABLE_JIT=OFF "

-- 
2.20.0


-- 
___

Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

http://lists.openembedded.org/mailman/listinfo/openembedded-core



--
Kai Kang

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

Re: [OE-core] [PATCH] webkitgtk: fix compile error for arm64

[Kang Kai]

On 2019/4/23 下午6:12, kai.k...@windriver.com wrote:

From: Kai Kang 

It removes function JSC::AssemblerBuffer::data() for ARM64 in commit
https://trac.webkit.org/changeset/236589/webkit. But it is required by
Cortex A53 from https://trac.webkit.org/changeset/175514/webkit and
fails to compile for arm64:

| 
.../tmp/work/aarch64-poky-linux/webkitgtk/2.24.0-r0/webkitgtk-2.24.0/Source/JavaScriptCore/assembler/ARM64Assembler.h:3769:100:
 error: 'class JSC::AssemblerBuffer' has no member named 'data'
| if 
(UNLIKELY((*reinterpret_cast_ptr(reinterpret_cast_ptr(m_buffer.data())
 + m_buffer.codeSize() - sizeof(int32_t)) & 0x0a00) == 0x0800))

Not set WTF_CPU_ARM64_CORTEXA53 for arm64 to fix the failure.


Any comment please? It still fails even apply the patch to update to 
2.24.1 for qemuarm64.


Regards,
Kai





Signed-off-by: Kai Kang 
---
  meta/recipes-sato/webkit/webkitgtk_2.24.0.bb | 2 --
  1 file changed, 2 deletions(-)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.24.0.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.24.0.bb
index 4a82dae9ef..54daa217bb 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.24.0.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.24.0.bb
@@ -92,8 +92,6 @@ EXTRA_OECMAKE_append_aarch64 = " -DUSE_LD_GOLD=OFF "
  EXTRA_OECMAKE_append_mipsarch = " -DUSE_LD_GOLD=OFF "
  EXTRA_OECMAKE_append_powerpc = " -DUSE_LD_GOLD=OFF "
  
-EXTRA_OECMAKE_append_aarch64 = " -DWTF_CPU_ARM64_CORTEXA53=ON"

-
  # JIT not supported on MIPS either
  EXTRA_OECMAKE_append_mipsarch = " -DENABLE_JIT=OFF "
  



--
Kai Kang

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

Re: [OE-core] [PATCH v2] virglrenderer: use gold linker for x86 if cflag -fvisibility=default set

[Kang Kai]

On 2019/4/30 下午10:46, Richard Purdie wrote:

On Tue, 2019-04-30 at 10:23 -0400, kai.k...@windriver.com wrote:

From: Kai Kang 

When gcc compile options '-fvisibility=default' is set in CFLAGS, it
fails to compile virglrenderer for x86:


i586-wrs-linux-libtool: link: i586-wrs-linux-gcc  -m32 -march=i586 ...

   -Wl,--whole-archive ./.libs/libvrend.a
   gallium/auxiliary/.libs/libgallium.a -Wl,--no-whole-archive ...
   -Wl,-Bsymbolic -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
   -fstack-protector-strong -Wl,-z -Wl,relro -Wl,-z -Wl,now   -pthread
   -Wl,-soname -Wl,libvirglrenderer.so.0 -o .libs/libvirglrenderer.so.0.2.0

ld: gallium/auxiliary/.libs/libgallium.a(u_cpu_detect.o): relocation

   R_386_GOTOFF against undefined symbol `util_cpu_caps' can not be used
   when making a shared object

ld: final link failed: bad value
collect2: error: ld returned 1 exit status

It seems GNU bfd linker doesn't work well to handle option '-Bsymbolic'
and gcc option '-fvisibility=default'. Use gold instead under this
circumstance.

Signed-off-by: Kai Kang 
---
  meta/recipes-graphics/virglrenderer/virglrenderer_0.7.0.bb | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.7.0.bb 
b/meta/recipes-graphics/virglrenderer/virglrenderer_0.7.0.bb
index 225a0b8b0c..f72cfbd9b4 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.7.0.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.7.0.bb
@@ -15,6 +15,8 @@ S = "${WORKDIR}/git"
  
  inherit autotools pkgconfig distro_features_check
  
+EXTRA_OEMAKE_x86 = "${@bb.utils.contains('CFLAGS', '-fvisibility=default', 'GM_LDFLAGS+=-fuse-ld=gold', '', d)}"

+
  BBCLASSEXTEND = "native nativesdk"
  
  REQUIRED_DISTRO_FEATURES = "opengl"

Do we really want to start adding hacks to recipes to work around
linker bugs like this?

Has the bug been reported upstream? Why doesn't this happen on non-x86?


I have sent the v1 patch  to virglrenderer upstream

https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/213

And they said that link option  '-Bsymbolic' " just checks that all 
symbols are available, and if they are not you should hit a run-time 
error when the symbol is used,
in summary, the flag is there to make sure that we don't hit this kind 
of run-time error."


It also doesn't fail on x86-64. I suspect there is something wrong in 
gnu bfd linker for x86.



Regards,
Kai




Cheers,

Richard




--
Kai Kang

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

Re: [OE-core] [PATCH 1/1] target-sdk-provides-dummy: set nostamp for do_package

[Kang Kai]

On 2019/4/30 下午6:19, richard.pur...@linuxfoundation.org wrote:

On Tue, 2019-04-30 at 03:15 -0400, kai.k...@windriver.com wrote:

From: Kai Kang 

It exists a situation that there is a common config file includes
multilib.conf but variable MULTILIBS is not set by default:

   require conf/multilib.conf
   MULTILIBS ?= ""

When build target-sdk-provides-dummy in the same build project with
following steps, it fails.

1 $ echo 'MACHINE = "qemux86"' >>conf/local.conf
   $ bitbake target-sdk-provides-dummy
2 $ cat <>conf/local.conf
 MACHINE = "qemux86-64"
 MULTILIBS = "multilib:lib32"
 DEFAULTTUNE_virtclass-multilib-lib32 = "i586"
 EOF
   $ bitbake target-sdk-provides-dummy
   $ bitbake lib32-target-sdk-provides-dummy

It fails to build lib32-target-sdk-provides-dummy with error
messages:


ERROR: target-sdk-provides-dummy-1.0-r0 do_packagedata: The recipe
target-sdk-provides-dummy
  is trying to install files into a shared area when those files
already exist. Those files
  and their manifest location are:
   .../tmp/pkgdata/qemux86-64/lib32-target-sdk-provides-dummy
 (matched in manifest-qemux86_64-lib32-target-sdk-provides-
dummy.packagedata)
   .../tmp/pkgdata/qemux86-64/runtime/lib32-target-sdk-provides-
dummy
 (matched in manifest-qemux86_64-lib32-target-sdk-provides-
dummy.packagedata)
   ... snip ...
Please verify which recipe should provide the above files.

Because target-sdk-provides-dummy is a virtual package, its sstate
caches are same for both qemux86 and qemux86_64. So when build
target-sdk-provides-dummy for qemux86_64, it re-uses the sstate cache
from qemux86 and then create file lib32-target-sdk-provides-dummy
under
${PKGDATA_DIR} which should not and then conflicts with lib32-target-
sdk-provides-dummy.

Make do_package always be executed to fix the issue. Because it is a
dummy
package, it won't cost too much build time.

Signed-off-by: Kai Kang 
---
  meta/recipes-core/meta/target-sdk-provides-dummy.bb | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/meta/recipes-core/meta/target-sdk-provides-dummy.bb
b/meta/recipes-core/meta/target-sdk-provides-dummy.bb
index 85472a825c..e09a08bcd7 100644
--- a/meta/recipes-core/meta/target-sdk-provides-dummy.bb
+++ b/meta/recipes-core/meta/target-sdk-provides-dummy.bb
@@ -52,3 +52,5 @@ DUMMYPROVIDES = "\
  "
  
  require dummy-sdk-package.inc

+
+do_package[nostamp] = "1"

This isn't the right way to fix it, we should probably whitelist that
particular file for multiple providers. See SSTATE_DUPWHITELIST.


OK. Thanks.

Kai




Cheers,

Richard






--
Kai Kang

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

Re: [OE-core] [PATCH] cryptodev: update SRCREV

[Kang Kai]

On 2019/4/24 下午8:38, Burton, Ross wrote:

I'd prefer this to be applying the patch, which also makes the fix
easier to backport.


OK. I'll send v2 to apply the the patch.

Regards,
Kai




Ross

On Wed, 24 Apr 2019 at 03:26, Kang Kai  wrote:

On 2019/4/15 上午11:42, kai.k...@windriver.com wrote:

From: Kai Kang 

Update SRCREV of cryptodev which only contains one fix for linux 5.0:

$ git log 
fd8b15ef1c8398a69a37932ee48c74ab40329a29..f971e0cd4a0ebe59fb2e8e17240399bf6901b09b
commit f971e0cd4a0ebe59fb2e8e17240399bf6901b09b
Author: Derald D. Woods 
Date:   Sun Feb 10 13:22:19 2019 -0600

  Fix module loading with Linux v5.0-rc5

  This commit fixes this module load error:
  [...]
  [   29.112091] cryptodev: loading out-of-tree module taints kernel.
  [   29.128906] cryptodev: Unknown symbol crypto_givcipher_type (err -2)
  [   29.188842] cryptodev: Unknown symbol crypto_givcipher_type (err -2)
  modprobe: can't load module cryptodev (extra/cryptodev.ko): unknown 
symbol in module, or unknown parameter
  [...]


Without this patch it fails to modprobe module cryptodev. Ping.

Kai



  Upstream Linux support for unused GIVCIPHER, and others, was dropped here:

  c79b411eaa72 (crypto: skcipher - remove remnants of internal IV 
generators)

  Signed-off-by: Derald D. Woods 

Signed-off-by: Kai Kang 
---
   meta/recipes-kernel/cryptodev/cryptodev.inc | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/cryptodev/cryptodev.inc 
b/meta/recipes-kernel/cryptodev/cryptodev.inc
index 252d39d23a..79ddefd435 100644
--- a/meta/recipes-kernel/cryptodev/cryptodev.inc
+++ b/meta/recipes-kernel/cryptodev/cryptodev.inc
@@ -4,7 +4,7 @@ LICENSE = "GPLv2"
   LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"

   SRC_URI = "git://github.com/cryptodev-linux/cryptodev-linux"
-SRCREV = "fd8b15ef1c8398a69a37932ee48c74ab40329a29"
+SRCREV = "f971e0cd4a0ebe59fb2e8e17240399bf6901b09b"

   S = "${WORKDIR}/git"



--
Kai Kang

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



--
Kai Kang

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

Re: [OE-core] [PATCH] cryptodev: update SRCREV

[Kang Kai]

On 2019/4/15 上午11:42, kai.k...@windriver.com wrote:

From: Kai Kang 

Update SRCREV of cryptodev which only contains one fix for linux 5.0:

$ git log 
fd8b15ef1c8398a69a37932ee48c74ab40329a29..f971e0cd4a0ebe59fb2e8e17240399bf6901b09b
commit f971e0cd4a0ebe59fb2e8e17240399bf6901b09b
Author: Derald D. Woods 
Date:   Sun Feb 10 13:22:19 2019 -0600

 Fix module loading with Linux v5.0-rc5

 This commit fixes this module load error:
 [...]
 [   29.112091] cryptodev: loading out-of-tree module taints kernel.
 [   29.128906] cryptodev: Unknown symbol crypto_givcipher_type (err -2)
 [   29.188842] cryptodev: Unknown symbol crypto_givcipher_type (err -2)
 modprobe: can't load module cryptodev (extra/cryptodev.ko): unknown symbol 
in module, or unknown parameter
 [...]



Without this patch it fails to modprobe module cryptodev. Ping.

Kai




 Upstream Linux support for unused GIVCIPHER, and others, was dropped here:

 c79b411eaa72 (crypto: skcipher - remove remnants of internal IV generators)

 Signed-off-by: Derald D. Woods 

Signed-off-by: Kai Kang 
---
  meta/recipes-kernel/cryptodev/cryptodev.inc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/cryptodev/cryptodev.inc 
b/meta/recipes-kernel/cryptodev/cryptodev.inc
index 252d39d23a..79ddefd435 100644
--- a/meta/recipes-kernel/cryptodev/cryptodev.inc
+++ b/meta/recipes-kernel/cryptodev/cryptodev.inc
@@ -4,7 +4,7 @@ LICENSE = "GPLv2"
  LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
  
  SRC_URI = "git://github.com/cryptodev-linux/cryptodev-linux"

-SRCREV = "fd8b15ef1c8398a69a37932ee48c74ab40329a29"
+SRCREV = "f971e0cd4a0ebe59fb2e8e17240399bf6901b09b"
  
  S = "${WORKDIR}/git"
  



--
Kai Kang

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

Re: [OE-core] [PATCH] virglrenderer: remove link option -Bsymbolic

[Kang Kai]

On 2019/4/9 上午12:36, Khem Raj wrote:

On Sun, Apr 7, 2019 at 6:59 PM Kang Kai  wrote:

On 2019/4/4 下午3:52, kai.k...@windriver.com wrote:

From: Kai Kang 

When gcc compile options '-O2 -fvisibility=default' are applied, it
fails to compile virglrenderer for x86:

| ld: gallium/auxiliary/.libs/libgallium.a(u_cpu_detect.o): relocation
R_386_GOTOFF against undefined symbol `util_cpu_caps' can not be used
when making a shared object
| ld: final link failed: bad value
| collect2: error: ld returned 1 exit status

Remove link option '-Bsymbolic' to fix the failure.


Any comments on this patch? Thank.

Kai



Signed-off-by: Kai Kang 
---
   .../0001-Remove-link-option-Bsymbolic.patch   | 34 +++
   .../virglrenderer/virglrenderer_0.7.0.bb  |  1 +
   2 files changed, 35 insertions(+)
   create mode 100644 
meta/recipes-graphics/virglrenderer/virglrenderer/0001-Remove-link-option-Bsymbolic.patch

diff --git 
a/meta/recipes-graphics/virglrenderer/virglrenderer/0001-Remove-link-option-Bsymbolic.patch
 
b/meta/recipes-graphics/virglrenderer/virglrenderer/0001-Remove-link-option-Bsymbolic.patch
new file mode 100644
index 00..faefa16aae
--- /dev/null
+++ 
b/meta/recipes-graphics/virglrenderer/virglrenderer/0001-Remove-link-option-Bsymbolic.patch
@@ -0,0 +1,34 @@
+When gcc compile options '-O2 -fvisibility=default' are applied, it fails to
+compile virglrenderer for x86:
+
+| ld: gallium/auxiliary/.libs/libgallium.a(u_cpu_detect.o): relocation
+  R_386_GOTOFF against undefined symbol `util_cpu_caps' can not be used
+  when making a shared object
+| ld: final link failed: bad value
+| collect2: error: ld returned 1 exit status
+
+Remove link option '-Bsymbolic' to fix the failure.
+

In spite of removing the option can we try replacing it with
-Bsymbolic-functions



Thanks. I'll try it.

Regards,
Kai





+Upstream-Status: Submitted 
[https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/213]
+
+Signed-off-by: Kai Kang 
+---
+ src/Makefile.am | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/Makefile.am b/src/Makefile.am
+index 9b668c8..7a421b8 100644
+--- a/src/Makefile.am
 b/src/Makefile.am
+@@ -48,7 +49,7 @@ endif
+ lib_LTLIBRARIES = libvirglrenderer.la
+ noinst_LTLIBRARIES = libvrend.la
+
+-GM_LDFLAGS = -Wl,-Bsymbolic -version-number 0:2 -no-undefined
++GM_LDFLAGS = -version-number 0:2 -no-undefined
+
+ libvirglrenderer_la_SOURCES = virglrenderer.c
+ libvirglrenderer_ladir = $(libdir)
+--
+2.20.1
+
diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.7.0.bb 
b/meta/recipes-graphics/virglrenderer/virglrenderer_0.7.0.bb
index 225a0b8b0c..afc709bc48 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.7.0.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.7.0.bb
@@ -9,6 +9,7 @@ SRCREV = "402c228861c9893f64cffbbcb4cb23044b8c721c"
   SRC_URI = "git://anongit.freedesktop.org/virglrenderer \
  file://0001-vtest-add-missing-includes.patch \
  file://0001-Makefile.am-explicitly-link-with-libdrm.patch \
+   file://0001-Remove-link-option-Bsymbolic.patch \
  "

   S = "${WORKDIR}/git"


--
Kai Kang



--
Kai Kang

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

Re: [OE-core] [PATCH] virglrenderer: remove link option -Bsymbolic

[Kang Kai]

On 2019/4/4 下午3:52, kai.k...@windriver.com wrote:

From: Kai Kang 

When gcc compile options '-O2 -fvisibility=default' are applied, it
fails to compile virglrenderer for x86:

| ld: gallium/auxiliary/.libs/libgallium.a(u_cpu_detect.o): relocation
   R_386_GOTOFF against undefined symbol `util_cpu_caps' can not be used
   when making a shared object
| ld: final link failed: bad value
| collect2: error: ld returned 1 exit status

Remove link option '-Bsymbolic' to fix the failure.



Any comments on this patch? Thank.

Kai




Signed-off-by: Kai Kang 
---
  .../0001-Remove-link-option-Bsymbolic.patch   | 34 +++
  .../virglrenderer/virglrenderer_0.7.0.bb  |  1 +
  2 files changed, 35 insertions(+)
  create mode 100644 
meta/recipes-graphics/virglrenderer/virglrenderer/0001-Remove-link-option-Bsymbolic.patch

diff --git 
a/meta/recipes-graphics/virglrenderer/virglrenderer/0001-Remove-link-option-Bsymbolic.patch
 
b/meta/recipes-graphics/virglrenderer/virglrenderer/0001-Remove-link-option-Bsymbolic.patch
new file mode 100644
index 00..faefa16aae
--- /dev/null
+++ 
b/meta/recipes-graphics/virglrenderer/virglrenderer/0001-Remove-link-option-Bsymbolic.patch
@@ -0,0 +1,34 @@
+When gcc compile options '-O2 -fvisibility=default' are applied, it fails to
+compile virglrenderer for x86:
+
+| ld: gallium/auxiliary/.libs/libgallium.a(u_cpu_detect.o): relocation
+  R_386_GOTOFF against undefined symbol `util_cpu_caps' can not be used
+  when making a shared object
+| ld: final link failed: bad value
+| collect2: error: ld returned 1 exit status
+
+Remove link option '-Bsymbolic' to fix the failure.
+
+Upstream-Status: Submitted 
[https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/213]
+
+Signed-off-by: Kai Kang 
+---
+ src/Makefile.am | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/Makefile.am b/src/Makefile.am
+index 9b668c8..7a421b8 100644
+--- a/src/Makefile.am
 b/src/Makefile.am
+@@ -48,7 +49,7 @@ endif
+ lib_LTLIBRARIES = libvirglrenderer.la
+ noinst_LTLIBRARIES = libvrend.la
+
+-GM_LDFLAGS = -Wl,-Bsymbolic -version-number 0:2 -no-undefined
++GM_LDFLAGS = -version-number 0:2 -no-undefined
+
+ libvirglrenderer_la_SOURCES = virglrenderer.c
+ libvirglrenderer_ladir = $(libdir)
+--
+2.20.1
+
diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.7.0.bb 
b/meta/recipes-graphics/virglrenderer/virglrenderer_0.7.0.bb
index 225a0b8b0c..afc709bc48 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.7.0.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.7.0.bb
@@ -9,6 +9,7 @@ SRCREV = "402c228861c9893f64cffbbcb4cb23044b8c721c"
  SRC_URI = "git://anongit.freedesktop.org/virglrenderer \
 file://0001-vtest-add-missing-includes.patch \
 file://0001-Makefile.am-explicitly-link-with-libdrm.patch \
+   file://0001-Remove-link-option-Bsymbolic.patch \
 "
  
  S = "${WORKDIR}/git"



--
Kai Kang

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

Re: [OE-core] Link issue of virglrenderer on x86 with gcc options '-O2 -fvisibility=default'

[Kang Kai]

On 2019/4/3 上午12:16, Khem Raj wrote:

On Tue, Apr 2, 2019 at 8:46 AM Kang Kai  wrote:

Hi Raj,

I meet a link problem of virglrenderer with gcc options '-O2
-fvisibility=default' configured in local.conf:

SELECTED_OPTIMIZATION = "-O2 -fvisibility=default"

It fails on qemux86 but succeeds on x86-64.

And the error message:

| i586-poky-linux-libtool: link: i586-poky-linux-gcc  -m32 -march=i586
-fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security
-Werror=
format-security
--sysroot=/home/kkang/buildarea/Yocto/build-systemd/tmp/work/i586-poky-linux/virglrenderer/0.7.0-r0/recipe-sysroot
-shared  -fPIC -DPIC
   .libs/virglrenderer.o  *-Wl,--whole-archive* ./.libs/libvrend.a
gallium/auxiliary/.libs/libgallium.a *-Wl,--no-whole-archive*  -lm -ldrm
-lgbm -lepoxy -lX1
1  -m32 -march=i586 -fstack-protector-strong
--sysroot=/home/kkang/buildarea/Yocto/build-systemd/tmp/work/i586-poky-linux/virglrenderer/0.7.0-r0/recipe-
sysroot -O2 -Wl,-Bsymbolic -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
-fstack-protector-strong -Wl,-z -Wl,relro -Wl,-z -Wl,now   -pthread
-Wl,-soname
-Wl,libvirglrenderer.so.0 -o .libs/libvirglrenderer.so.0.2.0
|
/home/kkang/buildarea/Yocto/build-systemd/tmp/work/i586-poky-linux/virglrenderer/0.7.0-r0/recipe-sysroot-native/usr/bin/i586-poky-linux/../../libexec/
i586-poky-linux/gcc/i586-poky-linux/8.3.0/ld:
gallium/auxiliary/.libs/libgallium.a(u_cpu_detect.o): relocation
R_386_GOTOFF against undefined symbol `ut
il_cpu_caps' can not be used when making a shared object

It could pass if options -Wl,--whole-archive and -Wl,--no-whole-archive
are removed.

It says 'relocation R_386_GOTOFF' but when I check the file, it shows
relocation type is R_386_GOT32X:

$ readelf --relocs ./util/.libs/u_cpu_detect.o | grep util_cpu_caps
0092  102b R_386_GOT32X  0004   util_cpu_caps

AFAIK R_386_GOT32X is not used with PIC. But I don't know why the type
is R_386_GOT32X that -fPIC has been applied already?

Any suggestion is great appreciated. Thanks.


it seems you have to build PIC archive for libgallium.a, it might not
be using the right -fPIC flags during compile/link phase.


Hi Raj,

Thanks a lot.

It turns out that caused by link option '-Bsymbolic'. Replace with 
'-Bdynamic' could resolve the issue. And I'll send a patch to upstream.



Regards,
Kai





--
Kai Kang



--
Kai Kang

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

[OE-core] Link issue of virglrenderer on x86 with gcc options '-O2 -fvisibility=default'

[Kang Kai]

Hi Raj,

I meet a link problem of virglrenderer with gcc options '-O2 
-fvisibility=default' configured in local.conf:


SELECTED_OPTIMIZATION = "-O2 -fvisibility=default"

It fails on qemux86 but succeeds on x86-64.

And the error message:

| i586-poky-linux-libtool: link: i586-poky-linux-gcc  -m32 -march=i586 
-fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security 
-Werror=
format-security 
--sysroot=/home/kkang/buildarea/Yocto/build-systemd/tmp/work/i586-poky-linux/virglrenderer/0.7.0-r0/recipe-sysroot 
-shared  -fPIC -DPIC
 .libs/virglrenderer.o  *-Wl,--whole-archive* ./.libs/libvrend.a 
gallium/auxiliary/.libs/libgallium.a *-Wl,--no-whole-archive*  -lm -ldrm 
-lgbm -lepoxy -lX1
1  -m32 -march=i586 -fstack-protector-strong 
--sysroot=/home/kkang/buildarea/Yocto/build-systemd/tmp/work/i586-poky-linux/virglrenderer/0.7.0-r0/recipe-
sysroot -O2 -Wl,-Bsymbolic -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed 
-fstack-protector-strong -Wl,-z -Wl,relro -Wl,-z -Wl,now   -pthread 
-Wl,-soname

-Wl,libvirglrenderer.so.0 -o .libs/libvirglrenderer.so.0.2.0
| 
/home/kkang/buildarea/Yocto/build-systemd/tmp/work/i586-poky-linux/virglrenderer/0.7.0-r0/recipe-sysroot-native/usr/bin/i586-poky-linux/../../libexec/
i586-poky-linux/gcc/i586-poky-linux/8.3.0/ld: 
gallium/auxiliary/.libs/libgallium.a(u_cpu_detect.o): relocation 
R_386_GOTOFF against undefined symbol `ut

il_cpu_caps' can not be used when making a shared object

It could pass if options -Wl,--whole-archive and -Wl,--no-whole-archive 
are removed.


It says 'relocation R_386_GOTOFF' but when I check the file, it shows 
relocation type is R_386_GOT32X:


$ readelf --relocs ./util/.libs/u_cpu_detect.o | grep util_cpu_caps
0092  102b R_386_GOT32X  0004   util_cpu_caps

AFAIK R_386_GOT32X is not used with PIC. But I don't know why the type 
is R_386_GOT32X that -fPIC has been applied already?


Any suggestion is great appreciated. Thanks.


--
Kai Kang

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

Re: [OE-core] [PATCH 1/2] avahi: fix CVE-2017-6519

[Kang Kai]

On 2019/4/2 下午3:46, Burton, Ross wrote:

The patch itself says two CVE IDs, so can you put them both in the
path header with your SOB please?


I have checked CVE-2018-1000845 which is rejected that it is duplicate 
of CVE-2017-6519. That why didn't list CVE-2018-1000845 in patch and 
commit message.


Regards,
Kai




Ross

On Tue, 2 Apr 2019 at 08:45,  wrote:

From: Kai Kang 

Backport patch to fix CVE-2017-6519.

CVE: CVE-2017-6519

Signed-off-by: Kai Kang 
---
  meta/recipes-connectivity/avahi/avahi.inc |  4 +-
  .../avahi/files/fix-CVE-2017-6519.patch   | 48 +++
  2 files changed, 51 insertions(+), 1 deletion(-)
  create mode 100644 
meta/recipes-connectivity/avahi/files/fix-CVE-2017-6519.patch

diff --git a/meta/recipes-connectivity/avahi/avahi.inc 
b/meta/recipes-connectivity/avahi/avahi.inc
index 11846849f0..8339e451f5 100644
--- a/meta/recipes-connectivity/avahi/avahi.inc
+++ b/meta/recipes-connectivity/avahi/avahi.inc
@@ -19,7 +19,9 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=2d5025d4aa3495befef8f17206a5b0a1 \
  
file://avahi-daemon/main.c;endline=21;md5=9ee77368c5407af77caaef1b07285969 \
  
file://avahi-client/client.h;endline=23;md5=f4ac741a25c4f434039ba3e18c8674cf"

-SRC_URI = 
"https://github.com/lathiat/avahi/releases/download/v${PV}/avahi-${PV}.tar.gz;
+SRC_URI = 
"https://github.com/lathiat/avahi/releases/download/v${PV}/avahi-${PV}.tar.gz \
+   file://fix-CVE-2017-6519.patch \
+   "

  UPSTREAM_CHECK_URI = "https://github.com/lathiat/avahi/releases/;
  SRC_URI[md5sum] = "d76c59d0882ac6c256d70a2a585362a6"
diff --git a/meta/recipes-connectivity/avahi/files/fix-CVE-2017-6519.patch 
b/meta/recipes-connectivity/avahi/files/fix-CVE-2017-6519.patch
new file mode 100644
index 00..7461fe193d
--- /dev/null
+++ b/meta/recipes-connectivity/avahi/files/fix-CVE-2017-6519.patch
@@ -0,0 +1,48 @@
+Upstream-Status: Backport [https://github.com/lathiat/avahi/commit/e111def]
+
+CVE: CVE-2017-6519
+
+Signed-off-by: Kai Kang 
+
+From e111def44a7df4624a4aa3f85fe98054bffb6b4f Mon Sep 17 00:00:00 2001
+From: Trent Lloyd 
+Date: Sat, 22 Dec 2018 09:06:07 +0800
+Subject: [PATCH] Drop legacy unicast queries from address not on local link
+
+When handling legacy unicast queries, ensure that the source IP is
+inside a subnet on the local link, otherwise drop the packet.
+
+Fixes #145
+Fixes #203
+CVE-2017-6519
+CVE-2018-1000845
+---
+ avahi-core/server.c | 8 
+ 1 file changed, 8 insertions(+)
+
+diff --git a/avahi-core/server.c b/avahi-core/server.c
+index a2cb19a8..a2580e38 100644
+--- a/avahi-core/server.c
 b/avahi-core/server.c
+@@ -930,6 +930,7 @@ static void dispatch_packet(AvahiServer *s, AvahiDnsPacket 
*p, const AvahiAddres
+
+ if (avahi_dns_packet_is_query(p)) {
+ int legacy_unicast = 0;
++char t[AVAHI_ADDRESS_STR_MAX];
+
+ /* For queries EDNS0 might allow ARCOUNT != 0. We ignore the
+  * AR section completely here, so far. Until the day we add
+@@ -947,6 +948,13 @@ static void dispatch_packet(AvahiServer *s, 
AvahiDnsPacket *p, const AvahiAddres
+ legacy_unicast = 1;
+ }
+
++if (!is_mdns_mcast_address(dst_address) &&
++!avahi_interface_address_on_link(i, src_address)) {
++
++avahi_log_debug("Received non-local unicast query from host %s on interface 
'%s.%i'.", avahi_address_snprint(t, sizeof(t), src_address), i->hardware->name, 
i->protocol);
++return;
++}
++
+ if (legacy_unicast)
+ reflect_legacy_unicast_query_packet(s, p, i, src_address, port);
+
--
2.20.0

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



--
Kai Kang

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

Re: [OE-core] [PATCH] fixup! qemu: backport patches to fix cves

[Kang Kai]

On 2019/3/21 上午5:34, Alexey Brodkin wrote:

Hi Kai Kang,


-Original Message-
From: kai.k...@windriver.com 
Sent: Wednesday, March 20, 2019 4:16 PM
To: richard.pur...@linuxfoundation.org
Cc: alexey.brod...@synopsys.com; openembedded-core@lists.openembedded.org
Subject: [PATCH] fixup! qemu: backport patches to fix cves

Just wondering if you were able to reproduce mentioned problem
on your side before fixing it?

Given Richard's input this problem was supposed to be caught
before your previous commit hit OE master branch but somehow it
slipped through the cracks...

Or otherwise my setup should be somehow very special if it only
happens for me.


I can reproduce the build failure with default configure:

$ . poky/oe-init-build-env
$ bitbake qemu-system-native

It should be covered by autobuilder. :(

And there is no error to build qemu and qemu-native  that 
hw/rdma/rdma_backend.c is not even compiled because:


* CONFIG_PCI is not set for qemu-native

* CONFIG_PVRDMA is not set for qemu


Regards,
Kai






-Alexey




--
Kai Kang

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

Re: [OE-core] qemu: backport patches to fix cves breaks qemu-system-native

[Kang Kai]

On 2019/3/20 下午3:42, Alexey Brodkin wrote:

Hello Kai Kang,

You recent changes in QEMU [1] lead to build failure:
-->8-
# bitbake qemu-system-native
...
| 
.../build/tmp-glibc/work/x86_64-linux/qemu-system-native/3.1.0-r0/qemu-3.1.0/hw/rdma/rdma_backend.c:316:42:
 error: 'VENDOR_ERR_INV_NUM_SGE' undeclared (first use in this function)
|  comp_handler(IBV_WC_GENERAL_ERR, VENDOR_ERR_INV_NUM_SGE, ctx);
|   ^
-->8-

That's obviously because of 
meta/recipes-devtools/qemu/qemu/0015-fix-CVE-2018-20124.patch.

I'm wondering if you tried to build QEMU yourself?


My fault. qemu & qemu-native has been verified but qemu-system-native 
not. I'll send fix ASAP.


Regards,
Kai




[1] 
https://github.com/openembedded/openembedded-core/commit/489ece1aa90d8f76b4c1f009d837f82e38e11ba9

-Alexey



--
Kai Kang

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

Re: [OE-core] [PATCH v2] libidn2: fix buildpaths qa issue in .pc file

[Kang Kai]

On 2019/2/19 下午2:57, kai.k...@windriver.com wrote:

From: Kai Kang 

When enable buildpaths qa check, it show warning of libidn2:

| WARNING: libidn2-2.0.5-r0 do_package_qa: QA Issue: File
/work/armv5e-poky-linux-gnueabi/libidn2/2.0.5-r0/packages-split/libidn2-dev/usr/lib/pkgconfig/libidn2.pc
in package contained reference to tmpdir [buildpaths]

Fix the issue by substituting @LTLIBUNISTRING@ in the .pc file.


Ping.




Signed-off-by: Kai Kang 
---
  .../fix-host-contamination-in-pc-file.patch   | 22 +++
  meta/recipes-extended/libidn/libidn2_2.0.5.bb |  3 ++-
  2 files changed, 24 insertions(+), 1 deletion(-)
  create mode 100644 
meta/recipes-extended/libidn/libidn2/fix-host-contamination-in-pc-file.patch

diff --git 
a/meta/recipes-extended/libidn/libidn2/fix-host-contamination-in-pc-file.patch 
b/meta/recipes-extended/libidn/libidn2/fix-host-contamination-in-pc-file.patch
new file mode 100644
index 00..026312ab0a
--- /dev/null
+++ 
b/meta/recipes-extended/libidn/libidn2/fix-host-contamination-in-pc-file.patch
@@ -0,0 +1,22 @@
+Configure option --with-libunistring-prefix is set to fix compile-host-path qa
+issue. It causes @LTLIBUNISTRING@ in line 'Libs.private' of libidn2.pc replaced
+with ${STAGING_EXECPREFIXDIR} which causes buildpaths qa issue.
+
+libunistring is a dependency of libidn2 and installs libraries to standard
+library path, so just substitute @LTLIBUNISTRING@ with standard library path
+and -lunistring in libidn2.pc.in.
+
+Upstream-Status: Inappropriate [embedded specific]
+
+Signed-off-by: Kai Kang 
+---
+diff --git a/libidn2.pc.in b/libidn2.pc.in
+index 0dade23..24cc29d 100644
+--- a/libidn2.pc.in
 b/libidn2.pc.in
+@@ -8,4 +8,4 @@ Description: Library implementing IDNA2008 and TR46
+ Version: @PACKAGE_VERSION@
+ Cflags: -I${includedir}
+ Libs: -L${libdir} -lidn2
+-Libs.private: @LTLIBICONV@ @LTLIBUNISTRING@
++Libs.private: @LTLIBICONV@ -L${libdir} -lunistring
diff --git a/meta/recipes-extended/libidn/libidn2_2.0.5.bb 
b/meta/recipes-extended/libidn/libidn2_2.0.5.bb
index 0daf7a6877..a243a9181e 100644
--- a/meta/recipes-extended/libidn/libidn2_2.0.5.bb
+++ b/meta/recipes-extended/libidn/libidn2_2.0.5.bb
@@ -11,7 +11,8 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=ab90e75ef97cc6318ce4f2fbda62fe4d \
  
  SRC_URI = "${GNU_MIRROR}/libidn/${BPN}-${PV}.tar.gz \

 file://Unset-need_charset_alias-when-building-for-musl.patch \
-  "
+   file://fix-host-contamination-in-pc-file.patch \
+   "
  SRC_URI[md5sum] = "eaf9a5b9d03b0cce3760f34b3124eb36"
  SRC_URI[sha256sum] = 
"53f69170886f1fa6fa5b332439c7a77a7d22626a82ef17e2c1224858bb4ca2b8"
  



--
Kai Kang

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

Re: [OE-core] [PATCH 3/4] libidn2: fix buildpaths qa warning

[Kang Kai]

On 2019/2/15 下午5:57, Richard Purdie wrote:

On Thu, 2019-02-14 at 21:06 -0500, kai.k...@windriver.com wrote:

From: Kai Kang 

Fix buildpaths qa warning of libidn2:


WARNING: libidn2-2.0.5-r0 do_package_qa: QA Issue: File
/work/core2-64-poky-linux/libidn2/2.0.5-r0/packages-split/libidn2-
dev/usr/lib/pkgconfig/libidn2.pc
in package contained reference to tmpdir [buildpaths]

Signed-off-by: Kai Kang 
---
  meta/recipes-extended/libidn/libidn2_2.0.5.bb | 4 
  1 file changed, 4 insertions(+)

diff --git a/meta/recipes-extended/libidn/libidn2_2.0.5.bb
b/meta/recipes-extended/libidn/libidn2_2.0.5.bb
index 0daf7a6877..da77c4402d 100644
--- a/meta/recipes-extended/libidn/libidn2_2.0.5.bb
+++ b/meta/recipes-extended/libidn/libidn2_2.0.5.bb
@@ -26,4 +26,8 @@ EXTRA_OECONF += "--disable-rpath \
  LICENSE_${PN} = "(GPLv2+ | LGPLv3)"
  LICENSE_${PN}-bin = "GPLv3+"
  
+do_install_append () {

+sed -i 's#${RECIPE_SYSROOT}##'
${D}${libdir}/pkgconfig/libidn2.pc
+}
+
  BBCLASSEXTEND = "native nativesdk"

I have a strong dislike for editing .pc files after the fact. Part of
the concern is sed expressions like this bitrot badly, its hard to tell
if they still work as intended.

Is there not a way we can generate a correct .pc file in the first
place even if that means a patch?


The buildpaths qa issue is caused by a patch to fix compile-host-path qa 
issue. But I could NOT reproduce compile-host-path issue when revert the 
patch.

I'll turn Khem for some help to check whether could revert that patch.

commit e87b501659eecc22f48b3e3ca8cde6b4de9f663a
Author: Khem Raj 
Date:   Sun Aug 19 10:23:41 2018 -0700

    libidn2: Fix libunistring detection

    libunistring is one such library which many autotooled packages
    mistake to use from build system if its installed on it. This
    is specifically toxic when build host arch is same as target arch
    since we only see the problem during runtime but thankfully OE
    has build time QA which warns about it.

    QA Issue: libidn2: The compile log indicates that host include 
and/or library paths were used.


    Using --with-libunistring-prefix nudges the autoconf system for the
    component to first look into target sysroot before going on to search
    on the build host

    (From OE-Core rev: 9a4ea4ff856e2379888ea5cdcc0e761956e1f53b)

    Signed-off-by: Khem Raj 
    Signed-off-by: Richard Purdie 

diff --git a/meta/recipes-extended/libidn/libidn2_2.0.5.bb 
b/meta/recipes-extended/libidn/libidn2_2.0.5.bb

index 0d7bddbc7f..0daf7a6877 100644
--- a/meta/recipes-extended/libidn/libidn2_2.0.5.bb
+++ b/meta/recipes-extended/libidn/libidn2_2.0.5.bb
@@ -19,6 +19,10 @@ DEPENDS = "virtual/libiconv libunistring"

 inherit pkgconfig autotools gettext texinfo gtk-doc lib_package

+EXTRA_OECONF += "--disable-rpath \
+ --with-libunistring-prefix=${STAGING_EXECPREFIXDIR} \
+ "
+
 LICENSE_${PN} = "(GPLv2+ | LGPLv3)"
 LICENSE_${PN}-bin = "GPLv3+"

Thanks.
Kai



Cheers,

Richard





--
Kai Kang

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

Re: [OE-core] [PATCH] bitbake.conf: reset default value of DEBUG_PREFIX_MAP

[Kang Kai]

On 2019/1/21 上午10:17, Khem Raj wrote:

On Sun, Jan 20, 2019 at 6:12 PM Kang Kai  wrote:

On 2019/1/19 上午4:54, Khem Raj wrote:

On Fri, Jan 18, 2019 at 12:43 PM Burton, Ross  wrote:

On Fri, 18 Jan 2019 at 17:55, Khem Raj  wrote:

I am bit concerned about using -ffile-prefix-map here, its gcc only
option so will cause clang to fail

It's almost like we need a toolchain override so this can be gcc-specific...

I've been meaning to do that for about a year now :(

Until then, couldn't meta-clang just override the value from the layer?

yes it can, but one by one there are many changes to keep and core becomes
tied to gcc. We should be conscious about it.


  From the link https://reviews.llvm.org/D49466 pasted by Dan, we know
that clang will support option '-ffile-prefix-map'.
I prefer to override DEBUG_PREFIX_MAP in meta-clang and remove it when
clang support for '-ffile-prefix-map' implemented.

Thats ok, not worried about clang at this point. But the patch itself
was not working last time on gcc either. So if that is fixed we can consider it.



OK. I am working on the issued pointed by Richard.





Regards,
Kai



Ross


--
Kai Kang



--
Kai Kang

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

Re: [OE-core] [PATCH] bitbake.conf: reset default value of DEBUG_PREFIX_MAP

[Kang Kai]

On 2019/1/19 上午4:54, Khem Raj wrote:

On Fri, Jan 18, 2019 at 12:43 PM Burton, Ross  wrote:

On Fri, 18 Jan 2019 at 17:55, Khem Raj  wrote:

I am bit concerned about using -ffile-prefix-map here, its gcc only
option so will cause clang to fail

It's almost like we need a toolchain override so this can be gcc-specific...

I've been meaning to do that for about a year now :(

Until then, couldn't meta-clang just override the value from the layer?

yes it can, but one by one there are many changes to keep and core becomes
tied to gcc. We should be conscious about it.



From the link https://reviews.llvm.org/D49466 pasted by Dan, we know 
that clang will support option '-ffile-prefix-map'.
I prefer to override DEBUG_PREFIX_MAP in meta-clang and remove it when 
clang support for '-ffile-prefix-map' implemented.


Regards,
Kai





Ross



--
Kai Kang

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

Re: [OE-core] [PATCH] bitbake.conf: reset default value of DEBUG_PREFIX_MAP

[Kang Kai]

On 2019/1/17 下午11:19, Christopher Larson wrote:
The commit message doesn’t match what you’re actually doing. 
"Specifying -fdebug-prefix-map is equivalent to specifying all 
the individual -f*-prefix-map options which means 
including -fmacro-prefix-map and -fdebug-prefix-map currently” I 
assume you mean "Specifying -ffile-prefix-map” there.



Sorry typo here.

Regards,
Kai




On Thu, Jan 17, 2019 at 12:13 AM > wrote:


From: Kai Kang mailto:kai.k...@windriver.com>>

Reset default value of DEBUG_PREFIX_MAP with '-fdebug-prefix-map'.
Specifying -fdebug-prefix-map is equivalent to specifying all the
individual -f*-prefix-map options which means including
-fmacro-prefix-map and -fdebug-prefix-map currently. Option
-fmacro-prefix-map helps to avoid buildpaths qa warnings which caused
by __FILE__ macro expansion for packages such as llvm and librepo.

Signed-off-by: Kai Kang mailto:kai.k...@windriver.com>>
---
 meta/conf/bitbake.conf | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 0bdcd04d74..d20460e845 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -599,9 +599,9 @@ EXTRA_OEMAKE_prepend_task-install =
"${PARALLEL_MAKEINST} "
 # Optimization flags.
 ##
 # Beware: applied last to first
-DEBUG_PREFIX_MAP ?=
"-fdebug-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}
\
-                     -fdebug-prefix-map=${STAGING_DIR_HOST}= \
-  -fdebug-prefix-map=${STAGING_DIR_NATIVE}= \
+DEBUG_PREFIX_MAP ?=
"-ffile-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}
\
+                     -ffile-prefix-map=${STAGING_DIR_HOST}= \
+                     -ffile-prefix-map=${STAGING_DIR_NATIVE}= \
 "
 DEBUG_FLAGS ?= "-g -feliminate-unused-debug-types
${DEBUG_PREFIX_MAP}"

-- 
2.20.0


-- 
___

Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

http://lists.openembedded.org/mailman/listinfo/openembedded-core



--
Christopher Larson
kergoth at gmail dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Senior Software Engineer, Mentor Graphics



--
Kai Kang

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

Re: [OE-core] [PATCH] libcomps & librepo: fix buildpaths qa warnings

[Kang Kai]

On 2019/1/15 下午6:01, Burton, Ross wrote:

On Tue, 15 Jan 2019 at 06:46,  wrote:

Add preprocess option '-fmacro-prefix-map' to TARGET_CPPFLAGS to fix
buildpaths qa warnings of libcomps and librepo.

This is something we should be doing globally, not in a specific recipe.

We pass -fdebug-prefix-map already in bitbake.conf (remap debug
paths), and macro-prefix-map is the same but for __FILE__.  This is
good, because we've a few patches to remove __FILE__ already and this
means we can drop it.

Digging further reveals that there's also -ffile-prefix-map, which
sets debug-prefix-map and macro-prefix-map at once.  We should just
change bitbake.conf to use that instead of debug-prefix-map.


OK.

--Kai




Ross



--
Kai Kang

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

Re: [OE-core] [PATCH] libcomps & librepo: fix buildpaths qa warnings

[Kang Kai]

On 2019/1/15 下午5:57, Alexander Kanavin wrote:

On Tue, 15 Jan 2019 at 07:46,  wrote:

Add preprocess option '-fmacro-prefix-map' to TARGET_CPPFLAGS to fix
buildpaths qa warnings of libcomps and librepo.

These warnings are not happening on the AB or on my local setup. Could
they be happening due to something in your local config?


Hi Alex,

I just enabled buildpaths check in local.conf:

WARN_QA_append = " buildpaths"

Regards,
Kai



Can you try
with plain poky master please?

Alex



--
Kai Kang

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

Re: [OE-core] [PATCH] wic: update test case test_qemu

[Kang Kai]

On 2019/1/11 下午9:15, Burton, Ross wrote:
I'm wondering what the point of checking the output of mount is.  If 
we're just checking that the image booted then the grep is sufficient 
right?



If just checking the wic image has been booted successfully, I think 
grep /boot is sufficient. V2 will be sent.


--Kai





Ross

On Fri, 11 Jan 2019 at 09:22, Kang Kai <mailto:kai.k...@windriver.com>> wrote:


On 2019/1/4 上午10:49, kai.k...@windriver.com
<mailto:kai.k...@windriver.com> wrote:
> From: Kai Kang mailto:kai.k...@windriver.com>>
>
> It checks output of mount in wic test case test_qemu. But the
outputs are
> different between sysvinit and systemd. Add assertion for systemd.
>
> Signed-off-by: Kai Kang mailto:kai.k...@windriver.com>>
> ---
>   meta/lib/oeqa/selftest/cases/wic.py | 5 -
>   1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/meta/lib/oeqa/selftest/cases/wic.py
b/meta/lib/oeqa/selftest/cases/wic.py
> index 36ee5e5a14..a6bc566166 100644
> --- a/meta/lib/oeqa/selftest/cases/wic.py
> +++ b/meta/lib/oeqa/selftest/cases/wic.py
> @@ -627,7 +627,10 @@ class Wic2(WicTestCase):
>           with runqemu('wic-image-minimal', ssh=False) as qemu:
>               cmd = "mount |grep '^/dev/' | cut -f1,3 -d ' ' | sort"
>               status, output = qemu.run_serial(cmd)
> -            self.assertEqual(output, '/dev/root /\r\n/dev/sda1
/boot\r\n/dev/sda3 /media\r\n/dev/sda4 /mnt')
> +            if 'sysvinit' in get_bb_var('DISTRO_FEATURES'):
> +                self.assertEqual(output, '/dev/root
/\r\n/dev/sda1 /boot\r\n/dev/sda3 /media\r\n/dev/sda4 /mnt')
> +            else:
> +                self.assertEqual(output, '/dev/sda1
/boot\r\n/dev/sda2 /\r\n/dev/sda3 /media\r\n/dev/sda4 /mnt')
>               cmd = "grep UUID= /etc/fstab"
>               status, output = qemu.run_serial(cmd)
>               self.assertEqual(1, status, 'Failed to run command
"%s": %s' % (cmd, output))


Ping

-- 
Kai Kang


-- 
___

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



--
Kai Kang

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

Re: [OE-core] [PATCH] wic: update test case test_qemu

[Kang Kai]

On 2019/1/4 上午10:49, kai.k...@windriver.com wrote:

From: Kai Kang 

It checks output of mount in wic test case test_qemu. But the outputs are
different between sysvinit and systemd. Add assertion for systemd.

Signed-off-by: Kai Kang 
---
  meta/lib/oeqa/selftest/cases/wic.py | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/selftest/cases/wic.py 
b/meta/lib/oeqa/selftest/cases/wic.py
index 36ee5e5a14..a6bc566166 100644
--- a/meta/lib/oeqa/selftest/cases/wic.py
+++ b/meta/lib/oeqa/selftest/cases/wic.py
@@ -627,7 +627,10 @@ class Wic2(WicTestCase):
  with runqemu('wic-image-minimal', ssh=False) as qemu:
  cmd = "mount |grep '^/dev/' | cut -f1,3 -d ' ' | sort"
  status, output = qemu.run_serial(cmd)
-self.assertEqual(output, '/dev/root /\r\n/dev/sda1 
/boot\r\n/dev/sda3 /media\r\n/dev/sda4 /mnt')
+if 'sysvinit' in get_bb_var('DISTRO_FEATURES'):
+self.assertEqual(output, '/dev/root /\r\n/dev/sda1 
/boot\r\n/dev/sda3 /media\r\n/dev/sda4 /mnt')
+else:
+self.assertEqual(output, '/dev/sda1 /boot\r\n/dev/sda2 
/\r\n/dev/sda3 /media\r\n/dev/sda4 /mnt')
  cmd = "grep UUID= /etc/fstab"
  status, output = qemu.run_serial(cmd)
  self.assertEqual(1, status, 'Failed to run command "%s": %s' % 
(cmd, output))



Ping

--
Kai Kang

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

Re: [OE-core] [poky] [meta-poky][PATCH 1/1] local.conf.sample: make systemd as default init manager

[Kang Kai]

On 2018/12/10 上午2:12, Richard Purdie wrote:

On Thu, 2018-12-06 at 20:53 +0800,kai.k...@windriver.com  wrote:

From: Kai Kang

Move configurations from local.conf.sample.extended to
local.conf.sample
to make systemd as default init manager for poky.

[YOCTO #13031]

Signed-off-by: Kai Kang
---
  meta-poky/conf/local.conf.sample  | 8 
  meta-poky/conf/local.conf.sample.extended | 8 
  2 files changed, 8 insertions(+), 8 deletions(-)

I had a feeling there would be some issues to fix before we could do
this by default:

systemd fails to compile with x32:
https://autobuilder.yoctoproject.org/typhoon/#/builders/57/builds/76



Fixed.



sanity tests on qemux86-64 core-image-sato-sdk:
https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/77/steps/7/logs/step1c


| RESULTS - stap.StapTest.test_stap - Testcase 1652: FAILED (674.37s)

Can't reproduce.



sanity tests on qemuarm core-image-sato-sdk with poky-lsb:
https://autobuilder.yoctoproject.org/typhoon/#/builders/38/builds/77/steps/7/logs/step1c

dpkg issues:
https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/77/steps/7/logs/step2c
https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/77/steps/7/logs/step1c


| RESULTS - parselogs.ParseLogsTest.test_parselogs - Testcase 1059: 
FAILED (36.92s)


Can't reproduce



wic failure:
https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/33/steps/7/logs/step2d
(postinstall problem?)


wic.Wic.test_iso_image: can't reproduce

wic.Wic2.test_iso_image: RR sendgb



musl sanity test issue:
https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/77/steps/7/logs/step1c
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/78/steps/7/logs/step1c


| RESULTS - systemd.SystemdJournalTests.test_systemd_boot_time - 
Testcase -1: SKIPPED (0.19s)


Fixed.


Would you like to try this patch again? Thanks.


--Kai




Hopefully its a small number of issues at the heart of this but we need
to sort this out before it can merge.

Cheers,

Richard





--
Kai Kang

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

Re: [OE-core] [PATCH 04/13] libdazzle: fix a build issue with meson 0.49.0

[Kang Kai]

On 2018/12/19 上午12:29, Alexander Kanavin wrote:

Signed-off-by: Alexander Kanavin 


Hi Alexander,

Have you ever meet build failure on qemumips with libdazzle:

 389 
/home/kkang/buildarea/WRLX-1019/systemd-oe-selftest-Dec24/tmp-glibc/work/mips32r2-wrs-linux/libdazzle/3.30.2-r0/recipe-sysroot/usr/include/glib-2.0/gobject/gobject.h:725: 
syntax error,
 unexpected ')' in '    ((__typeof__(new_object)) (g_object_ref) 
(new_object));' at ')'

 390 qemu: uncaught target signal 11 (Segmentation fault) - core dumped
 391 
/home/kkang/buildarea/WRLX-1019/systemd-oe-selftest-Dec24/tmp-glibc/work/mips32r2-wrs-linux/libdazzle/3.30.2-r0/recipe-sysroot/usr/bin/g-ir-scanner-qemuwrapper: 
line 6: 24294 Segmentati
 on fault  (core dumped) PSEUDO_UNLOAD=1 qemu-mips -r 3.2.0 -L 
/home/kkang/buildarea/WRLX-1019/systemd-oe-selftest-Dec24/tmp-glibc/work/mips32r2-wrs-linux/libdazzle/3.30.2-r0/recipe-
 sysroot -E 
LD_LIBRARY_PATH=$GIR_EXTRA_LIBS_PATH:.libs:/home/kkang/buildarea/WRLX-1019/systemd-oe-selftest-Dec24/tmp-glibc/work/mips32r2-wrs-linux/libdazzle/3.30.2-r0/recipe-sysroot//usr
/lib:/home/kkang/buildarea/WRLX-1019/systemd-oe-selftest-Dec24/tmp-glibc/work/mips32r2-wrs-linux/libdazzle/3.30.2-r0/recipe-sysroot//lib 
"$@"
 392 If the above error message is about missing .so libraries, then 
setting up GIR_EXTRA_LIBS_PATH in the recipe should help.

 393 (typically like this: GIR_EXTRA_LIBS_PATH="${B}/something/.libs" )
 394 Command 
'['/home/kkang/buildarea/WRLX-1019/systemd-oe-selftest-Dec24/tmp-glibc/work/mips32r2-wrs-linux/libdazzle/3.30.2-r0/recipe-sysroot/usr/bin/g-ir-scanner-qemuwrapper', 
'/home/kkang
/buildarea/WRLX-1019/systemd-oe-selftest-Dec24/tmp-glibc/work/mips32r2-wrs-linux/libdazzle/3.30.2-r0/build/tmp-introspecta3rexhyk/Dazzle-1.0', 
'--introspect-dump=/home/kkang/buildarea/W

RLX-1019/systemd-oe-selftest-Dec24/tmp-glibc/work/mips32r2-wrs-linux/libdazzle/3.30.2-r0/build/tmp-introspecta3rexhyk/functions.txt,/home/kkang/buildarea/WRLX-1019/systemd-oe-selftest-D
ec24/tmp-glibc/work/mips32r2-wrs-linux/libdazzle/3.30.2-r0/build/tmp-introspecta3rexhyk/dump.xml']' 
returned non-zero exit status 1

 395 ninja: build stopped: subcommand failed.
 396 WARNING: 
/home/kkang/buildarea/WRLX-1019/systemd-oe-selftest-Dec24/tmp-glibc/work/mips32r2-wrs-linux/libdazzle/3.30.2-r0/temp/run.do_compile.23419:1 
exit 1 from 'ninja -v -j 32'
 397 ERROR: Function failed: do_compile (log file is located at 
/home/kkang/buildarea/WRLX-1019/systemd-oe-selftest-Dec24/tmp-glibc/work/mips32r2-wrs-linux/libdazzle/3.30.2-r0/temp/log.do_co

 mpile.23419)


The first error has been fixed in gobject-introspection 1.58.2. But I 
didn't find out the root cause of "qemu: uncaught target signal 11 
(Segmentation fault) - core dumped".



Regards,
Kai



---
  ...ine-so-that-gir-compilation-succeeds.patch | 26 +++
  .../libdazzle/libdazzle_3.30.2.bb |  1 +
  2 files changed, 27 insertions(+)
  create mode 100644 
meta/recipes-gnome/libdazzle/libdazzle/0001-Add-a-define-so-that-gir-compilation-succeeds.patch

diff --git 
a/meta/recipes-gnome/libdazzle/libdazzle/0001-Add-a-define-so-that-gir-compilation-succeeds.patch
 
b/meta/recipes-gnome/libdazzle/libdazzle/0001-Add-a-define-so-that-gir-compilation-succeeds.patch
new file mode 100644
index 000..c959d43972f
--- /dev/null
+++ 
b/meta/recipes-gnome/libdazzle/libdazzle/0001-Add-a-define-so-that-gir-compilation-succeeds.patch
@@ -0,0 +1,26 @@
+From 546d53c3515e8a488a204763437d1fa0917097e5 Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin 
+Date: Tue, 11 Dec 2018 12:39:30 +0100
+Subject: [PATCH] Add a define so that gir compilation succeeds
+
+For some reason meson 0.49.0 does not anymore pass global arguments to gir 
compiler.
+
+Upstream-Status: Pending
+Signed-off-by: Alexander Kanavin 
+---
+ src/meson.build | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/meson.build b/src/meson.build
+index 6ff8a6a..f0b2887 100644
+--- a/src/meson.build
 b/src/meson.build
+@@ -132,7 +132,7 @@ if get_option('with_introspection')
+ install_dir_gir: girdir,
+ install_dir_typelib: typelibdir,
+ export_packages: libdazzle_package,
+- extra_args: [ '--c-include=dazzle.h', '--quiet' ],
++ extra_args: [ '--c-include=dazzle.h', '--quiet', 
'-DDAZZLE_COMPILATION' ],
+   )
+
+   if get_option('with_vapi')
diff --git a/meta/recipes-gnome/libdazzle/libdazzle_3.30.2.bb 
b/meta/recipes-gnome/libdazzle/libdazzle_3.30.2.bb
index 029adddb9ee..5441c10f990 100644
--- a/meta/recipes-gnome/libdazzle/libdazzle_3.30.2.bb
+++ b/meta/recipes-gnome/libdazzle/libdazzle_3.30.2.bb
@@ -7,6 +7,7 @@ inherit gnomebase upstream-version-is-even vala 
gobject-introspection
  
  DEPENDS = "glib-2.0-native glib-2.0 gtk+3"
  
+SRC_URI += " file://0001-Add-a-define-so-that-gir-compilation-succeeds.patch"

  SRC_URI[archive.md5sum] = "24e2e1b914a34f5b8868a9507d1f3c4c"
  SRC_URI[archive.sha256sum] = 

Re: [OE-core] [PATCH 1/1] grub-efi-native: workaround for fedora 29

[Kang Kai]

On 2018/12/19 下午6:43, Burton, Ross wrote:

On Wed, 19 Dec 2018 at 07:43,  wrote:

+Upstream-Status: Inappropriate [native]

If we're going to mark this as inappropriate then please make it clear
in the patch that its a workaround for a specific binutils and when
that stops being used we can remove it.


binutils version has been addressed in the patch. I'll update with 
workaround info.




However isn't this a problem
when building grub on F29, even outside of Yocto?  If so then it's not
inappropriate, it's an upstream bug and they should have the fix.



It is native build related, so grub is not affected that no grub-native 
is provided. I have created a defect on RedHat bugzilla:


https://bugzilla.redhat.com/show_bug.cgi?id=1660279


Regards,
Kai




Ross



--
Kai Kang

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

Re: [OE-core] [PATCH 1/1] distro_features_check.bbclass: show all error info at one time

[Kang Kai]

On 2018/12/6 下午9:41, kai.k...@windriver.com wrote:

From: Kai Kang 

In distro_features_check.bbclass it checks whether items in
REQUIRED_DISTRO_FEATURES and CONFLICT_DISTRO_FEATURES exist in
DISTRO_FEATURES. But it only shows one required or conflict distro
feature when error occurs. Update to show them all at one time.

Signed-off-by: Kai Kang 
---
  meta/classes/distro_features_check.bbclass | 29 +-
  1 file changed, 12 insertions(+), 17 deletions(-)

diff --git a/meta/classes/distro_features_check.bbclass 
b/meta/classes/distro_features_check.bbclass
index 9b78b03ef6..eeaa3b44cb 100644
--- a/meta/classes/distro_features_check.bbclass
+++ b/meta/classes/distro_features_check.bbclass
@@ -11,27 +11,22 @@
  
  python () {

  # Assume at least one var is set.
-distro_features = (d.getVar('DISTRO_FEATURES') or "").split()
+distro_features = set((d.getVar('DISTRO_FEATURES') or '').split())
  
-any_of_distro_features = d.getVar('ANY_OF_DISTRO_FEATURES')

+any_of_distro_features = set((d.getVar('ANY_OF_DISTRO_FEATURES') or 
'').split())
  if any_of_distro_features:
-any_of_distro_features = any_of_distro_features.split()
-if set.isdisjoint(set(any_of_distro_features),set(distro_features)):
-raise bb.parse.SkipRecipe("one of '%s' needs to be in 
DISTRO_FEATURES" % any_of_distro_features)
+if set.isdisjoint(any_of_distro_features, distro_features):
+raise bb.parse.SkipRecipe("one of '%s' needs to be in 
DISTRO_FEATURES" % ' '.join(any_of_distro_features))
  
-required_distro_features = d.getVar('REQUIRED_DISTRO_FEATURES')

+required_distro_features = set((d.getVar('REQUIRED_DISTRO_FEATURES') or 
'').split())
  if required_distro_features:
-required_distro_features = required_distro_features.split()
-for f in required_distro_features:
-if f in distro_features:
-continue
-else:
-raise bb.parse.SkipRecipe("missing required distro feature '%s' 
(not in DISTRO_FEATURES)" % f)
+missing = set.difference(required_distro_features, distro_features)
+if missing:
+raise bb.parse.SkipRecipe("missing required distro feature%s '%s' (not in 
DISTRO_FEATURES)" % ('s' if len(missing) > 1 else '', ' '.join(missing)))
  
-conflict_distro_features = d.getVar('CONFLICT_DISTRO_FEATURES')

+conflict_distro_features = set((d.getVar('CONFLICT_DISTRO_FEATURES') or 
'').split())
  if conflict_distro_features:
-conflict_distro_features = conflict_distro_features.split()
-for f in conflict_distro_features:
-if f in distro_features:
-raise bb.parse.SkipRecipe("conflicting distro feature '%s' (in 
DISTRO_FEATURES)" % f)
+conflicts = set.intersection(conflict_distro_features, distro_features)
+if conflicts:
+raise bb.parse.SkipRecipe("conflicting distro feature%s '%s' (in 
DISTRO_FEATURES)" % ('s' if len(conflicts) > 1 else '', ' '.join(conflicts)))
  }


Any comment on this patch? Thanks.

--
Kai Kang

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

Re: [OE-core] [PATCH 0/1] distro_features_check.bbclass: show all error info at one time

[Kang Kai]

On 2018/12/6 下午9:41, kai.k...@windriver.com wrote:

From: Kai Kang 

The following changes since commit aa93957c8353d222961f08e54fe8d4095dad72c1:

   tcl: Upgrade to 8.6.9 (2018-12-05 22:30:19 +)

are available in the Git repository at:

   git://git.pokylinux.org/poky-contrib kangkai/distro-check
   http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=kangkai/distro-check

Kai Kang (1):
   distro_features_check.bbclass: show all error info at one time

  meta/classes/distro_features_check.bbclass | 29 +-
  1 file changed, 12 insertions(+), 17 deletions(-)



Ping.

--
Kai Kang

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

Re: [OE-core] [poky] [meta-poky][PATCH 1/1] local.conf.sample: make systemd as default init manager

[Kang Kai]

On 2018/12/10 上午2:12, Richard Purdie wrote:

On Thu, 2018-12-06 at 20:53 +0800, kai.k...@windriver.com wrote:

From: Kai Kang 

Move configurations from local.conf.sample.extended to
local.conf.sample
to make systemd as default init manager for poky.

[YOCTO #13031]

Signed-off-by: Kai Kang 
---
  meta-poky/conf/local.conf.sample  | 8 
  meta-poky/conf/local.conf.sample.extended | 8 
  2 files changed, 8 insertions(+), 8 deletions(-)

I had a feeling there would be some issues to fix before we could do
this by default:

systemd fails to compile with x32:
https://autobuilder.yoctoproject.org/typhoon/#/builders/57/builds/76

sanity tests on qemux86-64 core-image-sato-sdk:
https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/77/steps/7/logs/step1c

sanity tests on qemuarm core-image-sato-sdk with poky-lsb:
https://autobuilder.yoctoproject.org/typhoon/#/builders/38/builds/77/steps/7/logs/step1c

dpkg issues:
https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/77/steps/7/logs/step2c
https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/77/steps/7/logs/step1c

wic failure:
https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/33/steps/7/logs/step2d
(postinstall problem?)

musl sanity test issue:
https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/77/steps/7/logs/step1c
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/78/steps/7/logs/step1c



Got it. I am going to fix fix them.

Regards,
Kai





Hopefully its a small number of issues at the heart of this but we need
to sort this out before it can merge.

Cheers,

Richard




--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 1/1] udev-hwdb: fix postinstall scripts failures when multilib enabled

[Kang Kai]

On 2018/10/24 上午5:17, richard.pur...@linuxfoundation.org wrote:

On Tue, 2018-10-23 at 14:43 +0800, Kang Kai wrote:

On 2018/10/22 下午11:11, Kang Kai wrote:

On 2018/10/18 下午11:28, kai.k...@windriver.com wrote:

From: Kai Kang 

When multilib is enabled and both udev-hwdb and ${MLPREFIX}udev-
hwdb are
installed to image, it fails to run one of their postinstall
scripts
that they both call ${base_bindir}/udevadm with same user mode
qemu.

Duplicate udevadm and add postinst-intercept update_udev_hwdb to
fix the
failures.

Signed-off-by: Kai Kang 
---
   meta/recipes-core/systemd/systemd_239.bb | 13 ++---
   meta/recipes-core/udev/eudev_3.2.5.bb| 11 +--
   scripts/postinst-intercepts/update_udev_hwdb |  6 ++
   3 files changed, 17 insertions(+), 13 deletions(-)
   create mode 100644 scripts/postinst-intercepts/update_udev_hwdb

diff --git a/meta/recipes-core/systemd/systemd_239.bb
b/meta/recipes-core/systemd/systemd_239.bb
index 7ed932141d..44e972ebce 100644
--- a/meta/recipes-core/systemd/systemd_239.bb
+++ b/meta/recipes-core/systemd/systemd_239.bb
@@ -284,6 +284,10 @@ do_install() {
   chown polkitd:root ${D}${datadir}/polkit-1/rules.d
   fi
   fi
+
+# duplicate udevadm for postinst script
+install -d ${D}${libexecdir}
+ln ${D}${base_bindir}/udevadm
${D}${libexecdir}/${MLPREFIX}udevadm
   }
 @@ -542,6 +546,7 @@ FILES_udev += "${base_sbindir}/udevd \
  ${systemd_unitdir}/system/*udev* \
  ${systemd_unitdir}/system/*.wants/*udev* \
  ${base_bindir}/udevadm \
+   ${libexecdir}/${MLPREFIX}udevadm \
  ${datadir}/bash-completion/completions/udevadm \
 "
   @@ -580,13 +585,7 @@ pkg_prerm_${PN} () {
   PACKAGE_WRITE_DEPS += "qemu-native"
   pkg_postinst_udev-hwdb () {
   if test -n "$D"; then
-if ${@bb.utils.contains('MACHINE_FEATURES', 'qemu-
usermode',
'true','false', d)}; then
-${@qemu_run_binary(d, '$D',
'${base_bindir}/udevadm')}
hwdb --update \
---root $D
-chown root:root $D${sysconfdir}/udev/hwdb.bin
-else
-$INTERCEPT_DIR/postinst_intercept
delay_to_first_boot
${PKG} mlprefix=${MLPREFIX}
-fi
+$INTERCEPT_DIR/postinst_intercept update_udev_hwdb
${PKG}
mlprefix=${MLPREFIX} binprefix=${MLPREFIX}
   else
   udevadm hwdb --update
   fi
diff --git a/meta/recipes-core/udev/eudev_3.2.5.bb
b/meta/recipes-core/udev/eudev_3.2.5.bb
index efd62c6495..592dd8f22a 100644
--- a/meta/recipes-core/udev/eudev_3.2.5.bb
+++ b/meta/recipes-core/udev/eudev_3.2.5.bb
@@ -50,6 +50,10 @@ do_install_append() {
 # hid2hci has moved to bluez4. removed in udev as of
version 169
   rm -f ${D}${base_libdir}/udev/hid2hci
+
+# duplicate udevadm for postinst script
+install -d ${D}${libexecdir}
+ln ${D}${bindir}/udevadm
${D}${libexecdir}/${MLPREFIX}udevadm
   }
 do_install_prepend_class-target () {
@@ -81,12 +85,7 @@ RPROVIDES_eudev-hwdb += "udev-hwdb"
   PACKAGE_WRITE_DEPS += "qemu-native"
   pkg_postinst_eudev-hwdb () {
   if test -n "$D"; then
-if ${@bb.utils.contains('MACHINE_FEATURES', 'qemu-
usermode',
'true','false', d)}; then

Hi Richard,

It seems check for 'qemu-usermode' should not be removed. And it
also
need to check for other intercept scripts.

I just realize that intercept scripts have been handled well in
lib/oe/package_manager.py. So please ignore my last reply.

I'm now confused, which version of this patch do we need?


Sorry for missing your comment and made you inconvenient.

I received some inner comments that remove check 'qemu-usermode' may 
cause problem. I was convinced and it has been merged to master-next 
already,
so I sent a reply that 'will send V2'. But after build without machine 
feature  'qemu-usermode', it turns out that the guardian of 
'qemu-usermode' has been
handled well by package_manager.py. Then I sent the last reply and not 
V2 patch sent.


Regards,
Kai




Cheers,

Richard




--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 1/1] udev-hwdb: fix postinstall scripts failures when multilib enabled

[Kang Kai]

On 2018/10/22 下午11:11, Kang Kai wrote:

On 2018/10/18 下午11:28, kai.k...@windriver.com wrote:

From: Kai Kang 

When multilib is enabled and both udev-hwdb and ${MLPREFIX}udev-hwdb are
installed to image, it fails to run one of their postinstall scripts
that they both call ${base_bindir}/udevadm with same user mode qemu.

Duplicate udevadm and add postinst-intercept update_udev_hwdb to fix the
failures.

Signed-off-by: Kai Kang 
---
  meta/recipes-core/systemd/systemd_239.bb | 13 ++---
  meta/recipes-core/udev/eudev_3.2.5.bb    | 11 +--
  scripts/postinst-intercepts/update_udev_hwdb |  6 ++
  3 files changed, 17 insertions(+), 13 deletions(-)
  create mode 100644 scripts/postinst-intercepts/update_udev_hwdb

diff --git a/meta/recipes-core/systemd/systemd_239.bb 
b/meta/recipes-core/systemd/systemd_239.bb

index 7ed932141d..44e972ebce 100644
--- a/meta/recipes-core/systemd/systemd_239.bb
+++ b/meta/recipes-core/systemd/systemd_239.bb
@@ -284,6 +284,10 @@ do_install() {
  chown polkitd:root ${D}${datadir}/polkit-1/rules.d
  fi
  fi
+
+    # duplicate udevadm for postinst script
+    install -d ${D}${libexecdir}
+    ln ${D}${base_bindir}/udevadm ${D}${libexecdir}/${MLPREFIX}udevadm
  }
    @@ -542,6 +546,7 @@ FILES_udev += "${base_sbindir}/udevd \
 ${systemd_unitdir}/system/*udev* \
 ${systemd_unitdir}/system/*.wants/*udev* \
 ${base_bindir}/udevadm \
+   ${libexecdir}/${MLPREFIX}udevadm \
 ${datadir}/bash-completion/completions/udevadm \
    "
  @@ -580,13 +585,7 @@ pkg_prerm_${PN} () {
  PACKAGE_WRITE_DEPS += "qemu-native"
  pkg_postinst_udev-hwdb () {
  if test -n "$D"; then
-    if ${@bb.utils.contains('MACHINE_FEATURES', 'qemu-usermode', 
'true','false', d)}; then
-    ${@qemu_run_binary(d, '$D', '${base_bindir}/udevadm')} 
hwdb --update \

-    --root $D
-    chown root:root $D${sysconfdir}/udev/hwdb.bin
-    else
-    $INTERCEPT_DIR/postinst_intercept delay_to_first_boot 
${PKG} mlprefix=${MLPREFIX}

-    fi
+    $INTERCEPT_DIR/postinst_intercept update_udev_hwdb ${PKG} 
mlprefix=${MLPREFIX} binprefix=${MLPREFIX}

  else
  udevadm hwdb --update
  fi
diff --git a/meta/recipes-core/udev/eudev_3.2.5.bb 
b/meta/recipes-core/udev/eudev_3.2.5.bb

index efd62c6495..592dd8f22a 100644
--- a/meta/recipes-core/udev/eudev_3.2.5.bb
+++ b/meta/recipes-core/udev/eudev_3.2.5.bb
@@ -50,6 +50,10 @@ do_install_append() {
    # hid2hci has moved to bluez4. removed in udev as of version 169
  rm -f ${D}${base_libdir}/udev/hid2hci
+
+    # duplicate udevadm for postinst script
+    install -d ${D}${libexecdir}
+    ln ${D}${bindir}/udevadm ${D}${libexecdir}/${MLPREFIX}udevadm
  }
    do_install_prepend_class-target () {
@@ -81,12 +85,7 @@ RPROVIDES_eudev-hwdb += "udev-hwdb"
  PACKAGE_WRITE_DEPS += "qemu-native"
  pkg_postinst_eudev-hwdb () {
  if test -n "$D"; then
-    if ${@bb.utils.contains('MACHINE_FEATURES', 'qemu-usermode', 
'true','false', d)}; then


Hi Richard,

It seems check for 'qemu-usermode' should not be removed. And it also 
need to check for other intercept scripts.


I just realize that intercept scripts have been handled well in 
lib/oe/package_manager.py. So please ignore my last reply.


Sorry for the inconvenience.

--Kai




So please ignore this patch and I'll send V2.

Regards,
Kai


-    ${@qemu_run_binary(d, '$D', '${bindir}/udevadm')} hwdb 
--update --root $D

-    chown root:root $D${sysconfdir}/udev/hwdb.bin
-    else
-    $INTERCEPT_DIR/postinst_intercept delay_to_first_boot 
${PKG} mlprefix=${MLPREFIX}

-    fi
+    $INTERCEPT_DIR/postinst_intercept update_udev_hwdb ${PKG} 
mlprefix=${MLPREFIX} binprefix=${MLPREFIX}

  else
  udevadm hwdb --update
  fi
diff --git a/scripts/postinst-intercepts/update_udev_hwdb 
b/scripts/postinst-intercepts/update_udev_hwdb

new file mode 100644
index 00..b5cce0a09d
--- /dev/null
+++ b/scripts/postinst-intercepts/update_udev_hwdb
@@ -0,0 +1,6 @@
+#!/bin/sh
+
+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





--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 1/1] udev-hwdb: fix postinstall scripts failures when multilib enabled

[Kang Kai]

On 2018/10/18 下午11:28, kai.k...@windriver.com wrote:

From: Kai Kang 

When multilib is enabled and both udev-hwdb and ${MLPREFIX}udev-hwdb are
installed to image, it fails to run one of their postinstall scripts
that they both call ${base_bindir}/udevadm with same user mode qemu.

Duplicate udevadm and add postinst-intercept update_udev_hwdb to fix the
failures.

Signed-off-by: Kai Kang 
---
  meta/recipes-core/systemd/systemd_239.bb | 13 ++---
  meta/recipes-core/udev/eudev_3.2.5.bb| 11 +--
  scripts/postinst-intercepts/update_udev_hwdb |  6 ++
  3 files changed, 17 insertions(+), 13 deletions(-)
  create mode 100644 scripts/postinst-intercepts/update_udev_hwdb

diff --git a/meta/recipes-core/systemd/systemd_239.bb 
b/meta/recipes-core/systemd/systemd_239.bb
index 7ed932141d..44e972ebce 100644
--- a/meta/recipes-core/systemd/systemd_239.bb
+++ b/meta/recipes-core/systemd/systemd_239.bb
@@ -284,6 +284,10 @@ do_install() {
chown polkitd:root ${D}${datadir}/polkit-1/rules.d
fi
fi
+
+   # duplicate udevadm for postinst script
+   install -d ${D}${libexecdir}
+   ln ${D}${base_bindir}/udevadm ${D}${libexecdir}/${MLPREFIX}udevadm
  }
  
  
@@ -542,6 +546,7 @@ FILES_udev += "${base_sbindir}/udevd \

 ${systemd_unitdir}/system/*udev* \
 ${systemd_unitdir}/system/*.wants/*udev* \
 ${base_bindir}/udevadm \
+   ${libexecdir}/${MLPREFIX}udevadm \
 ${datadir}/bash-completion/completions/udevadm \
"
  
@@ -580,13 +585,7 @@ pkg_prerm_${PN} () {

  PACKAGE_WRITE_DEPS += "qemu-native"
  pkg_postinst_udev-hwdb () {
if test -n "$D"; then
-   if ${@bb.utils.contains('MACHINE_FEATURES', 'qemu-usermode', 
'true','false', d)}; then
-   ${@qemu_run_binary(d, '$D', '${base_bindir}/udevadm')} 
hwdb --update \
-   --root $D
-   chown root:root $D${sysconfdir}/udev/hwdb.bin
-   else
-   $INTERCEPT_DIR/postinst_intercept delay_to_first_boot 
${PKG} mlprefix=${MLPREFIX}
-   fi
+   $INTERCEPT_DIR/postinst_intercept update_udev_hwdb ${PKG} 
mlprefix=${MLPREFIX} binprefix=${MLPREFIX}
else
udevadm hwdb --update
fi
diff --git a/meta/recipes-core/udev/eudev_3.2.5.bb 
b/meta/recipes-core/udev/eudev_3.2.5.bb
index efd62c6495..592dd8f22a 100644
--- a/meta/recipes-core/udev/eudev_3.2.5.bb
+++ b/meta/recipes-core/udev/eudev_3.2.5.bb
@@ -50,6 +50,10 @@ do_install_append() {
  
  	# hid2hci has moved to bluez4. removed in udev as of version 169

rm -f ${D}${base_libdir}/udev/hid2hci
+
+   # duplicate udevadm for postinst script
+   install -d ${D}${libexecdir}
+   ln ${D}${bindir}/udevadm ${D}${libexecdir}/${MLPREFIX}udevadm
  }
  
  do_install_prepend_class-target () {

@@ -81,12 +85,7 @@ RPROVIDES_eudev-hwdb += "udev-hwdb"
  PACKAGE_WRITE_DEPS += "qemu-native"
  pkg_postinst_eudev-hwdb () {
  if test -n "$D"; then
-if ${@bb.utils.contains('MACHINE_FEATURES', 'qemu-usermode', 
'true','false', d)}; then


Hi Richard,

It seems check for 'qemu-usermode' should not be removed. And it also 
need to check for other intercept scripts.


So please ignore this patch and I'll send V2.

Regards,
Kai



-${@qemu_run_binary(d, '$D', '${bindir}/udevadm')} hwdb --update 
--root $D
-chown root:root $D${sysconfdir}/udev/hwdb.bin
-else
-$INTERCEPT_DIR/postinst_intercept delay_to_first_boot ${PKG} 
mlprefix=${MLPREFIX}
-fi
+$INTERCEPT_DIR/postinst_intercept update_udev_hwdb ${PKG} 
mlprefix=${MLPREFIX} binprefix=${MLPREFIX}
  else
  udevadm hwdb --update
  fi
diff --git a/scripts/postinst-intercepts/update_udev_hwdb 
b/scripts/postinst-intercepts/update_udev_hwdb
new file mode 100644
index 00..b5cce0a09d
--- /dev/null
+++ b/scripts/postinst-intercepts/update_udev_hwdb
@@ -0,0 +1,6 @@
+#!/bin/sh
+
+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



--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 0/1] udev-hwdb: fix postinstall scripts failures when multilib enabled

[Kang Kai]

On 2018/10/18 下午11:28, kai.k...@windriver.com wrote:

From: Kai Kang 

The following changes since commit 4ef016683d986cc5291e494789ff5a49b28030eb:

   bitbake: test/data: Add new tests for task checksum changing/not changing 
(2018-10-18 10:59:27 +0100)

are available in the Git repository at:

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



Rebased on origin/master and updated contrib branch kangkai/udev.

Regards,
Kai




Kai Kang (1):
   udev-hwdb: fix postinstall scripts failures when multilib enabled

  meta/recipes-core/systemd/systemd_239.bb | 13 ++---
  meta/recipes-core/udev/eudev_3.2.5.bb| 11 +--
  scripts/postinst-intercepts/update_udev_hwdb |  6 ++
  3 files changed, 17 insertions(+), 13 deletions(-)
  create mode 100644 scripts/postinst-intercepts/update_udev_hwdb



--
Regards,
Neil | Kai Kang

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

[Kang Kai]

On 2018/10/19 上午10:21, ChenQi wrote:
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.



This commit is to fix file conflict of /etc/os-release between 
lib32-os-release and os-release.
When install os-release to nonarch_libdir, the issue is gone. So my 
commit could be reverted

when this commit is merged. Tested for qemux86-64.

--Kai





    (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"






--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH v2 0/1] image.bbclass: set consistent staging dirs

[Kang Kai]

On 2018年10月15日 14:31, kai.k...@windriver.com wrote:

From: Kai Kang 

V2:
* set consistent staging dirs for all images


Missing Richard's comment, please ignore this patch.

--Kai




The following changes since commit b02f3bfe2fee291a9db85094e5f31b1933acf871:

   local.conf.sample.extended: add another warning to comment about 
GLIBC_GENERATE_LOCALES (2018-10-14 23:45:40 +0100)

are available in the Git repository at:

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

Kai Kang (1):
   image.bbclass: set consistent staging dirs

  meta/classes/image.bbclass | 5 +
  1 file changed, 5 insertions(+)



--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 1/1] image_types_wic: set consistent staging dirs

[Kang Kai]

On 2018年10月12日 18:43, Richard Purdie wrote:

On Fri, 2018-10-12 at 16:57 +0800, kai.k...@windriver.com wrote:

From: Kai Kang 

When build wic image with multilib enabled by following config:

   MACHINE = "qemux86-64"
   require conf/multilib.conf
   MULTILIBS = "multilib:lib32"
   DEFAULTTUNE_virtclass-multilib-lib32 = "x86"

   IMAGE_FSTYPES = "wic"

it fails to build lib32 image such as lib32-core-image-minimal:


DEBUG: Executing shell function do_image_wic
INFO: Creating image(s)...

ERROR: Couldn't find correct bootimg_dir, exiting

Dependency syslinux is not expand to lib32-syslinux when multilib is
enabled. It is populated to ${WORKDIR}/recipe-sysroot, but script wic
searches syslinux in ${WORKDIR}/lib32-recipe-sysroot and causes
error.

Set consistent staging dirs for wic to fix the issue.

Signed-off-by: Kai Kang 
---
  meta/classes/image_types_wic.bbclass | 5 +
  1 file changed, 5 insertions(+)

diff --git a/meta/classes/image_types_wic.bbclass
b/meta/classes/image_types_wic.bbclass
index 5b40a9e919..402920805d 100644
--- a/meta/classes/image_types_wic.bbclass
+++ b/meta/classes/image_types_wic.bbclass
@@ -54,6 +54,11 @@ WKS_FILE_DEPENDS ??= "${WKS_FILE_DEPENDS_DEFAULT}
${WKS_FILE_DEPENDS_BOOTLOADERS
  
  DEPENDS += "${@ '${WKS_FILE_DEPENDS}' if d.getVar('USING_WIC') else

'' }"
  
+# Dependency syslinux is not expanded when multilib is enabled,

consistent staging dirs are needed
+RECIPE_SYSROOT = "${WORKDIR}/recipe-sysroot"
+STAGING_DIR_HOST = "${WORKDIR}/recipe-sysroot"
+STAGING_DIR_TARGET = "${WORKDIR}/recipe-sysroot"
+

Doesn't that change this for *all* image types? Not sure that is a good
idea...


OK. I'll build and test all image types.

--Kai



Cheers,

Richard





--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 1/1] nss: fix non-determinism when create blank certificate

[Kang Kai]

On 2018年10月12日 02:55, richard.pur...@linuxfoundation.org wrote:

On Thu, 2018-10-11 at 22:24 +0800, kai.k...@windriver.com wrote:

From: Kai Kang 

It uses tool certutil from nss to create a blank certificate. But the
checksum of output file key4.db changes every time:

$ certutil -N -d sql:. --empty-password
$ md5sum *
f9dac2cfcb07cc8ca6db442a9a570906  cert9.db
b892c5ff7c1977d4728240b0cf628377  key4.db
7b9136cb03f07ae62eb213a5239fda71  pkcs11.txt
$ rm *

$ certutil -N -d sql:. --empty-password
$ md5sum *
f9dac2cfcb07cc8ca6db442a9a570906  cert9.db
405d55178e866a115c1aa975fccfa764  key4.db
7b9136cb03f07ae62eb213a5239fda71  pkcs11.txt

Provide pre-created blank database files to fix non-determinism
issue.
And these files are from nss qemux86-64 build.

I agree with this however can we leave a comment in the recipe about
why we're including these and instructions on how to rebuild them
please?


OK. V2 will be sent.

Regards,
Kai



Cheers,

Richard




--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 05/10] nss: move create blank certificates to pkg_postinst

[Kang Kai]

On 2018年10月02日 23:53, richard.pur...@linuxfoundation.org wrote:

On Tue, 2018-10-02 at 23:29 +0800, Kang Kai wrote:

On 2018年09月29日 20:44, Richard Purdie wrote:

On Sat, 2018-09-29 at 13:43 +0800, kai.k...@windriver.com wrote:

From: Kai Kang 

There is a multilib install file conflict of nss:

file /etc/pki/nssdb/key4.db conflicts between attempted
installs of
lib32-nss-3.38-r0.corei7_32 and nss-3.38-r0.corei7_64

Move the creation of blank certificates to pkg_postinst. And
check if
certificates exist already, don't re-create them.

Signed-off-by: Kai Kang 
---
  meta/recipes-support/nss/nss_3.38.bb | 32 +-

--
  1 file changed, 20 insertions(+), 12 deletions(-)

This does raise a question - why aren't the generated files the
same?
Is there a determinism problem here? This sounds like the image
would
change with each build and couldn't be reproduced so we have a
bigger
problem?
  
It calls certutil to create blank certificates:


certutil -N -d sql:${D}${sysconfdir}/pki/nssdb/ -f ./empty_password

It should be current time related that create blank certificates in
current directory, the key4.db files are different:

kkang@msp-lpggp1:~/buildarea/bar-build
$ touch empty
kkang@msp-lpggp1:~/buildarea/bar-build
$ ./tmp/sysroots-components/x86_64/nss-native/usr/bin/certutil -N -d
sql:./ -f ./empty
password file contains no data
kkang@msp-lpggp1:~/buildarea/bar-build
$ md5sum *.db
1de1260b3f38349a8633d33acd4e4de7  cert9.db
*7fea1d4dbc99db3ba1b72e30428eb5dc  key4.db*
kkang@msp-lpggp1:~/buildarea/bar-build
$ rm *.db
kkang@msp-lpggp1:~/buildarea/bar-build
$ ./tmp/sysroots-components/x86_64/nss-native/usr/bin/certutil -N -d
sql:./ -f ./empty
password file contains no data
kkang@msp-lpggp1:~/buildarea/bar-build
$ md5sum *.db
1de1260b3f38349a8633d33acd4e4de7  cert9.db
*9fbbae3e2d65d29f51e357a2dc4650a2  key4.db*

Can we generate them with a known standard time then? Is there some way
to specify that or can we add one?


Unfortunately there is no such option for certutil when create new 
databases.


For Fedora, it provides pre-created blank database files. If provide 
blank db files is ok, I'll verify it for all archs.


Regards,
Kai




Cheers,

Richard



--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 05/10] nss: move create blank certificates to pkg_postinst

[Kang Kai]

On 2018年10月02日 23:53, richard.pur...@linuxfoundation.org wrote:

On Tue, 2018-10-02 at 23:29 +0800, Kang Kai wrote:

On 2018年09月29日 20:44, Richard Purdie wrote:

On Sat, 2018-09-29 at 13:43 +0800, kai.k...@windriver.com wrote:

From: Kai Kang 

There is a multilib install file conflict of nss:

file /etc/pki/nssdb/key4.db conflicts between attempted
installs of
lib32-nss-3.38-r0.corei7_32 and nss-3.38-r0.corei7_64

Move the creation of blank certificates to pkg_postinst. And
check if
certificates exist already, don't re-create them.

Signed-off-by: Kai Kang 
---
  meta/recipes-support/nss/nss_3.38.bb | 32 +-

--
  1 file changed, 20 insertions(+), 12 deletions(-)

This does raise a question - why aren't the generated files the
same?
Is there a determinism problem here? This sounds like the image
would
change with each build and couldn't be reproduced so we have a
bigger
problem?
  
It calls certutil to create blank certificates:


certutil -N -d sql:${D}${sysconfdir}/pki/nssdb/ -f ./empty_password

It should be current time related that create blank certificates in
current directory, the key4.db files are different:

kkang@msp-lpggp1:~/buildarea/bar-build
$ touch empty
kkang@msp-lpggp1:~/buildarea/bar-build
$ ./tmp/sysroots-components/x86_64/nss-native/usr/bin/certutil -N -d
sql:./ -f ./empty
password file contains no data
kkang@msp-lpggp1:~/buildarea/bar-build
$ md5sum *.db
1de1260b3f38349a8633d33acd4e4de7  cert9.db
*7fea1d4dbc99db3ba1b72e30428eb5dc  key4.db*
kkang@msp-lpggp1:~/buildarea/bar-build
$ rm *.db
kkang@msp-lpggp1:~/buildarea/bar-build
$ ./tmp/sysroots-components/x86_64/nss-native/usr/bin/certutil -N -d
sql:./ -f ./empty
password file contains no data
kkang@msp-lpggp1:~/buildarea/bar-build
$ md5sum *.db
1de1260b3f38349a8633d33acd4e4de7  cert9.db
*9fbbae3e2d65d29f51e357a2dc4650a2  key4.db*

Can we generate them with a known standard time then? Is there some way
to specify that or can we add one?


The md5sum of cert9.db are same but key4.db are different, so I have 
been checking the source code of nss but no conclusion yet.


Regards,
Kai



Cheers,

Richard



--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 05/10] nss: move create blank certificates to pkg_postinst

[Kang Kai]

On 2018年09月29日 20:44, Richard Purdie wrote:

On Sat, 2018-09-29 at 13:43 +0800, kai.k...@windriver.com wrote:

From: Kai Kang 

There is a multilib install file conflict of nss:

file /etc/pki/nssdb/key4.db conflicts between attempted installs of
lib32-nss-3.38-r0.corei7_32 and nss-3.38-r0.corei7_64

Move the creation of blank certificates to pkg_postinst. And check if
certificates exist already, don't re-create them.

Signed-off-by: Kai Kang 
---
  meta/recipes-support/nss/nss_3.38.bb | 32 +-
--
  1 file changed, 20 insertions(+), 12 deletions(-)

This does raise a question - why aren't the generated files the same?
Is there a determinism problem here? This sounds like the image would
change with each build and couldn't be reproduced so we have a bigger
problem?


It calls certutil to create blank certificates:

certutil -N -d sql:${D}${sysconfdir}/pki/nssdb/ -f ./empty_password

It should be current time related that create blank certificates in 
current directory, the key4.db files are different:


kkang@msp-lpggp1:~/buildarea/bar-build
$ touch empty
kkang@msp-lpggp1:~/buildarea/bar-build
$ ./tmp/sysroots-components/x86_64/nss-native/usr/bin/certutil -N -d 
sql:./ -f ./empty

password file contains no data
kkang@msp-lpggp1:~/buildarea/bar-build
$ md5sum *.db
1de1260b3f38349a8633d33acd4e4de7  cert9.db
*7fea1d4dbc99db3ba1b72e30428eb5dc  key4.db*
kkang@msp-lpggp1:~/buildarea/bar-build
$ rm *.db
kkang@msp-lpggp1:~/buildarea/bar-build
$ ./tmp/sysroots-components/x86_64/nss-native/usr/bin/certutil -N -d 
sql:./ -f ./empty

password file contains no data
kkang@msp-lpggp1:~/buildarea/bar-build
$ md5sum *.db
1de1260b3f38349a8633d33acd4e4de7  cert9.db
*9fbbae3e2d65d29f51e357a2dc4650a2  key4.db*


Regards,
Kai




Cheers,

Richard



--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 10/10] vala: update vapigen-wrapper

[Kang Kai]

On 2018年09月29日 20:33, Richard Purdie wrote:

On Sat, 2018-09-29 at 13:43 +0800, kai.k...@windriver.com wrote:

From: Kai Kang 

gobject-introspection has changed installation paths of .gir files.

gobject-introspection has not changed. *We* have changed it.

This is basically why I really don't want to start messing with
upstream code like this as I'm guessing this will be the first of many
such problems.

Has anyone discussed the gobject-introspection gir path issue with
upstream? If data is arch specific, it shouldn't be going into datadir
but into libexec iirc. I'd like to understand the upstream response
before we start hacking around this in OE in a way which will generate
a ton of patches and incompatibility.


I have sent the patch to 
https://gitlab.gnome.org/GNOME/gobject-introspection/merge_requests/63. 
It seems

no objection but can't build pass for VS2017, so not merged yet.

--Kai




Cheers,

Richard




--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 08/10] os-release: fix install file conflict for multilib

[Kang Kai]

On 2018年09月29日 20:37, Richard Purdie wrote:

On Sat, 2018-09-29 at 13:43 +0800, kai.k...@windriver.com wrote:

From: Kai Kang 

It fails to create image when install os-release and lib32-os-release
both:


file /etc/os-release conflicts between attempted installs of
os-release-1.0-r0.core2_64 and lib32-os-release-1.0-r0.x86

The /etc/os-release is a symlink link to ${libdir}/os-release.
Actually
the content of files are identical and make /etc/os-release to be
hard
link could fix the issue. But according to os-release (5), symlink
link
is necessary for initrd environment such as dracut.

Signed-off-by: Kai Kang 
---
  meta/recipes-core/os-release/os-release.bb | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/os-release/os-release.bb
b/meta/recipes-core/os-release/os-release.bb
index bf4f815a10..4d5487c06d 100644
--- a/meta/recipes-core/os-release/os-release.bb
+++ b/meta/recipes-core/os-release/os-release.bb
@@ -1,10 +1,12 @@
-inherit allarch
-
  SUMMARY = "Operating system identification"
  DESCRIPTION = "The /usr/lib/os-release file contains operating
system identification data."
  LICENSE = "MIT"
  INHIBIT_DEFAULT_DEPS = "1"
  
+inherit allarch multilib_script

+
+MULTILIB_SCRIPTS = "${PN}:${sysconfdir}/os-release"

This is exactly the kind of thing I did not want to see
MUTLILIB_SCRIPTS used for. Its now being proposed everywhere you have
an issue with conflicting files without consideration about what
actually makes sense.

What might make more sense here is only to build os-release for the
main namespace and not any of the multilibs. It could RPROVIDE if
necessary.


Robert's patch about "multilib: avoid expanding grub and grub-efi to 
multilib' has been merged to master-next,

I'll do it base on his patch.

Regards,
Kai



Cheers,

Richard




--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 06/10] libcheck: avoid multilib install file conflict

[Kang Kai]

On 2018年09月29日 20:42, Richard Purdie wrote:

On Sat, 2018-09-29 at 13:43 +0800, kai.k...@windriver.com wrote:

From: Kai Kang 

It has one line different which is a comment in check_stdint.h
between libcheck multilib packages. And then causes install file
conflict when install libcheck and lib32-libcheck at same time.

Remove the comment line from check_stdint.h to fix the issue.

Signed-off-by: Kai Kang 
---
  meta/recipes-support/libcheck/libcheck_0.12.0.bb | 5 +
  1 file changed, 5 insertions(+)

diff --git a/meta/recipes-support/libcheck/libcheck_0.12.0.bb
b/meta/recipes-support/libcheck/libcheck_0.12.0.bb
index e646d43968..9969e27054 100644
--- a/meta/recipes-support/libcheck/libcheck_0.12.0.bb
+++ b/meta/recipes-support/libcheck/libcheck_0.12.0.bb
@@ -16,6 +16,11 @@ inherit autotools pkgconfig texinfo
  
  CACHED_CONFIGUREVARS += "ac_cv_path_AWK_PATH=${bindir}/gawk"
  
+do_install_append_class-target () {

+# remove the only one line comment which causes multilib install
file conflict
+sed -i '/^\/\*/ d' ${D}${includedir}/check_stdint.h
+}

Please do this with a patch, not a sed expression.

The sed expressions are a maintenance nightmare since we don't know
if/when the header may change, or if/when this expression stops
working.


Got it. Thanks.

--Kai



Cheers,

Richard




--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 03/10] man-db: fix multilib install file conflict

[Kang Kai]

On 2018年09月29日 20:44, Richard Purdie wrote:

On Sat, 2018-09-29 at 13:43 +0800, kai.k...@windriver.com wrote:

From: Kai Kang 

The first line of config file man_db.conf is the package name. It
causes
multilib install file conflict. So remove the first line.

Signed-off-by: Kai Kang 
---
  meta/recipes-extended/man-db/man-db_2.8.3.bb | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/meta/recipes-extended/man-db/man-db_2.8.3.bb
b/meta/recipes-extended/man-db/man-db_2.8.3.bb
index 97e5a3d6fb..da6d291011 100644
--- a/meta/recipes-extended/man-db/man-db_2.8.3.bb
+++ b/meta/recipes-extended/man-db/man-db_2.8.3.bb
@@ -26,6 +26,9 @@ do_install() {
install -d ${D}/etc/default/volatiles
install -m 0644 ${WORKDIR}/99_mandb
${D}/etc/default/volatiles
fi
+
+# the 1st line of man_db.conf is package name which causes
multilib install file conflict
+sed -i '1d' ${D}${sysconfdir}/man_db.conf
  }

Please do this with a patch, not a sed expression.

The sed expressions are a maintenance nightmare since we don't know
if/when the config file may change, or if/when this expression stops
working.


Got it.

--Kai



Cheers,

Richard




--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 0/2] Fix install file conflicts of gobject-introspection when multilib is enabled

[Kang Kai]

On 2018年09月28日 16:27, Alexander Kanavin wrote:

The original patches never made it to the list, can you resend please?
(just confirmed with oe-core archive page)


It seems something wrong with git send-email on my new build server. 
Many thanks for the reminder.


--Kai



Alex


On Thu, 27 Sep 2018 at 10:28, Kang Kai  wrote:

On 2018年09月17日 17:43, Kai Kang wrote:

Some of .gir files are target related, so install .gir files to ${libdir}
rather than ${datadir} to fix install file conflicts when mutlilib is enabled.

The following changes since commit b78597a4e038ed64b379f11257002e5a5f24886f:

xf86-video-fbdev: update to 0.5.0 (2018-09-17 08:41:45 +0100)

are available in the Git repository at:

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

Kai Kang (2):
gobject-introspection: fix multilib install file conflicts
vala: update vapigen-wrapper

Ping...


   meta/recipes-devtools/vala/vala.inc   |  4 +-
   ...nfigure.ac-make-GIR_DIR-configurable.patch | 65 +++
   .../gobject-introspection_1.58.0.bb   | 10 ++-
   3 files changed, 75 insertions(+), 4 deletions(-)
   create mode 100644 
meta/recipes-gnome/gobject-introspection/gobject-introspection/0001-configure.ac-make-GIR_DIR-configurable.patch


--
Regards,
Neil | Kai Kang

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



--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 0/2] Fix install file conflicts of gobject-introspection when multilib is enabled

[Kang Kai]

On 2018年09月17日 17:43, Kai Kang wrote:

Some of .gir files are target related, so install .gir files to ${libdir}
rather than ${datadir} to fix install file conflicts when mutlilib is enabled.

The following changes since commit b78597a4e038ed64b379f11257002e5a5f24886f:

   xf86-video-fbdev: update to 0.5.0 (2018-09-17 08:41:45 +0100)

are available in the Git repository at:

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

Kai Kang (2):
   gobject-introspection: fix multilib install file conflicts
   vala: update vapigen-wrapper


Ping...



  meta/recipes-devtools/vala/vala.inc   |  4 +-
  ...nfigure.ac-make-GIR_DIR-configurable.patch | 65 +++
  .../gobject-introspection_1.58.0.bb   | 10 ++-
  3 files changed, 75 insertions(+), 4 deletions(-)
  create mode 100644 
meta/recipes-gnome/gobject-introspection/gobject-introspection/0001-configure.ac-make-GIR_DIR-configurable.patch



--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 1/7] allarch: only enable allarch when multilib is not used

[Kang Kai]

On 2018年09月14日 22:12, Martin Jansa wrote:

On Fri, Sep 14, 2018 at 01:25:12PM +0200, Martin Jansa wrote:

On Thu, Sep 13, 2018 at 10:10:46PM +0200, Martin Jansa wrote:

On Thu, Sep 13, 2018 at 08:20:07PM +0200, Martin Jansa wrote:

On Thu, Sep 06, 2018 at 11:52:24PM +0800, kai.k...@windriver.com wrote:

From: Kai Kang 

Some allarch packages rdepends non-allarch packages. when multilib is
used, it doesn't expand the dependency chain correctly, e.g.

core-image-sato -> ca-certificates(allarch) -> openssl

we expect dependency chain for lib32-core-image-sato:

lib32-core-image-sato -> ca-certificates(allarch) -> lib32-openssl

it should install lib32-openssl for ca-certificates but openssl is still
wrongly required.

Only enable allarch when multilib is not used to fix the issue.

signed-off-by: kai kang 
---
  meta/classes/allarch.bbclass | 12 +++-
  meta/classes/icecc.bbclass   |  2 +-
  meta/classes/multilib.bbclass|  3 ++-
  meta/classes/multilib_global.bbclass |  4 +---
  meta/classes/package.bbclass |  9 ++---
  5 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
index 1eebe0bf2e..45f62a5939 100644
--- a/meta/classes/allarch.bbclass
+++ b/meta/classes/allarch.bbclass
@@ -2,7 +2,17 @@
  # This class is used for architecture independent recipes/data files (usually 
scripts)
  #
  
-PACKAGE_ARCH = "all"

+python allarch_package_arch_handler () {
+if bb.data.inherits_class("nativesdk", d) or 
bb.data.inherits_class("crosssdk", d):
+return
+
+variants = d.getVar("MULTILIB_VARIANTS")
+if not variants:
+d.setVar("PACKAGE_ARCH", "all" )
+}
+
+addhandler allarch_package_arch_handler
+allarch_package_arch_handler[eventmask] = "bb.event.RecipePreFinalise"

Maybe I'm overlooking something, but doesn't this overwrite whatever
PACKAGE_ARCH as set before this?

I have some recipes where the PACKAGE_ARCH is set to MACHINE_ARCH through
another bbclass, but then overwritten with "all" by 
allarch_package_arch_handler:

# $PACKAGE_ARCH [5 operations]
#   set oe-core/meta/conf/bitbake.conf:150
# [_defaultval] "${TUNE_PKGARCH}"
#   set meta-lg-webos/meta-webos/conf/distro/include/webos.inc:241
# "${MACHINE_ARCH}"
#   set oe-core/meta/conf/documentation.conf:304
# [doc] "The architecture of the resulting package or packages."
#   set meta-lg-webos/meta-webos/classes/webos_machine_impl_dep.bbclass:11
# "${MACHINE_ARCH}"
#   set allarch.bbclass:12 [allarch_package_arch_handler]
# "all"
# pre-expansion value:
#   "all"
PACKAGE_ARCH="all"

But surprisingly if I do the same with e.g. packagegroup-core-boot in oe-core I 
get:

# $PACKAGE_ARCH [4 operations]
#   set /OE/build/oe-core/openembedded-core/meta/conf/bitbake.conf:150
# [_defaultval] "${TUNE_PKGARCH}"
#   set /OE/build/oe-core/openembedded-core/meta/conf/documentation.conf:304
# [doc] "The architecture of the resulting package or packages."
#   set 
/OE/build/oe-core/openembedded-core/meta/recipes-core/packagegroups/packagegroup-core-boot.bb:9
# "${MACHINE_ARCH}"
#   set? 
/OE/build/oe-core/openembedded-core/meta/classes/packagegroup.bbclass:12
# "all"
# pre-expansion value:
#   "${MACHINE_ARCH}"
PACKAGE_ARCH="qemux86_64"

Why isn't allarch_package_arch_handler executed in the 2nd case?

Now I see the difference, I was still living in the days when
"disabling" allarch was possible just by setting PACKAGE_ARCH before
inheritting allarch, but now I see that packagegroups do conditional
inherit as well since:
http://git.openembedded.org/openembedded-core/commit/?id=9c826962ec8fa45c2b035427442b90a41517144e
http://git.openembedded.org/openembedded-core/commit/?id=2c9b1d304daade7b0907320aeb9c522e7ab9dcab
so I'll modify currently failing recipes to do the same and stop
inheritting allarch when PACKAGE_ARCH is set to something else.

 From public layers I've found with test-signatures script only
fbset-nodes recipe in meta-oe which was setting PACKAGE_ARCH after
allarch inherit, allarch removal sent here:
http://lists.openembedded.org/pipermail/openembedded-devel/2018-September/120560.html

target-sdk-provides-dummy seems to be affected as well:
  === Comparing signatures for task do_populate_sysroot.sigdata between qemux86 
and qemux86copy ===
ERROR: lib32-target-sdk-provides-dummy different signature for task 
do_populate_sysroot.sigdata between qemux86 and qemux86copy
basehash changed from b0a44b2c7003b6b4aa3a023d9cb9fe82 to 
3a59fa25ddb6a95aff079d477ebf3457
Variable SSTATE_MANMACH value changed from 'qemux86' to 'qemux86copy'

ERROR: target-sdk-provides-dummy different signature for task 
do_populate_sysroot.sigdata between qemux86 and qemux86copy
basehash changed from 9e44f1deb3d15886ee96db1a3332764c to 
6b417d08a5113c9b06d13b3681f5ab4f
Variable SSTATE_MANMACH value changed from 'qemux86' to 'qemux86copy'


It's using:
inherit allarch

python() {
 # Put the package somewhere separate to 

Re: [OE-core] [PATCH 3/5] update_font_cache: update script for multilib

[Kang Kai]

On 2018年09月10日 06:58, Martin Jansa wrote:

And it fails in regular image build as well, because of qemu segfault:


What do you mean regulare image here? core-image-minimal, -sato or fails 
with all of them? I can't reproduce the failure, would you like to paste 
you local.conf here?


Regards,
Kai



NOTE: > Executing update_gio_module_cache intercept ...
NOTE: Exit code 139. Output:
+ [ True = False ]
+ qemu-i386 -r 3.2.0 -E 
LD_LIBRARY_PATH=WORKDIR/rootfs/usr/lib:WORKDIR/rootfs/lib -L 
WORKDIR/rootfs WORKDIR/rootfs/usr/libexec/gio-querymodules 
WORKDIR/rootfs/usr/lib/gio/modules/

qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

ERROR: The postinstall intercept hook 'update_gio_module_cache' 
failed, details in WORKDIR/temp/log.do_rootfs



On Sun, Sep 9, 2018 at 10:39 PM Martin Jansa <mailto:martin.ja...@gmail.com>> wrote:


I'm still able to reproduce the issue in my builds, I'll find out
what's different here.

It fails because of missing nativesdk-qemuwrapper here:

NOTE: Running intercept scripts:
NOTE: > Executing update_gio_module_cache-nativesdk intercept ...
NOTE: Exit code 127. Output:

SDK/intercept_scripts-b9d7b319af0f1ca17a1619924c1df1e231252a4e81ebd84cfd6b676ebe12fb99/update_gio_module_cache-nativesdk:
10:

SDK/intercept_scripts-b9d7b319af0f1ca17a1619924c1df1e231252a4e81ebd84cfd6b676ebe12fb99/update_gio_module_cache-nativesdk:
nativesdk-qemuwrapper: not found

WARNING: The postinstall intercept hook
'update_gio_module_cache-nativesdk' failed, details in
SDK/temp/log.do_populate_sdk


On Thu, Sep 6, 2018 at 5:28 PM Kang Kai mailto:kai.k...@windriver.com>> wrote:

On 2018年09月04日 18:02, Kang Kai wrote:

On 2018年09月04日 17:44, Martin Jansa wrote:

Hi Kai,

do you have similar fix for update_gio_module_cache
intercept? It seems to fail similarly with multilib enabled.


The fix is from script update_gio_module_cache, so I thought
it works and didn't meet the failure. I'll check it.

Hi Martin,

It has been done by

http://git.openembedded.org/openembedded-core/commit/?id=1f53140528d79c38d4f3a82cd0a03bd0ddc87275
Add lib23-gconf to image which inherits gio-module-cache, then
build image successfully.

Regards,
Kai




Thanks,
Kai



Regards,

On Sat, Aug 25, 2018 at 7:14 PM Kai Kang
mailto:kai.k...@windriver.com>> wrote:

Packages which inherit fontcache.bbclass call
postinstall script
update_font_cache. And in update_font_cache, it calls
${bindir}/fc-cache
by qemuwrapper. When multilib is enabled, both packages
foo and lib32-foo
will call ${bindir}/fc-cache and one of them will fail
to run obviously.

Duplicate install file fc-cache to ${libexecdir} with
${MLPREFIX} and
call proper fc-cache in update_font_cache.

Signed-off-by: Kai Kang mailto:kai.k...@windriver.com>>
---
 meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
<http://fontconfig_2.12.6.bb> | 8 +++-
 scripts/postinst-intercepts/update_font_cache        | 2 +-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git
a/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
<http://fontconfig_2.12.6.bb>
b/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
<http://fontconfig_2.12.6.bb>
index d4cbce80b45..db36c867741 100644
---
a/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
<http://fontconfig_2.12.6.bb>
+++
b/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
<http://fontconfig_2.12.6.bb>
@@ -35,9 +35,15 @@ do_configure_prepend() {
     rm -f ${S}/src/fcobjshash.h ${S}/src/fcobjshash.gperf
 }

+do_install_append_class-target() {
+    # duplicate fc-cache for postinstall script
+    mkdir -p ${D}${libexecdir}
+    cp ${D}${bindir}/fc-cache
${D}${libexecdir}/${MLPREFIX}fc-cache
+}
+
 PACKAGES =+ "fontconfig-utils"
 FILES_${PN} =+ "${datadir}/xml/*"
-FILES_fontconfig-utils = "${bindir}/*"
+FILES_fontconfig-utils = "${bindir}/* ${libexecdir}/*"

 # Work around past breakage in debian.bbclass
 RPROVIDES_fontconfig-utils = "libfontconfig-utils"
diff --git
a/scripts/postinst-intercepts/update_font_cache
b/scripts/postinst-intercepts/update_font_cache
index 20e9048adfc..e0ec471964c 100

Re: [OE-core] [PATCH 6/7] multilib: fix install file conflicts

[Kang Kai]

On 2018年09月07日 06:31, richard.pur...@linuxfoundation.org wrote:

On Thu, 2018-09-06 at 23:52 +0800, kai.k...@windriver.com wrote:

diff --git a/meta/recipes-core/udev/eudev_3.2.5.bb b/meta/recipes-
core/udev/eudev_3.2.5.bb
index 75617c8d4e..75130f03ef 100644
--- a/meta/recipes-core/udev/eudev_3.2.5.bb
+++ b/meta/recipes-core/udev/eudev_3.2.5.bb
@@ -23,7 +23,9 @@ SRC_URI = "http://dev.gentoo.org/~blueness/${BPN}/$
{BP}.tar.gz \
  SRC_URI[md5sum] = "6ca08c0e14380f87df8e8aceac123671"
  SRC_URI[sha256sum] =
"49c2d04105cad2526302627e040fa24b1916a9a3e059539bc8bb919b973890af"
  
-inherit autotools update-rc.d qemu pkgconfig distro_features_check

+inherit autotools update-rc.d qemu pkgconfig distro_features_check
multilib_script
+
+MULTILIB_SCRIPTS = "${PN}-dev:${datadir}/pkgconfig/udev.pc"
  
  CONFLICT_DISTRO_FEATURES = "systemd"
  
@@ -65,7 +67,7 @@ PACKAGES =+ "eudev-hwdb"
  
  
  FILES_${PN} += "${libexecdir} ${base_libdir}/udev ${bindir}/udevadm"

-FILES_${PN}-dev = "${datadir}/pkgconfig/udev.pc \
+FILES_${PN}-dev = "${datadir}/pkgconfig/udev.pc* \
 ${includedir}/libudev.h ${libdir}/libudev.so \
 ${includedir}/udev.h ${libdir}/libudev.la \
 ${libdir}/libudev.a
${libdir}/pkgconfig/libudev.pc"

I already commented on this, the file should be installed into libdir
if its arch specific. I suspect libudev.pc is, udev.pc is not and
udev.pc needs to stop referencing libdir.


Sorry, I thought no good way to deal ${libdir} in .pc files. I'll fix it.

Regards,
Kai


  


Regardless, we're not using MULTILIB_SCRIPTS for .pc files.

Cheers,

Richard



--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 3/5] update_font_cache: update script for multilib

[Kang Kai]

On 2018年09月04日 18:02, Kang Kai wrote:

On 2018年09月04日 17:44, Martin Jansa wrote:

Hi Kai,

do you have similar fix for update_gio_module_cache intercept? It 
seems to fail similarly with multilib enabled.


The fix is from script update_gio_module_cache, so I thought it works 
and didn't meet the failure. I'll check it.

Hi Martin,

It has been done by 
http://git.openembedded.org/openembedded-core/commit/?id=1f53140528d79c38d4f3a82cd0a03bd0ddc87275
Add lib23-gconf to image which inherits gio-module-cache, then build 
image successfully.


Regards,
Kai




Thanks,
Kai



Regards,

On Sat, Aug 25, 2018 at 7:14 PM Kai Kang <mailto:kai.k...@windriver.com>> wrote:


Packages which inherit fontcache.bbclass call postinstall script
update_font_cache. And in update_font_cache, it calls
${bindir}/fc-cache
by qemuwrapper. When multilib is enabled, both packages foo and
lib32-foo
will call ${bindir}/fc-cache and one of them will fail to run
obviously.

Duplicate install file fc-cache to ${libexecdir} with ${MLPREFIX} and
call proper fc-cache in update_font_cache.

Signed-off-by: Kai Kang mailto:kai.k...@windriver.com>>
---
 meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
<http://fontconfig_2.12.6.bb> | 8 +++-
 scripts/postinst-intercepts/update_font_cache         | 2 +-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git
a/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
<http://fontconfig_2.12.6.bb>
b/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
<http://fontconfig_2.12.6.bb>
index d4cbce80b45..db36c867741 100644
--- a/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
<http://fontconfig_2.12.6.bb>
+++ b/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
<http://fontconfig_2.12.6.bb>
@@ -35,9 +35,15 @@ do_configure_prepend() {
     rm -f ${S}/src/fcobjshash.h ${S}/src/fcobjshash.gperf
 }

+do_install_append_class-target() {
+    # duplicate fc-cache for postinstall script
+    mkdir -p ${D}${libexecdir}
+    cp ${D}${bindir}/fc-cache ${D}${libexecdir}/${MLPREFIX}fc-cache
+}
+
 PACKAGES =+ "fontconfig-utils"
 FILES_${PN} =+ "${datadir}/xml/*"
-FILES_fontconfig-utils = "${bindir}/*"
+FILES_fontconfig-utils = "${bindir}/* ${libexecdir}/*"

 # Work around past breakage in debian.bbclass
 RPROVIDES_fontconfig-utils = "libfontconfig-utils"
diff --git a/scripts/postinst-intercepts/update_font_cache
b/scripts/postinst-intercepts/update_font_cache
index 20e9048adfc..e0ec471964c 100644
--- a/scripts/postinst-intercepts/update_font_cache
+++ b/scripts/postinst-intercepts/update_font_cache
@@ -2,5 +2,5 @@

 set -e

-PSEUDO_UNLOAD=1 ${binprefix}qemuwrapper -L $D -E
${fontconfigcacheenv} $D${bindir}/fc-cache --sysroot=$D
--system-only ${fontconfigcacheparams}
+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}
-- 
2.11.0


-- 
___

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



--
Regards,
Neil | Kai Kang



--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 1/6] allarch: disable allarch when multilib is used

[Kang Kai]

On 2018年09月04日 16:36, richard.pur...@linuxfoundation.org wrote:

Hi,

I think this is close and it passes the tests on the autobuilder
however I did spot a couple of potential issues after thinking about
this for a bit.

On Sun, 2018-08-26 at 06:06 -0700, Kai Kang wrote:

Some allarch packages rdepends non-allarch packages. When multilib is
used, it doesn't expand the dependency chain correctly, e.g.

core-image-sato -> ca-certificates(allarch) -> openssl

we expect dependency chain for lib32-core-image-sato:

lib32-core-image-sato -> ca-certificates(allarch) -> lib32-openssl

it should install lib32-openssl for ca-certificates but openssl is
still wrongly required.

Copy allarch.bbclass to allarch-enabled.bbclass and only inherit
allarch-enabled.bbclass when multilib is not used.

Signed-off-by: Kai Kang 
---
  meta/classes/allarch-enabled.bbclass | 52 
  meta/classes/allarch.bbclass | 51 ++-
  meta/classes/icecc.bbclass   |  2 +-
  meta/classes/multilib.bbclass|  2 +-
  meta/classes/multilib_global.bbclass |  2 +-
  meta/classes/package.bbclass |  6 ++---
  6 files changed, 60 insertions(+), 55 deletions(-)
  create mode 100644 meta/classes/allarch-enabled.bbclass


diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
index 1eebe0bf2e7..0eca076df0b 100644
--- a/meta/classes/allarch.bbclass
+++ b/meta/classes/allarch.bbclass
@@ -1,52 +1,5 @@
  #
-# This class is used for architecture independent recipes/data files (usually 
scripts)
+# This class enables allarch only when multilib is not used.
  #
  
-PACKAGE_ARCH = "all"

-
-python () {
-# Allow this class to be included but overridden - only set
-# the values if we're still "all" package arch.
-if d.getVar("PACKAGE_ARCH") == "all":
-# No need for virtual/libc or a cross compiler
-d.setVar("INHIBIT_DEFAULT_DEPS","1")
-
-# Set these to a common set of values, we shouldn't be using them 
other that for WORKDIR directory
-# naming anyway
-d.setVar("baselib", "lib")
-d.setVar("TARGET_ARCH", "allarch")
-d.setVar("TARGET_OS", "linux")
-d.setVar("TARGET_CC_ARCH", "none")
-d.setVar("TARGET_LD_ARCH", "none")
-d.setVar("TARGET_AS_ARCH", "none")
-d.setVar("TARGET_FPU", "")
-d.setVar("TARGET_PREFIX", "")
-# Expand PACKAGE_EXTRA_ARCHS since the staging code needs this
-# (this removes any dependencies from the hash perspective)
-d.setVar("PACKAGE_EXTRA_ARCHS", d.getVar("PACKAGE_EXTRA_ARCHS"))
-d.setVar("SDK_ARCH", "none")
-d.setVar("SDK_CC_ARCH", "none")
-d.setVar("TARGET_CPPFLAGS", "none")
-d.setVar("TARGET_CFLAGS", "none")
-d.setVar("TARGET_CXXFLAGS", "none")
-d.setVar("TARGET_LDFLAGS", "none")
-d.setVar("POPULATESYSROOTDEPS", "")
-
-# Avoid this being unnecessarily different due to nuances of
-# the target machine that aren't important for "all" arch
-# packages.
-d.setVar("LDFLAGS", "")
-
-# No need to do shared library processing or debug symbol handling
-d.setVar("EXCLUDE_FROM_SHLIBS", "1")
-d.setVar("INHIBIT_PACKAGE_DEBUG_SPLIT", "1")
-d.setVar("INHIBIT_PACKAGE_STRIP", "1")
-
-# These multilib values shouldn't change allarch packages so exclude 
them
-d.appendVarFlag("emit_pkgdata", "vardepsexclude", " MULTILIB_VARIANTS")
-d.appendVarFlag("write_specfile", "vardepsexclude", " MULTILIBS")
-d.appendVarFlag("do_package", "vardepsexclude", " package_do_shlibs")
-elif bb.data.inherits_class('packagegroup', d) and not 
bb.data.inherits_class('nativesdk', d):
-bb.error("Please ensure recipe %s sets PACKAGE_ARCH before inherit packagegroup" 
% d.getVar("FILE"))
-}
-
+inherit ${@oe.utils.ifelse(d.getVar('MULTILIB_VARIANTS'), '', 
'allarch-enabled')}

Firstly, whilst I do understand why you've made this change like this,
I don't really like one line classes which clutter up the classes
directory. Using inherit like this does force the expansion of the
variable early and is very prone to "race" conditions. The above is
safe but see below.

FWIW the original code tried to switch off the value of the
PACKAGE_ARCH variable. If we change the way we enable/disable the code,
we should consider whether we can consistently use one mechanism for
both.

Secondly, does this change affect the behaviour of nativesdk?

I think this will disable allarch for nativesdk in any multilib build
and we don't want to do that, we only have a problem with target
multilib allarch.


I searched oe-core for which inherits allarch and bbextend nativesdk by:

$ rgrep 'inherit.*allarch' -l meta | xargs grep -l 
'BBCLASSEXTEND.*nativesdk'

meta/recipes-devtools/autoconf-archive/autoconf-archive_2018.03.13.bb
meta/recipes-support/ca-certificates/ca-certificates_20180409.bb

Re: [OE-core] [PATCH 3/5] update_font_cache: update script for multilib

[Kang Kai]

On 2018年09月04日 17:44, Martin Jansa wrote:

Hi Kai,

do you have similar fix for update_gio_module_cache intercept? It 
seems to fail similarly with multilib enabled.


The fix is from script update_gio_module_cache, so I thought it works 
and didn't meet the failure. I'll check it.


Thanks,
Kai



Regards,

On Sat, Aug 25, 2018 at 7:14 PM Kai Kang > wrote:


Packages which inherit fontcache.bbclass call postinstall script
update_font_cache. And in update_font_cache, it calls
${bindir}/fc-cache
by qemuwrapper. When multilib is enabled, both packages foo and
lib32-foo
will call ${bindir}/fc-cache and one of them will fail to run
obviously.

Duplicate install file fc-cache to ${libexecdir} with ${MLPREFIX} and
call proper fc-cache in update_font_cache.

Signed-off-by: Kai Kang mailto:kai.k...@windriver.com>>
---
 meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb
 | 8 +++-
 scripts/postinst-intercepts/update_font_cache         | 2 +-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb

b/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb

index d4cbce80b45..db36c867741 100644
--- a/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb

+++ b/meta/recipes-graphics/fontconfig/fontconfig_2.12.6.bb

@@ -35,9 +35,15 @@ do_configure_prepend() {
     rm -f ${S}/src/fcobjshash.h ${S}/src/fcobjshash.gperf
 }

+do_install_append_class-target() {
+    # duplicate fc-cache for postinstall script
+    mkdir -p ${D}${libexecdir}
+    cp ${D}${bindir}/fc-cache ${D}${libexecdir}/${MLPREFIX}fc-cache
+}
+
 PACKAGES =+ "fontconfig-utils"
 FILES_${PN} =+ "${datadir}/xml/*"
-FILES_fontconfig-utils = "${bindir}/*"
+FILES_fontconfig-utils = "${bindir}/* ${libexecdir}/*"

 # Work around past breakage in debian.bbclass
 RPROVIDES_fontconfig-utils = "libfontconfig-utils"
diff --git a/scripts/postinst-intercepts/update_font_cache
b/scripts/postinst-intercepts/update_font_cache
index 20e9048adfc..e0ec471964c 100644
--- a/scripts/postinst-intercepts/update_font_cache
+++ b/scripts/postinst-intercepts/update_font_cache
@@ -2,5 +2,5 @@

 set -e

-PSEUDO_UNLOAD=1 ${binprefix}qemuwrapper -L $D -E
${fontconfigcacheenv} $D${bindir}/fc-cache --sysroot=$D
--system-only ${fontconfigcacheparams}
+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}
-- 
2.11.0


-- 
___

Openembedded-core mailing list
Openembedded-core@lists.openembedded.org

http://lists.openembedded.org/mailman/listinfo/openembedded-core



--
Regards,
Neil | Kai Kang

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

Re: [OE-core] [PATCH 6/6] multilib: fix install file conflicts

[Kang Kai]

On 2018年09月04日 17:16, richard.pur...@linuxfoundation.org wrote:

On Sun, 2018-08-26 at 06:06 -0700, Kai Kang wrote:

Fix install files conflicts between multlib packages:


Error: Transaction check error:
   file /usr/bin/g-ir-annotation-tool conflicts between attempted installs of 
lib32-gobject-introspection-1.56.1-r0.x86 and 
gobject-introspection-1.56.1-r0.core2_64
   file /usr/bin/g-ir-scanner conflicts between attempted installs of 
lib32-gobject-introspection-1.56.1-r0.x86 and 
gobject-introspection-1.56.1-r0.core2_64
   file /usr/bin/cairo-trace conflicts between attempted installs of 
lib32-libcairo-perf-utils-1.14.12-r0.x86 and 
libcairo-perf-utils-1.14.12-r0.core2_64
   file /usr/bin/icu-config conflicts between attempted installs of 
lib32-icu-dev-62.1-r0.x86 and icu-dev-62.1-r0.core2_64
   file /usr/share/gir-1.0/GLib-2.0.gir conflicts between attempted installs of 
gobject-introspection-dev-1.56.1-r0.core2_64 and 
lib32-gobject-introspection-dev-1.56.1-r0.x86
   file /usr/bin/gpgrt-config conflicts between attempted installs of 
lib32-libgpg-error-dev-1.32-r0.x86 and libgpg-error-dev-1.32-r0.core2_64
   file /usr/share/pkgconfig/udev.pc conflicts between attempted installs of 
eudev-dev-3.2.5-r0.core2_64 and lib32-eudev-dev-3.2.5-r0.x86

.pc files installed into /usr/share are architecture
independent. Either it is arch dependent in which case its in the wrong
place, or it needs to be fixed.


For .pc file of eudev, it sets udevdir with prefix ${libdir}

$ diff -u image/usr/share/pkgconfig/udev.pc 
../../../x86-pokymllib32-linux/lib32-eudev/3.2.5-r0/image/usr/share/pkgconfig/udev.pc

--- image/usr/share/pkgconfig/udev.pc   2018-08-31 16:03:35.721580345 +0800
+++ 
../../../x86-pokymllib32-linux/lib32-eudev/3.2.5-r0/image/usr/share/pkgconfig/udev.pc 
2018-09-03 14:20:05.320474868 +0800

@@ -3,4 +3,4 @@
 Version: 220
 prefix=/usr
 exec_prefix=/usr
-udevdir=/lib64/udev
+udevdir=/lib/udev




We are not putting these under control of update-alternatives!

It would be helpful to understand the kinds of differences in some of
these files. gir files in /usr/share/gir-1.0/ should also really be
arch independent...


For the .gir file, it contains some length of types, such as long and 
pointer.


@@ -21251,16 +21251,16 @@
 This is ":" on UNIX machines and ";" under Windows.
   
 
-    
+    
   
 
-    
+    
   
 
-    
+    
   
 
-    
+    
   
 
 


Regards,
Kai



Cheers,

Richard



--
Regards,
Neil | Kai Kang

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