[OE-core] [PATCH] mdam: fix mdmonitor start up failure
From: Changqing Li
1. recently, mdadm has changed to use service file under srcdir,
so remove the one not be used.
2. add -y option to fix below problem
mdadm: No mail address or alert command - not monitoring
Signed-off-by: Changqing Li
---
...ption-y-for-use-syslog-to-recive-event-re.patch | 28 ++
.../recipes-extended/mdadm/files/mdmonitor.service | 20
meta/recipes-extended/mdadm/mdadm_4.1.bb | 3 +--
3 files changed, 29 insertions(+), 22 deletions(-)
create mode 100644
meta/recipes-extended/mdadm/files/0001-mdadm-add-option-y-for-use-syslog-to-recive-event-re.patch
delete mode 100644 meta/recipes-extended/mdadm/files/mdmonitor.service
diff --git
a/meta/recipes-extended/mdadm/files/0001-mdadm-add-option-y-for-use-syslog-to-recive-event-re.patch
b/meta/recipes-extended/mdadm/files/0001-mdadm-add-option-y-for-use-syslog-to-recive-event-re.patch
new file mode 100644
index 000..e00287c
--- /dev/null
+++
b/meta/recipes-extended/mdadm/files/0001-mdadm-add-option-y-for-use-syslog-to-recive-event-re.patch
@@ -0,0 +1,28 @@
+From 5fdc0173cb4fcf8656f0889ad364d2549795607f Mon Sep 17 00:00:00 2001
+From: Changqing Li
+Date: Mon, 1 Jul 2019 11:34:49 +0800
+Subject: [PATCH] mdadm: add option -y for use syslog to recive event report
+
+fix service startup failed when there is
+No mail address or alert command
+
+Upstream-Status: Inappropriate [configuration]
+
+Signed-off-by: Changqing Li
+---
+ systemd/mdmonitor.service | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/systemd/mdmonitor.service b/systemd/mdmonitor.service
+index 46f7b88..3fc4687 100644
+--- a/systemd/mdmonitor.service
b/systemd/mdmonitor.service
+@@ -13,4 +13,4 @@ DefaultDependencies=no
+ Environment= MDADM_MONITOR_ARGS=--scan
+ EnvironmentFile=-/run/sysconfig/mdadm
+ ExecStartPre=-/usr/lib/mdadm/mdadm_env.sh
+-ExecStart=BINDIR/mdadm --monitor $MDADM_MONITOR_ARGS
++ExecStart=BINDIR/mdadm --monitor -y $MDADM_MONITOR_ARGS
+--
+2.7.4
+
diff --git a/meta/recipes-extended/mdadm/files/mdmonitor.service
b/meta/recipes-extended/mdadm/files/mdmonitor.service
deleted file mode 100644
index a81578e..000
--- a/meta/recipes-extended/mdadm/files/mdmonitor.service
+++ /dev/null
@@ -1,20 +0,0 @@
-# This file is part of mdadm.
-#
-# mdadm is free software; you can redistribute it and/or modify it
-# under the terms of the GNU General Public License as published by
-# the Free Software Foundation; either version 2 of the License, or
-# (at your option) any later version.
-
-[Unit]
-Description=Software RAID monitoring and management
-ConditionPathExists=/etc/mdadm.conf
-
-[Service]
-Type=forking
-PIDFile=/var/run/mdadm/mdadm.pid
-EnvironmentFile=-/etc/sysconfig/mdmonitor
-ExecStartPre=mkdir -p /var/run/mdadm
-ExecStart=/sbin/mdadm --monitor -y --scan -f
--pid-file=/var/run/mdadm/mdadm.pid
-
-[Install]
-WantedBy=multi-user.target
diff --git a/meta/recipes-extended/mdadm/mdadm_4.1.bb
b/meta/recipes-extended/mdadm/mdadm_4.1.bb
index 494b81b..766004f 100644
--- a/meta/recipes-extended/mdadm/mdadm_4.1.bb
+++ b/meta/recipes-extended/mdadm/mdadm_4.1.bb
@@ -19,7 +19,7 @@ SRC_URI =
"${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.xz \
file://0001-fix-gcc-8-format-truncation-warning.patch \
file://debian-no-Werror.patch \
file://mdadm.init \
- file://mdmonitor.service \
+
file://0001-mdadm-add-option-y-for-use-syslog-to-recive-event-re.patch \
"
SRC_URI[md5sum] = "51bf3651bd73a06c413a2f964f299598"
SRC_URI[sha256sum] =
"ab7688842908d3583a704d491956f31324c3a5fc9f6a04653cb75d19f1934f4a"
@@ -65,7 +65,6 @@ do_install_append() {
oe_runmake install-systemd DESTDIR=${D}
}
-
do_compile_ptest() {
oe_runmake test
}
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 0/1] image.bbclass: fix systemd_preset_all
Changes in V2:
* Check /lib/systemd/systemd under ${IMAGE_ROOTFS} instead of checking
the existence of systemctl tool in native staging directory.
The following changes since commit bc5f6725af04417dcf5c65981d8b85abee9c61d8:
Revert "pigz: Add debug for autobuilder errors" (2019-06-30 23:33:45 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib ChenQi/image-systemd
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/image-systemd
Chen Qi (1):
image.bbclass: fix systemd_preset_all
meta/classes/image.bbclass | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH V2 1/1] image.bbclass: fix systemd_preset_all
Check the existence of systemd before using systemctl to preset units.
This is because even if 'systemd' is in DISTRO_FEATURES, it's possible
that systemd is not even installed. e.g. container-test-image in
meta-selftest layer.
As systemd DEPENDS on systemd-systemctl-native, the existence of systemd
also ensures the existence of systemd-systemctl-native.
This would fix the following test case when using systemd as the init
manager.
containerimage.ContainerImageTests.test_expected_files
Also remove the IMAGE_EXTRADEPENDS setting, as nothing references this
variable.
Signed-off-by: Chen Qi
---
meta/classes/image.bbclass | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index d2b2fb9..7daa97e 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -666,10 +666,11 @@ reproducible_final_image_task () {
}
systemd_preset_all () {
-systemctl --root="${IMAGE_ROOTFS}" --preset-mode=enable-only preset-all
+if [ -e ${IMAGE_ROOTFS}${root_prefix}/lib/systemd/systemd ]; then
+ systemctl --root="${IMAGE_ROOTFS}" --preset-mode=enable-only preset-all
+fi
}
-IMAGE_EXTRADEPENDS += "${@ 'systemd-systemctl-native' if
bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d) and not
bb.utils.contains('IMAGE_FEATURES', 'stateless-rootfs', True, False, d) else
''}"
IMAGE_PREPROCESS_COMMAND_append = " ${@ 'systemd_preset_all;' if
bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d) and not
bb.utils.contains('IMAGE_FEATURES', 'stateless-rootfs', True, False, d) else
''} reproducible_final_image_task; "
CVE_PRODUCT = ""
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [thud][PATCH] uboot-sign.bbclass: Remove tab indentations in python code
From: Robert Yang
Use 4 spaces to replace a tab.
Signed-off-by: Robert Yang
Signed-off-by: Richard Purdie
---
meta/classes/uboot-sign.bbclass | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/meta/classes/uboot-sign.bbclass b/meta/classes/uboot-sign.bbclass
index 8ee904e..afaf46f 100644
--- a/meta/classes/uboot-sign.bbclass
+++ b/meta/classes/uboot-sign.bbclass
@@ -80,16 +80,16 @@ do_concat_dtb () {
}
python () {
- uboot_pn = d.getVar('PREFERRED_PROVIDER_u-boot') or 'u-boot'
- if d.getVar('UBOOT_SIGN_ENABLE') == '1' and d.getVar('PN') == uboot_pn:
- kernel_pn = d.getVar('PREFERRED_PROVIDER_virtual/kernel')
+uboot_pn = d.getVar('PREFERRED_PROVIDER_u-boot') or 'u-boot'
+if d.getVar('UBOOT_SIGN_ENABLE') == '1' and d.getVar('PN') == uboot_pn:
+kernel_pn = d.getVar('PREFERRED_PROVIDER_virtual/kernel')
- # u-boot.dtb and u-boot-nodtb.bin are deployed _before_
do_deploy
- # Thus, do_deploy_setscene will also populate them in
DEPLOY_IMAGE_DIR
- bb.build.addtask('do_deploy_dtb', 'do_deploy', 'do_compile', d)
+# u-boot.dtb and u-boot-nodtb.bin are deployed _before_ do_deploy
+# Thus, do_deploy_setscene will also populate them in DEPLOY_IMAGE_DIR
+bb.build.addtask('do_deploy_dtb', 'do_deploy', 'do_compile', d)
- # do_concat_dtb is scheduled _before_ do_install as it
overwrite the
- # u-boot.bin in both DEPLOYDIR and DEPLOY_IMAGE_DIR.
- bb.build.addtask('do_concat_dtb', 'do_install', None, d)
- d.appendVarFlag('do_concat_dtb', 'depends', '
%s:do_assemble_fitimage' % kernel_pn)
+# do_concat_dtb is scheduled _before_ do_install as it overwrite the
+# u-boot.bin in both DEPLOYDIR and DEPLOY_IMAGE_DIR.
+bb.build.addtask('do_concat_dtb', 'do_install', None, d)
+d.appendVarFlag('do_concat_dtb', 'depends', ' %s:do_assemble_fitimage'
% kernel_pn)
}
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] quilt: update to 0.66
Signed-off-by: Oleksandr Kravchuk
---
.../quilt/{quilt-native_0.65.bb => quilt-native_0.66.bb} | 0
meta/recipes-devtools/quilt/quilt.inc | 4 ++--
.../quilt/0001-tests-Allow-different-output-from-mv.patch | 8
.../quilt/{quilt_0.65.bb => quilt_0.66.bb}| 0
4 files changed, 6 insertions(+), 6 deletions(-)
rename meta/recipes-devtools/quilt/{quilt-native_0.65.bb =>
quilt-native_0.66.bb} (100%)
rename meta/recipes-devtools/quilt/{quilt_0.65.bb => quilt_0.66.bb} (100%)
diff --git a/meta/recipes-devtools/quilt/quilt-native_0.65.bb
b/meta/recipes-devtools/quilt/quilt-native_0.66.bb
similarity index 100%
rename from meta/recipes-devtools/quilt/quilt-native_0.65.bb
rename to meta/recipes-devtools/quilt/quilt-native_0.66.bb
diff --git a/meta/recipes-devtools/quilt/quilt.inc
b/meta/recipes-devtools/quilt/quilt.inc
index dbf722be2a..dcba62c84b 100644
--- a/meta/recipes-devtools/quilt/quilt.inc
+++ b/meta/recipes-devtools/quilt/quilt.inc
@@ -13,8 +13,8 @@ SRC_URI = "${SAVANNAH_GNU_MIRROR}/quilt/quilt-${PV}.tar.gz \
SRC_URI_append_class-target = " file://gnu_patch_test_fix_target.patch"
-SRC_URI[md5sum] = "c67ba0228f5b7b8bbe469474661f92d6"
-SRC_URI[sha256sum] =
"f6cbc788e5cbbb381a3c6eab5b9efce67c776a8662a7795c7432fd27aa096819"
+SRC_URI[md5sum] = "6800c2404a2c0598ab2eff92a636ba70"
+SRC_URI[sha256sum] =
"314b319a6feb13bf9d0f9ffa7ce6683b06919e734a41275087ea457cc9dc6e07"
inherit autotools-brokensep ptest
diff --git
a/meta/recipes-devtools/quilt/quilt/0001-tests-Allow-different-output-from-mv.patch
b/meta/recipes-devtools/quilt/quilt/0001-tests-Allow-different-output-from-mv.patch
index 21219a0bba..6d0f4aedfd 100644
---
a/meta/recipes-devtools/quilt/quilt/0001-tests-Allow-different-output-from-mv.patch
+++
b/meta/recipes-devtools/quilt/quilt/0001-tests-Allow-different-output-from-mv.patch
@@ -1,4 +1,4 @@
-From 1530138960cfafbeefb95f2a760954c00b4d0ef0 Mon Sep 17 00:00:00 2001
+From e9fa816677993e520adff8bba26cb3e71f5a6665 Mon Sep 17 00:00:00 2001
From: Jussi Kukkonen
Date: Wed, 29 Mar 2017 15:11:59 +0300
Subject: [PATCH] tests: Allow different output from mv
@@ -12,18 +12,18 @@ Signed-off-by: Jussi Kukkonen
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/failbackup.test b/test/failbackup.test
-index 37046f7..fce6725 100644
+index 5f0f54f..0902b12 100644
--- a/test/failbackup.test
+++ b/test/failbackup.test
@@ -16,7 +16,7 @@ What happens when refresh fails because of a permission
error?
$ cat > test.txt
< This is updated test.txt.
$ quilt refresh --backup
-- >~ mv: cannot move [`']?%{P}test.diff'? to [`']?%{P}test.diff~'?:
Permission denied
+- >~ mv: cannot move [`']?patches/test.diff'? to
[`']?patches/test.diff~'?: Permission denied
+ >~ mv: .*: Permission denied
$ echo %{?}
> 1
--
-2.1.4
+2.17.1
diff --git a/meta/recipes-devtools/quilt/quilt_0.65.bb
b/meta/recipes-devtools/quilt/quilt_0.66.bb
similarity index 100%
rename from meta/recipes-devtools/quilt/quilt_0.65.bb
rename to meta/recipes-devtools/quilt/quilt_0.66.bb
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] ruby: update to 2.5.5
Signed-off-by: Oleksandr Kravchuk
---
meta/recipes-devtools/ruby/{ruby_2.5.3.bb => ruby_2.5.5.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/ruby/{ruby_2.5.3.bb => ruby_2.5.5.bb} (94%)
diff --git a/meta/recipes-devtools/ruby/ruby_2.5.3.bb
b/meta/recipes-devtools/ruby/ruby_2.5.5.bb
similarity index 94%
rename from meta/recipes-devtools/ruby/ruby_2.5.3.bb
rename to meta/recipes-devtools/ruby/ruby_2.5.5.bb
index 519daf294f..8ad59a7657 100644
--- a/meta/recipes-devtools/ruby/ruby_2.5.3.bb
+++ b/meta/recipes-devtools/ruby/ruby_2.5.5.bb
@@ -6,8 +6,8 @@ SRC_URI += " \
file://run-ptest \
"
-SRC_URI[md5sum] = "20c85b67846d49622ef3b24230803fef"
-SRC_URI[sha256sum] =
"9828d03852c37c20fa333a0264f2490f07338576734d910ee3fd538c9520846c"
+SRC_URI[md5sum] = "7e156fb526b8f4bb1b30a3dd8a7ce400"
+SRC_URI[sha256sum] =
"28a945fdf340e6ba04fc890b98648342e3cccfd6d223a48f3810572f11b2514c"
# it's unknown to configure script, but then passed to extconf.rb
# maybe it's not really needed as we're hardcoding the result with
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] bc: dc: fix exit code of q command
The exit code for "echo q | dc" is 1 for dc-1.4.1;
while the exit code for "echo q | dc" is 0 for dc-1.4.
Here is the answer from k...@gnu.org:
dc-1.4 was right. There was a rewrite of a chunk of code for 1.4.1 to
fix a corner case in the Q command, and somehow the placement of the
clean-up label for the 'q' command got misplaced on the error-handling
branch instead of the clean-exit branch. The patch below fixes this
(it is committed for whenever the next bc/dc release gets made).
Thanks for the report,
--Ken Pizzini
Signed-off-by: Li Zhou
---
.../bc/bc/0001-dc-fix-exit-code-of-q-command.patch | 44 ++
meta/recipes-extended/bc/bc_1.07.1.bb | 3 +-
2 files changed, 46 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-extended/bc/bc/0001-dc-fix-exit-code-of-q-command.patch
diff --git
a/meta/recipes-extended/bc/bc/0001-dc-fix-exit-code-of-q-command.patch
b/meta/recipes-extended/bc/bc/0001-dc-fix-exit-code-of-q-command.patch
new file mode 100644
index 000..1ef797d
--- /dev/null
+++ b/meta/recipes-extended/bc/bc/0001-dc-fix-exit-code-of-q-command.patch
@@ -0,0 +1,44 @@
+From e174b6e7d195d5a7465575641b7f68581f162574 Mon Sep 17 00:00:00 2001
+From: Li Zhou
+Date: Thu, 27 Jun 2019 13:10:47 +0800
+Subject: [PATCH] dc: fix exit code of q command
+
+The exit code for "echo q | dc" is 1 for dc-1.4.1;
+while the exit code for "echo q | dc" is 0 for dc-1.4.
+
+Here is the answer from k...@gnu.org:
+dc-1.4 was right. There was a rewrite of a chunk of code for 1.4.1 to
+fix a corner case in the Q command, and somehow the placement of the
+clean-up label for the 'q' command got misplaced on the error-handling
+branch instead of the clean-exit branch. The patch below fixes this
+(it is committed for whenever the next bc/dc release gets made).
+
+Thanks for the report,
+--Ken Pizzini
+
+Upstream-Status: Backport [Got the solution from maintainer]
+
+Signed-off-by: Li Zhou
+---
+ dc/eval.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/dc/eval.c b/dc/eval.c
+index 05a3d9e..bcab8db 100644
+--- a/dc/eval.c
b/dc/eval.c
+@@ -814,10 +814,10 @@ error_fail:
+ fprintf(stderr, "%s: ", progname);
+ perror("error reading input");
+ return DC_FAIL;
+-reset_and_exit_quit:
+ reset_and_exit_fail:
+ signal(SIGINT, sigint_default);
+ return DC_FAIL;
++reset_and_exit_quit:
+ reset_and_exit_success:
+ signal(SIGINT, sigint_default);
+ return DC_SUCCESS;
+--
+1.9.1
+
diff --git a/meta/recipes-extended/bc/bc_1.07.1.bb
b/meta/recipes-extended/bc/bc_1.07.1.bb
index 809b864..4a51302 100644
--- a/meta/recipes-extended/bc/bc_1.07.1.bb
+++ b/meta/recipes-extended/bc/bc_1.07.1.bb
@@ -13,7 +13,8 @@ DEPENDS = "flex-native"
SRC_URI = "${GNU_MIRROR}/${BPN}/${BP}.tar.gz \
file://no-gen-libmath.patch \
- file://libmath.h"
+ file://libmath.h \
+ file://0001-dc-fix-exit-code-of-q-command.patch"
SRC_URI[md5sum] = "cda93857418655ea43590736fc3ca9fc"
SRC_URI[sha256sum] =
"62adfca89b0a1c0164c2cdca59ca210c1d44c3ffc46daf9931cf4942664cb02a"
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] go-dep: disable PTEST_ENABLED
On 2019年06月28日 19:02, Richard Purdie wrote: On Fri, 2019-06-28 at 00:57 -0700, mingli...@windriver.com wrote: From: Mingli Yu The run-ptest logic for go-dep actually runs the /usr/lib64/go-dep/ptest/github.com/golang/dep/cmd/dep/dep.test whose source file is https://github.com/golang/dep/blob/master/cmd/dep/dep_test.go. That dep_test.go starts by rebuilding the dep program from source, then runs the tests using that copy of the program, so it's assuming that we're still in a development environment where we can run a full go build. Considering it not being designed for a cross-build setup, so disable PTEST_ENABLED. Signed-off-by: Mingli Yu --- meta/recipes-devtools/go/go-dep_0.5.0.bb | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/meta/recipes-devtools/go/go-dep_0.5.0.bb b/meta/recipes- devtools/go/go-dep_0.5.0.bb index a4d631f8ea..e9fc12fa5a 100644 --- a/meta/recipes-devtools/go/go-dep_0.5.0.bb +++ b/meta/recipes-devtools/go/go-dep_0.5.0.bb @@ -21,5 +21,6 @@ BBCLASSEXTEND = "native nativesdk" # For compiling ptest on mips and mips64, the current go-dep version fails with the go 1.11 toolchain. # error message: vet config not found -PTEST_ENABLED_mips = "0" -PTEST_ENABLED_mips64 = "0" +# disable PTEST_ENABLED as the run-ptest script for go-dep actually runs the /usr/lib64/go- dep/ptest/github.com/golang/dep/cmd/dep/dep.test whose source file is https://github.com/golang/dep/blob/master/cmd/dep/dep_test.go not being designed for a cross-build setup. +PTEST_ENABLED = "0" +PTEST_ENABLED = "0" Setting it twice looks wrong. Sorry, it should be my typo. If we're disabling it, why would we inherit the ptest class at all as its not going to work anywhere? Upstream not considering cross test usecases isn't a reason to disable a test, we have many tests enabled where upstream haven't considered a cross use case, we just tend to patch as needed and start a discussion with them. It sounds like its actually a network access problem from the image you're running into anyway? Hi RP, Have discussed the ptest more with Matt in the maillist and also tried to add the patch under the guide from Matt to make the https://github.com/golang/dep/blob/master/cmd/dep/dep_test.go work with cross-setup env. But seems it still doesn't work. Hi Matt, What's your opinion? Thanks, Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v1] postinst-intercepts: check tool presence in intercept hooks
On 6/30/2019 5:54 PM, richard.pur...@linuxfoundation.org wrote: >> /update_pixbuf_cache: cannot create >> /home//riscv-yocto/build/tmp-glibc/work/qemuriscv64-oe-linux/core- >> image-full-cmdline/1.0-r0/rootfs/usr/lib/gdk-pixbuf- >> 2.0/2.10.0/loaders/../loaders.cache: >> Directory nonexistent" > Knowing which branches (sumo vs. thud) and which layers does help put a > different perspective on this issue and helps us help you! > Sorry, I thought I mentioned this before. Issue showed up in thud. It was not there on sumo. > Is this a difference in dash shell vs bash shell (e.g. for /bin/sh) on > these machines? (if I had to guess that is where I'd start) Dash vs. bash didn't make a difference. I changed build machine to have /bin/sh point to /bin/bash rather than /bin/dash. The commit on github also says "it may help" with the postinst. Apparently, the issue has been solved mysteriously for them. One thing that issue on github mentions is that these issues were being ignored in sumo but are marked as real failures starting from thud. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bison: update to 3.4.1
Signed-off-by: Oleksandr Kravchuk
---
.../recipes-devtools/bison/{bison_3.3.2.bb => bison_3.4.1.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/bison/{bison_3.3.2.bb => bison_3.4.1.bb} (90%)
diff --git a/meta/recipes-devtools/bison/bison_3.3.2.bb
b/meta/recipes-devtools/bison/bison_3.4.1.bb
similarity index 90%
rename from meta/recipes-devtools/bison/bison_3.3.2.bb
rename to meta/recipes-devtools/bison/bison_3.4.1.bb
index adb9d48e90..7946e20c57 100644
--- a/meta/recipes-devtools/bison/bison_3.3.2.bb
+++ b/meta/recipes-devtools/bison/bison_3.4.1.bb
@@ -17,8 +17,8 @@ SRC_URI = "${GNU_MIRROR}/bison/bison-${PV}.tar.xz \
# No point in hardcoding path to m4, just use PATH
EXTRA_OECONF += "M4=m4"
-SRC_URI[md5sum] = "c9b552dee234b2f6b66e56b27e5234c9"
-SRC_URI[sha256sum] =
"039ee45b61d95e5003e7e8376f9080001b4066ff357bde271b7faace53b9d804"
+SRC_URI[md5sum] = "201286a573b12da109df96282fe4ff4a"
+SRC_URI[sha256sum] =
"27159ac5ebf736dffd5636fd2cd625767c9e437de65baa63cb0de83570bd820d"
inherit autotools gettext texinfo
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] bzip2: update to 1.0.7
Removed patches were upstreamed.
Signed-off-by: Oleksandr Kravchuk
---
.../bzip2/bzip2-1.0.6/CVE-2016-3189.patch | 18 --
...p2-qt-returns-0-for-corrupt-archives.patch | 55 ---
.../bzip2/{bzip2-1.0.6 => bzip2}/Makefile.am | 0
.../bzip2/{bzip2-1.0.6 => bzip2}/configure.ac | 0
.../bzip2/{bzip2-1.0.6 => bzip2}/run-ptest| 0
.../bzip2/{bzip2_1.0.6.bb => bzip2_1.0.7.bb} | 13 ++---
6 files changed, 4 insertions(+), 82 deletions(-)
delete mode 100644 meta/recipes-extended/bzip2/bzip2-1.0.6/CVE-2016-3189.patch
delete mode 100644
meta/recipes-extended/bzip2/bzip2-1.0.6/fix-bunzip2-qt-returns-0-for-corrupt-archives.patch
rename meta/recipes-extended/bzip2/{bzip2-1.0.6 => bzip2}/Makefile.am (100%)
rename meta/recipes-extended/bzip2/{bzip2-1.0.6 => bzip2}/configure.ac (100%)
rename meta/recipes-extended/bzip2/{bzip2-1.0.6 => bzip2}/run-ptest (100%)
rename meta/recipes-extended/bzip2/{bzip2_1.0.6.bb => bzip2_1.0.7.bb} (77%)
diff --git a/meta/recipes-extended/bzip2/bzip2-1.0.6/CVE-2016-3189.patch
b/meta/recipes-extended/bzip2/bzip2-1.0.6/CVE-2016-3189.patch
deleted file mode 100644
index 1d0c3a6dd3..00
--- a/meta/recipes-extended/bzip2/bzip2-1.0.6/CVE-2016-3189.patch
+++ /dev/null
@@ -1,18 +0,0 @@
-Upstream-Status: Backport
-https://bugzilla.suse.com/attachment.cgi?id=681334
-
-CVE: CVE-2016-3189
-Signed-off-by: Armin Kuster
-
-Index: bzip2-1.0.6/bzip2recover.c
-===
bzip2-1.0.6.orig/bzip2recover.c
-+++ bzip2-1.0.6/bzip2recover.c
-@@ -457,6 +457,7 @@ Int32 main ( Int32 argc, Char** argv )
- bsPutUChar ( bsWr, 0x50 ); bsPutUChar ( bsWr, 0x90 );
- bsPutUInt32 ( bsWr, blockCRC );
- bsClose ( bsWr );
-+outFile = NULL;
- }
- if (wrBlock >= rbCtr) break;
- wrBlock++;
diff --git
a/meta/recipes-extended/bzip2/bzip2-1.0.6/fix-bunzip2-qt-returns-0-for-corrupt-archives.patch
b/meta/recipes-extended/bzip2/bzip2-1.0.6/fix-bunzip2-qt-returns-0-for-corrupt-archives.patch
deleted file mode 100644
index ece90d94e6..00
---
a/meta/recipes-extended/bzip2/bzip2-1.0.6/fix-bunzip2-qt-returns-0-for-corrupt-archives.patch
+++ /dev/null
@@ -1,55 +0,0 @@
-From 8068659388127e8e63f2d2297ba2348c72b20705 Mon Sep 17 00:00:00 2001
-From: Wenzong Fan
-Date: Mon, 12 Oct 2015 03:19:51 -0400
-Subject: [PATCH] bzip2: fix bunzip2 -qt returns 0 for corrupt archives
-
-"bzip2 -t FILE" returns 2 if FILE exists, but is not a valid bzip2 file.
-"bzip2 -qt FILE" returns 0 when this happens, although it does print out
-an error message as is does so.
-
-This has been fix by Debian, just port changes from Debian patch file
-"20-legacy.patch".
-
-Debian defect:
-https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=279025
-
-Fix item from changelog:
-http://archive.debian.net/changelogs/pool/main/b/bzip2/bzip2_1.0.2-7/changelog
-
- * Fixed "bunzip2 -qt returns 0 for corrupt archives" (Closes: #279025).
-
-Upstream-Status: Pending
-
-Signed-off-by: Wenzong Fan
- bzip2.c | 14 --
- 1 file changed, 8 insertions(+), 6 deletions(-)
-
-diff --git a/bzip2.c b/bzip2.c
-index 6de9d1d..f2ce668 100644
a/bzip2.c
-+++ b/bzip2.c
-@@ -2003,12 +2003,14 @@ IntNative main ( IntNative argc, Char *argv[] )
- testf ( aa->name );
-}
- }
-- if (testFailsExist && noisy) {
-- fprintf ( stderr,
-- "\n"
-- "You can use the `bzip2recover' program to attempt to recover\n"
-- "data from undamaged sections of corrupted files.\n\n"
-- );
-+ if (testFailsExist) {
-+ if (noisy) {
-+fprintf ( stderr,
-+ "\n"
-+ "You can use the `bzip2recover' program to attempt to recover\n"
-+ "data from undamaged sections of corrupted files.\n\n"
-+);
-+ }
- setExit(2);
- exit(exitValue);
- }
---
-1.9.1
-
diff --git a/meta/recipes-extended/bzip2/bzip2-1.0.6/Makefile.am
b/meta/recipes-extended/bzip2/bzip2/Makefile.am
similarity index 100%
rename from meta/recipes-extended/bzip2/bzip2-1.0.6/Makefile.am
rename to meta/recipes-extended/bzip2/bzip2/Makefile.am
diff --git a/meta/recipes-extended/bzip2/bzip2-1.0.6/configure.ac
b/meta/recipes-extended/bzip2/bzip2/configure.ac
similarity index 100%
rename from meta/recipes-extended/bzip2/bzip2-1.0.6/configure.ac
rename to meta/recipes-extended/bzip2/bzip2/configure.ac
diff --git a/meta/recipes-extended/bzip2/bzip2-1.0.6/run-ptest
b/meta/recipes-extended/bzip2/bzip2/run-ptest
similarity index 100%
rename from meta/recipes-extended/bzip2/bzip2-1.0.6/run-ptest
rename to meta/recipes-extended/bzip2/bzip2/run-ptest
diff --git a/meta/recipes-extended/bzip2/bzip2_1.0.6.bb
b/meta/recipes-extended/bzip2/bzip2_1.0.7.bb
similarity index 77%
rename from meta/recipes-extended/bzip2/bzip2_1.0.6.bb
rename to meta/recipes-extended/bzip2/bzip2_1.0.7.bb
index
Re: [OE-core] [PATCH] bitbake.conf: Stop exporting TARGET_ flags variables
On Tue, 2019-06-25 at 14:16 +0100, Mike Crowe wrote: > Way back in > http://lists.openembedded.org/pipermail/openembedded-core/2014-April/210138.html > a few of us discussed not exporting TARGET_LDFLAGS. There seemed to be > support for this idea, and I modified our tree to not do so. I then seem to > have dropped the ball. :( We've been running like that for over five years, > and not observed any problems. > > It seems sensible to stop exporting TARGET_CPPFLAGS, TARGET_CFLAGS and > TARGET_CXXFLAGS too. > > I've successfully compile-tested core-image-minimal and core-image-sato for > x86_64 and qemuarm64 with these changes. FWIW I'm really happy to see this! Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v2] dropbear: new feature: disable-weak-ciphers
On Fri, 2019-06-28 at 18:03 -0500, Joseph Reynolds wrote: > From 587a9e5c637ad3e70b8e35a3ca66013693ce7ac7 Mon Sep 17 00:00:00 > 2001 > From: Joseph Reynolds > Date: Wed, 19 Jun 2019 20:16:40 -0500 > Subject: [PATCH v2] dropbear: new feature: disable-weak-ciphers > > Enhances dropbear with a new feature "disable-weak-ciphers", on by > default. > This feature disables all CBC, SHA1, and diffie-hellman group1 > ciphers in > the dropbear ssh server and client. > > Disable this feature if you need to connect to the ssh server from > older > clients. Additional customization can be done with local_options.h > as > usual. > > Tested: On github.com/openbmc/openbmc using dropbear_2019.78. > > Signed-off-by: Joseph Reynolds > --- > meta/recipes-core/dropbear/dropbear.inc| 6 ++- > .../0007-dropbear-disable-weak-ciphers.patch | 57 > ++ > 2 files changed, 61 insertions(+), 2 deletions(-) > create mode 100644 > meta/recipes-core/dropbear/dropbear/0007-dropbear-disable-weak- > ciphers.patch I merged v1 of this patch previously. What was different in this version? Also, the patch was still line wrapped so very hard to apply (had to be manually fixed). Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v1] postinst-intercepts: check tool presence in intercept hooks
On Sun, 2019-06-30 at 12:56 -0400, Sinan Kaya wrote: > On 6/27/2019 4:46 AM, Alexander Kanavin wrote: > > This issue showed up in thud using core-image-minimal. It was > > not there > > on sumo. > > > > > > If you can provide steps to reproduce, it could help. Please start > > with > > a git checkout of poky thud branch. > > > > Issue in only happening on the build machine with docker using ubuntu > 16.04 as a baseline. > > I'm having hard-time reproducing on my development machine. > > My cursory web search says that I'm not the only one hitting this > issue > and people have mysteriously solved this issue. > > https://github.com/riscv/meta-riscv/issues/26 > > The following matches what I see on the build machine. > > "/update_pixbuf_cache: 8: > /home/riscv-yocto/build/tmp-glibc/work/qemuriscv64-oe-linux/core- > image-full-cmdline/1.0-r0/intercept_scripts- > 2c03b46bc7941049a88b6c1719c35aade81b0ce5490421e7cca768bf8beb0d01 > > /update_pixbuf_cache: cannot create > /home//riscv-yocto/build/tmp-glibc/work/qemuriscv64-oe-linux/core- > image-full-cmdline/1.0-r0/rootfs/usr/lib/gdk-pixbuf- > 2.0/2.10.0/loaders/../loaders.cache: > Directory nonexistent" Knowing which branches (sumo vs. thud) and which layers does help put a different perspective on this issue and helps us help you! Is this a difference in dash shell vs bash shell (e.g. for /bin/sh) on these machines? (if I had to guess that is where I'd start) Cheers, Richard > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] devtool: warn user about multiple layer having the same base name
Hi Peter, On Friday, 28 June 2019 10:09:22 PM NZST Peter Kjellerstedt wrote: > I had not realized the layer name in the devtool finish command supports > abbreviations/patterns (whichever it is). My expectation from running > `devtool finish foo meta` would be to update the foo recipe in the meta > layer, not that it should go looking for every layer called meta-something. That's not how it works. The logic is here: https://git.openembedded.org/openembedded-core/tree/scripts/lib/devtool/standard.py#n1866 We only have the subdirectory the layer is in to use to determine what the name of the layer is, if you only specify the name. The only shortcuts in this function are "oe-core" and "openembedded-core" map to "meta". The case this patch is attempting to handle is where you have more than one layer in your configuration where the subdirectory in which the layer appears is called "meta". (People should generally avoid this and put the layer in a subdirectory whose name matches the name of the layer, but of course people can do whatever they want.) Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v1] postinst-intercepts: check tool presence in intercept hooks
On 6/27/2019 4:46 AM, Alexander Kanavin wrote: > This issue showed up in thud using core-image-minimal. It was not there > on sumo. > > > If you can provide steps to reproduce, it could help. Please start with > a git checkout of poky thud branch. > Issue in only happening on the build machine with docker using ubuntu 16.04 as a baseline. I'm having hard-time reproducing on my development machine. My cursory web search says that I'm not the only one hitting this issue and people have mysteriously solved this issue. https://github.com/riscv/meta-riscv/issues/26 The following matches what I see on the build machine. "/update_pixbuf_cache: 8: /home/riscv-yocto/build/tmp-glibc/work/qemuriscv64-oe-linux/core-image-full-cmdline/1.0-r0/intercept_scripts-2c03b46bc7941049a88b6c1719c35aade81b0ce5490421e7cca768bf8beb0d01 /update_pixbuf_cache: cannot create /home//riscv-yocto/build/tmp-glibc/work/qemuriscv64-oe-linux/core-image-full-cmdline/1.0-r0/rootfs/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/../loaders.cache: Directory nonexistent" -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/6] meson: update 0.50.1 -> 0.51.0
On Fri, 2019-06-28 at 15:24 +0200, Alexander Kanavin wrote: > Drop backports. > > Rebase other patches. > > Signed-off-by: Alexander Kanavin Something in one of the meson changes is resulting in: https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/766 (mingw failure in nativesdk-glib-2.0, I bisected it locally to one of the meson changes) Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] glib-2.0: Update to 2.60.4
On Sun, 2019-06-30 at 12:37 +0100, Richard Purdie wrote:
> On Thu, 2019-06-27 at 07:00 +0200, Peter Kjellerstedt wrote:
> > * For changes, see:
> > https://gitlab.gnome.org/GNOME/glib/blob/glib-2-60/NEWS
> > * Remove backported CVE-2019-12450.patch.
> >
> > Signed-off-by: Peter Kjellerstedt
> > ---
> > .../glib-2.0/glib-2.0/CVE-2019-12450.patch| 62 ---
> >
> > ...{glib-2.0_2.60.3.bb => glib-2.0_2.60.4.bb} | 5 +-
> > 2 files changed, 2 insertions(+), 65 deletions(-)
> > delete mode 100644 meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-
> > 12450.patch
> > rename meta/recipes-core/glib-2.0/{glib-2.0_2.60.3.bb => glib-
> > 2.0_2.60.4.bb} (85%)
>
> I worry this upgrade has introduced some kind of race:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/765
Sorry, this is caused by the meson changes.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/3] runqemu: Allow to store more than one lock for network interfaces
On Thu, 2019-06-27 at 22:38 -0500, Aníbal Limón wrote: > In order to support multiple tap devices in the same qemu virtual > machine. > > Signed-off-by: Aníbal Limón > --- With this change included tests failed on the autobuilder. I think it breaks usage of tap devices after the first one. E.g.: https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/756 (but testimage failed all over) Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] glib-2.0: Update to 2.60.4
On Thu, 2019-06-27 at 07:00 +0200, Peter Kjellerstedt wrote:
> * For changes, see:
> https://gitlab.gnome.org/GNOME/glib/blob/glib-2-60/NEWS
> * Remove backported CVE-2019-12450.patch.
>
> Signed-off-by: Peter Kjellerstedt
> ---
> .../glib-2.0/glib-2.0/CVE-2019-12450.patch| 62 ---
>
> ...{glib-2.0_2.60.3.bb => glib-2.0_2.60.4.bb} | 5 +-
> 2 files changed, 2 insertions(+), 65 deletions(-)
> delete mode 100644 meta/recipes-core/glib-2.0/glib-2.0/CVE-2019-
> 12450.patch
> rename meta/recipes-core/glib-2.0/{glib-2.0_2.60.3.bb => glib-
> 2.0_2.60.4.bb} (85%)
I worry this upgrade has introduced some kind of race:
https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/765
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] package: Build pkgdata specific to the current recipe
This switches the code to build pkgdata specific to the current recipe
which means that its filtered to the recipes dependencies and can perform
better as we can drop the lockfile.
It uses a similar method to the staging code to do this, using BB_TASKDEPDATA
to construct a list of packagedata task output which this recipe should "see".
The original pkgdata store is left unaltered so existing code works.
The lock file was there to prevent files disappearing as they were read or as
directories were listed. Since we have a copy of the data and only access output
from completed tasks (as per their manifests), we can remove the lock.
The lock was causing starvation issues on systems with parallelism.
There was also a potential determinism problem as the current code could "see"
data from recipes which it doesn't depend upon.
[YOCTO #13412]
Signed-off-by: Richard Purdie
---
meta/classes/package.bbclass | 16 +--
meta/classes/package_pkgdata.bbclass | 167 +++
2 files changed, 170 insertions(+), 13 deletions(-)
create mode 100644 meta/classes/package_pkgdata.bbclass
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 70babb3812c..8adf6e16508 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -40,6 +40,7 @@
inherit packagedata
inherit chrpath
+inherit package_pkgdata
# Need the package_qa_handle_error() in insane.bbclass
inherit insane
@@ -1571,7 +1572,7 @@ python package_do_filedeps() {
d.setVar("FILERPROVIDESFLIST_" + pkg, " ".join(provides_files[pkg]))
}
-SHLIBSDIRS = "${PKGDATA_DIR}/${MLPREFIX}shlibs2"
+SHLIBSDIRS = "${WORKDIR_PKGDATA}/${MLPREFIX}shlibs2"
SHLIBSWORKDIR = "${PKGDESTWORK}/${MLPREFIX}shlibs2"
python package_do_shlibs() {
@@ -1729,10 +1730,7 @@ python package_do_shlibs() {
needed = {}
-# Take shared lock since we're only reading, not writing
-lf = bb.utils.lockfile(d.expand("${PACKAGELOCK}"), True)
shlib_provider = oe.package.read_shlib_providers(d)
-bb.utils.unlockfile(lf)
for pkg in shlib_pkgs:
private_libs = d.getVar('PRIVATE_LIBS_' + pkg) or
d.getVar('PRIVATE_LIBS') or ""
@@ -1918,9 +1916,6 @@ python package_do_pkgconfig () {
f.write('%s\n' % p)
f.close()
-# Take shared lock since we're only reading, not writing
-lf = bb.utils.lockfile(d.expand("${PACKAGELOCK}"), True)
-
# Go from least to most specific since the last one found wins
for dir in reversed(shlibs_dirs):
if not os.path.exists(dir):
@@ -1936,8 +1931,6 @@ python package_do_pkgconfig () {
for l in lines:
pkgconfig_provided[pkg].append(l.rstrip())
-bb.utils.unlockfile(lf)
-
for pkg in packages.split():
deps = []
for n in pkgconfig_needed[pkg]:
@@ -2134,6 +2127,7 @@ def gen_packagevar(d):
PACKAGE_PREPROCESS_FUNCS ?= ""
# Functions for setting up PKGD
PACKAGEBUILDPKGD ?= " \
+package_prepare_pkgdata \
perform_packagecopy \
${PACKAGE_PREPROCESS_FUNCS} \
split_and_strip_files \
@@ -2261,12 +2255,8 @@ do_packagedata () {
addtask packagedata before do_build after do_package
SSTATETASKS += "do_packagedata"
-# PACKAGELOCK protects readers of PKGDATA_DIR against writes
-# whilst code is reading in do_package
-PACKAGELOCK = "${STAGING_DIR}/package-output.lock"
do_packagedata[sstate-inputdirs] = "${PKGDESTWORK}"
do_packagedata[sstate-outputdirs] = "${PKGDATA_DIR}"
-do_packagedata[sstate-lockfile] = "${PACKAGELOCK}"
do_packagedata[stamp-extra-info] = "${MACHINE_ARCH}"
python do_packagedata_setscene () {
diff --git a/meta/classes/package_pkgdata.bbclass
b/meta/classes/package_pkgdata.bbclass
new file mode 100644
index 000..18b7ed62e03
--- /dev/null
+++ b/meta/classes/package_pkgdata.bbclass
@@ -0,0 +1,167 @@
+WORKDIR_PKGDATA = "${WORKDIR}/pkgdata-sysroot"
+
+def package_populate_pkgdata_dir(pkgdatadir, d):
+import glob
+
+postinsts = []
+seendirs = set()
+stagingdir = d.getVar("PKGDATA_DIR")
+pkgarchs = ['${MACHINE_ARCH}']
+pkgarchs = pkgarchs +
list(reversed(d.getVar("PACKAGE_EXTRA_ARCHS").split()))
+pkgarchs.append('allarch')
+
+bb.utils.mkdirhier(pkgdatadir)
+for pkgarch in pkgarchs:
+for manifest in
glob.glob(d.expand("${SSTATE_MANIFESTS}/manifest-%s-*.packagedata" % pkgarch)):
+with open(manifest, "r") as f:
+for l in f:
+l = l.strip()
+dest = l.replace(stagingdir, "")
+if l.endswith("/"):
+staging_copydir(l, pkgdatadir, dest, seendirs)
+continue
+try:
+staging_copyfile(l, pkgdatadir, dest, postinsts,
seendirs)
+except FileExistsError:
+continue
+
+python package_prepare_pkgdata() {
+import copy
+
[OE-core] [PATCH 1/2] staging: Code cleanup
multiconfig dependencies no longer appear in BB_TASKDEPDATA so we can drop
this code.
Signed-off-by: Richard Purdie
---
meta/classes/staging.bbclass | 7 ---
1 file changed, 7 deletions(-)
diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index 92070602228..94c85248daf 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -261,12 +261,10 @@ python extend_recipe_sysroot() {
workdir = d.getVar("WORKDIR")
#bb.warn(str(taskdepdata))
pn = d.getVar("PN")
-mc = d.getVar("BB_CURRENT_MC")
stagingdir = d.getVar("STAGING_DIR")
sharedmanifests = d.getVar("COMPONENTS_DIR") + "/manifests"
recipesysroot = d.getVar("RECIPE_SYSROOT")
recipesysrootnative = d.getVar("RECIPE_SYSROOT_NATIVE")
-current_variant = d.getVar("BBEXTENDVARIANT")
# Detect bitbake -b usage
nodeps = d.getVar("BB_LIMITEDDEPS") or False
@@ -452,11 +450,6 @@ python extend_recipe_sysroot() {
msg_adding = []
for dep in configuredeps:
-if mc != 'default':
-# We should not care about other multiconfigs
-depmc = dep.split(':')[1]
-if depmc != mc:
-continue
c = setscenedeps[dep][0]
if c not in installed:
continue
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] devupstream.bbclass: Disable devupstream when multilib is enabled
On Fri, 2019-06-28 at 20:15 +0800, Robert Yang wrote:
> Fixed:
> MACHINE = "qemux86-64"
> require conf/multilib.conf
> MULTILIBS = "multilib:lib32"
> DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
>
> PREFERRED_VERSION_lttng-modules = "2.10.10+git%"
>
> $ bitbake world
>
> NOTE: preferred version 2.10.10+git% of lttng-modules not available
> (for item lib32-lttng-modules)
> NOTE: versions of lttng-modules available: 2.10.10
> ERROR: Multiple versions of lttng-modules are due to be built
> (/path/to/lttng-modules_2.10.10.bb
> virtual:devupstream:target:/path/to/lttng-modules_2.10.10.bb). Only
> one version of a given PN should be built in any given build. You
> likely need to set PREFERRED_VERSION_lttng-modules to select the
> correct version or don't depend on multiple versions.
>
> This is because 2.10.10+git% will be built for non-multilib lttng-
> modules since
> the PREFERRED_VERSION is set, but this version doesn't provide
> lib32-lttng-modules, so 2.10.10 will be built, then the error
> happens.
>
> Bitbake can't extend an extended recipe, for example:
> virtual:multilib:lib32:virtual:devupstream:target
>
> Or in a reverse order:
> virtual:devupstream:target:virtual:multilib:lib32
>
> So disable devupstream when multilib is enabled.
>
> Signed-off-by: Robert Yang
> ---
> meta/classes/devupstream.bbclass | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/meta/classes/devupstream.bbclass
> b/meta/classes/devupstream.bbclass
> index 7780c54..25403da 100644
> --- a/meta/classes/devupstream.bbclass
> +++ b/meta/classes/devupstream.bbclass
> @@ -19,6 +19,12 @@
> CLASSOVERRIDE .= ":class-devupstream"
>
> python devupstream_virtclass_handler () {
> +# bitbake can't extend an extended recipe, for example:
> +# virtual:multilib:lib32:virtual:devupstream:target
> +# So disable devupstream when multilib is enabled.
> +if d.getVar('MULTILIBS'):
> +raise bb.parse.SkipRecipe("Disable devupstream when multilib
> is enabled")
> +
> # Do nothing if this is inherited, as it's for BBCLASSEXTEND
> if "devupstream" not in (d.getVar('BBCLASSEXTEND') or ""):
> bb.error("Don't inherit devupstream, use BBCLASSEXTEND")
This is a bit of a serious problem with devupstream as it means we
can't rely upon it for default recipes. We need to file a bug about
this and find a way to fix it, perhaps teaching multilib about
devupstream so it can set BBCLASSEXTEND accordingly.
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
