Hi Alex,
I had gathered additional information related to this oe-selftest testcase for
crosstap.
1) Dependencies of crosstap script
a) bitbake -e virtual/kernel & bitbake -e systemtap-native to gather
the environment variables ( STAGING_BINDIR_TOOLCHAIN, TARGET_PREFIX,
TRANSLATED_TARGET_ARCH, STAGING_DIR_NATIVE)
b) host machine to build systemtap-native where it will execute
${SYSTEMTAP_HOST_INSTALLDIR}/usr/bin/stap
2) Running time for this crosstap oe-selftest test is ~1 hr 31 mins (fresh new
build without sstate and cache).
In order to convert this to runtime/testimage, we will need to perform below
1) Modify existing crosstap script to inverse the dependency on bitbake -e,
provide environment variables required as argument
2) Add additional step outside of testimage to bitbake the systemtap-native
I would like to propose that we keep this crosstap testcase as oe-selftest
instead of runtime/testimage as the extra efforts required and the additional
step required to build systemtap-native on the host machine.
Please let me know your input and suggestion.
Thank you very much!
Thanks,
Ee Peng
-----Original Message-----
From: Yeoh, Ee Peng
Sent: Wednesday, March 21, 2018 8:57 AM
To: [email protected]
Subject: RE: Openembedded-core Digest, Vol 86, Issue 203
Hi Alex
Can this be rewritten as a runtime test case to be used with testimage?
- Initially, the first attempt was to use testimage, but was facing
challenging situation where both testimage and crosstap script both required
execution of bitbake (this test case required executing crosstap script, where
crosstap script internally will execute bitbake for getting environment
variables). Thus the alternative was to develop this crosstap testcase as
oe-selftest.
It seems like the code duplicates much of what testimage.bbclass does, and we
generally try to avoid adding test cases that build and boot images in
oe-selftest, as it adds to already large running time for it.
The acceptable exception is when an image needs a really custom configuration,
but this is not the case here - you can take core-image-sato-sdk for example,
which comes pre-packaged with tools-profile and ssh server.
- Totally agreed with the point of avoid duplicate and adding more
running time for oe-selftest, but due to the use case of this testcase testing
crosstap script where crosstap script internally will execute bitbake for
getting environment variables, the current alternative was to use oe-selftest.
Please suggest other alternative if available.
Thank you very much for your attention & advice!
Ee Peng
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
[email protected]
Sent: Tuesday, March 20, 2018 6:53 PM
To: [email protected]
Subject: Openembedded-core Digest, Vol 86, Issue 203
Send Openembedded-core mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openembedded.org/mailman/listinfo/openembedded-core
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific than "Re:
Contents of Openembedded-core digest..."
Today's Topics:
1. Re: [PATCH] oe-selftest: crosstap: add tests for crosstap
script (Alexander Kanavin)
2. Re: [yocto] Yocto Project Status WW12?18 (Alexander Kanavin)
3. Re: [PATCHv3] iputils: add PACKAGECONFIG for libidn and
disable it by default (Martin Jansa)
4. [PATCH v2] libsolv: refresh the patch (Maxin B. John)
5. Re: [yocto] Yocto Project Status WW12?18 (Burton, Ross)
----------------------------------------------------------------------
Message: 1
Date: Tue, 20 Mar 2018 11:58:04 +0200
From: Alexander Kanavin <[email protected]>
To: Yeoh Ee Peng <[email protected]>,
[email protected]
Cc: Paul Eggleton <[email protected]>
Subject: Re: [OE-core] [PATCH] oe-selftest: crosstap: add tests for
crosstap script
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 03/20/2018 01:59 AM, Yeoh Ee Peng wrote:
> QA team were testing crosstap script manually. Add automated tests
> and systemtap file to test that crosstap script will instructs
> SystemTap to print hello world in qemu. This test will first built
> core-image-minimal image with tools-profile & ssh-server-openssh
> features and build systemtap-native on the host machine. Finally this
> test will boot the image with qemu and then execute crosstap script to
> print hello world on qemu.
Can this be rewritten as a runtime test case to be used with testimage?
It seems like the code duplicates much of what testimage.bbclass does, and we
generally try to avoid adding test cases that build and boot images in
oe-selftest, as it adds to already large running time for it.
The acceptable exception is when an image needs a really custom configuration,
but this is not the case here - you can take core-image-sato-sdk for example,
which comes pre-packaged with tools-profile and ssh server.
Alex
------------------------------
Message: 2
Date: Tue, 20 Mar 2018 12:07:32 +0200
From: Alexander Kanavin <[email protected]>
To: "Burton, Ross" <[email protected]>, akuster808
<[email protected]>
Cc: "[email protected]" <[email protected]>,
"[email protected]"
<[email protected]>
Subject: Re: [OE-core] [yocto] Yocto Project Status WW12?18
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
On 03/19/2018 10:07 PM, Burton, Ross wrote:
> Do we have a place identified for new changes (2.6) while 2.5
> stabilizes.
>
>
> A formal place, no.? I tend to queue stuff in a branch if master isn't
> taking all of my energy, otherwise the patches will sit on the list
> until 2.5 releases.? Typically master and sumo branches won't diverge
> until post-release.
Which brings me to a question: what is a good schedule and cadence for AUH
runs? Currently it's run on the 15th of every odd-numbered month (so January,
March, and so on), but I thought of shifting it one month forward, so it
doesn't land right in the middle of a feature freeze.
Thoughts?
Alex
------------------------------
Message: 3
Date: Tue, 20 Mar 2018 11:19:35 +0100
From: Martin Jansa <[email protected]>
To: Andre McCurdy <[email protected]>
Cc: OE Core mailing list <[email protected]>
Subject: Re: [OE-core] [PATCHv3] iputils: add PACKAGECONFIG for libidn
and disable it by default
Message-ID:
<CA+chaQdVBZTfp+jSuCwYufQQz2izdt-Z3OoafdRvAUmrtuP=l...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
And v1 just got merged to master, I'll send v2 with change of the default if
other agree.
I don't have strong opinion, yes it might be broken, but it was enabled since
the update to 20161105 and nobody was complaining and adding PACKAGECONFIG
usually shouldn't change the options currently used (I've meant to disable it
by default, just because Khem's request).
On Tue, Mar 20, 2018 at 12:32 AM, Andre McCurdy <[email protected]> wrote:
> On Sat, Mar 17, 2018 at 4:26 AM, Martin Jansa <[email protected]>
> wrote:
> > * it got enabled by default, but without the dependency on libidn in:
> > commit 5997981fa2c22609a88b8cbb595dbf7758b2f7c2
> > Author: Alexander Kanavin <[email protected]>
> > AuthorDate: Thu Feb 1 20:02:08 2018 +0200
> > Subject: iputils: update to 20161105
> >
> > * https://github.com/iputils/iputils/blob/master/RELNOTES.old
> > mentiones that IDN was enabled by default in:
> > [s20160308] and surprisingly the same in [s20150815]
> > but there are no release notes for s20151218 version we were using
> until
> > now, don't know how it really relates to [s20150815].
> >
> > * but there are some issues with libidn as described in:
> > https://github.com/iputils/iputils/commit/
> f3a461603ef4fb7512ade3bdb73fe1824e294547
> > so disable it by default.
> >
> > * fails with:
> > | In file included from ping_common.c:1:0:
> > | ping.h:39:10: fatal error: idna.h: No such file or directory
> > | #include <idna.h>
> > | ^~~~~~~~
> >
> > * Easiest way to reproduce this failure is to remove libidn from gnutls
> > PACKAGECONFIG or to use gnutls which doesn't have libidn PACKAGECONFIG
> > at all (like the one in meta-gplv2).
> >
> > * First it leads to following QA issue:
> > http://errors.yoctoproject.org/Errors/Build/53212/
> > ERROR: iputils-s20161105-r0 do_package_qa: QA Issue: iputils-ping
> rdepends on libidn, but it isn't a build dependency, missing libidn in
> DEPENDS or PACKAGECONFIG? [build-deps]
> > ERROR: iputils-s20161105-r0 do_package_qa: QA Issue:
> iputils-traceroute6 rdepends on libidn, but it isn't a build
> dependency, missing libidn in DEPENDS or PACKAGECONFIG? [build-deps]
> > ERROR: iputils-s20161105-r0 do_package_qa: QA run found fatal errors.
> > Please consider fixing them.
> > ERROR: iputils-s20161105-r0 do_package_qa: Function failed:
> > do_package_qa
> > ERROR: Logfile of failure stored in: /OE/build/oe-core/tmp-glibc/
> work/core2-64-oe-linux/iputils/s20161105-r0/temp/log.do_package_qa.762
> 7
> > ERROR: Task (/OE/build/oe-core/openembedded-core/meta/
> recipes-extended/iputils/iputils_s20161105.bb:do_package_qa) failed
> with exit code '1'
> >
> > * But if you cleansstate iputils as well (after removing libidn from
> > gnutls PACKAGECONFIG) to empty iputils RSS, then you get the error
> about
> > missing idna.h:
> > http://errors.yoctoproject.org/Errors/Build/53213/
> >
> > * Adding the libidn dependency explicitly in iputils recipe fixes the
> > issue.
> >
> > Signed-off-by: Martin Jansa <[email protected]>
> > ---
> > meta/recipes-extended/iputils/iputils_s20161105.bb | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-extended/iputils/iputils_s20161105.bb
> b/meta/recipes-extended/iputils/iputils_s20161105.bb
> > index ad7dbc4d4a..0125739b03 100644
> > --- a/meta/recipes-extended/iputils/iputils_s20161105.bb
> > +++ b/meta/recipes-extended/iputils/iputils_s20161105.bb
> > @@ -23,8 +23,11 @@ UPSTREAM_CHECK_GITTAGREGEX = "(?P<pver>s\d+)"
> >
> > EXTRA_OEMAKE = "-e MAKEFLAGS="
> >
> > +PACKAGECONFIG ?= ""
>
> It looks like mut (and now master-next) have picked up v1 of this
> patch, where libidn is enabled by default.
>
> > +PACKAGECONFIG[libidn] = "USE_IDN=yes,USE_IDN=no,libidn"
> > +
> > do_compile () {
> > - oe_runmake 'CC=${CC} -D_GNU_SOURCE' VPATH="${STAGING_LIBDIR}:${
> STAGING_DIR_HOST}/${base_libdir}" all
> > + oe_runmake 'CC=${CC} -D_GNU_SOURCE'
> > + VPATH="${STAGING_LIBDIR}:${
> STAGING_DIR_HOST}/${base_libdir}" ${PACKAGECONFIG_CONFARGS} all
> > }
> >
> > do_install () {
> > --
> > 2.15.1
> >
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > [email protected]
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180320/dc4e3bfe/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 20 Mar 2018 12:51:04 +0200
From: "Maxin B. John" <[email protected]>
To: [email protected]
Subject: [OE-core] [PATCH v2] libsolv: refresh the patch
Message-ID: <[email protected]>
fixes:
WARNING: libsolv-0.6.33-r0 do_patch:
Some of the context lines in patches were ignored. This can lead to incorrectly
applied patches.
The context lines in the patches can be updated with devtool:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Then the updated patches and the source tree (in devtool's workspace) should be
reviewed to make sure the patches apply in the correct place and don't
introduce duplicate lines (which can, and does happen when some of the context
is ignored). Further information:
http://lists.openembedded.org/pipermail/openembedded-core/2018-March/148675.html
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
Details:
Applying patch
0001-Add-fallback-fopencookie-implementation.patch
patching file ext/CMakeLists.txt
patching file ext/solv_xfopen.c
Hunk #1 succeeded at 12 with fuzz 1 (offset -1 lines).
Hunk #2 succeeded at 25 (offset -18 lines).
Hunk #3 succeeded at 34 (offset -18 lines).
Hunk #4 succeeded at 46 (offset -18 lines).
patching file ext/solv_xfopen_fallback_fopencookie.c
patching file ext/solv_xfopen_fallback_fopencookie.h
Now at patch 0001-Add-fallback-fopencookie-implementation.patch
Signed-off-by: Maxin B. John <[email protected]>
---
...0001-Add-fallback-fopencookie-implementation.patch | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git
a/meta/recipes-extended/libsolv/libsolv/0001-Add-fallback-fopencookie-implementation.patch
b/meta/recipes-extended/libsolv/libsolv/0001-Add-fallback-fopencookie-implementation.patch
index a575d0e..ef0dd82 100644
---
a/meta/recipes-extended/libsolv/libsolv/0001-Add-fallback-fopencookie-implementation.patch
+++ b/meta/recipes-extended/libsolv/libsolv/0001-Add-fallback-fopencooki
+++ e-implementation.patch
@@ -1,4 +1,4 @@
-From 4d9b6ec30b78d00ead0a22eb5d047dcdba37e99c Mon Sep 17 00:00:00 2001
+From 6224f087120c9ca41b302ac85d611a7280edda33 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Neal=20Gompa=20=28=E3=83=8B=E3=83=BC=E3=83=AB=E3=83=BB?=
=?UTF-8?q?=E3=82=B3=E3=82=99=E3=83=B3=E3=83=8F=E3=82=9A=29?=
<[email protected]>
@@ -13,6 +13,7 @@ Alex Kanavin: rebased CMakeLists.txt change to apply to
latest upstream code.
Upstream-Status: Denied [https://github.com/openSUSE/libsolv/pull/112]
Signed-off-by: Alexander Kanavin <[email protected]>
+
---
ext/CMakeLists.txt | 7 ++
ext/solv_xfopen.c | 10 +--
@@ -23,7 +24,7 @@ Signed-off-by: Alexander Kanavin <[email protected]>
create mode 100644 ext/solv_xfopen_fallback_fopencookie.h
diff --git a/ext/CMakeLists.txt b/ext/CMakeLists.txt -index 586eda8..477a2ef
100644
+index b8917a2..fac6c32 100644
--- a/ext/CMakeLists.txt
+++ b/ext/CMakeLists.txt
@@ -4,6 +4,13 @@ SET (libsolvext_SRCS
@@ -41,11 +42,11 @@ index 586eda8..477a2ef 100644
SET (libsolvext_SRCS ${libsolvext_SRCS}
pool_fileconflicts.c repo_rpmdb.c) diff --git a/ext/solv_xfopen.c
b/ext/solv_xfopen.c -index b0421bf..31345dd 100644
+index 2c64bb6..eb3a3ad 100644
--- a/ext/solv_xfopen.c
+++ b/ext/solv_xfopen.c
-@@ -13,6 +13,10 @@
- #include <zlib.h>
+@@ -12,6 +12,10 @@
+ #include <string.h>
#include <fcntl.h>
+#if !defined(HAVE_FUNOPEN) && !defined(HAVE_FOPENCOOKIE) @@ -55,7 +56,7 @@
index b0421bf..31345dd 100644
#include "solv_xfopen.h"
#include "util.h"
-@@ -39,7 +43,7 @@ static FILE *cookieopen(void *cookie, const char *mode,
+@@ -21,7 +25,7 @@ static FILE *cookieopen(void *cookie, const char
+*mode,
ssize_t (*cwrite)(void *, const char *, size_t),
int (*cclose)(void *))
{
@@ -64,7 +65,7 @@ index b0421bf..31345dd 100644
if (!cookie)
return 0;
return funopen(cookie,
-@@ -48,7 +52,7 @@ static FILE *cookieopen(void *cookie, const char *mode,
+@@ -30,7 +34,7 @@ static FILE *cookieopen(void *cookie, const char
+*mode,
(fpos_t (*)(void *, fpos_t, int))NULL,
/* seekfn */
cclose
);
@@ -73,7 +74,7 @@ index b0421bf..31345dd 100644
cookie_io_functions_t cio;
if (!cookie)
-@@ -60,8 +64,6 @@ static FILE *cookieopen(void *cookie, const char *mode,
+@@ -42,8 +46,6 @@ static FILE *cookieopen(void *cookie, const char
+*mode,
cio.write = cwrite;
cio.close = cclose;
return fopencookie(cookie, *mode == 'w' ? "w" : "r", cio); @@ -246,5
+247,5 @@ index 0000000..6a7bfee + +#endif
--
-2.11.0
+2.4.0
--
2.4.0
------------------------------
Message: 5
Date: Tue, 20 Mar 2018 10:52:43 +0000
From: "Burton, Ross" <[email protected]>
To: Alexander Kanavin <[email protected]>
Cc: "[email protected]" <[email protected]>,
"[email protected]"
<[email protected]>
Subject: Re: [OE-core] [yocto] Yocto Project Status WW12?18
Message-ID:
<cajto0ladpow1bccbfhseac7pbv2qnxuiwrnrk6mzev2dvwi...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On 20 March 2018 at 10:07, Alexander Kanavin <
[email protected]> wrote:
> On 03/19/2018 10:07 PM, Burton, Ross wrote:
>
>> Do we have a place identified for new changes (2.6) while 2.5
>> stabilizes.
>>
>>
>> A formal place, no. I tend to queue stuff in a branch if master isn't
>> taking all of my energy, otherwise the patches will sit on the list until
>> 2.5 releases. Typically master and sumo branches won't diverge until
>> post-release.
>>
>
> Which brings me to a question: what is a good schedule and cadence for AUH
> runs? Currently it's run on the 15th of every odd-numbered month (so
> January, March, and so on), but I thought of shifting it one month forward,
> so it doesn't land right in the middle of a feature freeze. Thoughts?
>
How long does a single run take, and why not run it every month?
Ross
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180320/7f228bdd/attachment.html>
------------------------------
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
End of Openembedded-core Digest, Vol 86, Issue 203
**************************************************
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
