Openembedded-core Digest, Vol 86, Issue 203
A message that is not in the archive (sent off-list or not yet received): mailman.18076.1521543183.1653.openembedded-core@lists.openembedded.org
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
Quoted 7 lines · Yeoh Ee Peng
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
Quoted 8 lines · Ross
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=Lw@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).
Quoted 76 lines · Andre McCurdy
Quoted 10 lines · Martin Jansa
* it got enabled by default, but without the dependency on libidn in:
commit5997981fa2c22609a88b8cbb595dbf7758b2f7c2
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 usinguntil
Quoted 4 lines
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/
f3a461603ef4fb7512ade3bdb73fe1824e294547Quoted 8 lines
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> | ^~~~~~~~Quoted 7 lines
* 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-r0do_package_qa: QA Issue: iputils-pingrdepends on libidn, but it isn't a build dependency, missing libidn in DEPENDS or PACKAGECONFIG? [build-deps]
Quoted 1 line
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]
Quoted 5 lines
ERROR: iputils-s20161105-r0
do_package_qa: QA run found fatal errors. Please consider fixing them.
ERROR: iputils-s20161105-r0do_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.7627
Quoted 1 line
ERROR: Task (/OE/build/oe-core/openembedded-core/meta/
recipes-extended/iputils/iputils_s20161105.bb:do_package_qa) failed with exit code '1'
Quoted 3 lines
* But if you cleansstate iputils as well (after removing libidn from gnutls PACKAGECONFIG) to empty iputils RSS, then you get the error
about
Quoted 6 lines
missing
idna.h:
http://errors.yoctoproject.org/Errors/Build/53213/* Adding the libidn dependency explicitly in iputils recipe fixes the issue.
Review
Quoted 6 lines
Signed-off-by Martin Jansa <[email protected]>--- meta/recipes-extended/iputils/iputils_s20161105.bb | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)(quoted diff) +0
-0b/meta/recipes-extended/iputils/iputils_s20161105.bb
meta/recipes-extended/iputils/iputils_s20161105.bb UPSTREAM_CHECK_GITTAGREGEX = "(?P<pver>s\d+)" · line 26
Quoted 8 lines
index
ad7dbc4d4a..0125739b03100644meta/recipes-extended/iputils/iputils_s20161105.bb +1
-0@@ -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.
Quoted 19 lines
meta/recipes-extended/iputils/iputils_s20161105.bb UPSTREAM_CHECK_GITTAGREGEX = "(?P<pver>s\d+)" · line 27
Quoted 4 lines
meta/recipes-extended/iputils/iputils_s20161105.bb +2
-1+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
meta/recipes-extended/iputils/iputils_s20161105.bb UPSTREAM_CHECK_GITTAGREGEX = "(?P<pver>s\d+)" · line 30
Quoted 1 line
meta/recipes-extended/iputils/iputils_s20161105.bb +1
-0+ oe_runmake 'CC=${CC} -D_GNU_SOURCE' VPATH="${STAGING_LIBDIR}:${STAGING_DIR_HOST}/${base_libdir}" ${PACKAGECONFIG_CONFARGS} all
Quoted 11 lines
meta/recipes-extended/iputils/iputils_s20161105.bb +0
-1} 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
--- ...0001-Add-fallback-fopencookie-implementation.patch | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-)
meta/recipes-extended/libsolv/libsolv/0001-Add-fallback-fopencookie-implementation.patch +10 -9
@@ -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
Signature · 19 lines
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: <CAJTo0LadpoW1BCCbfhsEac7PBV2qNxuiWrnRk6MZeV2DVWiDEA@mail.gmail.com> Content-Type: text/plain; charset="utf-8" On 20 March 2018 at 10:07, Alexander Kanavin <
Quoted 12 lines · [email protected]> wrote:
Quoted 9 lines · Ross
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.
Quoted 5 lines
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>
------------------------------
Signature · 8 lines
_______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core End of Openembedded-core Digest, Vol 86, Issue 203 **************************************************
A message that is not in the archive (sent off-list or not yet received): E0805CCB83E6104E80E61FD34E5788AE5305AF4A@PGSMSX102.gar.corp.intel.com
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/stap2) 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
Quoted 7 lines · Yeoh Ee Peng
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
Quoted 8 lines · Ross
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=Lw@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).
Quoted 77 lines · Andre McCurdy
Quoted 10 lines · Martin Jansa
* it got enabled by default, but without the dependency on libidn in:
commit5997981fa2c22609a88b8cbb595dbf7758b2f7c2
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 usinguntil
Quoted 4 lines
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/
f3a461603ef4fb7512ade3bdb73fe1824e294547Quoted 8 lines
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> | ^~~~~~~~Quoted 7 lines
* 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-r0do_package_qa: QA Issue: iputils-pingrdepends on libidn, but it isn't a build dependency, missing libidn in DEPENDS or PACKAGECONFIG? [build-deps]
Quoted 1 line
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]
Quoted 5 lines
ERROR: iputils-s20161105-r0
do_package_qa: QA run found fatal errors. Please consider fixing them.
ERROR: iputils-s20161105-r0do_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
Quoted 1 line
ERROR: Task (/OE/build/oe-core/openembedded-core/meta/
recipes-extended/iputils/iputils_s20161105.bb:do_package_qa) failed with exit code '1'
Quoted 3 lines
* But if you cleansstate iputils as well (after removing libidn from gnutls PACKAGECONFIG) to empty iputils RSS, then you get the error
about
Quoted 6 lines
missing
idna.h:
http://errors.yoctoproject.org/Errors/Build/53213/* Adding the libidn dependency explicitly in iputils recipe fixes the issue.
Review
Quoted 6 lines
Signed-off-by Martin Jansa <[email protected]>--- meta/recipes-extended/iputils/iputils_s20161105.bb | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)(quoted diff) +0
-0b/meta/recipes-extended/iputils/iputils_s20161105.bb
meta/recipes-extended/iputils/iputils_s20161105.bb UPSTREAM_CHECK_GITTAGREGEX = "(?P<pver>s\d+)" · line 26
Quoted 8 lines
index
ad7dbc4d4a..0125739b03100644meta/recipes-extended/iputils/iputils_s20161105.bb +1
-0@@ -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.
Quoted 20 lines
meta/recipes-extended/iputils/iputils_s20161105.bb UPSTREAM_CHECK_GITTAGREGEX = "(?P<pver>s\d+)" · line 27
Quoted 4 lines
meta/recipes-extended/iputils/iputils_s20161105.bb +2
-1+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
meta/recipes-extended/iputils/iputils_s20161105.bb UPSTREAM_CHECK_GITTAGREGEX = "(?P<pver>s\d+)" · line 31
Quoted 2 lines
meta/recipes-extended/iputils/iputils_s20161105.bb +2
-0+ oe_runmake 'CC=${CC} -D_GNU_SOURCE' + VPATH="${STAGING_LIBDIR}:${STAGING_DIR_HOST}/${base_libdir}" ${PACKAGECONFIG_CONFARGS} all
Quoted 11 lines
meta/recipes-extended/iputils/iputils_s20161105.bb +0
-1} 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
--- ...0001-Add-fallback-fopencookie-implementation.patch | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-)
meta/recipes-extended/libsolv/libsolv/0001-Add-fallback-fopencooki renamed from meta/recipes-extended/libsolv/libsolv/0001-Add-fallback-fopencookie-implementation.patch +0 -0
+++ 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]
+
---
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:
<CAJTo0LadpoW1BCCbfhsEac7PBV2qNxuiWrnRk6MZeV2DVWiDEA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Quoted 12 lines · Alexander Kanavin
Quoted 9 lines · Ross
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.
Quoted 5 lines
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>
------------------------------
Signature · 8 lines
_______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core End of Openembedded-core Digest, Vol 86, Issue 203 **************************************************
Quoted 7 lines · Ee Peng
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-nativeI 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.
Right, there are pros and cons to both options. I think testimage.bbclass has a mechanism for adding dependencies inside the class, so you don't need an additional step. You can add there something like:
TESTIMAGEDEPENDS += "${@bb.utils.contains('TEST_SUITES', 'crosstap', 'systemtap-native:do_populate_sysroot', '', d)}"
On the other hand, providing right bitbake variables to crosstap script may not be possible from command line in the context of testimage.bbclass.
Let me comment on the original patch again.
By the way, it's probably better for you to subscribe to this list as individual mails. Digests make it very hard for you to participate in discussions, and break the mail threads (e.g. I could have missed this email, and no one else can easily see what is it about from the subject).
Alex