[OE-core] [PATCH] runtime/ksample.py: correct a syntax and perfect item about architecture
Signed-off-by: Hongzhi.Song
---
meta/lib/oeqa/runtime/cases/ksample.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/lib/oeqa/runtime/cases/ksample.py
b/meta/lib/oeqa/runtime/cases/ksample.py
index 584d0fb..de2366a 100644
--- a/meta/lib/oeqa/runtime/cases/ksample.py
+++ b/meta/lib/oeqa/runtime/cases/ksample.py
@@ -105,7 +105,7 @@ class KSampleTest(KSample):
# kprobe
@OETestDepends(['ssh.SSHTest.test_ssh'])
def test_kprobe_test(self):
-self.check_arch("x86 ppc")
+self.check_arch("x86_64 i686 ppc")
index = ["kprobe", "kretprobe"]
for i in index:
self.kprobe_func(i)
@@ -173,9 +173,9 @@ class KSampleTest(KSample):
def test_hw_breakpoint_example(self):
# check arch
status, output = self.target.run("uname -m")
-result = ("x86" in output) or ("aarch64" in output)
+result = ("x86_64" in output) or ("aarch64" in output)
if not result:
-self.skipTest("the arch doesn't support hw breakpoint" % output)
+self.skipTest("the arch %s doesn't support hw breakpoint" % output)
# check config
self.check_config("CONFIG_KALLSYMS_ALL")
# make sure if module exists
--
2.8.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] python2-manifest.json: add logging to rdepends
Ping.
On 2019年01月17日 10:26, mingli...@windriver.com wrote:
From: Mingli Yu
Add loggging to rdepends for python-2to3
and python-multiprocessing.
before patch:
# python
Python 2.7.15 (default, Jan 15 2019, 03:09:01)
[GCC 8.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from multiprocessing import util
>>> util.get_logger()
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/multiprocessing/util.py", line 89, in get_logger
import logging, atexit
ImportError: No module named logging
>>>
After patch:
# python
Python 2.7.15 (default, Jan 15 2019, 09:05:49)
[GCC 8.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from multiprocessing import util
>>> util.get_logger()
>>>
Steps to reproduce:
1, add below line to local.conf
IMAGE_INSTALL_append += " python-multiprocessing"
2, bitbake core-image-base
3, runqemu qemux86 slirp nographic core-image-base
Signed-off-by: Mingli Yu
---
meta/recipes-devtools/python/python/python2-manifest.json | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/python/python/python2-manifest.json
b/meta/recipes-devtools/python/python/python2-manifest.json
index 4fff54a95bf..abaa10dbd2e 100644
--- a/meta/recipes-devtools/python/python/python2-manifest.json
+++ b/meta/recipes-devtools/python/python/python2-manifest.json
@@ -106,7 +106,8 @@
"2to3": {
"summary": "Python automated Python 2 to 3 code translator",
"rdepends": [
-"core"
+"core",
+"logging"
],
"files": [
"${bindir}/2to3",
@@ -728,6 +729,7 @@
"core",
"fcntl",
"io",
+"logging",
"pickle",
"subprocess",
"threading"
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] devtool: remove duplicate overrides
This has already been merged, but see below.
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org core-boun...@lists.openembedded.org> On Behalf Of Dan Dedrick
> Sent: den 21 januari 2019 17:05
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] devtool: remove duplicate overrides
>
> DEVTOOL_EXTRA_OVERRIDES only needs one entry for each instance of
> overrides. Previous to these changes it would find every override to
> SRC_URI and add it to the list. This would duplicate instances where
> SRC_URI is modified multiple times with the same override like:
> SRC_URI_append_foo += "file://0001-foo.patch"
> SRC_URI_append_foo += "file://0002-bar.patch"
>
> A bbappend might also overwrite a SRC_URI override, which would also
> cause multiple instances to occur.
>
> When there are multiple instances of the same override in
> DEVTOOL_EXTRA_OVERRIDES it causes devtool modify to fail when creating
> override branches. The failure occurs when attempting to create the same
> override branch a second time and looks like this:
>
> The stack trace of python calls that resulted in this exception/failure was:
> File: 'exec_python_func() autogenerated', lineno: 2, function:
> 0001:
> *** 0002:devtool_post_patch(d)
> 0003:
> File: '/build/poky/meta/classes/devtool-source.bbclass', lineno: 202,
> function: devtool_post_patch
> 0198:
> 0199:for override in extra_override_list:
The reference to extra_override_list above indicates that you developed
this patch for an older version of OE-Core, since that variable was
renamed on master of OE-Core in October when this problem was fixed (see
commit 95a92195). However, that fix was made to devtool-source.bbclass,
where it uses the value of DEVTOOL_EXTRA_OVERRIDES, instead of to
scripts/lib/devtool/standard.py where you made the change. This is
probably why you did not notice that the problem had already been fixed.
> 0200:localdata = bb.data.createCopy(d)
> 0201:if override in default_overrides:
> *** 0202:bb.process.run('git branch devtool-override-%s %s'
> % (override, devbranch), cwd=srcsubdir)
> 0203:else:
> 0204:# Reset back to the initial commit on a new branch
> 0205:bb.process.run('git checkout %s -b
> devtool-override-%s' % (initial_rev, override), cwd=srcsubdir)
> 0206:# Run do_patch function with the override applied
> File: '/build/poky/bitbake/lib/bb/process.py', lineno: 178, function: run
> 0174:if not stderr is None:
> 0175:stderr = stderr.decode("utf-8")
> 0176:
> 0177:if pipe.returncode != 0:
> *** 0178:raise ExecutionError(cmd, pipe.returncode, stdout, stderr)
> 0179:return stdout, stderr
> Exception: bb.process.ExecutionError: Execution of 'git branch
> devtool-override-foo devtool' failed with exit code 128:
> fatal: A branch named 'devtool-override-foo' already exists.
>
> Signed-off-by: Dan Dedrick
> ---
> scripts/lib/devtool/standard.py | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
> index d14b7a6543..a45ad36812 100644
> --- a/scripts/lib/devtool/standard.py
> +++ b/scripts/lib/devtool/standard.py
> @@ -509,6 +509,11 @@ def _extract_source(srctree, keep_temp, devbranch, sync,
> config, basepath, works
> if not 'flag' in event:
> if event['op'].startswith(('_append[', '_prepend[')):
>
> extra_overrides.append(event['op'].split('[')[1].split(']')[0])
> +# We want to remove duplicate overrides. If a recipe had multiple
> +# SRC_URI_override += values it would cause mulitple instances of
> +# overrides. This doesn't play nicely with things like creating a
> +# branch for every instance of DEVTOOL_EXTRA_OVERRIDES.
> +extra_overrides = list(set(extra_overrides))
> if extra_overrides:
> logger.info('SRC_URI contains some conditional appends/prepends
> - will create branches to represent these')
>
> --
> 2.20.1
//Peter
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] sstate siginfo question
On Tue, 2019-01-22 at 13:06 +, André Draszik wrote: > Hi, > > I am hoping to optimise some network traffic here a little by > reducing > sstate upload to our central server. > > These might be stupid questions on that subject: > * Are *.tgz.siginfo files without a matching *.tgz useful to be > shared They're useful if you need to debug signatures as they link other sstate hashes together. The system doesn't use them except when debugging (e.g. dumpsigs/diffsigs). > (uploaded to our centra sstate server), or is there no point? > * which siginfos can be safely avoided to be uploaded? I'd assume all > *_rm_work.tgz.siginfo There probably aren't many but rm_work/clean/cleansstate are pointless. > Any others? > * Can such an approach be feasible? Not sure it would save much. The sstate hash equivalence work should be much more promising for this. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Yocto Project Status WW04'19
Current Dev Position: YP 2.7 M2 Next Deadline: YP 2.7 M2 Cutoff is Jan. 21, 2019 SWAT Team Rotation: * SWAT lead is currently: Chen * SWAT team rotation: Chen -> Armin on Jan. 25, 2019 * SWAT team rotation: Armin -> Anuj on Feb. 1, 2019 * https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: * YP 2.6.1 is out of QA and the QA results are being reviewed. See: https://wiki.yoctoproject.org/wiki/WW02_-_2019-01-09_-_Full_Test_Cycle_2.6.1_RC1 * We have preliminary patches for the qemuarm migration to an armv7 machine. These haven't passed testing and will need some improvements, particularly in the area of graphics support so will be deferred to M3 but it is great to see progress being made. * The qemu virtgl patchset is also making great progress in review/development but will also be deferred to M3. * We are now running the build performance tests as part of our standard autobuilder which is a further step towards streamlining our testing and release process. We are having some problems with the graphs that are generated in the emails. If anyone has experience or interest in helping with this (google charts in emails) we'd love to hear from you! * The perl changes which landed last week seem to have mostly been ok, there have been some race issues and we're grateful to Alex and the perl-cross upstream for their fast turnaround on those. * Further fixes for the gitsm fetcher landed but there are still reports of issues. We continue to try and find ways to expand our test case matrix so we can fix the issues *and* ensure we don't regress. * The latest round of updates from the AUH were sent out. Some have responded to this and sent in upgrades, many have not. If you are listed as a maintainer, please help us keep recipes up to date! Planned Releases for YP 2.7: * YP 2.7 M2 Cutoff is Jan. 21, 2019 * YP 2.7 M2 Release Target is Feb. 1, 2019 * YP 2.7 M3 Cutoff is Feb. 25, 2019 * YP 2.7 M3 Release Target is Mar. 8, 2019 * YP 2.7 M4 Cutoff is Apr. 1, 2019 * YP 2.7 M4 Release Target is Apr. 26, 2019 Planned upcoming dot releases: * YP 2.6.1 (Thud) will is out of QA. * YP 2.5.3 (Sumo) will be targeted after YP 2.7 M2 is done. * YP 2.5.4 (Sumo) will be targeted after YP 2.7 M4 is done. * YP 2.6.2 (Thud) will be targeted after YP 2.5.4 is done. Tracking Metrics: * WDD 2421 (last week 2391) (https://wiki.yoctoproject.org/charts/combo.html) * Poky Patch Metrics oTotal patches found: 1572 (last week 1565) oPatches in the Pending State: 677 (43%) [last week 667 (43%)] Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.7_Status https://wiki.yoctoproject.org/wiki/Yocto_2.7_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.7_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] linux-yocto/4.19: qemuarma15: drop 'qemuarm' match
Until qemuarma15 is a drop in replacement for the existing versatile
qemuarm emulation, it shouldn't match on qemuarm as a machine
definition. Since the difference in capabilities will cause unexpected
issues at runtime.
Signed-off-by: Bruce Ashfield
---
meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto_4.19.bb | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
index cb0283d49fcb..bfce9aa76935 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.19.bb
@@ -12,7 +12,7 @@ python () {
}
SRCREV_machine ?= "7a0b04e5a8d036cd9dcc6ee64a838e8d8d5cdd56"
-SRCREV_meta ?= "0b9ea5596fd88277a4ecca1a8b8a1aca06a1ae37"
+SRCREV_meta ?= "7223248023d3d822c8c0227fb65d995ba6b7a351"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.19;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb
index 4e13bf125e8b..c734ad840708 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.19.bb
@@ -17,7 +17,7 @@ KCONF_BSP_AUDIT_LEVEL = "2"
SRCREV_machine_qemuarm ?= "d11db6c6617f689e6b9e2afaa3d3b2036c6d3d30"
SRCREV_machine ?= "eebb51300a07804a020ec468b5f8c5bf720198d9"
-SRCREV_meta ?= "0b9ea5596fd88277a4ecca1a8b8a1aca06a1ae37"
+SRCREV_meta ?= "7223248023d3d822c8c0227fb65d995ba6b7a351"
PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.19.bb
b/meta/recipes-kernel/linux/linux-yocto_4.19.bb
index 599418d9cb21..187437016f23 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.19.bb
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?=
"eebb51300a07804a020ec468b5f8c5bf720198d9"
SRCREV_machine_qemux86-64 ?= "eebb51300a07804a020ec468b5f8c5bf720198d9"
SRCREV_machine_qemumips64 ?= "dff23f01307cbab688d9677ecd4b5f350ec435d9"
SRCREV_machine ?= "eebb51300a07804a020ec468b5f8c5bf720198d9"
-SRCREV_meta ?= "0b9ea5596fd88277a4ecca1a8b8a1aca06a1ae37"
+SRCREV_meta ?= "7223248023d3d822c8c0227fb65d995ba6b7a351"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRANCH}; \
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.19;destsuffix=${KMETA}"
--
2.5.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-oe][PATCH] openssl: fix multilib file install conflicts
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org core-boun...@lists.openembedded.org> On Behalf Of Randy MacLeod
> Sent: den 22 januari 2019 00:01
> To: Patches and discussions about the oe-core layer c...@lists.openembedded.org>; Xulin Sun
> Subject: Re: [OE-core] [meta-oe][PATCH] openssl: fix multilib file
> install conflicts
>
> Xulin,
>
> Thanks for sending this patch.
>
> On 1/17/19 9:22 PM, Xulin Sun wrote:
> > To avoid issue like below if run "bitbake lib32-wrlinux-image-glibc-
> std"
>
> For future oe-core commits, please use a core-image-minimal
> example that will be more familiar to people outside of Wind River.
>
> > with series userspace packages(LAMP,krb5...) added:
> >
> > Error: Transaction check error:
> >file /usr/bin/c_rehash conflicts between attempted installs of
> >lib32-openssl-bin-1.1.1-r0.armv7at2hf_neon and openssl-bin-1.1.1-
> r0.aarch64
> >
>
> Also, while your commit log explains what you fixed, it
> doesn't describe the issue for those who don't know what c_rehash is so
> something like:
>
>Add multilib_script support for openssl's c_rehash which is
>a perl script.
>
> Followed by the example failure log that you showed.
>
>
> Since this hasn't been merged to master/master-next,
> it would be nice if you sent a v2.
>
> Thanks,
> ../Randy
>
> > Signed-off-by: Xulin Sun
> > ---
> > meta/recipes-connectivity/openssl/openssl_1.1.1a.bb | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
> b/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
> > index 5c4e69cfb7..21359fa68a 100644
> > --- a/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
> > +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1a.bb
> > @@ -206,3 +206,7 @@ RREPLACES_openssl-conf = "openssl10-conf"
> > RCONFLICTS_openssl-conf = "openssl10-conf"
> >
> > BBCLASSEXTEND = "native nativesdk"
> > +
> > +inherit multilib_script
> > +
> > +MULTILIB_SCRIPTS = "${PN}:${bindir}/c_rehash"
Shouldn't that be:
MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
given that openssl inherits lib_package and ${bindir}/c_rehash thus
ends up in the ${PN}-bin package?
//Peter
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] remove unused distutils-tools.bbclass
* As far as I can see nothing uses it
* From commit history it seems distutils-tools came in accidentally
Signed-off-by: Andreas Müller
---
meta/classes/distutils-tools.bbclass | 73
1 file changed, 73 deletions(-)
delete mode 100644 meta/classes/distutils-tools.bbclass
diff --git a/meta/classes/distutils-tools.bbclass
b/meta/classes/distutils-tools.bbclass
deleted file mode 100644
index 6f2880ea01..00
--- a/meta/classes/distutils-tools.bbclass
+++ /dev/null
@@ -1,73 +0,0 @@
-DISTUTILS_BUILD_ARGS ?= ""
-DISTUTILS_STAGE_HEADERS_ARGS ?= "--install-dir=${STAGING_INCDIR}/${PYTHON_DIR}"
-DISTUTILS_STAGE_ALL_ARGS ?= "--prefix=${STAGING_DIR_HOST}${prefix} \
---install-data=${STAGING_DATADIR}"
-DISTUTILS_INSTALL_ARGS ?= "--prefix=${D}/${prefix} \
---install-data=${D}/${datadir}"
-
-distutils_do_compile() {
- STAGING_INCDIR=${STAGING_INCDIR} \
- STAGING_LIBDIR=${STAGING_LIBDIR} \
- ${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py
build ${DISTUTILS_BUILD_ARGS} || \
- bbfatal_log "${PYTHON_PN} setup.py build_ext execution failed."
-}
-
-distutils_stage_headers() {
-install -d ${STAGING_DIR_HOST}${PYTHON_SITEPACKAGES_DIR}
-${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py
install_headers ${DISTUTILS_STAGE_HEADERS_ARGS} || \
-bbfatal_log "${PYTHON_PN} setup.py install_headers execution failed."
-}
-
-distutils_stage_all() {
-STAGING_INCDIR=${STAGING_INCDIR} \
-STAGING_LIBDIR=${STAGING_LIBDIR} \
-install -d ${STAGING_DIR_HOST}${PYTHON_SITEPACKAGES_DIR}
-PYTHONPATH=${STAGING_DIR_HOST}${PYTHON_SITEPACKAGES_DIR} \
-${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py
install ${DISTUTILS_STAGE_ALL_ARGS} || \
-bbfatal_log "${PYTHON_PN} setup.py install (stage) execution failed."
-}
-
-distutils_do_install() {
-echo "Beginning ${PN} Install ..."
-install -d ${D}${PYTHON_SITEPACKAGES_DIR}
-echo "Step 2 of ${PN} Install ..."
-STAGING_INCDIR=${STAGING_INCDIR} \
-STAGING_LIBDIR=${STAGING_LIBDIR} \
-PYTHONPATH=${D}/${PYTHON_SITEPACKAGES_DIR} \
-${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py
install --install-lib=${D}/${PYTHON_SITEPACKAGES_DIR} ${DISTUTILS_INSTALL_ARGS}
|| \
-bbfatal_log "${PYTHON_PN} setup.py install execution failed."
-
-echo "Step 3 of ${PN} Install ..."
-# support filenames with *spaces*
-find ${D} -name "*.py" -print0 | while read -d $'\0' i ; do \
-sed -i -e s:${D}::g $i
-done
-
-echo "Step 4 of ${PN} Install ..."
-if test -e ${D}${bindir} ; then
-for i in ${D}${bindir}/* ; do \
-sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
-done
-fi
-
-echo "Step 4 of ${PN} Install ..."
-if test -e ${D}${sbindir}; then
-for i in ${D}${sbindir}/* ; do \
-sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
-done
-fi
-
-echo "Step 5 of ${PN} Install ..."
-rm -f ${D}${PYTHON_SITEPACKAGES_DIR}/easy-install.pth
-
-#
-# FIXME: Bandaid against wrong datadir computation
-#
-if [ -e ${D}${datadir}/share ]; then
-mv -f ${D}${datadir}/share/* ${D}${datadir}/
-fi
-}
-
-#EXPORT_FUNCTIONS do_compile do_install
-
-export LDSHARED="${CCLD} -shared"
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] remove unused distutils-tools.bbclass
Please correct me if I am wrong Andreas Müller (1): remove unused distutils-tools.bbclass meta/classes/distutils-tools.bbclass | 73 1 file changed, 73 deletions(-) delete mode 100644 meta/classes/distutils-tools.bbclass -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] sstate siginfo question
Hi, I am hoping to optimise some network traffic here a little by reducing sstate upload to our central server. These might be stupid questions on that subject: * Are *.tgz.siginfo files without a matching *.tgz useful to be shared (uploaded to our centra sstate server), or is there no point? * which siginfos can be safely avoided to be uploaded? I'd assume all *_rm_work.tgz.siginfo Any others? * Can such an approach be feasible? Cheers, Andre' -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] [thud][PATCH] mdadm: add init and service scripts
On Fri, 18 Jan 2019 at 03:08, Hong Liu wrote:
> +do_install_append() {
> +install -d ${D}/${sysconfdir}/
> +install -m 644 ${S}/mdadm.conf-example ${D}${sysconfdir}/mdadm.conf
> +if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)};
> then
systemd.bbclass will delete these if systemd isn't enabled, so there's
no need to guard them.
> ++FILES_${PN} += " \
> +${systemd_unitdir} \
> +"
I believe systemd.bbclass does this too.
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3 v3] scripts/test-case-mgmt: store test result and reporting
Sorry, I realized that I had missed to include the files used for oe-selftest that testing the store operation. Submitted v5 patches that added the required files for oe-selftest -r resultstooltests. http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278243.html http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278244.html http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278245.html -Original Message- From: Yeoh, Ee Peng Sent: Tuesday, January 22, 2019 5:45 PM To: Richard Purdie ; openembedded-core@lists.openembedded.org Cc: Burton, Ross ; Paul Eggleton Subject: RE: [OE-core] [PATCH 2/3 v3] scripts/test-case-mgmt: store test result and reporting Hi Richard, After your recently sharing on pythonic, we had revised these scripts in hope to improve the code readability and ease of maintenance. Also new functionalities were developed following pythonic style. The latest patches are just submitted today at below URL. http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278240.html http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278238.html http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278239.html Changes compared to previous version: 1. Add new features, merge multiple testresults.json file & regression analysis for two specified testresults.json 2. Add selftest to test merge, store, report and regression functionalities 3. Revised code style to align with pythonic Regarding your questions below: 1. What target layout are we aiming for in the git repository? - Are we aiming for a directory per commit tested where all the test results for that commit are in the same json file? - A directory per commit, then a directory per type of test? or per test run? or ??? - Are branches used for each release series (master, thud, sumo etc?) Basically, the layout we'd use to import the autobuilder results for each master run for example remains unclear to me, or how we'd look up the status of a given commit. The target layout shall be a specific git branch for each commit tested, where the file directories shall be based on existing Autobuilder results archive (eg. assuming store command was executed inside Autobuilder machine that stored the testresults.json files and predefined directory), simply execute: $ resultstool store where source_dir was the top directory used by Autobuilder to archive all testresults.json file, git_branch was the QA cycle for current tested commit. The first instance to execute "resultstool store" will generate a git repository under // directory. To update files to be stored, simply execute $ resultstool store -d //. 2. The code doesn't support comparison of two sets of test results (which tests were added/removed? passed when previously failed? failed when previously passed?) Assuming results from a particular tested commit were merged into a single file (using existing "merge" functionality), user shall use the newly added "regression" functionality for comparing results status for two testresults.json files. Based on the configurations data for each result_id set, the comparison logic will select result with same configurations for comparison. More advance regression and automation can be developed from current code base. 3. The code also doesn't allow investigation of test report "subdata" like looking at the ptest results, comparing them to previous runs, showing the logs for passed/failed ptests. There is also the question of json build performance data. This was not supported as of now, this will need further enhancement. Please let me know if any questions and inputs. Thank you very much for your sharing and help! Thanks, Yeoh Ee Peng -Original Message- From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] Sent: Monday, January 21, 2019 10:26 PM To: Yeoh, Ee Peng ; openembedded-core@lists.openembedded.org Cc: Burton, Ross ; Paul Eggleton Subject: Re: [OE-core] [PATCH 2/3 v3] scripts/test-case-mgmt: store test result and reporting On Fri, 2019-01-04 at 14:46 +0800, Yeoh Ee Peng wrote: > These scripts were developed as an alternative testcase management > tool to Testopia. Using these scripts, user can manage the > testresults.json files generated by oeqa automated tests. Using the > "store" operation, user can store multiple groups of test result each > into individual git branch. Within each git branch, user can store > multiple testresults.json files under different directories (eg. > categorize directory by selftest-, runtime-- > ). > Then, using the "report" operation, user can view the test result > summary for all available testresults.json files being stored that > were grouped by directory and test configuration. > > This scripts depends on scripts/oe-git-archive where it was facing > error if gitpython package was not installed. Refer to [YOCTO#
[OE-core] [PATCH 2/2 v5] scripts/resultstool: enable manual execution and result creation
From: Mazliana
Integrated “manualexecution” operation to test-case-mgmt scripts.
Manual execution script is a helper script to execute all manual
test cases in baseline command, which consists of user guideline
steps and the expected results. The last step will ask user to
provide their input to execute result. The input options are
passed/failed/blocked/skipped status. The result given will be
written in testresults.json including log error from the user
input and configuration if there is any.The output test result
for json file is created by using OEQA library.
The configuration part is manually key-in by the user. The system
allow user to specify how many configuration they want to add and
they need to define the required configuration name and value pair.
In QA perspective, "configuration" means the test environments and
parameters used during QA setup before testing can be carry out.
Example of configurations: image used for boot up, host machine
distro used, poky configurations, etc.
The purpose of adding the configuration is to standardize the
output test result format between automation and manual execution.
To use these scripts, first source oe environment, then run the
entry point script to look for help.
$ resultstool
To execute manual test cases, execute the below
$ resultstool manualexecution
By default testresults.json store in /tmp/log/manual/
[YOCTO #12651]
Signed-off-by: Mazliana
Signed-off-by: Yeoh Ee Peng
---
scripts/lib/resultstool/manualexecution.py | 137 +
scripts/resultstool| 8 ++
2 files changed, 145 insertions(+)
create mode 100644 scripts/lib/resultstool/manualexecution.py
diff --git a/scripts/lib/resultstool/manualexecution.py
b/scripts/lib/resultstool/manualexecution.py
new file mode 100644
index 000..e0c0c36
--- /dev/null
+++ b/scripts/lib/resultstool/manualexecution.py
@@ -0,0 +1,137 @@
+# test case management tool - manual execution from testopia test cases
+#
+# Copyright (c) 2018, Intel Corporation.
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms and conditions of the GNU General Public License,
+# version 2, as published by the Free Software Foundation.
+#
+# This program is distributed in the hope it will be useful, but WITHOUT
+# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+# more details.
+#
+import argparse
+import json
+import os
+import sys
+import datetime
+import re
+from oeqa.core.runner import OETestResultJSONHelper
+from resultstool.resultsutils import load_json_file
+
+class ManualTestRunner(object):
+def __init__(self):
+self.jdata = ''
+self.test_module = ''
+self.test_suite = ''
+self.test_cases = ''
+self.configuration = ''
+self.starttime = ''
+self.result_id = ''
+self.write_dir = ''
+
+def _get_testcases(self, file):
+self.jdata = load_json_file(file)
+self.test_cases = []
+self.test_module = self.jdata[0]['test']['@alias'].split('.', 2)[0]
+self.test_suite = self.jdata[0]['test']['@alias'].split('.', 2)[1]
+for i in self.jdata:
+self.test_cases.append(i['test']['@alias'].split('.', 2)[2])
+
+def _get_input(self, config):
+while True:
+output = input('{} = '.format(config))
+if re.match('^[a-zA-Z0-9_]+$', output):
+break
+print('Only alphanumeric and underscore are allowed. Please try
again')
+return output
+
+def _create_config(self):
+self.configuration = {}
+while True:
+try:
+conf_total = int(input('\nPlease provide how many
configuration you want to save \n'))
+break
+except ValueError:
+print('Invalid input. Please provide input as a number not
character.')
+for i in range(conf_total):
+print('-')
+print('This is configuration #%s ' % (i + 1) + '. Please provide
configuration name and its value')
+print('-')
+name_conf = self._get_input('Configuration Name')
+value_conf = self._get_input('Configuration Value')
+print('-\n')
+self.configuration[name_conf.upper()] = value_conf
+current_datetime = datetime.datetime.now()
+self.starttime = current_datetime.strftime('%Y%m%d%H%M%S')
+self.configuration['STARTTIME'] = self.starttime
+self.configuration['TEST_TYPE'] = self.test_module
+
+def _create_result_id(self):
+self.result_id = 'manual_' + self.test_module + '_' + self.starttime
+
+def _execute_test_steps(self, test_id):
+test_result = {}
+
[OE-core] [PATCH 1/2 v5] resultstool: enable merge, store, report and regression analysis
OEQA outputs test results into json files and these files were
archived by Autobuilder during QA releases. Example: each oe-selftest
run by Autobuilder for different host distro generate a
testresults.json file.
These scripts were developed as a test result tools to manage
these testresults.json file.
Using the "store" operation, user can store multiple testresults.json
files as well as the pre-configured directories used to hold those files.
Using the "merge" operation, user can merge multiple testresults.json
files to a target file.
Using the "report" operation, user can view the test result summary
for all available testresults.json files inside a ordinary directory
or a git repository.
Using the "regression" operation, user can perform regression analysis
on testresults.json files specified.
These resultstool operations expect the testresults.json file to use
the json format below.
{
"": {
"configuration": {
"": "",
"": "",
...
"": "",
},
"result": {
"": {
"status": "",
"log": ""
},
"": {
"status": "",
"log": ""
},
...
"": {
"status": "",
"log": ""
},
}
},
...
"": {
"configuration": {
"": "",
"": "",
...
"": "",
},
"result": {
"": {
"status": "",
"log": ""
},
"": {
"status": "",
"log": ""
},
...
"": {
"status": "",
"log": ""
},
}
},
}
To use these scripts, first source oe environment, then run the
entry point script to look for help.
$ resultstool
To store test result from oeqa automated tests, execute the below
$ resultstool store
To merge multiple testresults.json files, execute the below
$ resultstool merge
To report test report, execute the below
$ resultstool report
To perform regression analysis, execute the below
$ resultstool regression
[YOCTO# 13012]
[YOCTO# 12654]
Signed-off-by: Yeoh Ee Peng
---
meta/lib/oeqa/files/testresults/testresults.json | 40 ++
meta/lib/oeqa/selftest/cases/resultstooltests.py | 104
scripts/lib/resultstool/__init__.py| 0
scripts/lib/resultstool/merge.py | 71 +++
scripts/lib/resultstool/regression.py | 134 +
scripts/lib/resultstool/report.py | 122 +++
scripts/lib/resultstool/resultsutils.py| 47
scripts/lib/resultstool/store.py | 110 +
.../resultstool/template/test_report_full_text.txt | 35 ++
scripts/resultstool| 84 +
10 files changed, 747 insertions(+)
create mode 100644 meta/lib/oeqa/files/testresults/testresults.json
create mode 100644 meta/lib/oeqa/selftest/cases/resultstooltests.py
create mode 100644 scripts/lib/resultstool/__init__.py
create mode 100644 scripts/lib/resultstool/merge.py
create mode 100644 scripts/lib/resultstool/regression.py
create mode 100644 scripts/lib/resultstool/report.py
create mode 100644 scripts/lib/resultstool/resultsutils.py
create mode 100644 scripts/lib/resultstool/store.py
create mode 100644 scripts/lib/resultstool/template/test_report_full_text.txt
create mode 100755 scripts/resultstool
diff --git a/meta/lib/oeqa/files/testresults/testresults.json
b/meta/lib/oeqa/files/testresults/testresults.json
new file mode 100644
index 000..1a62155
--- /dev/null
+++ b/meta/lib/oeqa/files/testresults/testresults.json
@@ -0,0 +1,40 @@
+{
+"runtime_core-image-minimal_qemuarm_20181225195701": {
+"configuration": {
+"DISTRO": "poky",
+"HOST_DISTRO": "ubuntu-16.04",
+"IMAGE_BASENAME": "core-image-minimal",
+"IMAGE_PKGTYPE": "rpm",
+"LAYERS": {
+"meta": {
+"branch": "master",
+"commit": "801745d918e83f976c706f29669779f5b292ade3",
+"commit_count": 52782
+},
+"meta-poky": {
+"branch": "master",
+"commit": "801745d918e83f976c706f29669779f5b292ade3",
+"commit_count": 52782
+},
+"meta-yocto-bsp": {
+"branch": "master",
+"commit": "801745d918e83f976c706f29669779f5b292ade3",
+"commit_count": 52782
+}
+},
+"MACHINE": "qemuarm",
+"STARTTIME": "20181225195701",
+"TEST_TYPE": "runtime"
+},
+"result": {
+
[OE-core] [PATCH 0/2 v5] test-case-mgmt
v1: Face key error from oe-git-archive Undesirable behavior when storing to multiple git branch v2: Include fix for oe-git-archive Include fix for store result to multiple git branch Improve git commit message v3: Enhance fix for oe-git-archive by using exception catch to improve code readability and easy to understand v4: Add new features, merge result files & regression analysis Add selftest to merge, store, report and regression functionalities Revise codebase for pythonic v5: Add required files for selftest testing store Mazliana (1): scripts/resultstool: enable manual execution and result creation Yeoh Ee Peng (1): resultstool: enable merge, store, report and regression analysis meta/lib/oeqa/files/testresults/testresults.json | 40 ++ meta/lib/oeqa/selftest/cases/resultstooltests.py | 104 scripts/lib/resultstool/__init__.py| 0 scripts/lib/resultstool/manualexecution.py | 137 + scripts/lib/resultstool/merge.py | 71 +++ scripts/lib/resultstool/regression.py | 134 scripts/lib/resultstool/report.py | 122 ++ scripts/lib/resultstool/resultsutils.py| 47 +++ scripts/lib/resultstool/store.py | 110 + .../resultstool/template/test_report_full_text.txt | 35 ++ scripts/resultstool| 92 ++ 11 files changed, 892 insertions(+) create mode 100644 meta/lib/oeqa/files/testresults/testresults.json create mode 100644 meta/lib/oeqa/selftest/cases/resultstooltests.py create mode 100644 scripts/lib/resultstool/__init__.py create mode 100644 scripts/lib/resultstool/manualexecution.py create mode 100644 scripts/lib/resultstool/merge.py create mode 100644 scripts/lib/resultstool/regression.py create mode 100644 scripts/lib/resultstool/report.py create mode 100644 scripts/lib/resultstool/resultsutils.py create mode 100644 scripts/lib/resultstool/store.py create mode 100644 scripts/lib/resultstool/template/test_report_full_text.txt create mode 100755 scripts/resultstool -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/3 v3] scripts/test-case-mgmt: store test result and reporting
Hi Richard, After your recently sharing on pythonic, we had revised these scripts in hope to improve the code readability and ease of maintenance. Also new functionalities were developed following pythonic style. The latest patches are just submitted today at below URL. http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278240.html http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278238.html http://lists.openembedded.org/pipermail/openembedded-core/2019-January/278239.html Changes compared to previous version: 1. Add new features, merge multiple testresults.json file & regression analysis for two specified testresults.json 2. Add selftest to test merge, store, report and regression functionalities 3. Revised code style to align with pythonic Regarding your questions below: 1. What target layout are we aiming for in the git repository? - Are we aiming for a directory per commit tested where all the test results for that commit are in the same json file? - A directory per commit, then a directory per type of test? or per test run? or ??? - Are branches used for each release series (master, thud, sumo etc?) Basically, the layout we'd use to import the autobuilder results for each master run for example remains unclear to me, or how we'd look up the status of a given commit. The target layout shall be a specific git branch for each commit tested, where the file directories shall be based on existing Autobuilder results archive (eg. assuming store command was executed inside Autobuilder machine that stored the testresults.json files and predefined directory), simply execute: $ resultstool store where source_dir was the top directory used by Autobuilder to archive all testresults.json file, git_branch was the QA cycle for current tested commit. The first instance to execute "resultstool store" will generate a git repository under // directory. To update files to be stored, simply execute $ resultstool store -d //. 2. The code doesn't support comparison of two sets of test results (which tests were added/removed? passed when previously failed? failed when previously passed?) Assuming results from a particular tested commit were merged into a single file (using existing "merge" functionality), user shall use the newly added "regression" functionality for comparing results status for two testresults.json files. Based on the configurations data for each result_id set, the comparison logic will select result with same configurations for comparison. More advance regression and automation can be developed from current code base. 3. The code also doesn't allow investigation of test report "subdata" like looking at the ptest results, comparing them to previous runs, showing the logs for passed/failed ptests. There is also the question of json build performance data. This was not supported as of now, this will need further enhancement. Please let me know if any questions and inputs. Thank you very much for your sharing and help! Thanks, Yeoh Ee Peng -Original Message- From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] Sent: Monday, January 21, 2019 10:26 PM To: Yeoh, Ee Peng ; openembedded-core@lists.openembedded.org Cc: Burton, Ross ; Paul Eggleton Subject: Re: [OE-core] [PATCH 2/3 v3] scripts/test-case-mgmt: store test result and reporting On Fri, 2019-01-04 at 14:46 +0800, Yeoh Ee Peng wrote: > These scripts were developed as an alternative testcase management > tool to Testopia. Using these scripts, user can manage the > testresults.json files generated by oeqa automated tests. Using the > "store" operation, user can store multiple groups of test result each > into individual git branch. Within each git branch, user can store > multiple testresults.json files under different directories (eg. > categorize directory by selftest-, runtime-- > ). > Then, using the "report" operation, user can view the test result > summary for all available testresults.json files being stored that > were grouped by directory and test configuration. > > This scripts depends on scripts/oe-git-archive where it was facing > error if gitpython package was not installed. Refer to [YOCTO# 13082] > for more detail. Thanks for the patches. These are a lot more readable than the previous versions and the code quality is much better which in turn helped review! I experimented with the code a bit. I'm fine with the manual test execution piece of this, I do have some questions/concerns with the result storage/reporting piece though. What target layout are we aiming for in the git repository? - Are we aiming for a directory per commit tested where all the test results for that commit are in the same json file? - A directory per commit, then a directory per type of test? or per test run? or ??? - Are branches used for each release series (master, thud, sumo etc?) Basically, the layout we'd use to import the
Re: [OE-core] Prelink problem
Hi Hongxu Jia! I have found, that You have implemented this prelink mechanism regarding to multilib. Are you sure, that these changes are required? If yes, is it possible to add somehow dependency to prelink-native? Or move it into image-prelink.bbclass. Just for the information, I have build a general image without including any prelink stuff. Regards, Andrej On 1/16/19 4:57 PM, Mark Hatle wrote: > On 1/16/19 1:23 AM, Andrej Valek wrote: >> Hi all >> >> Do we found some solution? As a workaround could be just add dependency >> to prelink native into rootfs if the command is really required. > > If the image stuff needs prelink, there should be a dependency in place. It > should only use prelink if the image-prelink is being used. > > So really something probably needs to be added to image-prelink class that > activates unprelink behavior with opkg, and adds the necessary dependency. > > --Mark > >> Regards, >> Andrej >> >> On 1/8/19 10:46 PM, Richard Purdie wrote: >>> On Tue, 2019-01-08 at 14:50 -0600, Mark Hatle wrote: On 1/8/19 2:37 PM, Burton, Ross wrote: > On Tue, 8 Jan 2019 at 20:15, Mark Hatle > wrote: >>> No idea why the opkg rootfs code is doing prelink operations >>> when RPM >>> or dpkg don't. CCing Mark who may have an idea here. I >>> thought the >>> autobuilder exerised multilib-on-opkg, but maybe not. >> >> They all should be doing prelink operations. The operation >> SHOULD be >> generically implemented as part of the image-prelink class, which >> is where I >> would have expected that copy to exist. >> >> If any of the package types of specifically doing something, that >> sounds >> broken... but the generic ones (last I looked) said to copy in >> the config file >> [if it didn't exist], run prelink, remove the file [if it wasn't >> there to start >> with]. > > Note that it's part of the incremental code, so needs to be in the > rootfs code directly I suspect. Frankly I'd love to see incremental > images removed. It makes promises it can't keep (the moment a > rootfs > postprocess command is used, all bets are off) and massively > complicates things. We assume the post process command is what an 'admin' would do. So the various package managers should be able to deal with it in most cases. (Note, obviously it's more freeform, but I wouldn't expect everything to work in you removed a large part of the filesystem for instance.) As for prelink, I'm surprised this is in the incremental code. I'm not sure why it would be necessary unless the incremental work wants to UNPRELINK the rootfs before performing the upgrade? Prelink itself should still be run as a postprocess command that takes the output of the filesystem and reprocesses it. So something seems out of sync here.. (at a minimum probably should be better commented on why it's needed..) >>> >>> The code is there for incremental opkg multilib image support. Its >>> trying to compare whether binaries are identical. To make it work, it >>> has to "unprelink" the files first before comparing. >>> >>> I'm not convinced this is a good idea :/. I'm wondering if incremental >>> image generation makes sense at all in this context to be honest. >>> >>> Cheers, >>> >>> Richard >>> > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2 v4] scripts/resultstool: enable manual execution and result creation
From: Mazliana
Integrated “manualexecution” operation to test-case-mgmt scripts.
Manual execution script is a helper script to execute all manual
test cases in baseline command, which consists of user guideline
steps and the expected results. The last step will ask user to
provide their input to execute result. The input options are
passed/failed/blocked/skipped status. The result given will be
written in testresults.json including log error from the user
input and configuration if there is any.The output test result
for json file is created by using OEQA library.
The configuration part is manually key-in by the user. The system
allow user to specify how many configuration they want to add and
they need to define the required configuration name and value pair.
In QA perspective, "configuration" means the test environments and
parameters used during QA setup before testing can be carry out.
Example of configurations: image used for boot up, host machine
distro used, poky configurations, etc.
The purpose of adding the configuration is to standardize the
output test result format between automation and manual execution.
To use these scripts, first source oe environment, then run the
entry point script to look for help.
$ resultstool
To execute manual test cases, execute the below
$ resultstool manualexecution
By default testresults.json store in /tmp/log/manual/
[YOCTO #12651]
Signed-off-by: Mazliana
Signed-off-by: Yeoh Ee Peng
---
scripts/lib/resultstool/manualexecution.py | 137 +
scripts/resultstool| 8 ++
2 files changed, 145 insertions(+)
create mode 100644 scripts/lib/resultstool/manualexecution.py
diff --git a/scripts/lib/resultstool/manualexecution.py
b/scripts/lib/resultstool/manualexecution.py
new file mode 100644
index 000..e0c0c36
--- /dev/null
+++ b/scripts/lib/resultstool/manualexecution.py
@@ -0,0 +1,137 @@
+# test case management tool - manual execution from testopia test cases
+#
+# Copyright (c) 2018, Intel Corporation.
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms and conditions of the GNU General Public License,
+# version 2, as published by the Free Software Foundation.
+#
+# This program is distributed in the hope it will be useful, but WITHOUT
+# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+# FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+# more details.
+#
+import argparse
+import json
+import os
+import sys
+import datetime
+import re
+from oeqa.core.runner import OETestResultJSONHelper
+from resultstool.resultsutils import load_json_file
+
+class ManualTestRunner(object):
+def __init__(self):
+self.jdata = ''
+self.test_module = ''
+self.test_suite = ''
+self.test_cases = ''
+self.configuration = ''
+self.starttime = ''
+self.result_id = ''
+self.write_dir = ''
+
+def _get_testcases(self, file):
+self.jdata = load_json_file(file)
+self.test_cases = []
+self.test_module = self.jdata[0]['test']['@alias'].split('.', 2)[0]
+self.test_suite = self.jdata[0]['test']['@alias'].split('.', 2)[1]
+for i in self.jdata:
+self.test_cases.append(i['test']['@alias'].split('.', 2)[2])
+
+def _get_input(self, config):
+while True:
+output = input('{} = '.format(config))
+if re.match('^[a-zA-Z0-9_]+$', output):
+break
+print('Only alphanumeric and underscore are allowed. Please try
again')
+return output
+
+def _create_config(self):
+self.configuration = {}
+while True:
+try:
+conf_total = int(input('\nPlease provide how many
configuration you want to save \n'))
+break
+except ValueError:
+print('Invalid input. Please provide input as a number not
character.')
+for i in range(conf_total):
+print('-')
+print('This is configuration #%s ' % (i + 1) + '. Please provide
configuration name and its value')
+print('-')
+name_conf = self._get_input('Configuration Name')
+value_conf = self._get_input('Configuration Value')
+print('-\n')
+self.configuration[name_conf.upper()] = value_conf
+current_datetime = datetime.datetime.now()
+self.starttime = current_datetime.strftime('%Y%m%d%H%M%S')
+self.configuration['STARTTIME'] = self.starttime
+self.configuration['TEST_TYPE'] = self.test_module
+
+def _create_result_id(self):
+self.result_id = 'manual_' + self.test_module + '_' + self.starttime
+
+def _execute_test_steps(self, test_id):
+test_result = {}
+
[OE-core] [PATCH 0/2 v4] test-case-mgmt
v1: Face key error from oe-git-archive Undesirable behavior when storing to multiple git branch v2: Include fix for oe-git-archive Include fix for store result to multiple git branch Improve git commit message v3: Enhance fix for oe-git-archive by using exception catch to improve code readability and easy to understand v4: Add new features, merge result files & regression analysis Add selftest to merge, store, report and regression functionalities Revise codebase for pythonic Mazliana (1): scripts/resultstool: enable manual execution and result creation Yeoh Ee Peng (1): resultstool: enable merge, store, report and regression analysis meta/lib/oeqa/selftest/cases/resultstooltests.py | 104 scripts/lib/resultstool/__init__.py| 0 scripts/lib/resultstool/manualexecution.py | 137 + scripts/lib/resultstool/merge.py | 71 +++ scripts/lib/resultstool/regression.py | 134 scripts/lib/resultstool/report.py | 122 ++ scripts/lib/resultstool/resultsutils.py| 47 +++ scripts/lib/resultstool/store.py | 110 + .../resultstool/template/test_report_full_text.txt | 35 ++ scripts/resultstool| 92 ++ 10 files changed, 852 insertions(+) create mode 100644 meta/lib/oeqa/selftest/cases/resultstooltests.py create mode 100644 scripts/lib/resultstool/__init__.py create mode 100644 scripts/lib/resultstool/manualexecution.py create mode 100644 scripts/lib/resultstool/merge.py create mode 100644 scripts/lib/resultstool/regression.py create mode 100644 scripts/lib/resultstool/report.py create mode 100644 scripts/lib/resultstool/resultsutils.py create mode 100644 scripts/lib/resultstool/store.py create mode 100644 scripts/lib/resultstool/template/test_report_full_text.txt create mode 100755 scripts/resultstool -- 2.7.4 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2 v4] resultstool: enable merge, store, report and regression analysis
OEQA outputs test results into json files and these files were
archived by Autobuilder during QA releases. Example: each oe-selftest
run by Autobuilder for different host distro generate a
testresults.json file.
These scripts were developed as a test result tools to manage
these testresults.json file.
Using the "store" operation, user can store multiple testresults.json
files as well as the pre-configured directories used to hold those files.
Using the "merge" operation, user can merge multiple testresults.json
files to a target file.
Using the "report" operation, user can view the test result summary
for all available testresults.json files inside a ordinary directory
or a git repository.
Using the "regression" operation, user can perform regression analysis
on testresults.json files specified.
These resultstool operations expect the testresults.json file to use
the json format below.
{
"": {
"configuration": {
"": "",
"": "",
...
"": "",
},
"result": {
"": {
"status": "",
"log": ""
},
"": {
"status": "",
"log": ""
},
...
"": {
"status": "",
"log": ""
},
}
},
...
"": {
"configuration": {
"": "",
"": "",
...
"": "",
},
"result": {
"": {
"status": "",
"log": ""
},
"": {
"status": "",
"log": ""
},
...
"": {
"status": "",
"log": ""
},
}
},
}
To use these scripts, first source oe environment, then run the
entry point script to look for help.
$ resultstool
To store test result from oeqa automated tests, execute the below
$ resultstool store
To merge multiple testresults.json files, execute the below
$ resultstool merge
To report test report, execute the below
$ resultstool report
To perform regression analysis, execute the below
$ resultstool regression
[YOCTO# 13012]
[YOCTO# 12654]
Signed-off-by: Yeoh Ee Peng
---
meta/lib/oeqa/selftest/cases/resultstooltests.py | 104
scripts/lib/resultstool/__init__.py| 0
scripts/lib/resultstool/merge.py | 71 +++
scripts/lib/resultstool/regression.py | 134 +
scripts/lib/resultstool/report.py | 122 +++
scripts/lib/resultstool/resultsutils.py| 47
scripts/lib/resultstool/store.py | 110 +
.../resultstool/template/test_report_full_text.txt | 35 ++
scripts/resultstool| 84 +
9 files changed, 707 insertions(+)
create mode 100644 meta/lib/oeqa/selftest/cases/resultstooltests.py
create mode 100644 scripts/lib/resultstool/__init__.py
create mode 100644 scripts/lib/resultstool/merge.py
create mode 100644 scripts/lib/resultstool/regression.py
create mode 100644 scripts/lib/resultstool/report.py
create mode 100644 scripts/lib/resultstool/resultsutils.py
create mode 100644 scripts/lib/resultstool/store.py
create mode 100644 scripts/lib/resultstool/template/test_report_full_text.txt
create mode 100755 scripts/resultstool
diff --git a/meta/lib/oeqa/selftest/cases/resultstooltests.py
b/meta/lib/oeqa/selftest/cases/resultstooltests.py
new file mode 100644
index 000..28bfa94
--- /dev/null
+++ b/meta/lib/oeqa/selftest/cases/resultstooltests.py
@@ -0,0 +1,104 @@
+import os
+import sys
+basepath = os.path.abspath(os.path.dirname(__file__) + '/../../../../../')
+lib_path = basepath + '/scripts/lib'
+sys.path = sys.path + [lib_path]
+from resultstool.report import ResultsTextReport
+from resultstool.regression import ResultsRegressionSelector, ResultsRegression
+from resultstool.merge import ResultsMerge
+from resultstool.store import ResultsGitStore
+from resultstool.resultsutils import checkout_git_dir
+from oeqa.selftest.case import OESelftestTestCase
+
+class ResultsToolTests(OESelftestTestCase):
+
+def test_report_can_aggregate_test_result(self):
+result_data = {'result': {'test1': {'status':'PASSED'},
+ 'test2': {'status': 'PASSED'},
+ 'test3': {'status': 'FAILED'},
+ 'test4': {'status': 'ERROR'},
+ 'test5': {'status': 'SKIPPED'}}}
+report = ResultsTextReport()
+result_report = report.get_aggregated_test_result(None, result_data)
+self.assertTrue(result_report['passed'] == 2, msg="Passed count not
correct:%s" % result_report['passed'])
+self.assertTrue(result_report['failed'] == 2, msg="Failed
[OE-core] [PATCH ver2] ptest-runner: pass libdir to DEFAULT_DIRECTORY when compiling
Ptest data are installed to PTEST_PATH ?= "${libdir}/${BPN}/ptest".
When libdir isn't "/usr/lib", it will cause "No ptests found" error
when running "ptest-runner" command. Here pass libdir to
DEFAULT_DIRECTORY when compiling to avoid that error.
Need update ptest-runner source code to get the new commit:
Signed-off-by: Li Zhou
---
meta/recipes-support/ptest-runner/ptest-runner_2.3.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-support/ptest-runner/ptest-runner_2.3.bb
b/meta/recipes-support/ptest-runner/ptest-runner_2.3.bb
index 26add9b..0a58f74 100644
--- a/meta/recipes-support/ptest-runner/ptest-runner_2.3.bb
+++ b/meta/recipes-support/ptest-runner/ptest-runner_2.3.bb
@@ -7,7 +7,7 @@ HOMEPAGE =
"http://git.yoctoproject.org/cgit/cgit.cgi/ptest-runner2/about/;
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://LICENSE;md5=751419260aa954499f7abaabaa882bbe"
-SRCREV = "80712583732b4a809532f644fb09e7d2e812d7ba"
+SRCREV = "e1062f776eea60c50435c6b8ddf9714a31141aee"
PV = "2.3+git${SRCPV}"
SRC_URI = "git://git.yoctoproject.org/ptest-runner2"
@@ -15,7 +15,7 @@ S = "${WORKDIR}/git"
FILES_${PN} = "${bindir}/ptest-runner"
-EXTRA_OEMAKE = "-e MAKEFLAGS="
+EXTRA_OEMAKE = "-e MAKEFLAGS= CFLAGS="${CFLAGS}
-DDEFAULT_DIRECTORY=\\\"${libdir}\\\"""
do_compile () {
oe_runmake
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] eSDK.py: unset BBPATH and BUILDDIR to avoid eSDK failure
When executing eSDK test case, the following error appears.
WARNING: attempting to use the extensible SDK in an environment
set up to run bitbake - this may lead to unexpected
results. Please source this script in a new shell session
instead.
FileExistsError: [Errno 17] File exists:
'/.../tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/selftest-esdk-fcuyzsqu/tmp/sysroots/x86_64/bin/pigz'
-> '/.../tmp/hosttools/pigz'
So unset these two vars to avoid messing things up.
Signed-off-by: Chen Qi
---
meta/lib/oeqa/selftest/cases/eSDK.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/selftest/cases/eSDK.py
b/meta/lib/oeqa/selftest/cases/eSDK.py
index d7aef93..7798706 100644
--- a/meta/lib/oeqa/selftest/cases/eSDK.py
+++ b/meta/lib/oeqa/selftest/cases/eSDK.py
@@ -31,7 +31,7 @@ class oeSDKExtSelfTest(OESelftestTestCase):
if not 'shell' in options:
options['shell'] = True
-runCmd("cd %s; . %s; %s" % (tmpdir_eSDKQA, env_eSDK, cmd), **options)
+runCmd("cd %s; unset BBPATH; unset BUILDDIR; . %s; %s" %
(tmpdir_eSDKQA, env_eSDK, cmd), **options)
@staticmethod
def generate_eSDK(image):
--
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] eSDK.py: unset BBPATH and BUILDDIR to avoid eSDK failure
*** BLURB HERE *** The following changes since commit 6fd870e6a1f61d17e43cf30db4259a939db93820: bitbake: bb.tests.codeparser: add parameter expansion modifiers test (2019-01-21 23:44:34 +) are available in the git repository at: git://git.pokylinux.org/poky-contrib ChenQi/eSDK-unset http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/eSDK-unset Chen Qi (1): eSDK.py: unset BBPATH and BUILDDIR to avoid eSDK failure meta/lib/oeqa/selftest/cases/eSDK.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.9.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
