[OE-core] [PATCH] libxml2: fix libxml2 ptest fails
From: Changqing Li
for core-image-minimal image, missing these two dependency
will cause below warning and error:
warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
./test/icu_parse_test.xml generated an error
Signed-off-by: Changqing Li
---
meta/recipes-core/libxml/libxml2_2.9.8.bb | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/libxml/libxml2_2.9.8.bb
b/meta/recipes-core/libxml/libxml2_2.9.8.bb
index 1f22bb0..27a648e 100644
--- a/meta/recipes-core/libxml/libxml2_2.9.8.bb
+++ b/meta/recipes-core/libxml/libxml2_2.9.8.bb
@@ -44,7 +44,12 @@ RDEPENDS_${PN}-ptest += "make
${@bb.utils.contains('PACKAGECONFIG', 'python', 'l
RDEPENDS_${PN}-python += "${@bb.utils.contains('PACKAGECONFIG', 'python',
'python3-core', '', d)}"
-RDEPENDS_${PN}-ptest_append_libc-glibc = " glibc-gconv-ebcdic-us
glibc-gconv-ibm1141 glibc-gconv-iso8859-5"
+RDEPENDS_${PN}-ptest_append_libc-glibc = " glibc-gconv-ebcdic-us \
+ glibc-gconv-ibm1141 \
+ glibc-gconv-iso8859-5 \
+ glibc-gconv-euc-jp \
+ locale-base-en-us \
+ "
export PYTHON_SITE_PACKAGES="${PYTHON_SITEPACKAGES_DIR}"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] base-files: fix handling of resize
On 08/01/2018 01:25 PM, Chen Qi wrote:
The current handling of resize is incorrect. Using `resize > /dev/null
2>&1 && resize > /dev/null' will cause the second resize command to not
execute because 'resize > /dev/null 2>&1' will fail for resize utility
from busybox.
What we really should do is just to check whether ${bindir}/resize
is executable and execute it if so. Using '-x' is sufficient.
Signed-off-by: Chen Qi
---
meta/recipes-core/base-files/base-files/profile | 6 +-
meta/recipes-core/base-files/base-files_3.0.14.bb | 1 +
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-core/base-files/base-files/profile
b/meta/recipes-core/base-files/base-files/profile
index e14cb2d..9e4283e 100644
--- a/meta/recipes-core/base-files/base-files/profile
+++ b/meta/recipes-core/base-files/base-files/profile
@@ -24,11 +24,7 @@ fi
# /dev/tty[A-z]), otherwise we confuse e.g. the eclipse launcher which tries
do
# use ssh
case $(tty 2>/dev/null) in
- # The first invocation of resize verifies that it exists, the second
- # does the actual resizing. This is due to that resize uses stderr to
- # determine the size of the tty, which does not work if it is redirected
- # to /dev/null.
- /dev/tty[A-z]*) resize >/dev/null 2>&1 && resize >/dev/null;;
+ /dev/tty[A-z]*) [ -x @BINDIR@/resize ] && @BINDIR@/resize >/dev/null;;
esac
export PATH PS1 OPIEDIR QPEDIR QTDIR EDITOR TERM
diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
b/meta/recipes-core/base-files/base-files_3.0.14.bb
index 1c0863b..05c0562 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -121,6 +121,7 @@ do_install () {
install -m 0644 ${WORKDIR}/usbd ${D}${sysconfdir}/default/usbd
install -m 0644 ${WORKDIR}/profile ${D}${sysconfdir}/profile
sed -i 's#ROOTHOME#${ROOT_HOME}#' ${D}${sysconfdir}/profile
+sed -i 's#@BINDIR@#${bindir}#g' ${D}${sysconfdir}/profile
Just noticed the indent here is not correct.
I've fixed this indentation problem and updated the remote branch.
Sorry for the inconvenience.
Best Regards,
Chen Qi
install -m 0644 ${WORKDIR}/shells ${D}${sysconfdir}/shells
install -m 0755 ${WORKDIR}/share/dot.profile
${D}${sysconfdir}/skel/.profile
install -m 0755 ${WORKDIR}/share/dot.bashrc
${D}${sysconfdir}/skel/.bashrc
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] base-files: fix handling of resize
The current handling of resize is incorrect. Using `resize > /dev/null
2>&1 && resize > /dev/null' will cause the second resize command to not
execute because 'resize > /dev/null 2>&1' will fail for resize utility
from busybox.
What we really should do is just to check whether ${bindir}/resize
is executable and execute it if so. Using '-x' is sufficient.
Signed-off-by: Chen Qi
---
meta/recipes-core/base-files/base-files/profile | 6 +-
meta/recipes-core/base-files/base-files_3.0.14.bb | 1 +
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-core/base-files/base-files/profile
b/meta/recipes-core/base-files/base-files/profile
index e14cb2d..9e4283e 100644
--- a/meta/recipes-core/base-files/base-files/profile
+++ b/meta/recipes-core/base-files/base-files/profile
@@ -24,11 +24,7 @@ fi
# /dev/tty[A-z]), otherwise we confuse e.g. the eclipse launcher which tries do
# use ssh
case $(tty 2>/dev/null) in
- # The first invocation of resize verifies that it exists, the second
- # does the actual resizing. This is due to that resize uses stderr to
- # determine the size of the tty, which does not work if it is redirected
- # to /dev/null.
- /dev/tty[A-z]*) resize >/dev/null 2>&1 && resize >/dev/null;;
+ /dev/tty[A-z]*) [ -x @BINDIR@/resize ] && @BINDIR@/resize >/dev/null;;
esac
export PATH PS1 OPIEDIR QPEDIR QTDIR EDITOR TERM
diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
b/meta/recipes-core/base-files/base-files_3.0.14.bb
index 1c0863b..05c0562 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -121,6 +121,7 @@ do_install () {
install -m 0644 ${WORKDIR}/usbd ${D}${sysconfdir}/default/usbd
install -m 0644 ${WORKDIR}/profile ${D}${sysconfdir}/profile
sed -i 's#ROOTHOME#${ROOT_HOME}#' ${D}${sysconfdir}/profile
+sed -i 's#@BINDIR@#${bindir}#g' ${D}${sysconfdir}/profile
install -m 0644 ${WORKDIR}/shells ${D}${sysconfdir}/shells
install -m 0755 ${WORKDIR}/share/dot.profile
${D}${sysconfdir}/skel/.profile
install -m 0755 ${WORKDIR}/share/dot.bashrc
${D}${sysconfdir}/skel/.bashrc
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] base-files: fix handling of resize
The following changes since commit 666e0783525a298217787e3d2f1460c57c2f59ca: gcc-7.3: Backport fixes for std::pair high memory usage (2018-07-31 22:55:35 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib ChenQi/base-files-resize http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/base-files-resize Chen Qi (1): base-files: fix handling of resize meta/recipes-core/base-files/base-files/profile | 6 +- meta/recipes-core/base-files/base-files_3.0.14.bb | 1 + 2 files changed, 2 insertions(+), 5 deletions(-) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] machine: remove kernel-modules from RRECOMMENDS
On 07/31/2018 11:22 PM, openembedded-core-boun...@lists.openembedded.org wrote: > On Tue, 2018-07-31 at 17:15 +0300, Maxin B. John wrote: >> qemumips,qemumips64 and x86 based machines include kernel-modules by >> default. Remove the kernel modules from RRECOMMENDS to make it >> consistent >> across the machines. >> >> Tested using core-image-sato on qemumips, qemumips64, qemux86 and >> qemux86-64 >> >> [YOCTO #12383] >> >> Signed-off-by: Maxin B. John >> --- >> meta/conf/machine/include/x86-base.inc | 2 -- >> meta/conf/machine/qemumips.conf| 2 -- >> meta/conf/machine/qemumips64.conf | 2 -- >> 3 files changed, 6 deletions(-) > > Looks good, do we need to add this to genericx86 or anything in meta- > intel given its changing x86-base.inc? > meta-intel explicitly includes the modules so no change needed there. I have sent the patch for genericx86 where it should be included now. Thanks, Anuj -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for util-linux: Enable fallocate for native/nativesdk
== Series Details == Series: util-linux: Enable fallocate for native/nativesdk Revision: 1 URL : https://patchwork.openembedded.org/series/13325/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fixRebase your series on top of targeted branch Targeted branch master (currently at 51a09ba272) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] util-linux: Enable fallocate for native/nativesdk
fallocate was disabled for native/nativesdk in:
http://git.openembedded.org/openembedded-core/commit/?id=17f3c548caf4adec37c3bbb139aa6b3900419794
We have since added uninative support and better glibc handling for SDKs
so this difference can be dropped now.
Signed-off-by: Richard Purdie
---
meta/recipes-core/util-linux/util-linux.inc | 3 +--
meta/recipes-core/util-linux/util-linux_2.32.bb | 2 --
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/meta/recipes-core/util-linux/util-linux.inc
b/meta/recipes-core/util-linux/util-linux.inc
index 9ac8bd6f798..9d52ed935f5 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -207,8 +207,7 @@ ALTERNATIVE_PRIORITY = "80"
ALTERNATIVE_${PN} = "dmesg kill more mkswap blockdev pivot_root switch_root"
ALTERNATIVE_${PN} += "hexdump last lastb logger mesg renice wall unshare"
-ALTERNATIVE_${PN} += "setsid chrt flock utmpdump eject nologin taskset"
-ALTERNATIVE_${PN}_append_class-target = " fallocate"
+ALTERNATIVE_${PN} += "setsid chrt flock utmpdump eject nologin taskset
fallocate"
ALTERNATIVE_LINK_NAME[dmesg] = "${base_bindir}/dmesg"
ALTERNATIVE_LINK_NAME[kill] = "${base_bindir}/kill"
diff --git a/meta/recipes-core/util-linux/util-linux_2.32.bb
b/meta/recipes-core/util-linux/util-linux_2.32.bb
index 55cc98c2002..4af7f873b93 100644
--- a/meta/recipes-core/util-linux/util-linux_2.32.bb
+++ b/meta/recipes-core/util-linux/util-linux_2.32.bb
@@ -21,10 +21,8 @@ SRC_URI[sha256sum] =
"6c7397abc764e32e8159c2e96042874a190303e77adceb4ac5bd502a27
CACHED_CONFIGUREVARS += "scanf_cv_alloc_modifier=ms"
EXTRA_OECONF_class-native = "${SHARED_EXTRA_OECONF} \
- --disable-fallocate \
--disable-use-tty-group \
"
EXTRA_OECONF_class-nativesdk = "${SHARED_EXTRA_OECONF} \
---disable-fallocate \
--disable-use-tty-group \
"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][PATCH] poky-lsb: security_flags.inc
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org core-boun...@lists.openembedded.org> On Behalf Of Hongzhi.Song
> Sent: den 31 juli 2018 13:07
> To: openembedded-core@lists.openembedded.org; raj.k...@gmail.com
> Subject: [OE-core] [oe-core][PATCH] poky-lsb: security_flags.inc
This is not only limited to poky-lsb. security_flags.inc is used
by many directly.
> To fix the following error, we append '-O' to the defination of
> _FORTIFY_SOURCE
>
> recipe-sysroot/usr/include/features.h:381:4: error: #warning
> _FORTIFY_SOURCE requires compiling with optimization (-O) [-Werror=cpp]
> # warning _FORTIFY_SOURCE requires compiling with optimization (-O)
> ^~~
>
> Signed-off-by: Hongzhi.Song
> ---
> meta/conf/distro/include/security_flags.inc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/conf/distro/include/security_flags.inc
> b/meta/conf/distro/include/security_flags.inc
> index 6245e89ada..1c32fd3165 100644
> --- a/meta/conf/distro/include/security_flags.inc
> +++ b/meta/conf/distro/include/security_flags.inc
> @@ -10,7 +10,7 @@ GCCPIE ?= "--enable-default-pie"
>
> # _FORTIFY_SOURCE requires -O1 or higher, so disable in debug builds as they
> use
> # -O0 which then results in a compiler warning.
> -lcl_maybe_fortify =
> "${@oe.utils.conditional('DEBUG_BUILD','1','','-D_FORTIFY_SOURCE=2',d)}"
> +lcl_maybe_fortify =
> "${@oe.utils.conditional('DEBUG_BUILD','1','','-D_FORTIFY_SOURCE=2 -O',d)}"
This is not the correct way to solve this problem. It should be fixed on
a per recipe basis. There is probably a reason why the code is being built
with -O0, so then changing it here without an investigation of which is
correct, to build with fortification and enabling optimization or to build
without fortification and without enabling optimization.
Changing it as per above could also have an impact on some packages by
actually lowering the optimization level.
> # Error on use of format strings that represent possible security problems
> SECURITY_STRINGFORMAT ?= "-Wformat -Wformat-security -Werror=format-security"
> --
> 2.11.0
//Peter
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] defaultsetup.conf: Enable security flags+pie by default
> -Original Message- > From: Khem Raj > Sent: den 27 juli 2018 23:27 > To: Peter Kjellerstedt > Cc: ChenQi ; Patches and discussions about the > oe-core layer > Subject: Re: [OE-core] [PATCH] defaultsetup.conf: Enable security > flags+pie by default > > On Fri, Jul 27, 2018 at 1:49 PM Peter Kjellerstedt > wrote: > > > > > -Original Message- > > > From: openembedded-core-boun...@lists.openembedded.org > > > core-boun...@lists.openembedded.org> On Behalf Of Khem Raj > > > Sent: den 24 juli 2018 16:12 > > > To: ChenQi > > > Cc: Patches and discussions about the oe-core layer > > c...@lists.openembedded.org> > > > Subject: Re: [OE-core] [PATCH] defaultsetup.conf: Enable security > > > flags+pie by default > > > > > > On Tue, Jul 24, 2018 at 12:30 AM ChenQi > wrote: > > > > > > > > Hi Khem, > > > > > > > > The comments in security-flags.inc also needs to be modified to > > > remove > > > > 'poky-lsb' info. > > > > > > > > I'd suggest we still put it into distro conf file (poky.conf) > instead > > > of > > > > defaultsetup.conf, because defaultsetup.conf is included by > > > > bitbake.conf. I think things in defaultsetup.conf should be > necessary > > > > default values to build things out. I don't think security flags > is > > > > necessary to build things out. > > > > > > this is the default setup, even non-poky users will get consistent > > > experience. > > > > I have to agree with Chen here. I think requiring security_flags.inc > from > > defaultsetup.conf is the wrong thing to do. We use security_flags.inc > in > > our setup, and I know how much trouble it has brought. To me, using > it > > should be a distro decision, not something that is enforced by the > use > > of bitbake. > > Thats fine, I can move this to poky distro settings, using it by > default would have > been in sync for all since reference distro is using it would be > easier for others when > submitting patches, as a phase 2 I was also thinking of defaulting to > hardeing in the toolchain itself > and remove this file completely that would have made it much better, > then folks who dont want hardeing could just disable > it in toolchain. but I am fine to leave it a distro decision for now. I do not think that relying on the toolchain to handle this is the right thing to do, given that some of us use external toolchains in addition to the toolchain from OE-Core... With the current setup we get roughly the same coverage regardless of which toolchain we use. //Peter -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [oe-core][PATCH v2] u-boot: Fix pylibfdt generation
u-boot attempts to build a Python library called pylibfdt. By default,
u-boot would attempt to use the build host's Python interpreter, which
causes numerous problems, not least of which is that it fails if the
host doesn't have the Python development package installed (complaining
about not being able to find Python.h)
Rectify this situation by including the proper build time dependencies
for pylibfdt and passing the proper arguments to make.
[YOCTO #12867]
Signed-off-by: Joshua Watt
---
meta/recipes-bsp/u-boot/u-boot.inc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/recipes-bsp/u-boot/u-boot.inc
b/meta/recipes-bsp/u-boot/u-boot.inc
index c2bcf998402..95c2f4db14d 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -7,8 +7,11 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
inherit uboot-config uboot-extlinux-config uboot-sign deploy
+DEPENDS += "swig-native python-native"
+
EXTRA_OEMAKE = 'CROSS_COMPILE=${TARGET_PREFIX} CC="${TARGET_PREFIX}gcc
${TOOLCHAIN_OPTIONS}" V=1'
EXTRA_OEMAKE += 'HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}"'
+EXTRA_OEMAKE += 'PYTHON=nativepython STAGING_INCDIR=${STAGING_INCDIR_NATIVE}
STAGING_LIBDIR=${STAGING_LIBDIR_NATIVE}'
PACKAGECONFIG ??= "openssl"
# u-boot will compile its own tools during the build, with specific
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] python[3]native: allow use of both native Python 2 and 3
Instead of both classes using ${PYTHON_PN} (which is set by python-dir and
python3-dir), hardcode the right values so that it is possible to inherit both
pythonnative and python3native at the same time.
If both are inherited then both native Pythons are available, but the last to be
inherited will be the one to set PYTHON.
Signed-off-by: Ross Burton
---
meta/classes/python3native.bbclass | 6 +++---
meta/classes/pythonnative.bbclass | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta/classes/python3native.bbclass
b/meta/classes/python3native.bbclass
index 89665efee8b..da12a714703 100644
--- a/meta/classes/python3native.bbclass
+++ b/meta/classes/python3native.bbclass
@@ -1,8 +1,8 @@
inherit python3-dir
-PYTHON="${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN}"
-EXTRANATIVEPATH += "${PYTHON_PN}-native"
-DEPENDS_append = " ${PYTHON_PN}-native "
+PYTHON="${STAGING_BINDIR_NATIVE}/python3-native/python3"
+EXTRANATIVEPATH += "python3-native"
+DEPENDS_append = " python3-native "
# python-config and other scripts are using distutils modules
# which we patch to access these variables
diff --git a/meta/classes/pythonnative.bbclass
b/meta/classes/pythonnative.bbclass
index 4cc8b2769c2..ae6600cd155 100644
--- a/meta/classes/pythonnative.bbclass
+++ b/meta/classes/pythonnative.bbclass
@@ -1,11 +1,11 @@
inherit python-dir
-PYTHON="${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN}"
+PYTHON="${STAGING_BINDIR_NATIVE}/python-native/python"
# PYTHON_EXECUTABLE is used by cmake
PYTHON_EXECUTABLE="${PYTHON}"
-EXTRANATIVEPATH += "${PYTHON_PN}-native"
-DEPENDS_append = " ${PYTHON_PN}-native "
+EXTRANATIVEPATH += "python-native"
+DEPENDS_append = " python-native "
# python-config and other scripts are using distutils modules
# which we patch to access these variables
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] meson: don't dump full error log on failure
If the configure fails then we don't really want to see hundreds of lines of
test output (this would be similar to dumping out autoconf's config.log). The
error includes the path of the full log if further debugging is required.
Signed-off-by: Ross Burton
---
meta/classes/meson.bbclass | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/classes/meson.bbclass b/meta/classes/meson.bbclass
index 66c44e8bb23..e3b452786d8 100644
--- a/meta/classes/meson.bbclass
+++ b/meta/classes/meson.bbclass
@@ -101,7 +101,6 @@ CONFIGURE_FILES = "meson.build"
meson_do_configure() {
bbnote Executing meson ${EXTRA_OEMESON}...
if ! meson ${MESONOPTS} "${MESON_SOURCEPATH}" "${B}" ${MESON_CROSS_FILE}
${EXTRA_OEMESON}; then
-cat ${B}/meson-logs/meson-log.txt
bbfatal_log meson failed
fi
}
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 8/8] [PATCH v2] meta-toolchain: Added dnf-nativesdk into cross-development toolchain.
2018-07-31 13:15 GMT+02:00 : > Why not add some dnf like wrappers around the eSDK though? We have > tools like devtool and recipetool but there is a lot of potential to > add a simpler interface to enable these "customise rootfs" type of > workflows. For what it's worth, I'm just now looking into an integration process of one of automotive tier1s. They use a similar, custom developed ipk tooling to add pre-built binaries to a pre-generated rootfs. So yes, I'd also rather have a standard, common solution for this. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] machine: remove kernel-modules from RRECOMMENDS
On Tue, 2018-07-31 at 17:15 +0300, Maxin B. John wrote: > qemumips,qemumips64 and x86 based machines include kernel-modules by > default. Remove the kernel modules from RRECOMMENDS to make it > consistent > across the machines. > > Tested using core-image-sato on qemumips, qemumips64, qemux86 and > qemux86-64 > > [YOCTO #12383] > > Signed-off-by: Maxin B. John > --- > meta/conf/machine/include/x86-base.inc | 2 -- > meta/conf/machine/qemumips.conf| 2 -- > meta/conf/machine/qemumips64.conf | 2 -- > 3 files changed, 6 deletions(-) Looks good, do we need to add this to genericx86 or anything in meta- intel given its changing x86-base.inc? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Yocto Project Status WW31’18
Current Dev Position: YP 2.6 M3. Next Deadline: YP 2.6 M2 Release Target was July 27, 2018 SWAT Team Rotation: · SWAT lead is currently: Tracy · SWAT team rotation: Tracy -> Armin on Aug. 3, 2018 · SWAT team rotation: Armin -> Maxin on Aug. 10, 2018 · https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Project Announcements: There has been various changes in the project recently which have caused concern for some users and contributors. It is worth highlighting the recent news that: · The Yocto Project recently welcomed two new platinum members, Facebook and Arm to the advisory board · Richard Purdie is being funded by the project to continue in his role as the overall project architect, currently for a three month period whilst governance is discussed. · Nicolas Dechesne (Linaro) has taken over the community manager role from Jefro · Lieu Ta (WindRiver) has taken over the advisory board chairperson role from Jefro · Andreea Volosincu (WindRiver) has taken on the advocacy lead role from Tracey Erway · Discussions about the future governance of the project with a view to modernisation and clarification are now ongoing but are based upon the strong foundations above. Key Status/Updates: · YP 2.6 M2 is in QA. See https://wiki.yoctoproject.org/wiki/2.6_QA_Status. It is 98% complete and should complete this week. · YP 2.2.4 has been released. This is the final release of the YP 2.2 (morty) series. · We are about to build 2.5.1 (sumo) after M2 completes QA. · The races in oe-selftest parallelisation are now mostly resolved and we will be able to use it by default with master. We had a record 30 minute oe-selftest run with hot sstate (compared with 13 hours at its worst with cold sstate and no parallelism). · Multiconfig dependencies looks ready to merge (thanks Alejandro/Xlinx). · The layerindex library code from Mark/Windriver needs close review as it builds API any setup tool would rely upon. · The sstate equivalency server work from Joshua/Garmin needs review · The kernel-devsrc rework from Bruce/Windriver is hopefully ready to go in now multilib issues that were stopping it have been resolved. · Uninative 2.2 was released. There was a critical bug found in the first attempt and a patch was reverted to allow the release. This releases fixes build issues with newer distros. Planned Releases for YP 2.6: · YP 2.6 M2 Build is in QA. · YP 2.6 M2 Release Target was July 27, 2018 · YP 2.6 M3 Build Target is Aug. 27, 2018 · YP 2.6 M3 Release Target is Sept. 7, 2018 · YP 2.6 M4 Build Target is Oct. 1, 2018 · YP 2.6 M4 Release Target is Oct. 26, 2018 Planned upcoming dot releases: · YP 2.5.1 (Sumo) will be targeted after YP 2.6 M2 is done. · YP 2.4.4 (Rocko) will be targeted after YP 2.6 M4 is done. · YP 2.5.2 (Sumo) will be targeted after YP 2.4.4 is done. Tracking Metrics: · WDD 2620 (last week 2618) (https://wiki.yoctoproject.org/charts/combo.html) · Poky Patch Metrics oTotal patches found: 1619 (last week 1619) oPercentage of patches in the Pending State: 740 (46%) [last week 762 (46%)] Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status https://wiki.yoctoproject.org/wiki/Yocto_2.6_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.6_Features The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status [If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!] Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 •Cell:(208) 244-4460 • Email: stephen.k.jol...@intel.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] machine: remove kernel-modules from RRECOMMENDS
qemumips,qemumips64 and x86 based machines include kernel-modules by default. Remove the kernel modules from RRECOMMENDS to make it consistent across the machines. Tested using core-image-sato on qemumips, qemumips64, qemux86 and qemux86-64 [YOCTO #12383] Signed-off-by: Maxin B. John --- meta/conf/machine/include/x86-base.inc | 2 -- meta/conf/machine/qemumips.conf| 2 -- meta/conf/machine/qemumips64.conf | 2 -- 3 files changed, 6 deletions(-) diff --git a/meta/conf/machine/include/x86-base.inc b/meta/conf/machine/include/x86-base.inc index 0edcea7..be037be 100644 --- a/meta/conf/machine/include/x86-base.inc +++ b/meta/conf/machine/include/x86-base.inc @@ -8,8 +8,6 @@ MACHINE_FEATURES += "screen keyboard pci usbhost ext2 ext3 x86 \ acpi serial usbgadget alsa" -MACHINE_EXTRA_RRECOMMENDS += "kernel-modules" - IMAGE_FSTYPES ?= "hddimg" KERNEL_IMAGETYPE ?= "bzImage" diff --git a/meta/conf/machine/qemumips.conf b/meta/conf/machine/qemumips.conf index 986315a..a60f67a 100644 --- a/meta/conf/machine/qemumips.conf +++ b/meta/conf/machine/qemumips.conf @@ -10,5 +10,3 @@ KERNEL_IMAGETYPE = "vmlinux" KERNEL_ALT_IMAGETYPE = "vmlinux.bin" SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyS1" - -MACHINE_EXTRA_RRECOMMENDS = " kernel-modules" diff --git a/meta/conf/machine/qemumips64.conf b/meta/conf/machine/qemumips64.conf index 3f91cbe..a166a10 100644 --- a/meta/conf/machine/qemumips64.conf +++ b/meta/conf/machine/qemumips64.conf @@ -10,5 +10,3 @@ KERNEL_IMAGETYPE = "vmlinux" KERNEL_ALT_IMAGETYPE = "vmlinux.bin" SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyS1" - -MACHINE_EXTRA_RRECOMMENDS = " kernel-modules" -- 2.4.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] openssl: fix missing dependency on hostperl-runtime-native
Openssl 1.1 requires perl in order to build (just as openssl 1.0
does). The missing dependency has gone unnoticed up to now since
hostperl-runtime-native is included in ASSUME_PROVIDED.
Signed-off-by: Andre McCurdy
---
meta/recipes-connectivity/openssl/openssl_1.1.0h.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.0h.bb
b/meta/recipes-connectivity/openssl/openssl_1.1.0h.bb
index a7cd6a4..88ef42e 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.0h.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.0h.bb
@@ -8,6 +8,8 @@ SECTION = "libs/network"
LICENSE = "openssl"
LIC_FILES_CHKSUM = "file://LICENSE;md5=d57d511030c9d66ef5f5966bee5a7eff"
+DEPENDS = "hostperl-runtime-native"
+
SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz \
file://run-ptest \
file://openssl-c_rehash.sh \
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] openssl_1.0: drop unnecessary dependency on makedepend-native
On Tue, Jul 31, 2018 at 3:24 AM, Andrej Valek wrote: > This program is required for "oe_runmake depend" command. It runs > command in MAKEDEPPROG variable, which is set to makedepend. Makedepend > consists from makedepend-native package. That's what you might guess from casually reading the Makefile. It's not what actually happens. > Cheers, > Andrej > > On 07/31/18 12:08, Richard Purdie wrote: >> On Mon, 2018-07-30 at 18:28 -0700, Andre McCurdy wrote: >>> The openssl Configure script will only select standalone makedepend >>> (vs running "$CC -M") when building with gcc < 3.x or with an Apple >>> Xcode version which predates the switch to clang (in approx 2010?). >>> Neither of these cases are possible when building under OE, therefore >>> the dependency on makedepend-native can be dropped (ie align the >>> openssl 1.0 recipe with the 1.1 recipe, which has dropped the >>> makedepend-native dependency already). >>> >>> Signed-off-by: Andre McCurdy >>> --- >>> meta/recipes-connectivity/openssl/openssl_1.0.2o.bb | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb >>> b/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb >>> index f5d3274..78c8552 100644 >>> --- a/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb >>> +++ b/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb >>> @@ -8,7 +8,7 @@ SECTION = "libs/network" >>> LICENSE = "openssl" >>> LIC_FILES_CHKSUM = >>> "file://LICENSE;md5=f475368924827d06d4b416111c8bdb77" >>> >>> -DEPENDS = "makedepend-native hostperl-runtime-native" >>> +DEPENDS = "hostperl-runtime-native" >>> DEPENDS_append_class-target = " openssl-native" >>> >>> PROVIDES += "openssl10" >> >> This was added quite 'recently' in: >> >> http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=50c23e6c26a64b0c04e99abacb61ec00d1abace9 >> >> I've cc'd Andrej in case he can tell us why that was needed? >> >> Cheers, >> >> Richard >> -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] oe-selftest: devtool: avoid parallel races by using temporary copy of core
Some of the devtool tests make changes to files under meta/ -
legitimately since we want these tests to be working with real recipes
and associated files. Unfortunately with the new oe-selftest
parallelisation this can break other tests if files go missing at the
wrong time (among other scenarios). To avoid this issue, simply take a
copy of the core repository and use that for these tests. (We copy the
entire repository since changing the path of meta/ influences COREBASE
and thus we need to have things like scripts/ alongside as well).
Signed-off-by: Paul Eggleton
---
meta/lib/oeqa/selftest/cases/devtool.py | 64 +
1 file changed, 64 insertions(+)
diff --git a/meta/lib/oeqa/selftest/cases/devtool.py
b/meta/lib/oeqa/selftest/cases/devtool.py
index 43a66c8e283..3c1189003de 100644
--- a/meta/lib/oeqa/selftest/cases/devtool.py
+++ b/meta/lib/oeqa/selftest/cases/devtool.py
@@ -11,6 +11,70 @@ from oeqa.utils.commands import runCmd, bitbake, get_bb_var,
create_temp_layer
from oeqa.utils.commands import get_bb_vars, runqemu, get_test_layer
from oeqa.core.decorator.oeid import OETestID
+oldmetapath = None
+
+def setUpModule():
+import bb.utils
+
+global templayerdir
+templayerdir = tempfile.mkdtemp(prefix='devtoolqa')
+corecopydir = os.path.join(templayerdir, 'core-copy')
+bblayers_conf = os.path.join(os.environ['BUILDDIR'], 'conf',
'bblayers.conf')
+edited_layers = []
+
+# We need to take a copy of the meta layer so we can modify it and not
+# have any races against other tests that might be running in parallel
+# however things like COREBASE mean that you can't just copy meta, you
+# need the whole repository.
+def bblayers_edit_cb(layerpath, canonical_layerpath):
+global oldmetapath
+if not canonical_layerpath.endswith('/'):
+# This helps us match exactly when we're using this path later
+canonical_layerpath += '/'
+if not edited_layers and canonical_layerpath.endswith('/meta/'):
+edited_layers.append(layerpath)
+oldmetapath = layerpath
+result = runCmd('git rev-parse --show-toplevel',
cwd=canonical_layerpath)
+oldreporoot = result.output.rstrip()
+newmetapath = os.path.join(corecopydir,
os.path.relpath(oldmetapath, oldreporoot))
+runCmd('git clone %s %s' % (oldreporoot, corecopydir),
cwd=templayerdir)
+# Now we need to copy any modified files
+# You might ask "why not just copy the entire tree instead of
+# cloning and doing this?" - well, the problem with that is
+# TMPDIR or an equally large subdirectory might exist
+# under COREBASE and we don't want to copy that, so we have
+# to be selective.
+result = runCmd('git status --porcelain', cwd=oldreporoot)
+for line in result.output.splitlines():
+if line.startswith(' M ') or line.startswith('?? '):
+relpth = line.split()[1]
+pth = os.path.join(oldreporoot, relpth)
+if pth.startswith(canonical_layerpath):
+if relpth.endswith('/'):
+destdir = os.path.join(corecopydir, relpth)
+shutil.copytree(pth, destdir)
+else:
+destdir = os.path.join(corecopydir,
os.path.dirname(relpth))
+bb.utils.mkdirhier(destdir)
+shutil.copy2(pth, destdir)
+return newmetapath
+else:
+return layerpath
+bb.utils.edit_bblayers_conf(bblayers_conf, None, None, bblayers_edit_cb)
+
+def tearDownModule():
+if oldmetapath:
+edited_layers = []
+def bblayers_edit_cb(layerpath, canonical_layerpath):
+if not edited_layers and canonical_layerpath.endswith('/meta'):
+edited_layers.append(layerpath)
+return oldmetapath
+else:
+return layerpath
+bblayers_conf = os.path.join(os.environ['BUILDDIR'], 'conf',
'bblayers.conf')
+bb.utils.edit_bblayers_conf(bblayers_conf, None, None,
bblayers_edit_cb)
+shutil.rmtree(templayerdir)
+
class DevtoolBase(OESelftestTestCase):
@classmethod
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] util-linux.inc: add fallocate only for class-target
On Fri, 2018-07-27 at 12:05 +0100, Burton, Ross wrote: > On 27 July 2018 at 00:58, Andre McCurdy wrote: > > On Thu, Jul 26, 2018 at 4:34 PM, Burton, Ross > m> wrote: > > > On 26 July 2018 at 14:58, Ioan-Adrian Ratiu > > > wrote: > > > > Because the util-linux_2.32.bb recipe explicitely disables > > > > fallocate > > > > for nativesdk triggering build warnings: > > > > > > Does anyone know why util-linux disables fallocate for nativesdk > > > and > > > native builds? > > > > Seems to date back to this commit: > > > > http://git.openembedded.org/openembedded-core/commit/?id=17f3c548 > > caf4adec37c3bbb139aa6b3900419794 > > > > +# fallocate is glibc 2.10, fallocate64 is glibc 2.11 > > +# we need to disable it for older versions > > +EXTRA_OECONF += "ac_cv_func_fallocate=no" > > +EXTRA_OECONF_virtclass-native += "--disable-fallocate > > --disable-use-tty-group" > > Well done, it was late and I got bored following the git-blame > log. :) > > Sounds like historical reasons to me, does anyone object to dropping > this? No, I think this predates uninative... Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] vulkan-demos: upgrade to latest commit
Hi RP, On Tue, Jul 31, 2018 at 01:01:31PM +0100, richard.pur...@linuxfoundation.org wrote: > On Tue, 2018-07-31 at 12:17 +0100, Burton, Ross wrote: > > On 31 July 2018 at 11:53, Maxin B. John wrote: > > > Update subcomponents gli and glm based on the new structure of > > > repository. > > > > If they're submodules then the gitsm: fetcher should get those for > > you. > > The gitsm fetcher is broken from an archive/mirroring persective iirc > though. Using it in OE-Core by default is therefore potentially > problematic :(. Thanks for looking into this. Saw similar comments for this change (old one): https://patchwork.openembedded.org/patch/85413/ > Cheers, > > Richard Best Regards, Maxin -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] vulkan-demos: upgrade to latest commit
On Tue, 2018-07-31 at 12:17 +0100, Burton, Ross wrote: > On 31 July 2018 at 11:53, Maxin B. John wrote: > > Update subcomponents gli and glm based on the new structure of > > repository. > > If they're submodules then the gitsm: fetcher should get those for > you. The gitsm fetcher is broken from an archive/mirroring persective iirc though. Using it in OE-Core by default is therefore potentially problematic :(. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] multiconfig: Enable multiconfig dependencies on oe-core
On Mon, 2018-07-30 at 15:05 -0700, Alejandro Enedino Hernandez Samaniego wrote: > On 07/26/2018 08:36 PM, Khem Raj wrote: > > > > On 7/25/18 9:05 AM, Alejandro Enedino Hernandez Samaniego wrote: > > > This patch enables multiconfig dependencies (mcdepends) to be > > > used on > > > recipes using the following format: > > > > > > task[mcdepends] = "multiconfig:FROM-MC:TO-MC:PN:task-to-depend- > > > on" > > > > > > For the sake of simplicity consider the following example: > > > > > > Assuming we have set up multiconfig builds, one for qemux86 and > > > one for > > > qemuarm, named x86 and arm respectively. > > > > > > Adding the following line to an image recipe (core-image-sato): > > > do_image[mcdepends] = "multiconfig:x86:arm:core-image- > > > minimal:do_rootfs" > > > > > > > Do we really need to add multiconfig to keyword namespace ? can we > > deduce this from "arch1:arch2:..." > > Bitbake already uses this and I believed adopting it would make it > easier for the user to understand its usage. > > For example, since the multiconfig names are also provided during > setup, if you assume that someone set up the build and a different > user is going through the recipe, arch1:arch2 wouldn't mean a lot for > that user because they may not map 1:1 to MACHINE names. It is consistent with the rest of the system. I'm still torn on whether we should shorten "multiconfig:" to "mc:" but we need to be consistent. > > secondy, this need to be well documented, with examples for users > > I agree we could add more documentation to it, where do you think it > should go? I'm going to queue the patches for testing in -next, they look good to me just reading the patches. Could you start to work with Scott (cc'd) to get this new dependency type listed in the bitbake manual and anywhere else it needs to be documented? Its great to see this finally working! Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] vulkan-demos: upgrade to latest commit
On 31 July 2018 at 11:53, Maxin B. John wrote: > Update subcomponents gli and glm based on the new structure of > repository. If they're submodules then the gitsm: fetcher should get those for you. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 8/8] [PATCH v2] meta-toolchain: Added dnf-nativesdk into cross-development toolchain.
On Tue, 2018-07-31 at 02:18 +, Zheng, Ruoqin wrote: > Hi Richard > > eSDK is actually a better technique for developers. But it’s > only suitable for those people who has experience on Yocto Project. Remember that the eSDK can function just like the SDK. You can use more of its tools but you don't have to. > In the other hand, using dnf-nativesdk in meta-toolchain to > customize rootfs is easier fot those people who are familiar with > dnf(I think most linux user known it). Why not add some dnf like wrappers around the eSDK though? We have tools like devtool and recipetool but there is a lot of potential to add a simpler interface to enable these "customise rootfs" type of workflows. > For example, developers finish the OSS build work and provide > the toolchain and packages to users. In this case, users do not need > to know any knowledge about yocto build system but just how to use > dnf to install a rootfs. > > So it can reduce the workload of end-users who need to > customize rootfs for their embedded device. At lease, they don’t need > to maintain a yocto build server. The eSDK behaves very much like the SDK and then you have access to whichever tools the eSDK is providing, all the way up to the full build system but only if you need that. I still think there is the option of providing some simpler tooling to the eSDK which would work for the kinds of users you're talking about. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [oe-core][PATCH] poky-lsb: security_flags.inc
To fix the following error, we append '-O' to the defination of _FORTIFY_SOURCE
recipe-sysroot/usr/include/features.h:381:4: error: #warning _FORTIFY_SOURCE
requires compiling with optimization (-O) [-Werror=cpp]
# warning _FORTIFY_SOURCE requires compiling with optimization (-O)
^~~
Signed-off-by: Hongzhi.Song
---
meta/conf/distro/include/security_flags.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/distro/include/security_flags.inc
b/meta/conf/distro/include/security_flags.inc
index 6245e89ada..1c32fd3165 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -10,7 +10,7 @@ GCCPIE ?= "--enable-default-pie"
# _FORTIFY_SOURCE requires -O1 or higher, so disable in debug builds as they
use
# -O0 which then results in a compiler warning.
-lcl_maybe_fortify =
"${@oe.utils.conditional('DEBUG_BUILD','1','','-D_FORTIFY_SOURCE=2',d)}"
+lcl_maybe_fortify =
"${@oe.utils.conditional('DEBUG_BUILD','1','','-D_FORTIFY_SOURCE=2 -O',d)}"
# Error on use of format strings that represent possible security problems
SECURITY_STRINGFORMAT ?= "-Wformat -Wformat-security -Werror=format-security"
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core] INCOMPATIBLE_LICENSE mechanism
On Thursday, 26 July 2018 5:14:05 PM BST Richard Purdie wrote: > On Thu, 2018-07-26 at 13:16 +, Peter Kjellerstedt wrote: > > This is related to a similar problem we are seeing with the use of > > “or” for licenses. We use the archiver.bbclass to export all open > > source code we use. However, for recipes that specify multiple > > licenses using “or”, we would like to specify the one under which we > > are using the code. E.g., if the LICENSE is “GPL-2.0 | Proprietary”, > > we would like to treat the code as “Proprietary”, but when it comes > > to the archiver.bbclass, even if we have told it to ignore packages > > with Proprietary licenses, it will include the package due to the > > alternative GPL-2.0 license. > > > > The idea we have is to allow to specify a USED_LICENSE (e.g., in a > > bbappend or a separate configuration file), which should take the > > actually used license. This should be verified to be one of the > > allowed licenses specified in LICENSE (in case LICENSE changes and no > > longer allows the chosen license), and after that, LICENSE should be > > treated as if this was the value it had been given. This does, > > however, not take into account the use of the same package in > > multiple images with different licensing requirements (we only build > > one image so that is not a problem for us). > > Just thinking out loud you could have something like a > > gplv3-license-incompatible.inc: > > LICENSE_pn- = "MIT" > LICENSE_pn- = "GPLv2" > INCOMPATIBLE_LICENSE = "GPLv3" That was my first thought, but the issue is that you won't get any warning in future if the LICENSE value within the recipe changes to no longer provide the option you've selected. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] vulkan-demos: upgrade to latest commit
Remove upstreamed patches: 1. 0001-Fix-build-on-x86.patch 2. 0001-Support-installing-demos-support-out-of-tree-builds.patch Updated the following patch: 1. 0001-Don-t-build-demos-with-questionably-licensed-data.patch Update subcomponents gli and glm based on the new structure of repository. License-Update: Update in location of file. No change in checksum Signed-off-by: Maxin B. John --- ...ild-demos-with-questionably-licensed-data.patch | 51 +++-- .../vulkan-demos/0001-Fix-build-on-x86.patch | 41 --- ...stalling-demos-support-out-of-tree-builds.patch | 85 -- meta/recipes-graphics/vulkan/vulkan-demos_git.bb | 11 ++- 4 files changed, 36 insertions(+), 152 deletions(-) delete mode 100644 meta/recipes-graphics/vulkan/vulkan-demos/0001-Fix-build-on-x86.patch delete mode 100644 meta/recipes-graphics/vulkan/vulkan-demos/0001-Support-installing-demos-support-out-of-tree-builds.patch diff --git a/meta/recipes-graphics/vulkan/vulkan-demos/0001-Don-t-build-demos-with-questionably-licensed-data.patch b/meta/recipes-graphics/vulkan/vulkan-demos/0001-Don-t-build-demos-with-questionably-licensed-data.patch index d32c8f2..93bcfbf 100644 --- a/meta/recipes-graphics/vulkan/vulkan-demos/0001-Don-t-build-demos-with-questionably-licensed-data.patch +++ b/meta/recipes-graphics/vulkan/vulkan-demos/0001-Don-t-build-demos-with-questionably-licensed-data.patch @@ -1,6 +1,6 @@ -From 55770fb07c42fe410cf8d09f8f5976babc89b9ef Mon Sep 17 00:00:00 2001 -From: Jussi Kukkonen -Date: Tue, 4 Jul 2017 17:13:45 +0300 +From 0a27144d43b70121f57f6036514d069ca9d2b971 Mon Sep 17 00:00:00 2001 +From: "Maxin B. John" +Date: Mon, 30 Jul 2018 17:23:29 +0300 Subject: [PATCH] Don't build demos with questionably licensed data Some of the models don't have open source compatible licenses: @@ -9,43 +9,46 @@ resources that are not included. ssao: scenerendering: - Sibenik model, no license found +Sibenik model, no license found deferred: deferredmultisampling: deferredshadows: - armor model, CC-BY-3.0 +armor model, CC-BY-3.0 vulkanscene: imgui: shadowmapping: - vulkanscene model, no license found +vulkanscene model, no license found indirectdraw: - plant model, no license found +plant model, no license found hdr: pbribl: pbrtexture: - Require external Vulkan Asset Pack +Require external Vulkan Asset Pack Upstream-Status: Inappropriate [configuration] + Signed-off-by: Jussi Kukkonen +Signed-off-by: Maxin B. John --- - CMakeLists.txt | 13 - - 1 file changed, 13 deletions(-) + examples/CMakeLists.txt | 14 -- + 1 file changed, 14 deletions(-) -diff --git a/CMakeLists.txt b/CMakeLists.txt -index 4958fff..0f9d3e4 100644 a/CMakeLists.txt -+++ b/CMakeLists.txt -@@ -150,17 +150,11 @@ set(EXAMPLES - computeparticles +diff --git a/examples/CMakeLists.txt b/examples/CMakeLists.txt +index 8eee3a4..698d3b3 100644 +--- a/examples/CMakeLists.txt b/examples/CMakeLists.txt +@@ -47,18 +47,12 @@ set(EXAMPLES computeshader + conservativeraster debugmarker - deferred - deferredmultisampling - deferredshadows + descriptorsets displacement distancefieldfonts dynamicuniformbuffer @@ -53,32 +56,36 @@ index 4958fff..0f9d3e4 100644 geometryshader - hdr - imgui -- indirectdraw +- indirectdraw + inputattachments instancing mesh - multisampling -@@ -170,20 +164,14 @@ set(EXAMPLES +@@ -70,8 +64,6 @@ set(EXAMPLES parallaxmapping particlefire pbrbasic - pbribl - pbrtexture pipelines + pipelinestatistics pushconstants +@@ -79,15 +71,10 @@ set(EXAMPLES radialblur raytracing + renderheadless - scenerendering screenshot - shadowmapping - shadowmappingomni +- shadowmappingcascade skeletalanimation specializationconstants sphericalenvmapping - ssao + stencilbuffer subpasses terraintessellation - tessellation -@@ -196,7 +184,6 @@ set(EXAMPLES +@@ -101,7 +88,6 @@ set(EXAMPLES texturesparseresidency triangle viewportarray @@ -87,5 +94,5 @@ index 4958fff..0f9d3e4 100644 buildExamples() -- -2.13.2 +2.4.0 diff --git a/meta/recipes-graphics/vulkan/vulkan-demos/0001-Fix-build-on-x86.patch b/meta/recipes-graphics/vulkan/vulkan-demos/0001-Fix-build-on-x86.patch deleted file mode 100644 index 681b342..000 --- a/meta/recipes-graphics/vulkan/vulkan-demos/0001-Fix-build-on-x86.patch +++ /dev/null @@ -1,41 +0,0 @@ -From b0495efb6c3ea3a530fcbaddac86da57ecce5a66 Mon Sep 17 00:00:00 2001 -From: Jussi Kukkonen -Date: Mon, 10 Jul 2017 13:11:12 +0300 -Subject: [PATCH] Fix build on x86 -MIME-Version: 1.0 -Content-Type: text/plain; charset=UTF-8
[OE-core] [PATCH 1/2] vulkan: upgrade to version 1.1.73.0
Refresh the patch:
demos-Don-t-build-tri-or-cube.patch
License-Update: Updates in copyright information.
Signed-off-by: Maxin B. John
---
.../vulkan/demos-Don-t-build-tri-or-cube.patch | 110 -
.../{vulkan_1.0.65.2.bb => vulkan_1.1.73.0.bb} | 7 +-
2 files changed, 69 insertions(+), 48 deletions(-)
rename meta/recipes-graphics/vulkan/{vulkan_1.0.65.2.bb => vulkan_1.1.73.0.bb}
(88%)
diff --git
a/meta/recipes-graphics/vulkan/vulkan/demos-Don-t-build-tri-or-cube.patch
b/meta/recipes-graphics/vulkan/vulkan/demos-Don-t-build-tri-or-cube.patch
index bcf84a5..b0b9fc4 100644
--- a/meta/recipes-graphics/vulkan/vulkan/demos-Don-t-build-tri-or-cube.patch
+++ b/meta/recipes-graphics/vulkan/vulkan/demos-Don-t-build-tri-or-cube.patch
@@ -1,21 +1,30 @@
-commit f63cbe944107b5cd8f150ceaaec43b26099d5688
+From 9b13be109bc66f4d4a1ad53ce5c92c7c495e41d7 Mon Sep 17 00:00:00 2001
+From: "Maxin B. John"
+Date: Tue, 24 Jul 2018 17:40:52 +0300
+Subject: [PATCH] commit f63cbe944107b5cd8f150ceaaec43b26099d5688
+
Author: Adam Jackson
Date: Tue Feb 16 10:05:25 2016 -0500
-demos: Don't build tri or cube
-
-There are more interesting demos, all we really want here is vulkaninfo.
-This helps because we don't need to pre-build glslang/llvm/lunarglass
-just to get the loader and layers.
+demos: Don't build tri or cube
+
+There are more interesting demos, all we really want here is vulkaninfo.
+This helps because we don't need to pre-build glslang/llvm/lunarglass
+just to get the loader and layers.
Upstream-Status: Inappropriate [configuration]
+
Signed-off-by: Jussi Kukkonen
+Signed-off-by: Maxin B. John
+---
+ demos/CMakeLists.txt | 88
+ 1 file changed, 88 deletions(-)
-Index: git/demos/CMakeLists.txt
-===
git.orig/demos/CMakeLists.txt
-+++ git/demos/CMakeLists.txt
-@@ -63,46 +63,6 @@ elseif(UNIX)
+diff --git a/demos/CMakeLists.txt b/demos/CMakeLists.txt
+index 4f32679..26e4cdf 100644
+--- a/demos/CMakeLists.txt
b/demos/CMakeLists.txt
+@@ -93,42 +93,6 @@ elseif(UNIX)
else()
endif()
@@ -37,38 +46,40 @@ Index: git/demos/CMakeLists.txt
-endif()
-endforeach()
-
--add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/demos/cube-vert.spv
-- COMMAND ${GLSLANG_VALIDATOR} -s -V -o
${CMAKE_BINARY_DIR}/demos/cube-vert.spv ${PROJECT_SOURCE_DIR}/demos/cube.vert
-- DEPENDS cube.vert ${GLSLANG_VALIDATOR}
-- )
--add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/demos/cube-frag.spv
-- COMMAND ${GLSLANG_VALIDATOR} -s -V -o
${CMAKE_BINARY_DIR}/demos/cube-frag.spv ${PROJECT_SOURCE_DIR}/demos/cube.frag
-- DEPENDS cube.frag ${GLSLANG_VALIDATOR}
-- )
- file(COPY cube.vcxproj.user DESTINATION ${CMAKE_BINARY_DIR}/demos)
- file(COPY vulkaninfo.vcxproj.user DESTINATION ${CMAKE_BINARY_DIR}/demos)
--else()
--if (${CMAKE_SYSTEM_PROCESSOR} STREQUAL ${CMAKE_HOST_SYSTEM_PROCESSOR})
--add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/demos/cube-vert.spv
--COMMAND ${GLSLANG_VALIDATOR} -s -V -o cube-vert.spv
${PROJECT_SOURCE_DIR}/demos/cube.vert
--DEPENDS cube.vert ${GLSLANG_VALIDATOR}
--)
--add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/demos/cube-frag.spv
--COMMAND ${GLSLANG_VALIDATOR} -s -V -o cube-frag.spv
${PROJECT_SOURCE_DIR}/demos/cube.frag
--DEPENDS cube.frag ${GLSLANG_VALIDATOR}
--)
--endif()
-endif()
+-
+-add_custom_command(
+-COMMENT "Compiling cube demo vertex shader"
+-OUTPUT cube.vert.inc
+-COMMAND ${GLSLANG_VALIDATOR} -V -x -o
${CMAKE_CURRENT_BINARY_DIR}/cube.vert.inc ${PROJECT_SOURCE_DIR}/demos/cube.vert
+-MAIN_DEPENDENCY ${PROJECT_SOURCE_DIR}/demos/cube.vert
+-DEPENDS ${PROJECT_SOURCE_DIR}/demos/cube.vert ${GLSLANG_VALIDATOR}
+-)
+-add_custom_command(
+-COMMENT "Compiling cube demo fragment shader"
+-OUTPUT cube.frag.inc
+-COMMAND ${GLSLANG_VALIDATOR} -V -x -o
${CMAKE_CURRENT_BINARY_DIR}/cube.frag.inc ${PROJECT_SOURCE_DIR}/demos/cube.frag
+-MAIN_DEPENDENCY ${PROJECT_SOURCE_DIR}/demos/cube.frag
+-DEPENDS ${PROJECT_SOURCE_DIR}/demos/cube.frag ${GLSLANG_VALIDATOR}
+-)
- if(WIN32)
- include_directories (
-@@ -116,43 +76,6 @@ endif()
- add_executable(${API_LOWERCASE}info vulkaninfo.c)
- target_link_libraries(${API_LOWERCASE}info ${LIBRARIES})
+ include_directories(${CMAKE_CURRENT_BINARY_DIR})
--if(NOT WIN32)
+@@ -172,55 +136,3 @@ if(${CMAKE_SYSTEM_NAME} STREQUAL "Linux")
+ install(TARGETS ${API_LOWERCASE}info DESTINATION
${CMAKE_INSTALL_BINDIR})
+ endif()
+ endif()
+-
+-##
+-# cube
+-
+-if(APPLE)
+-include(macOS/cube/cube.cmake)
+-elseif(NOT WIN32)
-if (${CMAKE_SYSTEM_PROCESSOR} STREQUAL ${CMAKE_HOST_SYSTEM_PROCESSOR})
--
Re: [OE-core] [PATCH] openssl_1.0: drop unnecessary dependency on makedepend-native
This program is required for "oe_runmake depend" command. It runs command in MAKEDEPPROG variable, which is set to makedepend. Makedepend consists from makedepend-native package. Cheers, Andrej On 07/31/18 12:08, Richard Purdie wrote: > On Mon, 2018-07-30 at 18:28 -0700, Andre McCurdy wrote: >> The openssl Configure script will only select standalone makedepend >> (vs running "$CC -M") when building with gcc < 3.x or with an Apple >> Xcode version which predates the switch to clang (in approx 2010?). >> Neither of these cases are possible when building under OE, therefore >> the dependency on makedepend-native can be dropped (ie align the >> openssl 1.0 recipe with the 1.1 recipe, which has dropped the >> makedepend-native dependency already). >> >> Signed-off-by: Andre McCurdy >> --- >> meta/recipes-connectivity/openssl/openssl_1.0.2o.bb | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb >> b/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb >> index f5d3274..78c8552 100644 >> --- a/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb >> +++ b/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb >> @@ -8,7 +8,7 @@ SECTION = "libs/network" >> LICENSE = "openssl" >> LIC_FILES_CHKSUM = >> "file://LICENSE;md5=f475368924827d06d4b416111c8bdb77" >> >> -DEPENDS = "makedepend-native hostperl-runtime-native" >> +DEPENDS = "hostperl-runtime-native" >> DEPENDS_append_class-target = " openssl-native" >> >> PROVIDES += "openssl10" > > This was added quite 'recently' in: > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=50c23e6c26a64b0c04e99abacb61ec00d1abace9 > > I've cc'd Andrej in case he can tell us why that was needed? > > Cheers, > > Richard > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] openssl_1.0: drop unnecessary dependency on makedepend-native
On Mon, 2018-07-30 at 18:28 -0700, Andre McCurdy wrote: > The openssl Configure script will only select standalone makedepend > (vs running "$CC -M") when building with gcc < 3.x or with an Apple > Xcode version which predates the switch to clang (in approx 2010?). > Neither of these cases are possible when building under OE, therefore > the dependency on makedepend-native can be dropped (ie align the > openssl 1.0 recipe with the 1.1 recipe, which has dropped the > makedepend-native dependency already). > > Signed-off-by: Andre McCurdy > --- > meta/recipes-connectivity/openssl/openssl_1.0.2o.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb > b/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb > index f5d3274..78c8552 100644 > --- a/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb > +++ b/meta/recipes-connectivity/openssl/openssl_1.0.2o.bb > @@ -8,7 +8,7 @@ SECTION = "libs/network" > LICENSE = "openssl" > LIC_FILES_CHKSUM = > "file://LICENSE;md5=f475368924827d06d4b416111c8bdb77" > > -DEPENDS = "makedepend-native hostperl-runtime-native" > +DEPENDS = "hostperl-runtime-native" > DEPENDS_append_class-target = " openssl-native" > > PROVIDES += "openssl10" This was added quite 'recently' in: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=50c23e6c26a64b0c04e99abacb61ec00d1abace9 I've cc'd Andrej in case he can tell us why that was needed? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] test-result-log: testcase management tool to store and view test result
Hi Richard & Paul & Ross, As per our conversation in the past, there was a need to provide alternative testcase management tool to Testopia in order to achieve our goals of: 1) To unblocked Bugzilla upgrade to a newer version in order to receive the improvement in WebServices, performance, and GUI. 2) To improve overall QA testing efficiency where it reduce maintenance cost when Testopia need to manually synchronize the test case content between Testopia and the available automated test cases inside OEQA, also it minimize test execution rerun where someone need to retrieve test failure log information from previous QA cycle (Testopia does not store test log due to its limitation on Testopia API for automation). To provide alternative testcase management tool to Testopia, here was the first batch of patch target to enable storing test result for OEQA automated testcase execution and view test summary report. There are another patch planned to enable manual test execution and store/view test result. Please review this patch and provide us your valuable inputs and feedbacks. Thank you very much for your attention! Best regards, Yeoh Ee Peng -Original Message- From: Yeoh, Ee Peng Sent: Tuesday, July 31, 2018 5:23 PM To: openembedded-core@lists.openembedded.org Cc: Yeoh, Ee Peng Subject: [PATCH] test-result-log: testcase management tool to store and view test result These scripts were developed as an alternative testcase management tool to Testopia. Using these scripts, user can store test result from OEQA automated testcase execution and view the test report. These scripts will store test result & log in GIT repository and show text-based summary report. To use these scripts, first source oe environment, then run the entry point script to look for help information. $ test-result-log To store test result for OEQA automated testcase, execute the below $ test-result-log store-auto / To view summary test report, execute the below $ test-result-log view Signed-off-by: Yeoh Ee Peng --- scripts/lib/testresultlog/gitstore.py | 387 + scripts/lib/testresultlog/oeqalogparser.py | 97 ++ scripts/lib/testresultlog/oeqatestdiscover.py | 65 scripts/lib/testresultlog/storeauto.py | 122 +++ .../template/test_report_full_text.txt | 33 ++ .../test_report_include_idle_full_text.txt | 33 ++ scripts/lib/testresultlog/view.py | 198 +++ scripts/test-result-log| 84 + 8 files changed, 1019 insertions(+) create mode 100644 scripts/lib/testresultlog/gitstore.py create mode 100644 scripts/lib/testresultlog/oeqalogparser.py create mode 100644 scripts/lib/testresultlog/oeqatestdiscover.py create mode 100644 scripts/lib/testresultlog/storeauto.py create mode 100644 scripts/lib/testresultlog/template/test_report_full_text.txt create mode 100644 scripts/lib/testresultlog/template/test_report_include_idle_full_text.txt create mode 100644 scripts/lib/testresultlog/view.py create mode 100755 scripts/test-result-log diff --git a/scripts/lib/testresultlog/gitstore.py b/scripts/lib/testresultlog/gitstore.py new file mode 100644 index 000..67f2749 --- /dev/null +++ b/scripts/lib/testresultlog/gitstore.py @@ -0,0 +1,387 @@ +import tempfile +import os +import pathlib +import json +import subprocess +import shutil +import scriptpath +scriptpath.add_bitbake_lib_path() +scriptpath.add_oe_lib_path() +from oeqa.utils.git import GitRepo, GitError + +class GitStore(object): + +def __init__(self): +self.script_path = os.path.dirname(os.path.realpath(__file__)) +self.base_path = self.script_path + '/../../..' + +def _create_temporary_workspace_dir(self): +return tempfile.mkdtemp(prefix='testresultlog.') + +def _remove_temporary_workspace_dir(self, workspace_dir): +return subprocess.run(["rm", "-rf", workspace_dir]) + +def _get_project_environment_directory_path(self, project_dir, test_environment_list): +project_env_dir = project_dir +for env in test_environment_list: +project_env_dir = os.path.join(project_env_dir, env) +return project_env_dir + +def _get_testmodule_list(self, testmodule_testsuite_dict): +return sorted(list(testmodule_testsuite_dict.keys())) + +def _get_testcase_list(self, testsuite_list, testsuite_testcase_dict): +testcase_list = [] +for testsuite in sorted(testsuite_list): +if testsuite in testsuite_testcase_dict: +for testcase in testsuite_testcase_dict[testsuite]: +testcase_list.append(testcase) +return testcase_list + +def _get_testcase_status(self, testcase, testcase_status_dict): +if testcase in testcase_status_dict: +return testcase_status_dict[testcase] +return "" + +def
[OE-core] [PATCH] test-result-log: testcase management tool to store and view test result
These scripts were developed as an alternative testcase management
tool to Testopia. Using these scripts, user can store test result
from OEQA automated testcase execution and view the test report.
These scripts will store test result & log in GIT repository and
show text-based summary report. To use these scripts, first source
oe environment, then run the entry point script to look for help
information.
$ test-result-log
To store test result for OEQA automated testcase, execute the below
$ test-result-log store-auto /
To view summary test report, execute the below
$ test-result-log view
Signed-off-by: Yeoh Ee Peng
---
scripts/lib/testresultlog/gitstore.py | 387 +
scripts/lib/testresultlog/oeqalogparser.py | 97 ++
scripts/lib/testresultlog/oeqatestdiscover.py | 65
scripts/lib/testresultlog/storeauto.py | 122 +++
.../template/test_report_full_text.txt | 33 ++
.../test_report_include_idle_full_text.txt | 33 ++
scripts/lib/testresultlog/view.py | 198 +++
scripts/test-result-log| 84 +
8 files changed, 1019 insertions(+)
create mode 100644 scripts/lib/testresultlog/gitstore.py
create mode 100644 scripts/lib/testresultlog/oeqalogparser.py
create mode 100644 scripts/lib/testresultlog/oeqatestdiscover.py
create mode 100644 scripts/lib/testresultlog/storeauto.py
create mode 100644 scripts/lib/testresultlog/template/test_report_full_text.txt
create mode 100644
scripts/lib/testresultlog/template/test_report_include_idle_full_text.txt
create mode 100644 scripts/lib/testresultlog/view.py
create mode 100755 scripts/test-result-log
diff --git a/scripts/lib/testresultlog/gitstore.py
b/scripts/lib/testresultlog/gitstore.py
new file mode 100644
index 000..67f2749
--- /dev/null
+++ b/scripts/lib/testresultlog/gitstore.py
@@ -0,0 +1,387 @@
+import tempfile
+import os
+import pathlib
+import json
+import subprocess
+import shutil
+import scriptpath
+scriptpath.add_bitbake_lib_path()
+scriptpath.add_oe_lib_path()
+from oeqa.utils.git import GitRepo, GitError
+
+class GitStore(object):
+
+def __init__(self):
+self.script_path = os.path.dirname(os.path.realpath(__file__))
+self.base_path = self.script_path + '/../../..'
+
+def _create_temporary_workspace_dir(self):
+return tempfile.mkdtemp(prefix='testresultlog.')
+
+def _remove_temporary_workspace_dir(self, workspace_dir):
+return subprocess.run(["rm", "-rf", workspace_dir])
+
+def _get_project_environment_directory_path(self, project_dir,
test_environment_list):
+project_env_dir = project_dir
+for env in test_environment_list:
+project_env_dir = os.path.join(project_env_dir, env)
+return project_env_dir
+
+def _get_testmodule_list(self, testmodule_testsuite_dict):
+return sorted(list(testmodule_testsuite_dict.keys()))
+
+def _get_testcase_list(self, testsuite_list, testsuite_testcase_dict):
+testcase_list = []
+for testsuite in sorted(testsuite_list):
+if testsuite in testsuite_testcase_dict:
+for testcase in testsuite_testcase_dict[testsuite]:
+testcase_list.append(testcase)
+return testcase_list
+
+def _get_testcase_status(self, testcase, testcase_status_dict):
+if testcase in testcase_status_dict:
+return testcase_status_dict[testcase]
+return ""
+
+def _create_testcase_dict(self, testcase_list, testcase_status_dict):
+testcase_dict = {}
+for testcase in sorted(testcase_list):
+#testcase_key = '%s.%s' % (testsuite_name, testcase)
+testcase_status = self._get_testcase_status(testcase,
testcase_status_dict)
+testcase_dict[testcase] = {"testresult": testcase_status,"bugs":
""}
+#print('DEBUG: testcase_dict: %s' % testcase_dict)
+return testcase_dict
+
+def _create_testsuite_testcase_teststatus_json_object(self,
testsuite_list, testsuite_testcase_dict, testcase_status_dict):
+#print('DEBUG: creating testsuite testcase for testsuite list: %s' %
testsuite_list)
+json_object = {'testsuite':{}}
+testsuite_dict = json_object['testsuite']
+for testsuite in sorted(testsuite_list):
+testsuite_dict[testsuite] = {'testcase': {}}
+#print('DEBUG: testsuite: %s' % testsuite)
+#print('DEBUG: testsuite_testcase_dict[testsuite]: %s' %
testsuite_testcase_dict[testsuite])
+testsuite_dict[testsuite]['testcase'] =
self._create_testcase_dict(testsuite_testcase_dict[testsuite],
testcase_status_dict)
+return json_object
+
+def _create_testsuite_json_formatted_string(self, testsuite_list,
testsuite_testcase_dict, testcase_status_dict):
+testsuite_testcase_list =
Re: [OE-core] Is a dependency on hostperl-runtime-native actually useful?
On Mon, 2018-07-30 at 18:06 -0700, Andre McCurdy wrote: > On Mon, Jul 30, 2018 at 3:23 PM, Richard Purdie > wrote: > > On Mon, 2018-07-30 at 14:44 -0700, Andre McCurdy wrote: > > > Currently the openssl 1.0 recipe defines a dependency on > > > hostperl-runtime-native and the openssl 1.1 recipe does not. Both > > > run > > > "perl ./Configure ..." as part of do_configure(). > > > > > > Since hostperl-runtime-native is included in ASSUME_PROVIDED, is > > > it > > > really useful for the openssl 1.0 recipe to list it in DEPENDS? > > > > > > ie is the openssl 1.0 recipe being unnecessarily complex or is > > > the > > > openssl 1.1 recipe being too simplistic? > > > > It is useful for things to list their dependencies and we did have > > an > > effort to actually list things out so we know ASSUME_PROVIDED is > > correct. This means we can spot areas we might be able to trim back > > dependencies (amongst other reasons). > > > > With the introduction of HOSTTOOLS, its perhaps less needed than it > > was > > but in principle it is still useful to know which things need a > > given > > item, particularly where its more unusual. I'd still be interested > > in > > trying to cut back HOSTTOOLS a bit more. > > > > The 1.1 recipe was pretty heavily cut back, probably too much so > > based > > on some of the patches we've been getting... > > Thanks. Is there an obvious reason why both recipes shouldn't be > using perl-native rather than hostperl-runtime-native? Building with > perl-native seems to work fine. Build time overhead. openssl-native is one of the early dependencies (or it certainly used to be due to git-native before we ASSUME_PROVIDED it). Allowing openssl-native to use host perl cut down build time significantly. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/4] systemd: backport patch to allow setting dbus calls timeout
On 07/31/2018 03:13 PM, Chen Qi wrote:
Backport 0001-sd-bus-make-BUS_DEFAULT_TIMEOUT-configurable.patch
which allows setting dbus calls timeout via BUS_DEFAULT_TIMEOUT
environment variable.
The environment variable's name is actually SYSTEMD_BUS_TIMEOUT.
I've fixed the commit message and updated the remote repo.
This is needed as we are meeting timeout failures from the oeqa
runtime test case systemd.py.
Signed-off-by: Chen Qi
---
...bus-make-BUS_DEFAULT_TIMEOUT-configurable.patch | 175 +
meta/recipes-core/systemd/systemd_239.bb | 1 +
2 files changed, 176 insertions(+)
create mode 100644
meta/recipes-core/systemd/systemd/0001-sd-bus-make-BUS_DEFAULT_TIMEOUT-configurable.patch
diff --git
a/meta/recipes-core/systemd/systemd/0001-sd-bus-make-BUS_DEFAULT_TIMEOUT-configurable.patch
b/meta/recipes-core/systemd/systemd/0001-sd-bus-make-BUS_DEFAULT_TIMEOUT-configurable.patch
new file mode 100644
index 000..45c9b5b
--- /dev/null
+++
b/meta/recipes-core/systemd/systemd/0001-sd-bus-make-BUS_DEFAULT_TIMEOUT-configurable.patch
@@ -0,0 +1,175 @@
+From 5b75a72ee968c9666b5f2ea313720b6c383cb4c2 Mon Sep 17 00:00:00 2001
+From: Yu Watanabe
+Date: Fri, 13 Jul 2018 17:38:47 +0900
+Subject: [PATCH] sd-bus: make BUS_DEFAULT_TIMEOUT configurable
+
+This adds sd_bus_{get,set}_method_call_timeout().
+If the timeout is not set or set to 0, then the timeout value is
+parsed from $SYSTEMD_BUS_TIMEOUT= environment variable. If the
+environment variable is not set, then built-in timeout is used.
+---
+ doc/ENVIRONMENT.md | 5 +
+ src/libsystemd/libsystemd.sym| 5 +
+ src/libsystemd/sd-bus/bus-internal.h | 9
+ src/libsystemd/sd-bus/bus-message.c | 7 +--
+ src/libsystemd/sd-bus/sd-bus.c | 40 ++--
+ src/systemd/sd-bus.h | 3 +++
+ 6 files changed, 61 insertions(+), 8 deletions(-)
+
+Upstream-Status: Backport
+
+Signed-off-by: Chen Qi
+
+diff --git a/doc/ENVIRONMENT.md b/doc/ENVIRONMENT.md
+index 85d26fe28c..641a03d5d7 100644
+--- a/doc/ENVIRONMENT.md
b/doc/ENVIRONMENT.md
+@@ -37,6 +37,11 @@ All tools:
+ useful for debugging, in order to test generators and other code against
+ specific kernel command lines.
+
++* `$SYSTEMD_BUS_TIMEOUT=SECS` — specifies the maximum time to wait for method
call
++ completion. If no time unit is specified, assumes seconds. The usual other
units
++ are understood, too (us, ms, s, min, h, d, w, month, y). If it is not set
or set
++ to 0, then the built-in default is used.
++
+ systemctl:
+
+ * `$SYSTEMCTL_FORCE_BUS=1` — if set, do not connect to PID1's private D-Bus
+diff --git a/src/libsystemd/libsystemd.sym b/src/libsystemd/libsystemd.sym
+index 1eec17db50..006dbc9c3f 100644
+--- a/src/libsystemd/libsystemd.sym
b/src/libsystemd/libsystemd.sym
+@@ -570,3 +570,8 @@ global:
+ sd_event_source_set_destroy_callback;
+ sd_event_source_get_destroy_callback;
+ } LIBSYSTEMD_238;
++
++LIBSYSTEMD_240 {
++sd_bus_set_method_call_timeout;
++sd_bus_get_method_call_timeout;
++} LIBSYSTEMD_239;
+diff --git a/src/libsystemd/sd-bus/bus-internal.h
b/src/libsystemd/sd-bus/bus-internal.h
+index 2087ef8eeb..4864b1e911 100644
+--- a/src/libsystemd/sd-bus/bus-internal.h
b/src/libsystemd/sd-bus/bus-internal.h
+@@ -319,6 +319,9 @@ struct sd_bus {
+
+ int *inotify_watches;
+ size_t n_inotify_watches;
++
++/* zero means use value specified by $SYSTEMD_BUS_TIMEOUT=
environment variable or built-in default */
++usec_t method_call_timeout;
+ };
+
+ /* For method calls we time-out at 25s, like in the D-Bus reference
implementation */
+@@ -336,8 +339,7 @@ struct sd_bus {
+
+ #define BUS_CONTAINER_DEPTH 128
+
+-/* Defined by the specification as maximum size of an array in
+- * bytes */
++/* Defined by the specification as maximum size of an array in bytes */
+ #define BUS_ARRAY_MAX_SIZE 67108864
+
+ #define BUS_FDS_MAX 1024
+@@ -388,8 +390,7 @@ void bus_close_io_fds(sd_bus *b);
+ _slash = streq((prefix), "/") ? NULL : strrchr((prefix), '/'))
+
+ /* If we are invoking callbacks of a bus object, ensure unreffing the
+- * bus from the callback doesn't destroy the object we are working
+- * on */
++ * bus from the callback doesn't destroy the object we are working on */
+ #define BUS_DONT_DESTROY(bus) \
+ _cleanup_(sd_bus_unrefp) _unused_ sd_bus *_dont_destroy_##bus =
sd_bus_ref(bus)
+
+diff --git a/src/libsystemd/sd-bus/bus-message.c
b/src/libsystemd/sd-bus/bus-message.c
+index 8d92bc2002..dffe70a665 100644
+--- a/src/libsystemd/sd-bus/bus-message.c
b/src/libsystemd/sd-bus/bus-message.c
+@@ -5809,8 +5809,11 @@ int bus_message_remarshal(sd_bus *bus, sd_bus_message
**m) {
+ return r;
+
+ timeout = (*m)->timeout;
+-if (timeout == 0 && !((*m)->header->flags &
BUS_MESSAGE_NO_REPLY_EXPECTED))
+-timeout =
Re: [OE-core] [PATCH v2] cross-canadian/libgcc: fix aarch64's multilib SDK
> Please test this patch with musl target preferably arm/aarch64 and also
> ppc/glibc by generating SDKs
Ok, I'll test it.
Best regards.
Lei
> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: Friday, July 27, 2018 11:31 AM
> To: Robert Yang; Lei, Maohui; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH v2] cross-canadian/libgcc: fix aarch64's
> multilib
> SDK
>
>
>
> On 7/25/18 1:04 AM, Robert Yang wrote:
> > Hi Maohui,
> >
> > Thanks for sending it, I do think that oe-core needs this patch.
> >
> > // Robert
> >
> > On 06/26/2018 06:27 AM, Lei Maohui wrote:
> >> The arm toolchain has a "-gnueabi" suffix, but aarch64 doesn't, this
> >> makes multilib sdk doesn't work, there will be error as following:
> >>
> >> .../usr/libexec/armeb-poky-linux-gux-linux-gnueabi/7.3.0/real-ld:
> >> cannot find crtbeginS.o: No such file or directo
> >> .../usr/libexec/armeb-poky-linux-gux-linux-gnueabi/7.3.0/real-ld:
> >> cannot find -lgcc
> >> .../usr/libexec/armeb-poky-linux-gux-linux-gnueabi/7.3.0/real-ld:
> >> cannot find -lgcc
> >> collect2: error: ld returned 1 exit status
> >>
>
> Please test this patch with musl target preferably arm/aarch64 and also
> ppc/glibc by generating SDKs
>
> >> Signed-off-by: Robert Yang
> >> Signed-off-by: Lei Maohui
> >> ---
> >> meta/recipes-devtools/gcc/libgcc-common.inc | 23
> >> +--
> >> 1 file changed, 17 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/meta/recipes-devtools/gcc/libgcc-common.inc
> >> b/meta/recipes-devtools/gcc/libgcc-common.inc
> >> index 848a476..a49fc98 100644
> >> --- a/meta/recipes-devtools/gcc/libgcc-common.inc
> >> +++ b/meta/recipes-devtools/gcc/libgcc-common.inc
> >> @@ -145,11 +145,22 @@ fakeroot python do_extra_symlinks() {
> >> if bb.data.inherits_class('nativesdk', d):
> >> return
> >> - targetsys = d.getVar('BASETARGET_SYS')
> >> + base_targetsys = d.getVar('BASETARGET_SYS')
> >> + targetsys = d.getVar('TARGET_SYS')
> >> +
> >> + if base_targetsys != targetsys:
> >> + dest = d.getVar('D') + d.getVar('libdir') + '/' +
> >> +base_targetsys
> >> + dest_list = [dest]
> >> + # For multilib like aarch64 + arm, need 2 symlinks:
> >> + # 1) BASETARGET_SYS as usual
> >> + # 2) BASETARGET_SYS + "-gnueabi" for multilib
> >> + libce = d.getVar('LIBCEXTENSION')
> >> + abie = d.getVar('ABIEXTENSION')
> >> + if abie and libce and targetsys.endswith(libce + abie):
> >> + dest_list.append(dest + libce + abie)
> >> + src = targetsys
> >> + for dir in dest_list:
> >> + if not os.path.lexists(dir) and
> >> os.path.lexists(d.getVar('D', True) + d.getVar('libdir', True)):
> >> + os.symlink(src, dir)
> >> - if targetsys != d.getVar('TARGET_SYS'):
> >> - dest = d.getVar('D') + d.getVar('libdir') + '/' + targetsys
> >> - src = d.getVar('TARGET_SYS')
> >> - if not os.path.lexists(dest) and
> >> os.path.lexists(d.getVar('D') + d.getVar('libdir')):
> >> - os.symlink(src, dest)
> >> }
> >>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Is a dependency on hostperl-runtime-native actually useful?
On 31 July 2018 at 02:06, Andre McCurdy wrote: > On Mon, Jul 30, 2018 at 3:23 PM, Richard Purdie > wrote: >> On Mon, 2018-07-30 at 14:44 -0700, Andre McCurdy wrote: >>> Currently the openssl 1.0 recipe defines a dependency on >>> hostperl-runtime-native and the openssl 1.1 recipe does not. Both run >>> "perl ./Configure ..." as part of do_configure(). >>> >>> Since hostperl-runtime-native is included in ASSUME_PROVIDED, is it >>> really useful for the openssl 1.0 recipe to list it in DEPENDS? >>> >>> ie is the openssl 1.0 recipe being unnecessarily complex or is the >>> openssl 1.1 recipe being too simplistic? >> >> It is useful for things to list their dependencies and we did have an >> effort to actually list things out so we know ASSUME_PROVIDED is >> correct. This means we can spot areas we might be able to trim back >> dependencies (amongst other reasons). >> >> With the introduction of HOSTTOOLS, its perhaps less needed than it was >> but in principle it is still useful to know which things need a given >> item, particularly where its more unusual. I'd still be interested in >> trying to cut back HOSTTOOLS a bit more. >> >> The 1.1 recipe was pretty heavily cut back, probably too much so based >> on some of the patches we've been getting... > > Thanks. Is there an obvious reason why both recipes shouldn't be using > perl-native rather than hostperl-runtime-native? Building with > perl-native seems to work fine. Because using the host perl means not depending on perl-native, which should only be used if we need to run a module that we built. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/4] systemd: backport patch to allow setting dbus calls timeout
Backport 0001-sd-bus-make-BUS_DEFAULT_TIMEOUT-configurable.patch
which allows setting dbus calls timeout via BUS_DEFAULT_TIMEOUT
environment variable.
This is needed as we are meeting timeout failures from the oeqa
runtime test case systemd.py.
Signed-off-by: Chen Qi
---
...bus-make-BUS_DEFAULT_TIMEOUT-configurable.patch | 175 +
meta/recipes-core/systemd/systemd_239.bb | 1 +
2 files changed, 176 insertions(+)
create mode 100644
meta/recipes-core/systemd/systemd/0001-sd-bus-make-BUS_DEFAULT_TIMEOUT-configurable.patch
diff --git
a/meta/recipes-core/systemd/systemd/0001-sd-bus-make-BUS_DEFAULT_TIMEOUT-configurable.patch
b/meta/recipes-core/systemd/systemd/0001-sd-bus-make-BUS_DEFAULT_TIMEOUT-configurable.patch
new file mode 100644
index 000..45c9b5b
--- /dev/null
+++
b/meta/recipes-core/systemd/systemd/0001-sd-bus-make-BUS_DEFAULT_TIMEOUT-configurable.patch
@@ -0,0 +1,175 @@
+From 5b75a72ee968c9666b5f2ea313720b6c383cb4c2 Mon Sep 17 00:00:00 2001
+From: Yu Watanabe
+Date: Fri, 13 Jul 2018 17:38:47 +0900
+Subject: [PATCH] sd-bus: make BUS_DEFAULT_TIMEOUT configurable
+
+This adds sd_bus_{get,set}_method_call_timeout().
+If the timeout is not set or set to 0, then the timeout value is
+parsed from $SYSTEMD_BUS_TIMEOUT= environment variable. If the
+environment variable is not set, then built-in timeout is used.
+---
+ doc/ENVIRONMENT.md | 5 +
+ src/libsystemd/libsystemd.sym| 5 +
+ src/libsystemd/sd-bus/bus-internal.h | 9
+ src/libsystemd/sd-bus/bus-message.c | 7 +--
+ src/libsystemd/sd-bus/sd-bus.c | 40 ++--
+ src/systemd/sd-bus.h | 3 +++
+ 6 files changed, 61 insertions(+), 8 deletions(-)
+
+Upstream-Status: Backport
+
+Signed-off-by: Chen Qi
+
+diff --git a/doc/ENVIRONMENT.md b/doc/ENVIRONMENT.md
+index 85d26fe28c..641a03d5d7 100644
+--- a/doc/ENVIRONMENT.md
b/doc/ENVIRONMENT.md
+@@ -37,6 +37,11 @@ All tools:
+ useful for debugging, in order to test generators and other code against
+ specific kernel command lines.
+
++* `$SYSTEMD_BUS_TIMEOUT=SECS` — specifies the maximum time to wait for method
call
++ completion. If no time unit is specified, assumes seconds. The usual other
units
++ are understood, too (us, ms, s, min, h, d, w, month, y). If it is not set
or set
++ to 0, then the built-in default is used.
++
+ systemctl:
+
+ * `$SYSTEMCTL_FORCE_BUS=1` — if set, do not connect to PID1's private D-Bus
+diff --git a/src/libsystemd/libsystemd.sym b/src/libsystemd/libsystemd.sym
+index 1eec17db50..006dbc9c3f 100644
+--- a/src/libsystemd/libsystemd.sym
b/src/libsystemd/libsystemd.sym
+@@ -570,3 +570,8 @@ global:
+ sd_event_source_set_destroy_callback;
+ sd_event_source_get_destroy_callback;
+ } LIBSYSTEMD_238;
++
++LIBSYSTEMD_240 {
++sd_bus_set_method_call_timeout;
++sd_bus_get_method_call_timeout;
++} LIBSYSTEMD_239;
+diff --git a/src/libsystemd/sd-bus/bus-internal.h
b/src/libsystemd/sd-bus/bus-internal.h
+index 2087ef8eeb..4864b1e911 100644
+--- a/src/libsystemd/sd-bus/bus-internal.h
b/src/libsystemd/sd-bus/bus-internal.h
+@@ -319,6 +319,9 @@ struct sd_bus {
+
+ int *inotify_watches;
+ size_t n_inotify_watches;
++
++/* zero means use value specified by $SYSTEMD_BUS_TIMEOUT=
environment variable or built-in default */
++usec_t method_call_timeout;
+ };
+
+ /* For method calls we time-out at 25s, like in the D-Bus reference
implementation */
+@@ -336,8 +339,7 @@ struct sd_bus {
+
+ #define BUS_CONTAINER_DEPTH 128
+
+-/* Defined by the specification as maximum size of an array in
+- * bytes */
++/* Defined by the specification as maximum size of an array in bytes */
+ #define BUS_ARRAY_MAX_SIZE 67108864
+
+ #define BUS_FDS_MAX 1024
+@@ -388,8 +390,7 @@ void bus_close_io_fds(sd_bus *b);
+ _slash = streq((prefix), "/") ? NULL : strrchr((prefix), '/'))
+
+ /* If we are invoking callbacks of a bus object, ensure unreffing the
+- * bus from the callback doesn't destroy the object we are working
+- * on */
++ * bus from the callback doesn't destroy the object we are working on */
+ #define BUS_DONT_DESTROY(bus) \
+ _cleanup_(sd_bus_unrefp) _unused_ sd_bus *_dont_destroy_##bus =
sd_bus_ref(bus)
+
+diff --git a/src/libsystemd/sd-bus/bus-message.c
b/src/libsystemd/sd-bus/bus-message.c
+index 8d92bc2002..dffe70a665 100644
+--- a/src/libsystemd/sd-bus/bus-message.c
b/src/libsystemd/sd-bus/bus-message.c
+@@ -5809,8 +5809,11 @@ int bus_message_remarshal(sd_bus *bus, sd_bus_message
**m) {
+ return r;
+
+ timeout = (*m)->timeout;
+-if (timeout == 0 && !((*m)->header->flags &
BUS_MESSAGE_NO_REPLY_EXPECTED))
+-timeout = BUS_DEFAULT_TIMEOUT;
++if (timeout == 0 && !((*m)->header->flags &
BUS_MESSAGE_NO_REPLY_EXPECTED)) {
++r = sd_bus_get_method_call_timeout(bus, );
++
[OE-core] [PATCH 1/4] oe_syslog.py: fix settings in OEHasPackage decorator
1. For test_syslog_running, we should not restrict it to run for
only busybox-syslog and sysklogd. So extend it to all syslog
providers in oe-core and meta-openembedded.
2. For test_syslog_startup_config, fix to make it depend on the
existence of busybox-syslog. The previous condition "!sysklogd
&& busybox" is incorrect, because busybox may be compiled without
syslog support, and sysklogd and busybox-syslog conflict with
each other.
Signed-off-by: Chen Qi
---
meta/lib/oeqa/runtime/cases/oe_syslog.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/lib/oeqa/runtime/cases/oe_syslog.py
b/meta/lib/oeqa/runtime/cases/oe_syslog.py
index 005b697..935f10f 100644
--- a/meta/lib/oeqa/runtime/cases/oe_syslog.py
+++ b/meta/lib/oeqa/runtime/cases/oe_syslog.py
@@ -8,7 +8,7 @@ class SyslogTest(OERuntimeTestCase):
@OETestID(201)
@OETestDepends(['ssh.SSHTest.test_ssh'])
-@OEHasPackage(["busybox-syslog", "sysklogd"])
+@OEHasPackage(["busybox-syslog", "sysklogd", "rsyslog", "syslog-ng"])
def test_syslog_running(self):
cmd = '%s | grep -i [s]yslogd' % self.tc.target_cmds['ps']
status, output = self.target.run(cmd)
@@ -45,7 +45,7 @@ class SyslogTestConfig(OERuntimeTestCase):
@OETestID(202)
@OETestDepends(['oe_syslog.SyslogTestConfig.test_syslog_logger'])
-@OEHasPackage(["!sysklogd", "busybox"])
+@OEHasPackage(["busybox-syslog"])
@skipIfDataVar('VIRTUAL-RUNTIME_init_manager', 'systemd',
'Not appropiate for systemd image')
def test_syslog_startup_config(self):
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/4] parselogs.py: ignore network interface name changing failure
The following error from systemd-udevd is not harmful. It's just because our qemu targets are using eth0. Error changing net interface name 'eth0' to 'enp0s3': Device or resource busy Note that systemd is using a different network interface naming scheme from traditional ethX naming scheme. To make this error message go away, we could symlink /etc/udev/rules.d/80-net-setup-link.rules to /dev/null to recover traditional naming scheme. But I'm not sure if this will cause regression in user experience for systemd users of OE. So just ignore this error message so that parselogs.py test case does not fail. Signed-off-by: Chen Qi --- meta/lib/oeqa/runtime/cases/parselogs.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py b/meta/lib/oeqa/runtime/cases/parselogs.py index f0bcd16..017b550 100644 --- a/meta/lib/oeqa/runtime/cases/parselogs.py +++ b/meta/lib/oeqa/runtime/cases/parselogs.py @@ -51,7 +51,8 @@ common_errors = [ "Cannot set xattr user.Librepo.DownloadInProgress", "Failed to read /var/lib/nfs/statd/state: Success", "error retry time-out =", -"logind: cannot setup systemd-logind helper (-61), using legacy fallback" +"logind: cannot setup systemd-logind helper (-61), using legacy fallback", +"Error changing net interface name 'eth0' to " ] video_related = [ -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/4] systemd.py: increase default bus timeout
Use SYSTEMD_BUS_TIMEOUT to set default timeout to 240s to avoid
timeout problem on slow qemu machines.
Signed-off-by: Chen Qi
---
meta/lib/oeqa/runtime/cases/systemd.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/lib/oeqa/runtime/cases/systemd.py
b/meta/lib/oeqa/runtime/cases/systemd.py
index db69384..460b8fc 100644
--- a/meta/lib/oeqa/runtime/cases/systemd.py
+++ b/meta/lib/oeqa/runtime/cases/systemd.py
@@ -11,11 +11,11 @@ from oeqa.core.decorator.data import skipIfNotFeature
class SystemdTest(OERuntimeTestCase):
def systemctl(self, action='', target='', expected=0, verbose=False):
-command = 'systemctl %s %s' % (action, target)
+command = 'SYSTEMD_BUS_TIMEOUT=240s systemctl %s %s' % (action, target)
status, output = self.target.run(command)
message = '\n'.join([command, output])
if status != expected and verbose:
-cmd = 'systemctl status --full %s' % target
+cmd = 'SYSTEMD_BUS_TIMEOUT=240s systemctl status --full %s' %
target
message += self.target.run(cmd)[1]
self.assertEqual(status, expected, message)
return output
@@ -63,7 +63,7 @@ class SystemdBasicTests(SystemdTest):
"""
endtime = time.time() + (60 * 2)
while True:
-status, output = self.target.run('systemctl --state=activating')
+status, output = self.target.run('SYSTEMD_BUS_TIMEOUT=240s
systemctl --state=activating')
if "0 loaded units listed" in output:
return (True, '')
if time.time() >= endtime:
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/4] A few fixes related to oeqa runtime
The following changes since commit 9c419271b5cf927924682c3200451979f02409bb: bitbake: codeparser: Track oe.utils.conditional usage (2018-07-30 12:45:15 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib ChenQi/oeqa_fixes http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/oeqa_fixes Chen Qi (4): oe_syslog.py: fix settings in OEHasPackage decorator parselogs.py: ignore network interface name changing failure systemd: backport patch to allow setting dbus calls timeout systemd.py: increase default bus timeout meta/lib/oeqa/runtime/cases/oe_syslog.py | 4 +- meta/lib/oeqa/runtime/cases/parselogs.py | 3 +- meta/lib/oeqa/runtime/cases/systemd.py | 6 +- ...bus-make-BUS_DEFAULT_TIMEOUT-configurable.patch | 175 + meta/recipes-core/systemd/systemd_239.bb | 1 + 5 files changed, 183 insertions(+), 6 deletions(-) create mode 100644 meta/recipes-core/systemd/systemd/0001-sd-bus-make-BUS_DEFAULT_TIMEOUT-configurable.patch -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
