Am Freitag, dem 27.01.2023 um 16:14 +0000 schrieb Richard Purdie:

On Fri, 2023-01-27 at 13:30 +0100, Max Krummenacher wrote:

From: Max Krummenacher <max.krummenacher@...>

OE-Core changed the cache handling which made the use of ${BPN} fail.

Parsing recipes...WARNING: .../samhain-standalone.bb: Exception during build_dependencies for
do_configure
WARNING: .../samhain-standalone.bb: Error during finalise of .../samhain-standalone.bb
ERROR: ExpansionError during parsing .../samhain-standalone.bb
Traceback (most recent call last):
  File "Var <MODE_NAME>", line 1, in <module>
bb.data_smart.ExpansionError: Failure expanding variable MODE_NAME, expression was
${@d.getVar('BPN').split('-')[1]} which triggered exception IndexError: list index out of
range
The variable dependency chain for the failure is: MODE_NAME -> SAMHAIN_MODE -> do_configure

Simplify the setting of MODE_NAME and SAMHAIN_MODE by moving them from
the inc file to the recipe files where we know their values.

Relevant commits to produce the error:
bitbake:
ee89ade5 cache/codeparser: Switch to a new BB_CACHEDIR variable for cache location
oe-core:
7c15e03dd3 bitbake.conf: Add BB_HASH_CODEPARSER_VALS

Signed-off-by: Max Krummenacher <max.krummenacher@...>
---
 recipes-ids/samhain/samhain-client.bb     | 3 +++
 recipes-ids/samhain/samhain-server.bb     | 3 +++
 recipes-ids/samhain/samhain-standalone.bb | 3 +++
 recipes-ids/samhain/samhain.inc           | 8 --------
 4 files changed, 9 insertions(+), 8 deletions(-)

This is the second report I've seen of this. I'm wondering about
changing the default PN dummy value in bitbake.conf to include a "-"...

Cheers,

Richard

Richards patch [1] fixes the parsing error too. So we can drop this
one unless the simpler logic is worth taking it.

[1] https://lore.kernel.org/all/20230127163308.2649311-1-richard.purdie@linuxfoundation.org/

Thanks Richard.

Regards
Max

Signed-off-by: Khem Raj <raj.khem@...>
---
recipes-extended/libtirpc/libtirpc_%.bbappend | 14 ++++++++++++++
1 file changed, 14 insertions(+)
create mode 100644 recipes-extended/libtirpc/libtirpc_%.bbappend

diff --git a/recipes-extended/libtirpc/libtirpc_%.bbappend b/recipes-extended/libtirpc/libtirpc_%.bbappend
new file mode 100644
index 0000000..f336a91
--- /dev/null
+++ b/recipes-extended/libtirpc/libtirpc_%.bbappend
@@ -0,0 +1,14 @@
+LIC_FILES_CHKSUM:class-nativesdk:mingw32 = "file://COPYING;md5=1c32c8e351f97e43e1ad6cf7f62de3bf"
+SRCREV:class-nativesdk:mingw32 = "d4d918c1be631d770f09d2769834e5314cc9345a"
+SRC_URI:class-nativesdk:mingw32 = "git://github.com/kraj/libtirpc-mingw;protocol=https;branch=main"
+
+CFLAGS:append:class-nativesdk:mingw32 = " -D__REACTOS__"
+
+EXTRA_OECONF:remove:class-nativesdk:mingw32 = "--disable-gssapi"
+S:class-nativesdk:mingw32 = "${WORKDIR}/git"
+B:class-nativesdk:mingw32 = "${S}"
+
+do_install:append:class-nativesdk:mingw32() {
+ install -Dm 0644 ${D}/etc/netconfig ${D}${sysconfdir}/netconfig
+ rm -rf ${D}/etc
+}
--
2.39.1

On Fri, 2023-01-27 at 13:30 +0100, Max Krummenacher wrote:

From: Max Krummenacher <max.krummenacher@...>

OE-Core changed the cache handling which made the use of ${BPN} fail.

Parsing recipes...WARNING: .../samhain-standalone.bb: Exception during build_dependencies for do_configure
WARNING: .../samhain-standalone.bb: Error during finalise of .../samhain-standalone.bb
ERROR: ExpansionError during parsing .../samhain-standalone.bb
Traceback (most recent call last):
File "Var <MODE_NAME>", line 1, in <module>
bb.data_smart.ExpansionError: Failure expanding variable MODE_NAME, expression was ${@d.getVar('BPN').split('-')[1]} which triggered exception IndexError: list index out of range
The variable dependency chain for the failure is: MODE_NAME -> SAMHAIN_MODE -> do_configure

Simplify the setting of MODE_NAME and SAMHAIN_MODE by moving them from
the inc file to the recipe files where we know their values.

Relevant commits to produce the error:
bitbake:
ee89ade5 cache/codeparser: Switch to a new BB_CACHEDIR variable for cache location
oe-core:
7c15e03dd3 bitbake.conf: Add BB_HASH_CODEPARSER_VALS

Signed-off-by: Max Krummenacher <max.krummenacher@...>
---
recipes-ids/samhain/samhain-client.bb | 3 +++
recipes-ids/samhain/samhain-server.bb | 3 +++
recipes-ids/samhain/samhain-standalone.bb | 3 +++
recipes-ids/samhain/samhain.inc | 8 --------
4 files changed, 9 insertions(+), 8 deletions(-)

This is the second report I've seen of this. I'm wondering about
changing the default PN dummy value in bitbake.conf to include a "-"...

Cheers,

Richard

On 1/27/23 10:51, Richard Purdie wrote:

On Fri, 2023-01-27 at 09:26 +0100, Alexis Lothoré wrote:

On 1/26/23 23:42, Richard Purdie wrote:

On Tue, 2023-01-24 at 18:30 +0100, Alexis Lothoré via
lists.yoctoproject.org wrote:

Thanks. Since I like living dangerously, I've put these on the master
branch for the M2 release build. I wanted to see how this does in a
real world test.

Thanks. Please feel free to reach back if you observe any unwanted side effect,
since most of my knowledge is based on scripts reading and autobuilder builds
history. I have tried to test it as much as possible on my machine, but as I was
discussing with Alexandre Belloni, the many stubs and fake data used do not make
the tests as accurate as the real world case.

The result of the M2 build is here, specifically the regression report:

https://autobuilder.yocto.io/pub/releases/yocto-4.2_M2.rc2/testresults/testresult-regressions-report.txt

(warning, it is a 13MB file, which may hint at some problems)

https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/4844/steps/29/logs/stdio

was the log from running the script. It also suggests there may be a
few issues.

I think we need some improvements to the report. Firstly it should
state at the top which revisions are being compared and any tags they
correspond to. 

Yes, I was thinking about this while tweaking send-qa-email. Another point I
need to understand is how the regression report is managed if resulttool finds
multiple tags in results dir concerning the same yocto revision. I feel that the
result is not the same if it finds one tag or multiple tags for the same
revision. Does it really make sense to check regression against multiple tags
referencing the same yocto revision ? If so, indeed we should make the tag name
appear. If not, how to distinguish which tag is appropriate ? This question is
more linked to resulttool internals than to send-qa-email.

Next, we need to understand why the large chunk of tests "disappeared".
it may be related to the "Failed to retrieved" messages?

I also happen to know the reproducibility tests failed in this build,
yet the regression report has no mention of that.

ACK, I will take a look.

So the patches are a start but there is much more to do.

Regards,

--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Hi

Please disregard this duplicate. Forgot to delete a backup copy before
git send-email.
Sorry about the noise.

Max

This is different to the previous error. Yocto itself does not prevent
the recipe from building, but something inside the component is
producing an error during configuration. One of the screenshots
mentions that 'hantro_h1' is not found, so you need to investigate why
is it being searched for and why it's not where it should be. There's
also a message about 'complete log' that you can check.

Alex

From: Max Krummenacher <max.krummenacher@...>

OE-Core changed the cache handling which made the use of ${BPN} no fail.

| Parsing recipes...WARNING: .../samhain-standalone.bb: Exception during build_dependencies for do_configure
| WARNING: .../samhain-standalone.bb: Error during finalise of .../samhain-standalone.bb
| ERROR: ExpansionError during parsing .../samhain-standalone.bb
| Traceback (most recent call last):
| File "Var <MODE_NAME>", line 1, in <module>
| bb.data_smart.ExpansionError: Failure expanding variable MODE_NAME, expression was ${@d.getVar('BPN').split('-')[1]} which triggered exception IndexError: list index out of range
| The variable dependency chain for the failure is: MODE_NAME -> SAMHAIN_MODE -> do_configure

Simplify the setting of MODE_NAME and SAMHAIN_MODE by setting them
in the recipe files where we know their values.

bitbake:
ee89ade5 cache/codeparser: Switch to a new BB_CACHEDIR variable for cache location
oe-core:
7c15e03dd3 bitbake.conf: Add BB_HASH_CODEPARSER_VALS

Signed-off-by: Max Krummenacher <max.krummenacher@...>
---
recipes-ids/samhain/samhain-client.bb | 3 +++
recipes-ids/samhain/samhain-server.bb | 3 +++
recipes-ids/samhain/samhain-standalone.bb | 3 +++
recipes-ids/samhain/samhain.inc | 8 --------
4 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/recipes-ids/samhain/samhain-client.bb b/recipes-ids/samhain/samhain-client.bb
index 2b99e20..0de9c34 100644
--- a/recipes-ids/samhain/samhain-client.bb
+++ b/recipes-ids/samhain/samhain-client.bb
@@ -8,5 +8,8 @@ EXTRA_OECONF += " \
--with-port=${SAMHAIN_PORT} \
"

+MODE_NAME = "client"
+SAMHAIN_MODE = "client"
+
RDEPENDS:${PN} = "acl zlib attr bash"
RCONFLICTS:${PN} = "samhain-standalone"
diff --git a/recipes-ids/samhain/samhain-server.bb b/recipes-ids/samhain/samhain-server.bb
index 51bce07..8bae2d2 100644
--- a/recipes-ids/samhain/samhain-server.bb
+++ b/recipes-ids/samhain/samhain-server.bb
@@ -8,6 +8,9 @@ SRC_URI += "file://samhain-server-volatiles \
file://samhain-server-volatiles.conf \
"

+MODE_NAME = "server"
+SAMHAIN_MODE = "server"
+
TARGET_CC_ARCH += "${LDFLAGS}"

do_install:append() {
diff --git a/recipes-ids/samhain/samhain-standalone.bb b/recipes-ids/samhain/samhain-standalone.bb
index b832dc8..ae9ed2b 100644
--- a/recipes-ids/samhain/samhain-standalone.bb
+++ b/recipes-ids/samhain/samhain-standalone.bb
@@ -7,6 +7,9 @@ SRC_URI += "file://samhain-not-run-ptest-on-host.patch \

PROVIDES += "samhain"

+MODE_NAME = "standalone"
+SAMHAIN_MODE = "no"
+
SYSTEMD_SERVICE:${PN} = "samhain.service"

inherit ptest
diff --git a/recipes-ids/samhain/samhain.inc b/recipes-ids/samhain/samhain.inc
index eb8592d..8967d72 100644
--- a/recipes-ids/samhain/samhain.inc
+++ b/recipes-ids/samhain/samhain.inc
@@ -40,14 +40,6 @@ SYSTEMD_PACKAGES = "${PN}"
SYSTEMD_SERVICE:${PN} = "${INITSCRIPT_NAME}.service"
SYSTEMD_AUTO_ENABLE = "disable"

-# mode mapping:
-# BPN MODE_NAME SAMHAIN_MODE
-# samhain-standalone standalone no
-# samhain-client client client
-# samhain-server server server
-MODE_NAME = "${@d.getVar('BPN').split('-')[1]}"
-SAMHAIN_MODE = "${@oe.utils.ifelse(d.getVar('MODE_NAME') == 'standalone', 'no', '${MODE_NAME}')}"
-
# supports mysql|postgresql|oracle|odbc but postgresql is the only one available

PACKAGECONFIG ??= "postgresql ps \
--
2.35.3

From: Max Krummenacher <max.krummenacher@...>

OE-Core changed the cache handling which made the use of ${BPN} fail.

| Parsing recipes...WARNING: .../samhain-standalone.bb: Exception during build_dependencies for do_configure
| WARNING: .../samhain-standalone.bb: Error during finalise of .../samhain-standalone.bb
| ERROR: ExpansionError during parsing .../samhain-standalone.bb
| Traceback (most recent call last):
| File "Var <MODE_NAME>", line 1, in <module>
| bb.data_smart.ExpansionError: Failure expanding variable MODE_NAME, expression was ${@d.getVar('BPN').split('-')[1]} which triggered exception IndexError: list index out of range
| The variable dependency chain for the failure is: MODE_NAME -> SAMHAIN_MODE -> do_configure

Simplify the setting of MODE_NAME and SAMHAIN_MODE by moving them from
the inc file to the recipe files where we know their values.

Relevant commits to produce the error:
bitbake:
ee89ade5 cache/codeparser: Switch to a new BB_CACHEDIR variable for cache location
oe-core:
7c15e03dd3 bitbake.conf: Add BB_HASH_CODEPARSER_VALS

Signed-off-by: Max Krummenacher <max.krummenacher@...>
---
recipes-ids/samhain/samhain-client.bb | 3 +++
recipes-ids/samhain/samhain-server.bb | 3 +++
recipes-ids/samhain/samhain-standalone.bb | 3 +++
recipes-ids/samhain/samhain.inc | 8 --------
4 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/recipes-ids/samhain/samhain-client.bb b/recipes-ids/samhain/samhain-client.bb
index 2b99e20..0de9c34 100644
--- a/recipes-ids/samhain/samhain-client.bb
+++ b/recipes-ids/samhain/samhain-client.bb
@@ -8,5 +8,8 @@ EXTRA_OECONF += " \
--with-port=${SAMHAIN_PORT} \
"

+MODE_NAME = "client"
+SAMHAIN_MODE = "client"
+
RDEPENDS:${PN} = "acl zlib attr bash"
RCONFLICTS:${PN} = "samhain-standalone"
diff --git a/recipes-ids/samhain/samhain-server.bb b/recipes-ids/samhain/samhain-server.bb
index 51bce07..8bae2d2 100644
--- a/recipes-ids/samhain/samhain-server.bb
+++ b/recipes-ids/samhain/samhain-server.bb
@@ -8,6 +8,9 @@ SRC_URI += "file://samhain-server-volatiles \
file://samhain-server-volatiles.conf \
"

+MODE_NAME = "server"
+SAMHAIN_MODE = "server"
+
TARGET_CC_ARCH += "${LDFLAGS}"

do_install:append() {
diff --git a/recipes-ids/samhain/samhain-standalone.bb b/recipes-ids/samhain/samhain-standalone.bb
index b832dc8..ae9ed2b 100644
--- a/recipes-ids/samhain/samhain-standalone.bb
+++ b/recipes-ids/samhain/samhain-standalone.bb
@@ -7,6 +7,9 @@ SRC_URI += "file://samhain-not-run-ptest-on-host.patch \

PROVIDES += "samhain"

+MODE_NAME = "standalone"
+SAMHAIN_MODE = "no"
+
SYSTEMD_SERVICE:${PN} = "samhain.service"

inherit ptest
diff --git a/recipes-ids/samhain/samhain.inc b/recipes-ids/samhain/samhain.inc
index eb8592d..8967d72 100644
--- a/recipes-ids/samhain/samhain.inc
+++ b/recipes-ids/samhain/samhain.inc
@@ -40,14 +40,6 @@ SYSTEMD_PACKAGES = "${PN}"
SYSTEMD_SERVICE:${PN} = "${INITSCRIPT_NAME}.service"
SYSTEMD_AUTO_ENABLE = "disable"

-# mode mapping:
-# BPN MODE_NAME SAMHAIN_MODE
-# samhain-standalone standalone no
-# samhain-client client client
-# samhain-server server server
-MODE_NAME = "${@d.getVar('BPN').split('-')[1]}"
-SAMHAIN_MODE = "${@oe.utils.ifelse(d.getVar('MODE_NAME') == 'standalone', 'no', '${MODE_NAME}')}"
-
# supports mysql|postgresql|oracle|odbc but postgresql is the only one available

PACKAGECONFIG ??= "postgresql ps \
--
2.35.3

Hi Nikita

*IMAGE_INSTALL:append = "gstreamer1.0 gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-plugins-bad

If you do not put a space after the double quotation marks, the package names before and after will be attached to each other during the merge.

See https://docs.yoctoproject.org/bitbake/2.2/bitbake-user-manual/bitbake-user-manual-metadata.html#appending-and-prepending-override-style-syntax

On 2023/01/27 20:48, Nikita Gupta wrote:

Hello List,
As i earlier mentioned that i want to do some customisation in local.conf by adding few pkgs (below).
*IMAGE_INSTALL:append = "gstreamer1.0 gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-plugins-bad gstreamer1.0-plugins-ugly  gstreamer1.0-libav imx-vpuwrap imx-gpu-g2d imx-gpu-viv gstreamer1.0-plugins-imx imx-gst1.0-plugin"
LICENSE_FLAGS_ACCEPTED = " commercial"
IMAGE_INSTALL:append = "kernel-devsrc"
IMAGE_INSTALL:append = "gstreamer1.0-rtsp-server gst-variable-rtsp-server"
IMAGE_INSTALL:append = " gtk+3"
CORE_IMAGE_EXTRA_INSTALL += " opencv libopencv-core-dev libopencv-highgui-dev libopencv-imgproc-dev libopencv-objdetect-dev libopencv-ml-dev"
#LICENSE_FLAGS_WHITELIST = " commercial"
IMAGE_ROOTFS_EXTRA_SPACE = "1048576 "*
 and iafter bitbake m getting below errors.
nikita@nikita-HP-Laptop-15-bs0xx:~/Yocto/imx-yocto-bsp$ *bitbake imx-image-full*
Loading cache: 100% |##########################################################################################################| Time: 0:00:01
Loaded 4736 entries from dependency cache.
Parsing recipes: 100% |########################################################################################################| Time: 0:00:02
Parsing of 3190 .bb files complete (3188 cached, 2 parsed). 4738 targets, 262 skipped, 3 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing RPROVIDES 'imx-gst1.0-pluginkernel-devsrcgstreamer1.0-rtsp-server' (but /home/nikita/Yocto/imx-yocto-bsp/sources/meta-imx/meta-sdk/dynamic-layers/qt6-layer/recipes-fsl/images/imx-image-full.bb <http://imx-image-full.bb> RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'imx-gst1.0-pluginkernel-devsrcgstreamer1.0-rtsp-server' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['imx-gst1.0-pluginkernel-devsrcgstreamer1.0-rtsp-server']
ERROR: Required build target 'imx-image-full' has no buildable providers.
Missing or unbuildable dependency chain was: ['imx-image-full', 'imx-gst1.0-pluginkernel-devsrcgstreamer1.0-rtsp-server']
Summary: There were 2 ERROR messages, returning a non-zero exit code.
These packages are needed i can not remove So please help me what can i do in this.
Thanks in Advance.
On Fri, 27 Jan 2023 at 17:00, Nikita Gupta <nikitagupta2509@... <mailto:nikitagupta2509@...>> wrote:
Hello Alex
When i run bitbake libimxvpuapi2 and it shows below error (images attached).
Can you please tell me that is "libimxvpuapi2" compatible with imx8mplus board?
Thanks in Advance
On Fri, 27 Jan 2023 at 14:35, Alexander Kanavin <alex.kanavin@... <mailto:alex.kanavin@...>> wrote:
The screenshot indicates the problem originates in libimxvpuapi2
recipe. So you should get more information by running 'bitbake
libimxvpuapi2'.
Alex
On Fri, 27 Jan 2023 at 07:46, Nikita Gupta <nikitagupta2509@... <mailto:nikitagupta2509@...>> wrote:
>
> Hello Alexander
>
> I am not getting your query . Can u please explain your question?
>
> Regards
> Nikita Gupta
>
> On Wed, Jan 25, 2023, 18:35 Alexander Kanavin <alex.kanavin@... <mailto:alex.kanavin@...>> wrote:
>>
>> What happens if you bitbake libimx… thingy directly?
>>
>> Alex
>>
>> On Wed 25. Jan 2023 at 13.47, Nikita Gupta <nikitagupta2509@... <mailto:nikitagupta2509@...>> wrote:
>>>
>>> Hello list,
>>>
>>> I was just making image for imx8mplus by adding few pkgs in my local.conf but encountered few errors so i am here
for your help.
>>> I added below pkgs in my local.conf file
>>>
>>> IMAGE_INSTALL:append = "gstreamer1.0 gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-plugins-bad
gstreamer1.0-plugins-ugly  gstreamer1.0-libav imx-vpuwrap imx-gpu-g2d imx-gpu-viv gstreamer1.0-plugins-imx
imx-gst1.0-plugin"
>>> LICENSE_FLAGS_WHITELIST = "commercial"
>>> IMAGE_INSTALL:append = "kernel-devsrc"
>>> IMAGE_INSTALL_append += "gstreamer1.0-rtsp-server gst-variable-rtsp-server"
>>> IMAGE_INSTALL:append = " gtk+3"
>>> CORE_IMAGE_EXTRA_INSTALL += " opencv libopencv-core-dev libopencv-highgui-dev libopencv-imgproc-dev
libopencv-objdetect-dev libopencv-ml-dev"
>>> IMAGE_ROOTFS_EXTRA_SPACE = "1048576 "
>>>
>>> So my local.conf file now looks like this
>>> So i am getting below error after baking my recipe ( Attached image).
>>>
>>> Please tell what should I need to do to resolve this.
>>>
>>> Thanks in advance
>>>
>>>
>>>

--
Takayasu Ito
Solution Department, Lineo Solutions, Inc.
https://www.lineo.co.jp/english/
Email: ito@...
Yocto Project Ambassador

On Fri, 2023-01-27 at 05:13 +0000, Pokybuild User wrote:

A build flagged for QA (yocto-4.2_M2.rc2) was completed on the autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-4.2_M2.rc2


Build hash information:

bitbake: c19035e8e71c419c5688a86bfc9c946c96f638e8
meta-agl: 09135164a21a216c6e3e75d7decce896b92962f0
meta-arm: d8383c11f3f8220d2b989ec73604e5faff988299
meta-aws: 7b4f54b3e1f675e2033f6a589ac519e44e62b58b
meta-intel: b3c7d3ee44e4ab71df44b5be3c48d2f47d89d8a0
meta-mingw: 250617ffa524c082b848487359b9d045703d59c2
meta-openembedded: ceceffcb1e3ef4f9ba7708f77c27e30a7aea61e5
meta-virtualization: 31954471605ae3b41627a0ab7b0dcfe8c5851bd7
oecore: 493f2d163718d78560a2b3ad5d3c0fb34caae8c0
poky: 5e249ec855517765f4b99e8039cb888ffa09c211



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...

A reproducibility issue did occur in this release build in kernel-
devsrc and perf. 

I think we should put this through QA and release note the issue. There
is a patch which I think should fix it but I don't want to rush it in.
We will fix the issue before final release of 4.2.

Cheers,

Richard

On Fri, 2023-01-27 at 09:26 +0100, Alexis Lothoré wrote:

On 1/26/23 23:42, Richard Purdie wrote:

On Tue, 2023-01-24 at 18:30 +0100, Alexis Lothoré via
lists.yoctoproject.org wrote:

Thanks. Since I like living dangerously, I've put these on the master
branch for the M2 release build. I wanted to see how this does in a
real world test.

Thanks. Please feel free to reach back if you observe any unwanted side effect,
since most of my knowledge is based on scripts reading and autobuilder builds
history. I have tried to test it as much as possible on my machine, but as I was
discussing with Alexandre Belloni, the many stubs and fake data used do not make
the tests as accurate as the real world case.

The result of the M2 build is here, specifically the regression report:

https://autobuilder.yocto.io/pub/releases/yocto-4.2_M2.rc2/testresults/testresult-regressions-report.txt

(warning, it is a 13MB file, which may hint at some problems)

https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/4844/steps/29/logs/stdio

was the log from running the script. It also suggests there may be a
few issues.

I think we need some improvements to the report. Firstly it should
state at the top which revisions are being compared and any tags they
correspond to. 

Next, we need to understand why the large chunk of tests "disappeared".
it may be related to the "Failed to retrieved" messages?

I also happen to know the reproducibility tests failed in this build,
yet the regression report has no mention of that.

So the patches are a start but there is much more to do.

Cheers,

Richard

The screenshot indicates the problem originates in libimxvpuapi2
recipe. So you should get more information by running 'bitbake
libimxvpuapi2'.

Alex

On 1/26/23 23:42, Richard Purdie wrote:

On Tue, 2023-01-24 at 18:30 +0100, Alexis Lothoré via
lists.yoctoproject.org wrote:

Thanks. Since I like living dangerously, I've put these on the master
branch for the M2 release build. I wanted to see how this does in a
real world test.

Thanks. Please feel free to reach back if you observe any unwanted side effect,
since most of my knowledge is based on scripts reading and autobuilder builds
history. I have tried to test it as much as possible on my machine, but as I was
discussing with Alexandre Belloni, the many stubs and fake data used do not make
the tests as accurate as the real world case.

I did notice one issue which we'll need to fix in some follow up
patches, I'll reply to the patch about that.

ACK, I am working on it

--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Hi Richard,
thanks for the feedback

On 1/26/23 23:47, Richard Purdie wrote:

On Tue, 2023-01-24 at 18:30 +0100, Alexis Lothoré via lists.yoctoproject.org wrote:

report = subprocess.check_output([resulttool, "report", args.results_dir])
with open(args.results_dir + "/testresult-report.txt", "wb") as f:
f.write(report)

There looks to be a potential issue here since you drop the use of
comparebranch entirely. This comes from config.json:

"BUILD_HISTORY_FORKPUSH" : {"poky-contrib:ross/mut" : "poky:master", "poky:master-next" : "poky:master"},

and basically what it says is that master-next is a force push branch
which should be compared against master (and ross/mut should be
compared against master too).

We need this code so that when we build test branches, we run the
regression comparison against the last known master test results. We
should probably put Alexandre's test branch in there too.

I may have missed that. I need to dig a bit to understand exactly what is
expected here in order to fix it. Noted, I will take a look at it.

Regards

--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

A build flagged for QA (yocto-4.2_M2.rc2) was completed on the autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-4.2_M2.rc2


Build hash information:

bitbake: c19035e8e71c419c5688a86bfc9c946c96f638e8
meta-agl: 09135164a21a216c6e3e75d7decce896b92962f0
meta-arm: d8383c11f3f8220d2b989ec73604e5faff988299
meta-aws: 7b4f54b3e1f675e2033f6a589ac519e44e62b58b
meta-intel: b3c7d3ee44e4ab71df44b5be3c48d2f47d89d8a0
meta-mingw: 250617ffa524c082b848487359b9d045703d59c2
meta-openembedded: ceceffcb1e3ef4f9ba7708f77c27e30a7aea61e5
meta-virtualization: 31954471605ae3b41627a0ab7b0dcfe8c5851bd7
oecore: 493f2d163718d78560a2b3ad5d3c0fb34caae8c0
poky: 5e249ec855517765f4b99e8039cb888ffa09c211



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...

On Tue, 2023-01-24 at 18:30 +0100, Alexis Lothoré via lists.yoctoproject.org wrote:

Instead of only generating regressions reports against HEAD of relevant branch, compute
most relevant tag (ie : release) against which we can check for regressions. General rules
introduced are the following :
- milestone release is checked against previous milestone if possible, otherwise
against major release
- point release is checked against previous point release if possible,
otherwise against major release
- major release is checked against previous major release
- a non release build is checked against base branch
Examples :
- 4.1.2.rc1 is checked against yocto-4.1.1
- 4.1.2 is checked against yocto-4.1.1
- 4.1.1.rc1 is checked against yocto-4.1
- 4.1.1 is checked against yocto-4.1
- 4.1 is checked against yocto-4.0
- 4.1.rc4 is checked against yocto-4.0
- 4.1_M2.rc1 is checked against 4.1_M1
- 4.1_M2 is checked against 4.1_M1
- 4.1_M1.rc1 is checked against yocto-4.0
- 4.1_M1 is checked against yocto-4.0

Signed-off-by: Alexis Lothoré <alexis.lothore@...>
---
scripts/send_qa_email.py | 86 +++++++++++++++++++++++++++++++++-------
scripts/utils.py | 47 ++++++++++++++++++++++
2 files changed, 118 insertions(+), 15 deletions(-)

diff --git a/scripts/send_qa_email.py b/scripts/send_qa_email.py
index 4023918..199fe4e 100755
--- a/scripts/send_qa_email.py
+++ b/scripts/send_qa_email.py
@@ -9,11 +9,79 @@ import json
import os
import sys
import subprocess
-import errno
import tempfile
+import re

import utils

+def is_non_release_version(version):
+ p = re.compile('\d{8}-\d+')
+ return p.match(version) is not None
+
+def get_previous_tag(targetrepodir, version):
+ previousversion = None
+ previousmilestone = None
+ if version:
+ if is_non_release_version(version):
+ return subprocess.check_output(["git", "describe", "--abbrev=0"], cwd=targetrepodir).decode('utf-8').strip()
+ compareversion, comparemilestone, _ = utils.get_version_from_string(version)
+ compareversionminor = compareversion[-1]
+ # After ignoring rc part, if we get a minor to 0 on point release (e.g 4.0.0),
+ # reject last digit since such versions do not exist
+ if len(compareversion) == 3 and compareversionminor == 0:
+ compareversion = compareversion[:-1]
+
+ # Process milestone if not first in current release
+ if comparemilestone and comparemilestone > 1:
+ previousversion = compareversion
+ previousmilestone = comparemilestone-1
+ # Process first milestone or release if not first in major release
+ elif compareversionminor > 0:
+ previousversion = compareversion[:-1] + [compareversion[-1] - 1]
+ # Otherwise : format it as tag (which must exist) and search previous tag
+ else:
+ comparetagstring = utils.get_tag_from_version(compareversion, comparemilestone)
+ return subprocess.check_output(["git", "describe", "--abbrev=0", comparetagstring + "^"], cwd=targetrepodir).decode('utf-8').strip()
+
+ return utils.get_tag_from_version(previousversion, previousmilestone)
+
+ # All other cases : merely check against latest tag reachable
+ defaultbaseversion, _, _ = utils.get_version_from_string(subprocess.check_output(["git", "describe", "--abbrev=0"], cwd=targetrepodir).decode('utf-8').strip())
+ return utils.get_tag_from_version(defaultbaseversion, None)
+
+def get_sha1(targetrepodir, revision):
+ return subprocess.check_output(["git", "rev-list", "-n", "1", revision], cwd=targetrepodir).decode('utf-8').strip()
+
+def fetch_testresults(resultdir, revision):
+ rawtags = subprocess.check_output(["git", "ls-remote", "--refs", "--tags", "origin", f"*{revision}*"], cwd=resultdir).decode('utf-8').strip()
+ if not rawtags:
+ raise Exception(f"No reference found for commit {revision} in {resultdir}")
+ for ref in [rawtag.split()[1] for rawtag in rawtags.splitlines()]:
+ print(f"Fetching matching revisions: {ref}")
+ subprocess.check_call(["git", "fetch", "--depth", "1", "origin", f"{ref}:{ref}"], cwd=resultdir)
+
+
+def generate_regression_report(resulttool, targetrepodir, basebranch, resultdir, outputdir, yoctoversion):
+ baseversion = get_previous_tag(targetrepodir, yoctoversion)
+ baserevision = get_sha1(targetrepodir, baseversion)
+ comparerevision = get_sha1(targetrepodir, basebranch)
+ print(f"Compare version : {basebranch} ({comparerevision})")
+ print(f"Base tag : {baseversion} ({baserevision})")
+
+ try:
+ """
+ Results directory is likely a shallow clone :
+ we need to fetch results corresponding to base revision before
+ running resulttool
+ """
+ fetch_testresults(resultdir, baserevision)
+ regreport = subprocess.check_output([resulttool, "regression-git", "-B", basebranch, "--commit", baserevision, "--commit2", comparerevision, resultdir])
+ with open(outputdir + "/testresult-regressions-report.txt", "wb") as f:
+ f.write(regreport)
+ except subprocess.CalledProcessError as e:
+ error = str(e)
+ print(f"Error while generating report between {baserevision} and {comparerevision} : {error}")
+

def send_qa_email():
parser = utils.ArgParser(description='Process test results and optionally send an email about the build to prompt QA to begin testing.')
@@ -57,16 +125,7 @@ def send_qa_email():
branch = repos['poky']['branch']
repo = repos['poky']['url']

- extraopts = None
basebranch, comparebranch = utils.getcomparisonbranch(ourconfig, repo, branch)
- if basebranch:
- extraopts = " --branch %s --commit %s" % (branch, revision)
- if comparebranch:
- extraopts = extraopts + " --branch2 %s" % (comparebranch)
- elif basebranch:
- print("No comparision branch found, comparing to %s" % basebranch)
- extraopts = extraopts + " --branch2 %s" % basebranch
-
report = subprocess.check_output([resulttool, "report", args.results_dir])
with open(args.results_dir + "/testresult-report.txt", "wb") as f:
f.write(report)

There looks to be a potential issue here since you drop the use of
comparebranch entirely. This comes from config.json:

"BUILD_HISTORY_FORKPUSH" : {"poky-contrib:ross/mut" : "poky:master", "poky:master-next" : "poky:master"},

and basically what it says is that master-next is a force push branch
which should be compared against master (and ross/mut should be
compared against master too).

We need this code so that when we build test branches, we run the
regression comparison against the last known master test results. We
should probably put Alexandre's test branch in there too.

Cheers,

Richard