date:20230206

[OE-core] [meta-oe][PATCH V1] cpio: add ptest

2023-02-06 Thread Yan Xin Kuan

From: Yan 

enable the ptest function for cpio.

cpio takes 1 second maybe less, so it is fast.

you will get ptest result like this:

PASS: symlink
SKIP: symlink-bad-length
..

Signed-off-by: Yan 
---
 .../distro/include/ptest-packagelists.inc |  1 +
 .../recipes-extended/cpio/cpio-2.13/run-ptest | 10 ++
 meta/recipes-extended/cpio/cpio_2.13.bb   | 19 ++-
 3 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 meta/recipes-extended/cpio/cpio-2.13/run-ptest

diff --git a/meta/conf/distro/include/ptest-packagelists.inc 
b/meta/conf/distro/include/ptest-packagelists.inc
index d3e18ea4a4..3ca08d2b01 100644
--- a/meta/conf/distro/include/ptest-packagelists.inc
+++ b/meta/conf/distro/include/ptest-packagelists.inc
@@ -12,6 +12,7 @@ PTESTS_FAST = "\
 bc-ptest \
 bluez5-ptest \
 busybox-ptest \
+cpio-ptest \
 diffstat-ptest \
 diffutils-ptest \
 ethtool-ptest \
diff --git a/meta/recipes-extended/cpio/cpio-2.13/run-ptest 
b/meta/recipes-extended/cpio/cpio-2.13/run-ptest
new file mode 100644
index 00..bdac7259c1
--- /dev/null
+++ b/meta/recipes-extended/cpio/cpio-2.13/run-ptest
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+# Define cpio test work dir
+WORKDIR=/usr/lib/cpio/ptest/tests/
+
+# Run test
+cd ${WORKDIR}
+./atconfig ./atlocal ./testsuite
+
+./testsuite 2>&1 | grep -E '[0-9]{1,3}: ' | sed -e 's/^.//' -e 
'/[ok]$/s/^/PASS: /;/FAILED (.*)/s/^/FAIL: /;/skipped (.*)/s/^/SKIP: 
/;/expected failure/ s/^/PASS: /;/UNEXPECTED PASS/s/^/FAIL: /' -e 's/ok$//g' -e 
's/FAILED.*//g' -e 's/skipped.*//g' -e 's/expected failure.*//g' -e 
's/UNEXPECTED PASS.*//g'
diff --git a/meta/recipes-extended/cpio/cpio_2.13.bb 
b/meta/recipes-extended/cpio/cpio_2.13.bb
index eb3dc138a9..1a16b066f5 100644
--- a/meta/recipes-extended/cpio/cpio_2.13.bb
+++ b/meta/recipes-extended/cpio/cpio_2.13.bb
@@ -12,12 +12,13 @@ SRC_URI = "${GNU_MIRROR}/cpio/cpio-${PV}.tar.gz \
file://0001-obstack-Fix-a-clang-warning.patch \
file://CVE-2021-38185.patch \
file://0001-Use-__alignof__-with-clang.patch \
+   file://run-ptest \
"
 
 SRC_URI[md5sum] = "389c5452d667c23b5eceb206f5000810"
 SRC_URI[sha256sum] = 
"e87470d9c984317f658567c03bfefb6b0c829ff17dbf6b0de48d71a4c8f3db88"
 
-inherit autotools gettext texinfo
+inherit autotools gettext texinfo ptest
 
 # Issue applies to use of cpio in SUSE/OBS, doesn't apply to us
 CVE_CHECK_IGNORE += "CVE-2010-4226"
@@ -38,6 +39,22 @@ do_install () {
 mv "${D}${mandir}/man8/rmt.8" "${D}${mandir}/man8/rmt-cpio.8"
 }
 
+do_compile_ptest() {
+oe_runmake -C ${B}/gnu/ check
+oe_runmake -C ${B}/lib/ check
+oe_runmake -C ${B}/rmt/ check
+oe_runmake -C ${B}/src/ check
+oe_runmake -C ${B}/tests/ genfile
+}
+
+do_install_ptest() {
+install -d ${D}${PTEST_PATH}/tests/
+install --mode=755 ${B}/tests/atconfig ${D}${PTEST_PATH}/tests/
+install --mode=755 ${B}/tests/atlocal ${D}${PTEST_PATH}/tests/
+install --mode=755 ${B}/tests/genfile ${D}${PTEST_PATH}/tests/
+install --mode=755 ${S}/tests/testsuite ${D}${PTEST_PATH}/tests/
+}
+
 PACKAGES =+ "${PN}-rmt"
 
 FILES:${PN}-rmt = "${sbindir}/rmt*"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176803): 
https://lists.openembedded.org/g/openembedded-core/message/176803
Mute This Topic: https://lists.openembedded.org/mt/96802432/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] Current high bug count owners for Yocto Project 4.2

2023-02-06 Thread Stephen Jolley

All,

Below is the list as of top 32 bug owners as of the end of WW05 of who have
open medium or higher bugs and enhancements against YP 4.2.   There are 57
possible work days left until the final release candidates for YP 4.2 needs
to be released.


Who

Count


michael.opdenac...@bootlin.com

33


ross.bur...@arm.com

29


randy.macl...@windriver.com

28


richard.pur...@linuxfoundation.org

26


david.re...@windriver.com

23


bruce.ashfi...@gmail.com

20


jpewhac...@gmail.com

10


sakib.sa...@windriver.com

8


pa...@zhukoff.net

7


saul.w...@windriver.com

6


tim.orl...@konsulko.com

4


pi...@toganlabs.com

4


sundeep.kokko...@gmail.com

3


zheng@windriver.com

2


jon.ma...@arm.com

2


naveen.go...@windriver.com

2


rybczyn...@gmail.com

2


bluelightn...@bluelightning.org

2


alexis.loth...@bootlin.com

2


s...@bigsur.com

2


alexandre.bell...@bootlin.com

2


yashinde...@gmail.com

1


tvgamb...@gmail.com

1


st...@sakoman.com

1


hongxu@windriver.com

1


mhalst...@linuxfoundation.org

1


thr...@amazon.de

1


mathew.pro...@gmail.com

1


thomas.per...@bootlin.com

1


louis.ran...@syslinbit.com

1


martin.ja...@gmail.com

1


sundeep.kokko...@windriver.com

1


Grand Total

228

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176802): 
https://lists.openembedded.org/g/openembedded-core/message/176802
Mute This Topic: https://lists.openembedded.org/mt/96800726/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] Yocto Project Newcomer & Unassigned Bugs - Help Needed

2023-02-06 Thread Stephen Jolley

All,

 

The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means people
can find them. They're being listed on the triage page under the appropriate
heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please
review:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and
how to create a bugzilla account at:

https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 409
unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out
with these.  Bugs are split into two types, "true bugs" where things don't
work as they should and "enhancements" which are features we'd want to add
to the system.  There are also roughly four different "priority" classes
right now,  "4.2", "4.3", "4.99" and "Future", the more pressing/urgent
issues being in "4.2" and then "4.3".

 

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com
 ) an e-mail with the bug number you would
like and I will assign it to you (please make sure you have a Bugzilla
account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer
_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176801): 
https://lists.openembedded.org/g/openembedded-core/message/176801
Mute This Topic: https://lists.openembedded.org/mt/96800703/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [meta-oe][PATCH] nlohmann-json: Allow empty main package for SDK

2023-02-06 Thread Khem Raj

On Mon, Feb 6, 2023 at 1:36 PM Tom Hochstein  wrote:
>
> Oops, I don’t often send for non OE-Core and I forgot there was a separate 
> mailing list for that. I usually just cut and paste from here:
>
>
>
> http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded#Sending_patches
>
>
>
> Which makes it easy to overlook the mailing list requirement.
>
>
>
> There are several examples in the repo that use this same pattern. Here’s one:
>
>
>
> https://github.com/openembedded/meta-openembedded/commit/7163946b56539725d5a5868a9318e56e713a4a95
>
>
>
> It has the advantage of not installing the header in the image. Should the 
> -dev solution be preferred?

if these are development headers and libs then yes its better since it
goes with the general philosophy of putting these files in -dev pkgs.

>
>
>
> Tom
>
>
>
> From: Martin Jansa 
> Sent: Monday, February 6, 2023 3:13 PM
> To: Tom Hochstein 
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [meta-oe][PATCH] nlohmann-json: Allow empty main 
> package for SDK
>
>
>
> Wrong ML and why do you want to install empty package? Add nlohmann-json-dev 
> to imx-gpu-sdk recipe instead.
>
>
>
> On Mon, Feb 6, 2023 at 10:09 PM Tom Hochstein  wrote:
>
> The header-only package cannot be included in the SDK without marking
> the main package with ALLOW_EMPTY.
>
> Fixes rootfs problem:
> ```
> The following packages have unmet dependencies:
>  imx-gpu-sdk : Depends: nlohmann-json but it is not installable
> E: Unable to correct problems, you have held broken packages.
> ```
>
> Signed-off-by: Tom Hochstein 
> ---
>  meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb 
> b/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb
> index 502262820..6cf27755e 100644
> --- a/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb
> +++ b/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb
> @@ -18,7 +18,7 @@ inherit cmake
>  EXTRA_OECMAKE += "-DJSON_BuildTests=OFF"
>
>  # nlohmann-json is a header only C++ library, so the main package will be 
> empty.
> -
> +ALLOW_EMPTY:${PN} = "1"
>  RDEPENDS:${PN}-dev = ""
>
>  BBCLASSEXTEND = "native nativesdk"
> --
> 2.25.1
>
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176800): 
https://lists.openembedded.org/g/openembedded-core/message/176800
Mute This Topic: https://lists.openembedded.org/mt/96793459/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [meta-oe][PATCH] nlohmann-json: Allow empty main package for SDK

2023-02-06 Thread Tom Hochstein

Oops, I don't often send for non OE-Core and I forgot there was a separate 
mailing list for that. I usually just cut and paste from here:

http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded#Sending_patches

Which makes it easy to overlook the mailing list requirement.

There are several examples in the repo that use this same pattern. Here's one:

https://github.com/openembedded/meta-openembedded/commit/7163946b56539725d5a5868a9318e56e713a4a95

It has the advantage of not installing the header in the image. Should the -dev 
solution be preferred?

Tom

From: Martin Jansa 
Sent: Monday, February 6, 2023 3:13 PM
To: Tom Hochstein 
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [meta-oe][PATCH] nlohmann-json: Allow empty main package 
for SDK

Wrong ML and why do you want to install empty package? Add nlohmann-json-dev to 
imx-gpu-sdk recipe instead.

On Mon, Feb 6, 2023 at 10:09 PM Tom Hochstein 
mailto:tom.hochst...@nxp.com>> wrote:
The header-only package cannot be included in the SDK without marking
the main package with ALLOW_EMPTY.

Fixes rootfs problem:
```
The following packages have unmet dependencies:
 imx-gpu-sdk : Depends: nlohmann-json but it is not installable
E: Unable to correct problems, you have held broken packages.
```

Signed-off-by: Tom Hochstein 
mailto:tom.hochst...@nxp.com>>
---
 
meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb
 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb
 
b/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb
index 502262820..6cf27755e 100644
--- 
a/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb
+++ 
b/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb
@@ -18,7 +18,7 @@ inherit cmake
 EXTRA_OECMAKE += "-DJSON_BuildTests=OFF"

 # nlohmann-json is a header only C++ library, so the main package will be 
empty.
-
+ALLOW_EMPTY:${PN} = "1"
 RDEPENDS:${PN}-dev = ""

 BBCLASSEXTEND = "native nativesdk"
--
2.25.1




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176799): 
https://lists.openembedded.org/g/openembedded-core/message/176799
Mute This Topic: https://lists.openembedded.org/mt/96793459/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [meta-oe][PATCH] nlohmann-json: Allow empty main package for SDK

2023-02-06 Thread Martin Jansa

Wrong ML and why do you want to install empty package? Add
nlohmann-json-dev to imx-gpu-sdk recipe instead.

On Mon, Feb 6, 2023 at 10:09 PM Tom Hochstein  wrote:

> The header-only package cannot be included in the SDK without marking
> the main package with ALLOW_EMPTY.
>
> Fixes rootfs problem:
> ```
> The following packages have unmet dependencies:
>  imx-gpu-sdk : Depends: nlohmann-json but it is not installable
> E: Unable to correct problems, you have held broken packages.
> ```
>
> Signed-off-by: Tom Hochstein 
> ---
>  meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta-oe/recipes-devtools/nlohmann-json/
> nlohmann-json_3.11.2.bb b/meta-oe/recipes-devtools/nlohmann-json/
> nlohmann-json_3.11.2.bb
> index 502262820..6cf27755e 100644
> --- a/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb
> +++ b/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb
> @@ -18,7 +18,7 @@ inherit cmake
>  EXTRA_OECMAKE += "-DJSON_BuildTests=OFF"
>
>  # nlohmann-json is a header only C++ library, so the main package will be
> empty.
> -
> +ALLOW_EMPTY:${PN} = "1"
>  RDEPENDS:${PN}-dev = ""
>
>  BBCLASSEXTEND = "native nativesdk"
> --
> 2.25.1
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176798): 
https://lists.openembedded.org/g/openembedded-core/message/176798
Mute This Topic: https://lists.openembedded.org/mt/96793459/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [meta-oe][PATCH] nlohmann-json: Allow empty main package for SDK

2023-02-06 Thread Tom Hochstein

The header-only package cannot be included in the SDK without marking
the main package with ALLOW_EMPTY.

Fixes rootfs problem:
```
The following packages have unmet dependencies:
 imx-gpu-sdk : Depends: nlohmann-json but it is not installable
E: Unable to correct problems, you have held broken packages.
```

Signed-off-by: Tom Hochstein 
---
 meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb 
b/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb
index 502262820..6cf27755e 100644
--- a/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb
+++ b/meta-oe/recipes-devtools/nlohmann-json/nlohmann-json_3.11.2.bb
@@ -18,7 +18,7 @@ inherit cmake
 EXTRA_OECMAKE += "-DJSON_BuildTests=OFF"
 
 # nlohmann-json is a header only C++ library, so the main package will be 
empty.
-
+ALLOW_EMPTY:${PN} = "1"
 RDEPENDS:${PN}-dev = ""
 
 BBCLASSEXTEND = "native nativesdk"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176797): 
https://lists.openembedded.org/g/openembedded-core/message/176797
Mute This Topic: https://lists.openembedded.org/mt/96793459/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] SPDX 3 and OE-core CycloneDX support

2023-02-06 Thread Alex Stewart

Thanks for the context; I'll feed this back into our internal discussions.

Looks like I just missed the general meeting for this month. I've joined
the ML and I'll try to attend in the future.

On 2/5/23 05:08, Joshua Watt wrote:

On Fri, Feb 3, 2023 at 12:26 PM Alex Stewart wrote:

Hey Josh,

I have been roadmapping SBOM generation for NI's yocto distro and have a
few open questions about the future of SPDX and the create-spdx bbclass.
Since your name seems to be attached to both of those, I figure you
might have the best insight here.

Also posting to the OE-core ML so that this discussion can help other
members.

1. SPDX 3 timeline. I hear that SPDX 3 is going to be a complete rewrite
of the spec, with more support for modern SBOM discussion topics like
VEX and more comprehensive vulnerability tracking. And it also seems to
me that the timeline for its release is very behind schedule [1], but
still in active development. Can you give a SWAG for how close that new
spec is to completion? Are we months away or years?

Our goal is to provide SPDX 3.0 with "example" SPDX 3.0 documents
before the initial release. This should benefit both projects, since
it means that we can give SPDX real examples of comprehensive SBoMs
before they release the 3.0 spec, and also means that Yocto project
SPDX output should be of high quality.

SPDX 3.0 is moving along and it's getting closer to release, but I
can't say exactly when the release will be. If you have serious
interest in this, I would recommend joining the SPDX meetings:
https://urldefense.com/v3/__https://github.com/spdx/meetings/blob/main/README.md__;!!FbZ0ZwI3Qg!ofUCTG3cuMma5YvThWEwqKVzFJ2AWeMpZT8faPH4PrT-1fujpKm0yyXwYU9fcuvDPHNI0DnNjVqJWLTVF84$

2. If/when SPDX 3 support is released, is it to be assumed that the SPDX
facilities in OE core are going to be upgraded to handle it?

Yes. We should have support for generating either the current SPDX
2.2, or SPDX 3.0

3. The rest of my org is interested in CycloneDX as our common SBOM
format. Have there been any discussions about supporting CDX SBOMs in
OE-core? Any blockers there; or is it something that my org could author
and upstream if we decide to go that route?

As stated, we don't really think supporting CycloneDX is worth our
effort in the project. That effort would probably be better spent
making the conversion tools better.

There's not really any documentation why we made this choice, I just
decided to do it this way when I wrote the implementation. TBH I think
both formats are technically fine, but SPDX had an edge because of the
LF connection between the two projects. Gvien that there are
conversion tools between them, I wasn't really concerned that choosing
one format of the other would cause problems.

[1]
https://urldefense.com/v3/__https://github.com/spdx/spdx-spec/milestone/3__;!!FbZ0ZwI3Qg!ofUCTG3cuMma5YvThWEwqKVzFJ2AWeMpZT8faPH4PrT-1fujpKm0yyXwYU9fcuvDPHNI0DnNjVqJbtlx0Hc$

Appreciate the input,

--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stew...@ni.com

--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stew...@ni.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176796):
https://lists.openembedded.org/g/openembedded-core/message/176796
Mute This Topic: https://lists.openembedded.org/mt/96729387/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] meta/lib/oeqa/selftest/cases/wic: Add tests for kernel installation and skip-kernel-install in wic plugin.

2023-02-06 Thread Kareem Zarka

This commit adds two tests to the wic plugin to verify that the kernel
is installed correctly when `skip-kernel-install` is not provided
and not installed when `skip-kernel-install=true`.
These tests ensure that the wic plugin is working correctly and will
help catch any future issues with kernel installation.

Signed-off-by: Kareem Zarka 
---
 meta/lib/oeqa/selftest/cases/wic.py | 71 +
 1 file changed, 71 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/wic.py 
b/meta/lib/oeqa/selftest/cases/wic.py
index ca1abb970a..40188a866a 100644
--- a/meta/lib/oeqa/selftest/cases/wic.py
+++ b/meta/lib/oeqa/selftest/cases/wic.py
@@ -16,6 +16,7 @@ import hashlib
 from glob import glob
 from shutil import rmtree, copy
 from tempfile import NamedTemporaryFile
+from tempfile import TemporaryDirectory
 
 from oeqa.selftest.case import OESelftestTestCase
 from oeqa.core.decorator import OETestTag
@@ -220,6 +221,76 @@ class Wic(WicTestCase):
 result = runCmd("wic ls %s:1/ -n %s" % (images[0], sysroot))   
 self.assertIn("kernel",result.output)
 
+def test_skip_kernel_install(self):
+"""Test skip_kernel_install in wic plugin"""
+# create a temporary file for the WKS content
+with NamedTemporaryFile("w", suffix=".wks") as wks:
+# write the WKS content to the temporary file
+wks.writelines([
+'part --source bootimg-efi \
+--sourceparams="loader=grub-efi,skip-kernal-install=true"\
+--label boot --active'
+])
+wks.flush()
+# create a temporary directory to extract the disk image to
+with TemporaryDirectory() as tmpdir:
+img = 'core-image-minimal'
+# build the image using the WKS file
+cmd = "wic create %s -e %s -o %s" % (wks.name, img, 
self.resultdir)
+runCmd(cmd)
+wksname = os.path.splitext(os.path.basename(wks.name))[0]
+out = glob(os.path.join(self.resultdir, "%s-*.direct" % 
wksname))
+self.assertEqual(1, len(out))
+
+# extract the content of the disk image to the temporary 
directory
+cmd = "wic cp %s:1 %s" % (out[0], tmpdir)
+runCmd(cmd)
+
+# check if the kernel is installed or not
+kimgtype = get_bb_var('KERNEL_IMAGETYPE', 'core-image-minimal')
+for file in os.listdir(tmpdir):
+if file == kimgtype :
+raise AssertionError(
+"The kernel image '{}' was found in\
+the partition".format(kimgtype)
+)
+
+def test_kernel_installation(self):
+"""Test kernel installation in wic plugin"""
+# create a temporary file for the WKS content
+with NamedTemporaryFile("w", suffix=".wks") as wks:
+# write the WKS content to the temporary file
+wks.writelines([
+'part --source bootimg-efi \
+--sourceparams="loader=grub-efi"\
+--label boot --active\n'
+])
+wks.flush()
+# create a temporary directory to extract the disk image to
+with TemporaryDirectory() as tmpdir:
+img = 'core-image-minimal'
+# build the image using the WKS file
+cmd = "wic create %s -e %s -o %s" % (wks.name, img, 
self.resultdir)
+runCmd(cmd)
+wksname = os.path.splitext(os.path.basename(wks.name))[0]
+out = glob(os.path.join(self.resultdir, "%s-*.direct" % 
wksname))
+self.assertEqual(1, len(out))
+
+# extract the content of the disk image to the temporary 
directory
+cmd = "wic cp %s:1 %s" % (out[0], tmpdir)
+runCmd(cmd)
+
+# check if the kernel is installed or not
+kimgtype = get_bb_var('KERNEL_IMAGETYPE', 'core-image-minimal')
+for file in os.listdir(tmpdir):
+if file == kimgtype :
+found = True
+break
+self.assertTrue(
+found,"The kernel image was not found\
+in the boot prtition".format(kimgtype)
+)
+
 def test_sdimage_bootpart(self):
 """Test creation of sdimage-bootpart image"""
 cmd = "wic create sdimage-bootpart -e core-image-minimal -o %s" % 
self.resultdir
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176795): 
https://lists.openembedded.org/g/openembedded-core/message/176795
Mute This Topic: https://lists.openembedded.org/mt/96791017/21656
Group Owner:

[OE-core] [PATCH] wic/plugins/source/bootimg-efi: Skip installing kernel-image into boot.

2023-02-06 Thread Kareem Zarka

The issue with installing the kernel-image to both rootfs
and boot partition is that some systems rely on the kernel-image in
rootfs and not in the boot partition.
This leads to duplication of the kernel-image, which can cause
unnecessary storage usage and potential compatibility issues.

This patch provides a solution to this problem by adding a new
parameter "skip-kernel-install" to the wic kickstart file, which can
be passed to the plugin.
If the parameter is provided, the plugin will skip installing the
kernel-image to the boot partition, avoiding duplication and potential
issues.

By adding this new parameter, we give the users the option to install
the kernel-image only in rootfs, or to install it in both rootfs and
boot partition, depending on their needs and preferences.
This will help to improve the system's storage usage and compatibility.

Tests for this functionality will be added in the next patch.

Signed-off-by: Kareem Zarka 
---
 scripts/lib/wic/plugins/source/bootimg-efi.py | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py 
b/scripts/lib/wic/plugins/source/bootimg-efi.py
index 4b00913a70..363b9f5242 100644
--- a/scripts/lib/wic/plugins/source/bootimg-efi.py
+++ b/scripts/lib/wic/plugins/source/bootimg-efi.py
@@ -363,9 +363,13 @@ class BootimgEFIPlugin(SourcePlugin):
 objcopy_cmd += " %s %s/EFI/Linux/linux.efi" % (efi_stub, 
hdddir)
 exec_native_cmd(objcopy_cmd, native_sysroot)
 else:
-install_cmd = "install -m 0644 %s/%s %s/%s" % \
-(staging_kernel_dir, kernel, hdddir, kernel)
-exec_cmd(install_cmd)
+# skip-kernal-install was added to source_params to conifgure 
installing the kernel-image.
+# set skip_kernal_install in the kickstart file to skip installing 
it into hdddir.
+# if not set then the kernel-image will be installed.
+if not  source_params.get('skip-kernal-install'):
+install_cmd = "install -m 0644 %s/%s %s/%s" % \
+(staging_kernel_dir, kernel, hdddir, kernel)
+exec_cmd(install_cmd)
 
 if get_bitbake_var("IMAGE_EFI_BOOT_FILES"):
 for src_path, dst_path in cls.install_task:
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176794): 
https://lists.openembedded.org/g/openembedded-core/message/176794
Mute This Topic: https://lists.openembedded.org/mt/96791012/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] SPDX 3 and OE-core CycloneDX support

2023-02-06 Thread Alex Stewart




On 2/5/23 08:11, Richard Purdie wrote:

On Sat, 2023-02-04 at 15:47 -0600, Alex Stewart wrote:

On 2/3/23 17:06, Richard Purdie wrote:

On Fri, 2023-02-03 at 12:26 -0600, Alex Stewart wrote:

Hey Josh,

I have been roadmapping SBOM generation for NI's yocto distro and have a
few open questions about the future of SPDX and the create-spdx bbclass.
Since your name seems to be attached to both of those, I figure you
might have the best insight here.

Also posting to the OE-core ML so that this discussion can help other
members.


1. SPDX 3 timeline. I hear that SPDX 3 is going to be a complete rewrite
of the spec, with more support for modern SBOM discussion topics like
VEX and more comprehensive vulnerability tracking. And it also seems to
me that the timeline for its release is very behind schedule [1], but
still in active development. Can you give a SWAG for how close that new
spec is to completion? Are we months away or years?

2. If/when SPDX 3 support is released, is it to be assumed that the SPDX
facilities in OE core are going to be upgraded to handle it?

Assuming someone does the work, which is likely, yes. We did namespace
the class in master to prepare for that.


3. The rest of my org is interested in CycloneDX as our common SBOM
format. Have there been any discussions about supporting CDX SBOMs in
OE-core? Any blockers there; or is it something that my org could author
and upstream if we decide to go that route?

At this point OpenEmbedded/Yocto Project has decided to go the SPDX
route for various reasons.

Are those reasons documented somewhere?

Something about CDX rubs me the wrong way (besides it being named like
an off-brand printer company), but I can't put my finger on what. So if
there are technical reasons that it is less desirable for the OE
usecase, I'd like to know about them.

I think I share that same feeling but it is hard to put a finger on
why.

I'm not sure anything was documented but there was a discussion by the
TSC when we made the decision. Some rough random thoughts:

* SPDX did go the extra step of becoming an ISO standard

* We (as a community) have much better contacts with the SPDX
   community. It is a fellow Linux Foundation project.

* We already were using SPDX license identifiers so this is a natural
   progression/alignment.

* Looking at the CDX repositories and mailing lists, the discussions
   and contributions do look to be from a much smaller ecosystem

* SPDX are interested in engaging with us, which as Joshua mentions,
   does have benefits. If we run into challenges, we can likely seek
   help. We're actively involved with 3.0 which means we can hopefully
   ensure it works well for us.

Both specifications do encode roughly the same information so the
project alignment with SPDX and the "social" aspects likely tipped the
balance.


That's good context. Thanks.


My understanding is that CDX has better support for embedding
vulnerability (+VEX) and attestation elements into its DOM, which is
something that our Aero-Def customers will be interested in. I suppose I
can build workflows to add that information after converting the OE-SPDX
document to CDX, but I'd like to integrate the whole thing into an OE
build, if possible.

I think CDX added VEX information in the last year or so and SPDX plans
to do so in their 3.0. I have had the feeling it is due soon.


I'm not sure I want to see two formats being
added directly to the core, the better solution would likely be to
translate the SPDX output into CycloneDX if/as needed.

I'm concerned about the lossiness of that conversion. Based on the
CDX-SPDX mapping document in the cdx2spdx tool repo [1], they seem
roughly compatible. But I haven't been able to find a clean tool which
converts the other direction, nor a mapping document for the SPDX->CDX
pathway.

You could take that different ways but it could mean people aren't
finding a need to convert SPDX to CDX, meaning SPDX is working for
them.


From what I've seen, I think the SBOM ecosystem is too immature to say 
whether one is preferred over the other. It seems like most folks are 
just working with whatever falls out of their static dep analysis 
tooling, or gets handed to them by their security auditor.


I haven't yet seen evidence that any of our customers have an SBOM 
*pipeline* such that they would need to pick a common spec; but I 
suspect that is coming.



I don't really want to have two partially implemented SBoM mechanisms
in YP/OE so I'd probably suggest any CDX code was a separate layer at
this point. If there is actual missing capability, I'd be asking SPDX
to resolve it :)


Understood. I'll assume that we'll have to maintain our own layer, if we 
go that route.



Cheers,

Richard

(copying Kate Stewart to the discussion)



--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stew...@ni.com


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176793):

Re: [OE-core][PATCH] libgit: add ptest for libgit2

2023-02-06 Thread jason.lau

Hi Alex,

>//Thanks, can you add this to the the patch description? Is it possible to add 
>the installation rules into it as well, and then offer the patch upstream?
I thinks you are right, I should try to send the patch the libgit2 upstream 
first.

>// It's probably time we split slow ptests into subsets and test them in 
>parallel with two different image recipes. Can you look into that please?

No problem, I could do it. it's my great honor.

Thanks,
haitao

-Original Message-
From: Alexander Kanavin  
Sent: Monday, February 6, 2023 5:55 PM
To: Liu, Haitao 
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core][PATCH] libgit: add ptest for libgit2

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.

Thanks, can you add this to the the patch description? Is it possible to add 
the installation rules into it as well, and then offer the patch upstream?

It's probably time we split slow ptests into subsets and test them in parallel 
with two different image recipes. Can you look into that please?

Alex


On Mon, 6 Feb 2023 at 10:43, Liu, Haitao  wrote:
>
> HI Alex
>
> >// Did you use kvm? 21 minutes looks excessive, and I'm not sure we want to 
> >lengthen the ptest by this much. libgit2 is not at the core of the typical 
> >linux stack.
>
> I have tested libgit2 on a intel board with "Intel(R) Genuine Intel(R) CPU", 
> not KVM. It took so much time because that it has 2885 testcases.
>
> >// The added patch needs a better commit message. What does it add or change 
> >and why? Why is it inappropriate for upstream submission?
>
> An absolute path (CLAR_FIXTURES)is defined as specifying the location of the 
> resource files. The CLAR_FIXTURES is set at compile time.
> The test binary will try to load the files from the absolute patch which does 
> not exist on target board and  it  yields a lot of errors about "No such file 
> or directory. "
> So I  have to change CLAR_FIXTURES to PTEST path (/usr/lib/libgit2/ptest/).
>
>
> Thanks,
> haitao
>
> -Original Message-
> From: Alexander Kanavin 
> Sent: Monday, February 6, 2023 4:49 PM
> To: Liu, Haitao 
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core][PATCH] libgit: add ptest for libgit2
>
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and 
> know the content is safe.
>
> Did you use kvm? 21 minutes looks excessive, and I'm not sure we want to 
> lengthen the ptest by this much. libgit2 is not at the core of the typical 
> linux stack.
>
> The added patch needs a better commit message. What does it add or change and 
> why? Why is it inappropriate for upstream submission?
>
> Alex
>
> On Mon, 6 Feb 2023 at 09:44, jason.lau  wrote:
> >
> > Add ptest for libgit2.
> > ALl test passed on a trial run and it took around 21m56s to execute 
> > so added curl-ptest to PTESTS_SLOW.
> >
> > Signed-off-by: Liu Haitao 
> > ---
> >  .../distro/include/ptest-packagelists.inc |  1 +
> >  ...ests-add-CLAR_FIXTURES_DIR-for-ptest.patch | 54
> > +++  .../recipes-support/libgit2/libgit2/run-ptest |
> > 7 +++  meta/recipes-support/libgit2/libgit2_1.5.0.bb | 18 ++-
> >  4 files changed, 78 insertions(+), 2 deletions(-)  create mode 
> > 100644
> > meta/recipes-support/libgit2/libgit2/0001-tests-add-CLAR_FIXTURES_DI
> > R-
> > for-ptest.patch  create mode 100644
> > meta/recipes-support/libgit2/libgit2/run-ptest
> >
> > diff --git a/meta/conf/distro/include/ptest-packagelists.inc
> > b/meta/conf/distro/include/ptest-packagelists.inc
> > index 5422ecd378..9b88b58070 100644
> > --- a/meta/conf/distro/include/ptest-packagelists.inc
> > +++ b/meta/conf/distro/include/ptest-packagelists.inc
> > @@ -104,6 +104,7 @@ PTESTS_SLOW = "\
> >  tcl-ptest \
> >  util-linux-ptest \
> >  valgrind-ptest \
> > +libgit2-ptest \
> >  "
> >
> >  PTESTS_SLOW:remove:riscv64 = "valgrind-ptest"
> > diff --git
> > a/meta/recipes-support/libgit2/libgit2/0001-tests-add-CLAR_FIXTURES_
> > DI
> > R-for-ptest.patch
> > b/meta/recipes-support/libgit2/libgit2/0001-tests-add-CLAR_FIXTURES_
> > DI
> > R-for-ptest.patch
> > new file mode 100644
> > index 00..f547d29e8a
> > --- /dev/null
> > +++ b/meta/recipes-support/libgit2/libgit2/0001-tests-add-CLAR_FIXTU
> > +++ RE
> > +++ S_DIR-for-ptest.patch
> > @@ -0,0 +1,54 @@
> > +From 7ae59e785260bb820cf1449da84140f8ae613e9f Mon Sep 17 00:00:00
> > +2001
> > +From: Liu Haitao 
> > +Date: Mon, 6 Feb 2023 06:40:20 +0200
> > +Subject: [PATCH] tests: add CLAR_FIXTURES_DIR for ptest
> > +
> > +Upstream-Status: Inappropriate [yocto specific]
> > +
> > +Signed-off-by: Liu Haitao 
> > +---
> > + tests/libgit2/CMakeLists.txt | 8 +++-
> > + tests/util/CMakeLists.txt| 8 +++-
> > + 2 files changed, 14 insertions(+), 2 deletions(-)
> > +
> > +diff --git

Re: [OE-core][PATCH] libgit: add ptest for libgit2

2023-02-06 Thread Alexander Kanavin

Thanks, can you add this to the the patch description? Is it possible
to add the installation rules into it as well, and then offer the
patch upstream?

It's probably time we split slow ptests into subsets and test them in
parallel with two different image recipes. Can you look into that
please?

Alex


On Mon, 6 Feb 2023 at 10:43, Liu, Haitao  wrote:
>
> HI Alex
>
> >// Did you use kvm? 21 minutes looks excessive, and I'm not sure we want to 
> >lengthen the ptest by this much. libgit2 is not at the core of the typical 
> >linux stack.
>
> I have tested libgit2 on a intel board with "Intel(R) Genuine Intel(R) CPU", 
> not KVM. It took so much time because that it has 2885 testcases.
>
> >// The added patch needs a better commit message. What does it add or change 
> >and why? Why is it inappropriate for upstream submission?
>
> An absolute path (CLAR_FIXTURES)is defined as specifying the location of the 
> resource files. The CLAR_FIXTURES is set at compile time.
> The test binary will try to load the files from the absolute patch which does 
> not exist on target board and  it  yields a lot of errors about "No such file 
> or directory. "
> So I  have to change CLAR_FIXTURES to PTEST path (/usr/lib/libgit2/ptest/).
>
>
> Thanks,
> haitao
>
> -Original Message-
> From: Alexander Kanavin 
> Sent: Monday, February 6, 2023 4:49 PM
> To: Liu, Haitao 
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core][PATCH] libgit: add ptest for libgit2
>
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender and 
> know the content is safe.
>
> Did you use kvm? 21 minutes looks excessive, and I'm not sure we want to 
> lengthen the ptest by this much. libgit2 is not at the core of the typical 
> linux stack.
>
> The added patch needs a better commit message. What does it add or change and 
> why? Why is it inappropriate for upstream submission?
>
> Alex
>
> On Mon, 6 Feb 2023 at 09:44, jason.lau  wrote:
> >
> > Add ptest for libgit2.
> > ALl test passed on a trial run and it took around 21m56s to execute so
> > added curl-ptest to PTESTS_SLOW.
> >
> > Signed-off-by: Liu Haitao 
> > ---
> >  .../distro/include/ptest-packagelists.inc |  1 +
> >  ...ests-add-CLAR_FIXTURES_DIR-for-ptest.patch | 54
> > +++  .../recipes-support/libgit2/libgit2/run-ptest |
> > 7 +++  meta/recipes-support/libgit2/libgit2_1.5.0.bb | 18 ++-
> >  4 files changed, 78 insertions(+), 2 deletions(-)  create mode 100644
> > meta/recipes-support/libgit2/libgit2/0001-tests-add-CLAR_FIXTURES_DIR-
> > for-ptest.patch  create mode 100644
> > meta/recipes-support/libgit2/libgit2/run-ptest
> >
> > diff --git a/meta/conf/distro/include/ptest-packagelists.inc
> > b/meta/conf/distro/include/ptest-packagelists.inc
> > index 5422ecd378..9b88b58070 100644
> > --- a/meta/conf/distro/include/ptest-packagelists.inc
> > +++ b/meta/conf/distro/include/ptest-packagelists.inc
> > @@ -104,6 +104,7 @@ PTESTS_SLOW = "\
> >  tcl-ptest \
> >  util-linux-ptest \
> >  valgrind-ptest \
> > +libgit2-ptest \
> >  "
> >
> >  PTESTS_SLOW:remove:riscv64 = "valgrind-ptest"
> > diff --git
> > a/meta/recipes-support/libgit2/libgit2/0001-tests-add-CLAR_FIXTURES_DI
> > R-for-ptest.patch
> > b/meta/recipes-support/libgit2/libgit2/0001-tests-add-CLAR_FIXTURES_DI
> > R-for-ptest.patch
> > new file mode 100644
> > index 00..f547d29e8a
> > --- /dev/null
> > +++ b/meta/recipes-support/libgit2/libgit2/0001-tests-add-CLAR_FIXTURE
> > +++ S_DIR-for-ptest.patch
> > @@ -0,0 +1,54 @@
> > +From 7ae59e785260bb820cf1449da84140f8ae613e9f Mon Sep 17 00:00:00
> > +2001
> > +From: Liu Haitao 
> > +Date: Mon, 6 Feb 2023 06:40:20 +0200
> > +Subject: [PATCH] tests: add CLAR_FIXTURES_DIR for ptest
> > +
> > +Upstream-Status: Inappropriate [yocto specific]
> > +
> > +Signed-off-by: Liu Haitao 
> > +---
> > + tests/libgit2/CMakeLists.txt | 8 +++-
> > + tests/util/CMakeLists.txt| 8 +++-
> > + 2 files changed, 14 insertions(+), 2 deletions(-)
> > +
> > +diff --git a/tests/libgit2/CMakeLists.txt
> > +b/tests/libgit2/CMakeLists.txt index 27f421ad6..e1a95a610 100644
> > +--- a/tests/libgit2/CMakeLists.txt
> >  b/tests/libgit2/CMakeLists.txt
> > +@@ -9,7 +9,13 @@ if(NOT PYTHONINTERP_FOUND)
> > + ENDIF()
> > +
> > + set(CLAR_PATH "${PROJECT_SOURCE_DIR}/tests/clar")
> > +-set(CLAR_FIXTURES "${PROJECT_SOURCE_DIR}/tests/resources/")
> > ++
> > ++IF (CLAR_FIXTURES_DIR)
> > ++  SET(CLAR_FIXTURES "${CLAR_FIXTURES_DIR}/resources/")
> > ++ELSE()
> > ++  set(CLAR_FIXTURES "${PROJECT_SOURCE_DIR}/tests/resources/")
> > ++ENDIF()
> > ++
> > + set(TEST_PATH "${CMAKE_CURRENT_SOURCE_DIR}")
> > + add_definitions(-DCLAR_FIXTURE_PATH=\"${CLAR_FIXTURES}\")
> > + add_definitions(-DCLAR_TMPDIR=\"libgit2_tests\")
> > +diff --git a/tests/util/CMakeLists.txt b/tests/util/CMakeLists.txt
> > +index 232590ffd..c736bb3bb 100644
> > +--- a/tests/util/CMakeLists.txt
> >

Re: [OE-core][PATCH] libgit: add ptest for libgit2

2023-02-06 Thread jason.lau

HI Alex

>// Did you use kvm? 21 minutes looks excessive, and I'm not sure we want to 
>lengthen the ptest by this much. libgit2 is not at the core of the typical 
>linux stack.

I have tested libgit2 on a intel board with "Intel(R) Genuine Intel(R) CPU", 
not KVM. It took so much time because that it has 2885 testcases. 

>// The added patch needs a better commit message. What does it add or change 
>and why? Why is it inappropriate for upstream submission?

An absolute path (CLAR_FIXTURES)is defined as specifying the location of the 
resource files. The CLAR_FIXTURES is set at compile time.  
The test binary will try to load the files from the absolute patch which does 
not exist on target board and  it  yields a lot of errors about "No such file 
or directory. " 
So I  have to change CLAR_FIXTURES to PTEST path (/usr/lib/libgit2/ptest/). 


Thanks,
haitao

-Original Message-
From: Alexander Kanavin  
Sent: Monday, February 6, 2023 4:49 PM
To: Liu, Haitao 
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core][PATCH] libgit: add ptest for libgit2

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.

Did you use kvm? 21 minutes looks excessive, and I'm not sure we want to 
lengthen the ptest by this much. libgit2 is not at the core of the typical 
linux stack.

The added patch needs a better commit message. What does it add or change and 
why? Why is it inappropriate for upstream submission?

Alex

On Mon, 6 Feb 2023 at 09:44, jason.lau  wrote:
>
> Add ptest for libgit2.
> ALl test passed on a trial run and it took around 21m56s to execute so 
> added curl-ptest to PTESTS_SLOW.
>
> Signed-off-by: Liu Haitao 
> ---
>  .../distro/include/ptest-packagelists.inc |  1 +
>  ...ests-add-CLAR_FIXTURES_DIR-for-ptest.patch | 54 
> +++  .../recipes-support/libgit2/libgit2/run-ptest |  
> 7 +++  meta/recipes-support/libgit2/libgit2_1.5.0.bb | 18 ++-
>  4 files changed, 78 insertions(+), 2 deletions(-)  create mode 100644 
> meta/recipes-support/libgit2/libgit2/0001-tests-add-CLAR_FIXTURES_DIR-
> for-ptest.patch  create mode 100644 
> meta/recipes-support/libgit2/libgit2/run-ptest
>
> diff --git a/meta/conf/distro/include/ptest-packagelists.inc 
> b/meta/conf/distro/include/ptest-packagelists.inc
> index 5422ecd378..9b88b58070 100644
> --- a/meta/conf/distro/include/ptest-packagelists.inc
> +++ b/meta/conf/distro/include/ptest-packagelists.inc
> @@ -104,6 +104,7 @@ PTESTS_SLOW = "\
>  tcl-ptest \
>  util-linux-ptest \
>  valgrind-ptest \
> +libgit2-ptest \
>  "
>
>  PTESTS_SLOW:remove:riscv64 = "valgrind-ptest"
> diff --git 
> a/meta/recipes-support/libgit2/libgit2/0001-tests-add-CLAR_FIXTURES_DI
> R-for-ptest.patch 
> b/meta/recipes-support/libgit2/libgit2/0001-tests-add-CLAR_FIXTURES_DI
> R-for-ptest.patch
> new file mode 100644
> index 00..f547d29e8a
> --- /dev/null
> +++ b/meta/recipes-support/libgit2/libgit2/0001-tests-add-CLAR_FIXTURE
> +++ S_DIR-for-ptest.patch
> @@ -0,0 +1,54 @@
> +From 7ae59e785260bb820cf1449da84140f8ae613e9f Mon Sep 17 00:00:00 
> +2001
> +From: Liu Haitao 
> +Date: Mon, 6 Feb 2023 06:40:20 +0200
> +Subject: [PATCH] tests: add CLAR_FIXTURES_DIR for ptest
> +
> +Upstream-Status: Inappropriate [yocto specific]
> +
> +Signed-off-by: Liu Haitao 
> +---
> + tests/libgit2/CMakeLists.txt | 8 +++-
> + tests/util/CMakeLists.txt| 8 +++-
> + 2 files changed, 14 insertions(+), 2 deletions(-)
> +
> +diff --git a/tests/libgit2/CMakeLists.txt 
> +b/tests/libgit2/CMakeLists.txt index 27f421ad6..e1a95a610 100644
> +--- a/tests/libgit2/CMakeLists.txt
>  b/tests/libgit2/CMakeLists.txt
> +@@ -9,7 +9,13 @@ if(NOT PYTHONINTERP_FOUND)
> + ENDIF()
> +
> + set(CLAR_PATH "${PROJECT_SOURCE_DIR}/tests/clar")
> +-set(CLAR_FIXTURES "${PROJECT_SOURCE_DIR}/tests/resources/")
> ++
> ++IF (CLAR_FIXTURES_DIR)
> ++  SET(CLAR_FIXTURES "${CLAR_FIXTURES_DIR}/resources/")
> ++ELSE()
> ++  set(CLAR_FIXTURES "${PROJECT_SOURCE_DIR}/tests/resources/")
> ++ENDIF()
> ++
> + set(TEST_PATH "${CMAKE_CURRENT_SOURCE_DIR}")
> + add_definitions(-DCLAR_FIXTURE_PATH=\"${CLAR_FIXTURES}\")
> + add_definitions(-DCLAR_TMPDIR=\"libgit2_tests\")
> +diff --git a/tests/util/CMakeLists.txt b/tests/util/CMakeLists.txt 
> +index 232590ffd..c736bb3bb 100644
> +--- a/tests/util/CMakeLists.txt
>  b/tests/util/CMakeLists.txt
> +@@ -9,7 +9,13 @@ if(NOT PYTHONINTERP_FOUND)
> + ENDIF()
> +
> + set(CLAR_PATH "${libgit2_SOURCE_DIR}/tests/clar")
> +-set(CLAR_FIXTURES "${libgit2_SOURCE_DIR}/tests/resources/")
> ++
> ++IF (CLAR_FIXTURES_DIR)
> ++  SET(CLAR_FIXTURES "${CLAR_FIXTURES_DIR}/resources/")
> ++ELSE()
> ++  set(CLAR_FIXTURES "${libgit2_SOURCE_DIR}/tests/resources/")
> ++ENDIF()
> ++
> + set(TEST_PATH "${CMAKE_CURRENT_SOURCE_DIR}")
> + add_definitions(-DCLAR_FIXTURE_PATH=\"${CLAR_FIXTURES}\")
> + add_definitions(-DCLAR_TMPDIR=\"libgit2_tests\")

Re: [OE-core][PATCH] libgit: add ptest for libgit2

2023-02-06 Thread Alexander Kanavin

Did you use kvm? 21 minutes looks excessive, and I'm not sure we want
to lengthen the ptest by this much. libgit2 is not at the core of the
typical linux stack.

The added patch needs a better commit message. What does it add or
change and why? Why is it inappropriate for upstream submission?

Alex

On Mon, 6 Feb 2023 at 09:44, jason.lau  wrote:
>
> Add ptest for libgit2.
> ALl test passed on a trial run and it took around 21m56s to execute so
> added curl-ptest to PTESTS_SLOW.
>
> Signed-off-by: Liu Haitao 
> ---
>  .../distro/include/ptest-packagelists.inc |  1 +
>  ...ests-add-CLAR_FIXTURES_DIR-for-ptest.patch | 54 +++
>  .../recipes-support/libgit2/libgit2/run-ptest |  7 +++
>  meta/recipes-support/libgit2/libgit2_1.5.0.bb | 18 ++-
>  4 files changed, 78 insertions(+), 2 deletions(-)
>  create mode 100644 
> meta/recipes-support/libgit2/libgit2/0001-tests-add-CLAR_FIXTURES_DIR-for-ptest.patch
>  create mode 100644 meta/recipes-support/libgit2/libgit2/run-ptest
>
> diff --git a/meta/conf/distro/include/ptest-packagelists.inc 
> b/meta/conf/distro/include/ptest-packagelists.inc
> index 5422ecd378..9b88b58070 100644
> --- a/meta/conf/distro/include/ptest-packagelists.inc
> +++ b/meta/conf/distro/include/ptest-packagelists.inc
> @@ -104,6 +104,7 @@ PTESTS_SLOW = "\
>  tcl-ptest \
>  util-linux-ptest \
>  valgrind-ptest \
> +libgit2-ptest \
>  "
>
>  PTESTS_SLOW:remove:riscv64 = "valgrind-ptest"
> diff --git 
> a/meta/recipes-support/libgit2/libgit2/0001-tests-add-CLAR_FIXTURES_DIR-for-ptest.patch
>  
> b/meta/recipes-support/libgit2/libgit2/0001-tests-add-CLAR_FIXTURES_DIR-for-ptest.patch
> new file mode 100644
> index 00..f547d29e8a
> --- /dev/null
> +++ 
> b/meta/recipes-support/libgit2/libgit2/0001-tests-add-CLAR_FIXTURES_DIR-for-ptest.patch
> @@ -0,0 +1,54 @@
> +From 7ae59e785260bb820cf1449da84140f8ae613e9f Mon Sep 17 00:00:00 2001
> +From: Liu Haitao 
> +Date: Mon, 6 Feb 2023 06:40:20 +0200
> +Subject: [PATCH] tests: add CLAR_FIXTURES_DIR for ptest
> +
> +Upstream-Status: Inappropriate [yocto specific]
> +
> +Signed-off-by: Liu Haitao 
> +---
> + tests/libgit2/CMakeLists.txt | 8 +++-
> + tests/util/CMakeLists.txt| 8 +++-
> + 2 files changed, 14 insertions(+), 2 deletions(-)
> +
> +diff --git a/tests/libgit2/CMakeLists.txt b/tests/libgit2/CMakeLists.txt
> +index 27f421ad6..e1a95a610 100644
> +--- a/tests/libgit2/CMakeLists.txt
>  b/tests/libgit2/CMakeLists.txt
> +@@ -9,7 +9,13 @@ if(NOT PYTHONINTERP_FOUND)
> + ENDIF()
> +
> + set(CLAR_PATH "${PROJECT_SOURCE_DIR}/tests/clar")
> +-set(CLAR_FIXTURES "${PROJECT_SOURCE_DIR}/tests/resources/")
> ++
> ++IF (CLAR_FIXTURES_DIR)
> ++  SET(CLAR_FIXTURES "${CLAR_FIXTURES_DIR}/resources/")
> ++ELSE()
> ++  set(CLAR_FIXTURES "${PROJECT_SOURCE_DIR}/tests/resources/")
> ++ENDIF()
> ++
> + set(TEST_PATH "${CMAKE_CURRENT_SOURCE_DIR}")
> + add_definitions(-DCLAR_FIXTURE_PATH=\"${CLAR_FIXTURES}\")
> + add_definitions(-DCLAR_TMPDIR=\"libgit2_tests\")
> +diff --git a/tests/util/CMakeLists.txt b/tests/util/CMakeLists.txt
> +index 232590ffd..c736bb3bb 100644
> +--- a/tests/util/CMakeLists.txt
>  b/tests/util/CMakeLists.txt
> +@@ -9,7 +9,13 @@ if(NOT PYTHONINTERP_FOUND)
> + ENDIF()
> +
> + set(CLAR_PATH "${libgit2_SOURCE_DIR}/tests/clar")
> +-set(CLAR_FIXTURES "${libgit2_SOURCE_DIR}/tests/resources/")
> ++
> ++IF (CLAR_FIXTURES_DIR)
> ++  SET(CLAR_FIXTURES "${CLAR_FIXTURES_DIR}/resources/")
> ++ELSE()
> ++  set(CLAR_FIXTURES "${libgit2_SOURCE_DIR}/tests/resources/")
> ++ENDIF()
> ++
> + set(TEST_PATH "${CMAKE_CURRENT_SOURCE_DIR}")
> + add_definitions(-DCLAR_FIXTURE_PATH=\"${CLAR_FIXTURES}\")
> + add_definitions(-DCLAR_TMPDIR=\"libgit2_tests\")
> +--
> +2.39.1
> +
> diff --git a/meta/recipes-support/libgit2/libgit2/run-ptest 
> b/meta/recipes-support/libgit2/libgit2/run-ptest
> new file mode 100644
> index 00..66e0392af6
> --- /dev/null
> +++ b/meta/recipes-support/libgit2/libgit2/run-ptest
> @@ -0,0 +1,7 @@
> +#!/bin/sh
> +
> +cd tests
> +
> +export CLAR_SUMMARY="${PWD}/results.xml"
> +
> +./libgit2_tests -t | sed -e 's|ok .* - # SKIP|SKIP:|' -e 's|not ok .* 
> -|FAIL:|'  -e 's|ok .* -|PASS:|'
> diff --git a/meta/recipes-support/libgit2/libgit2_1.5.0.bb 
> b/meta/recipes-support/libgit2/libgit2_1.5.0.bb
> index ee4d79b11a..aca8b94551 100644
> --- a/meta/recipes-support/libgit2/libgit2_1.5.0.bb
> +++ b/meta/recipes-support/libgit2/libgit2_1.5.0.bb
> @@ -5,12 +5,15 @@ LIC_FILES_CHKSUM = 
> "file://COPYING;md5=112e6bb421dea73cd41de09e777f2d2c"
>
>  DEPENDS = "curl openssl zlib libssh2 libgcrypt libpcre2"
>
> -SRC_URI = "git://github.com/libgit2/libgit2.git;branch=main;protocol=https"
> +SRC_URI = "git://github.com/libgit2/libgit2.git;branch=main;protocol=https \
> +   file://0001-tests-add-CLAR_FIXTURES_DIR-for-ptest.patch \
> +   file://run-ptest \
> +  "
>  SRCREV = "fbea439d4b6fc91c6b619d01b85ab3b7746e4c19"
>
>  S = "${WORKDIR}/git"
>
> -inherit cmake
> +inherit

[OE-core][PATCH] libgit: add ptest for libgit2

2023-02-06 Thread jason.lau

Add ptest for libgit2.
ALl test passed on a trial run and it took around 21m56s to execute so
added curl-ptest to PTESTS_SLOW.

Signed-off-by: Liu Haitao 
---
 .../distro/include/ptest-packagelists.inc |  1 +
 ...ests-add-CLAR_FIXTURES_DIR-for-ptest.patch | 54 +++
 .../recipes-support/libgit2/libgit2/run-ptest |  7 +++
 meta/recipes-support/libgit2/libgit2_1.5.0.bb | 18 ++-
 4 files changed, 78 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-support/libgit2/libgit2/0001-tests-add-CLAR_FIXTURES_DIR-for-ptest.patch
 create mode 100644 meta/recipes-support/libgit2/libgit2/run-ptest

diff --git a/meta/conf/distro/include/ptest-packagelists.inc 
b/meta/conf/distro/include/ptest-packagelists.inc
index 5422ecd378..9b88b58070 100644
--- a/meta/conf/distro/include/ptest-packagelists.inc
+++ b/meta/conf/distro/include/ptest-packagelists.inc
@@ -104,6 +104,7 @@ PTESTS_SLOW = "\
 tcl-ptest \
 util-linux-ptest \
 valgrind-ptest \
+libgit2-ptest \
 "
 
 PTESTS_SLOW:remove:riscv64 = "valgrind-ptest"
diff --git 
a/meta/recipes-support/libgit2/libgit2/0001-tests-add-CLAR_FIXTURES_DIR-for-ptest.patch
 
b/meta/recipes-support/libgit2/libgit2/0001-tests-add-CLAR_FIXTURES_DIR-for-ptest.patch
new file mode 100644
index 00..f547d29e8a
--- /dev/null
+++ 
b/meta/recipes-support/libgit2/libgit2/0001-tests-add-CLAR_FIXTURES_DIR-for-ptest.patch
@@ -0,0 +1,54 @@
+From 7ae59e785260bb820cf1449da84140f8ae613e9f Mon Sep 17 00:00:00 2001
+From: Liu Haitao 
+Date: Mon, 6 Feb 2023 06:40:20 +0200
+Subject: [PATCH] tests: add CLAR_FIXTURES_DIR for ptest
+
+Upstream-Status: Inappropriate [yocto specific]
+
+Signed-off-by: Liu Haitao 
+---
+ tests/libgit2/CMakeLists.txt | 8 +++-
+ tests/util/CMakeLists.txt| 8 +++-
+ 2 files changed, 14 insertions(+), 2 deletions(-)
+
+diff --git a/tests/libgit2/CMakeLists.txt b/tests/libgit2/CMakeLists.txt
+index 27f421ad6..e1a95a610 100644
+--- a/tests/libgit2/CMakeLists.txt
 b/tests/libgit2/CMakeLists.txt
+@@ -9,7 +9,13 @@ if(NOT PYTHONINTERP_FOUND)
+ ENDIF()
+ 
+ set(CLAR_PATH "${PROJECT_SOURCE_DIR}/tests/clar")
+-set(CLAR_FIXTURES "${PROJECT_SOURCE_DIR}/tests/resources/")
++
++IF (CLAR_FIXTURES_DIR)
++  SET(CLAR_FIXTURES "${CLAR_FIXTURES_DIR}/resources/")
++ELSE()
++  set(CLAR_FIXTURES "${PROJECT_SOURCE_DIR}/tests/resources/")
++ENDIF()
++
+ set(TEST_PATH "${CMAKE_CURRENT_SOURCE_DIR}")
+ add_definitions(-DCLAR_FIXTURE_PATH=\"${CLAR_FIXTURES}\")
+ add_definitions(-DCLAR_TMPDIR=\"libgit2_tests\")
+diff --git a/tests/util/CMakeLists.txt b/tests/util/CMakeLists.txt
+index 232590ffd..c736bb3bb 100644
+--- a/tests/util/CMakeLists.txt
 b/tests/util/CMakeLists.txt
+@@ -9,7 +9,13 @@ if(NOT PYTHONINTERP_FOUND)
+ ENDIF()
+ 
+ set(CLAR_PATH "${libgit2_SOURCE_DIR}/tests/clar")
+-set(CLAR_FIXTURES "${libgit2_SOURCE_DIR}/tests/resources/")
++
++IF (CLAR_FIXTURES_DIR)
++  SET(CLAR_FIXTURES "${CLAR_FIXTURES_DIR}/resources/")
++ELSE()
++  set(CLAR_FIXTURES "${libgit2_SOURCE_DIR}/tests/resources/")
++ENDIF()
++
+ set(TEST_PATH "${CMAKE_CURRENT_SOURCE_DIR}")
+ add_definitions(-DCLAR_FIXTURE_PATH=\"${CLAR_FIXTURES}\")
+ add_definitions(-DCLAR_TMPDIR=\"libgit2_tests\")
+-- 
+2.39.1
+
diff --git a/meta/recipes-support/libgit2/libgit2/run-ptest 
b/meta/recipes-support/libgit2/libgit2/run-ptest
new file mode 100644
index 00..66e0392af6
--- /dev/null
+++ b/meta/recipes-support/libgit2/libgit2/run-ptest
@@ -0,0 +1,7 @@
+#!/bin/sh 
+
+cd tests
+
+export CLAR_SUMMARY="${PWD}/results.xml"
+
+./libgit2_tests -t | sed -e 's|ok .* - # SKIP|SKIP:|' -e 's|not ok .* 
-|FAIL:|'  -e 's|ok .* -|PASS:|' 
diff --git a/meta/recipes-support/libgit2/libgit2_1.5.0.bb 
b/meta/recipes-support/libgit2/libgit2_1.5.0.bb
index ee4d79b11a..aca8b94551 100644
--- a/meta/recipes-support/libgit2/libgit2_1.5.0.bb
+++ b/meta/recipes-support/libgit2/libgit2_1.5.0.bb
@@ -5,12 +5,15 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=112e6bb421dea73cd41de09e777f2d2c"
 
 DEPENDS = "curl openssl zlib libssh2 libgcrypt libpcre2"
 
-SRC_URI = "git://github.com/libgit2/libgit2.git;branch=main;protocol=https"
+SRC_URI = "git://github.com/libgit2/libgit2.git;branch=main;protocol=https \
+   file://0001-tests-add-CLAR_FIXTURES_DIR-for-ptest.patch \
+   file://run-ptest \
+  "
 SRCREV = "fbea439d4b6fc91c6b619d01b85ab3b7746e4c19"
 
 S = "${WORKDIR}/git"
 
-inherit cmake
+inherit cmake ptest
 
 EXTRA_OECMAKE = "\
 -DBUILD_CLAR=OFF \
@@ -19,4 +22,15 @@ EXTRA_OECMAKE = "\
 -DREGEX_BACKEND='pcre2' \
 "
 
+EXTRA_OECMAKE_PTEST = " -DBUILD_CLAR=ON -DVALGRIND=ON 
-DCLAR_FIXTURES_DIR=${PTEST_PATH}/tests "
+
+EXTRA_OECMAKE += "${@bb.utils.contains('DISTRO_FEATURES', 'ptest', 
'${EXTRA_OECMAKE_PTEST}', '', d)} "
+
+do_install_ptest(){
+install -d ${D}${PTEST_PATH}/tests/
+install ${B}/libgit2_tests ${D}${PTEST_PATH}/tests/
+cp ${S}/tests/resources/ ${D}${PTEST_PATH}/tests/ -rf
+}
+
+
 BBCLASSEXTEND = "native"
-- 
2.39.0

[OE-core] [meta-oe][PATCH V1] cpio: add ptest

[OE-core] Current high bug count owners for Yocto Project 4.2

[OE-core] Yocto Project Newcomer & Unassigned Bugs - Help Needed

Re: [OE-core] [meta-oe][PATCH] nlohmann-json: Allow empty main package for SDK

Re: [OE-core] [meta-oe][PATCH] nlohmann-json: Allow empty main package for SDK

Re: [OE-core] [meta-oe][PATCH] nlohmann-json: Allow empty main package for SDK

[OE-core] [meta-oe][PATCH] nlohmann-json: Allow empty main package for SDK

Re: [OE-core] SPDX 3 and OE-core CycloneDX support

[OE-core] [PATCH] meta/lib/oeqa/selftest/cases/wic: Add tests for kernel installation and skip-kernel-install in wic plugin.

[OE-core] [PATCH] wic/plugins/source/bootimg-efi: Skip installing kernel-image into boot.

Re: [OE-core] SPDX 3 and OE-core CycloneDX support

Re: [OE-core][PATCH] libgit: add ptest for libgit2

Re: [OE-core][PATCH] libgit: add ptest for libgit2

Re: [OE-core][PATCH] libgit: add ptest for libgit2

Re: [OE-core][PATCH] libgit: add ptest for libgit2

[OE-core][PATCH] libgit: add ptest for libgit2

16 matches

Site Navigation

Mail list logo

Footer information