Re: [yocto] [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.29.rc1)

[Jing Hui Tham]

Hi All,
 
QA for yocto-3.1.29.rc1 is completed. This is the full report for this release: 
 
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults
 
=== Summary 
No high milestone defects.
 
No new issue found. 
 
Thanks,
Jing Hui


> -Original Message-
> From: qa-build-notificat...@lists.yoctoproject.org  notificat...@lists.yoctoproject.org> On Behalf Of Pokybuild User
> Sent: Saturday, October 28, 2023 6:06 AM
> To: yocto@lists.yoctoproject.org
> Cc: qa-build-notificat...@lists.yoctoproject.org
> Subject: [qa-build-notification] QA notification for completed autobuilder
> build (yocto-3.1.29.rc1)
> 
> 
> A build flagged for QA (yocto-3.1.29.rc1) was completed on the autobuilder
> and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-3.1.29.rc1
> 
> 
> Build URL:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6111
> 
> Build hash information:
> 
> bitbake: dd826595414c5dc1a649f45a9dd2430bf6d4699b
> meta-agl: 280f7e70af30eefd885f6e60bd29863b46bb2eab
> meta-arm: b1fe8443a7a72c65fa0fc3371f607c6671b3a882
> meta-aws: 6e3ace380b609dadf58c81c734ef2061e9636914
> meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
> meta-intel: e482213f37828216c7a7df68ff353652cc865ec1
> meta-mingw: 7bdc58e6c5d1054b1b6ad5c4e480a95e995ccbae
> meta-openembedded: 300be975359fdb3a3b2bf7c6fe15dea7acac575d
> meta-virtualization: 35c723774ee06b3c1831f00a2cbf25cbeae132e1
> oecore: 0dbf3a15321b8033ff8ed86c6aa261fdb9c3d5bb
> poky: aeac1034661725b5c83e79f76238429fb236b090
> 
> 
> 
> This is an automated message from the Yocto Project Autobuilder
> Git: git://git.yoctoproject.org/yocto-autobuilder2
> Email: richard.pur...@linuxfoundation.org
> 
> 
> 
> 
> 
> 
> 


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

Re: [yocto] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused?

[Adrian Freihofer]

On Wed, 2023-11-01 at 18:28 +0100, Alexander Kanavin wrote:
> On Wed, 1 Nov 2023 at 16:45,  wrote:
> > I think these differences between SDK and bitbake environment are
> > no
> > longer required and they have been problematic. I would try to make
> > the
> > bitbake environment usable like the eSDK environment was without
> > trying
> > to replicate all the details of the eSDK installer such as these
> > local.conf settings.
> 
> I have now split up the populate_sdk_ext into separate functions [1]
> for better maintainability, and the more I think about what to do
> next, the more I agree with Adrian. I just don't see why (in a
> standard yocto build) would we want to manipulate PATH to provide a
> restricted set of tools, or to create a "local.conf+extra stuff"
> (locked signatures, esdk tweaks) environment, when existing
> local.conf
> by itself is already working fine, and full set of tools is better
> than a restricted one. If we want to add or remove locked signatures,
> this can be done with 'bitbake -s lockedsigs' or bblock for specific
> recipes only. And SDK's cross-toolchain is accessible via
> meta-ide-support/build-sysroots flow.
> 
> [1]
> https://git.yoctoproject.org/poky-contrib/commit/?h=akanavin/sstate-for-all

Splitting allows to copy the new function with the + from the patch
into this email and comment it.

+python copy_buildsystem () {
+ import oe.copy_buildsystem
+
+ baseoutpath = d.getVar('SDK_OUTPUT') + '/' + d.getVar('SDKPATH')
+
+ # Determine if we're building a derivative extensible SDK (from
devtool build-sdk)
+ derivative = (d.getVar('SDK_DERIVATIVE') or '') == '1'

What's the advantage of that? There are now two worlds: The bitbake
world and the SDK world which behave similar but not equal. Both need
to be maintained and tested.

We use only bitbake on our CI/CD infrastructure. For users who have
only the eSDK installed, it's hard to understand what the CI does and
even harder to reproduce errors happening on the CI.

We also had some setups with a containerized eSDK on the CI for the
integration of application source code. But this did not work at all.
The SDK container is basically outdated when the first component of the
firmware gets updated. If other components depend on that component an
SDK container update is required. Handling breaking changes easily is a
big advantage of bitbake which gets lost when using any kind of locked
or badly packaged variant of it.

+
+ conf_initpath, conf_bbpath, core_meta_subdir, sdkbblayers =
copy_bitbake_and_layers(d, baseoutpath, derivative)

Changing the directory layout leads to many pitfalls especially if more
layers than just poky are used. This should be replaced by the new
bitbake-layers tools. This means there is only one official way for
setting up bitbake layers and the folder structure gets exactly
replicated.

+
+ write_devtool_config(d, baseoutpath, conf_bbpath, conf_initpath,
core_meta_subdir)

Not sure there is much left when we have only the bitbake world. But
defining some defaults might be still useful.

+
+ write_unlocked_sigs(d, baseoutpath)

Lets turn this more towards a QA check. As a SDK maintainer I would
like to provide SDKs with 100% sstate included. But as a user, if I
have a choice between waiting a few minutes until bitbake compiled some
missing parts or getting an error message telling me I can't get an SDK
now, I'd probably choose compile.
If I remember correctly, with the old eSDK installer this is even
worse. This error happens during the installation which leads to an SDK
in an undefined state. The user must delete it again and fix the
generation of the SDK installer, which might be a very complicated and
time consuming task with the existing tools.

+
+ write_bblayers_conf(d, baseoutpath, sdkbblayers)

Also something which can be replaced by the new bitbake-layers utility.

+
+ uninative_checksum = copy_uninative(d, baseoutpath)

Not sure if this is still needed. With a bitbake environment this just
happens from sstate, I guess. So why doing it differently for the SDK?

+
+ write_local_conf(d, baseoutpath, derivative, core_meta_subdir,
uninative_checksum)

Also something which can be replaced by the new bitbake-layers utility.

+
+ prepare_locked_cache(d, baseoutpath, conf_initpath)

The sstate could be shipped in three different ways:
 * Included in the installer and just extracted into $SSTATE_DIR. This
   is simple but it does not scale at all. If you maintain multiple
   distros and MACHINES and want to have fast update cycles,
   distributing complete sstate archives quickly becomes practically
   impossible, as the same data is packed into several huge archives.
   That leads to issues on the infrastructure side. But also on the
   user's machine having one sstate folder e.g. ~/sstate-cache instead
   of several $TMPDIR/sstate-cache folders is beneficial.
 * No sstate is included, the sstate gets "lazy" fetched from
   SSTATE_MIRROR. Also that looks easy but does not scale very well for
   the SDK

Re: [yocto] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused?

[Alexander Kanavin]

On Thu, 2 Nov 2023 at 09:32,  wrote:

> Sorry for repeating some parts which we already had in other emails.
> But I tried to summarize the lengthy discussion a bit in one place.

So here's what I'd like to try:

- write a new populate_build_replica task that writes a few things
under ${WORKDIR}/replica
-- setup-layers json and script
(another option is to copy the layer trees themselves like esdk does,
which is left for maybe later. Completely offline replication is not
an initial goal, and it's good to get to a minimally viable
implementation asap.)
-- meta-build-config layer with the local.conf/bblayer.conf template.
-- sstate cache needed to fulfil the bitbake target that the task is
for (this would reuse code from esdk that does the same as much as
possible)

All of this is then packaged into a self-extracting shell archive that:
- unpacks itself
- fetches layers using the json/script from the unpacked tree
- sets up a build directory using the template from meta-build-config
in the unpacked tree
- tweaks site.conf to point to the prepackaged sstate

And voila! (in theory) This should be the same build as the one that
was produced elsewhere.

Alex

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

Re: [yocto] [meta-rockchip][PATCH] rockchip-rkbin: fail if lacking an override

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

Looks good to me,

Reviewed-by: Quentin Schulz 

Cheers,
Quentin

On 10/25/23 16:57, Trevor Woerner via lists.yoctoproject.org wrote:

Looking forward, rkbin should only be used by specific Rockchip platforms
for which TF-A support is not (yet?) available. If rkbin gets added by
accident without an override, add a bbfatal to let the user know an
override is required.

Signed-off-by: Trevor Woerner 
---
  recipes-bsp/rkbin/rockchip-rkbin_git.bb | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/recipes-bsp/rkbin/rockchip-rkbin_git.bb 
b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
index f9e680d16cb9..a3ab34189041 100644
--- a/recipes-bsp/rkbin/rockchip-rkbin_git.bb
+++ b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
@@ -25,7 +25,7 @@ do_install() {
  PACKAGES = "${PN}"
  ALLOW_EMPTY:${PN} = "1"
  
-do_deploy() {

+do_deploy:rk3588s() {
# Prebuilt TF-A
install -m 644 ${S}/bin/rk35/rk3588_bl31_v*.elf 
${DEPLOYDIR}/bl31-rk3588.elf
# Prebuilt OPTEE-OS
@@ -34,4 +34,8 @@ do_deploy() {
install -m 644 ${S}/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v*.bin 
${DEPLOYDIR}/ddr-rk3588.bin
  }
  
+do_deploy() {

+   bbfatal "COMPATIBLE_MACHINE requires a corresponding do_deploy:() 
override"
+}
+
  addtask deploy after do_install






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

Re: [yocto] [meta-rockchip][PATCH 3/3] rock-pi-s: add

[Quentin Schulz via lists.yoctoproject.org]

Hi Trevor,

On 10/30/23 18:26, Trevor Woerner wrote:

On Wed 2023-10-04 @ 04:23:31 PM, Quentin Schulz wrote:

On 10/3/23 15:56, Trevor Woerner wrote:

On Mon 2023-10-02 @ 06:17:15 PM, Quentin Schulz wrote:

diff --git a/recipes-bsp/rkbin/rockchip-rkbin_git.bb 
b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
index 7fefb017053b..49e1e682eb7d 100644
--- a/recipes-bsp/rkbin/rockchip-rkbin_git.bb
+++ b/recipes-bsp/rkbin/rockchip-rkbin_git.bb
@@ -1,9 +1,12 @@
DESCRIPTION = "Rockchip Firmware and Tool Binaries"
LICENSE = "Proprietary"
+LICENSE:rk3308 = "CLOSED"
LIC_FILES_CHKSUM = "file://LICENSE;md5=15faa4a01e7eb0f5d33f9f2bcc7bff62"
+LIC_FILES_CHKSUM:rk3308 = "file://README;md5=39cc9df955478b8df26158d489fdcc95"
SRC_URI = 
"git://github.com/rockchip-linux/rkbin;protocol=https;branch=master"
SRCREV = "b4558da0860ca48bf1a571dd33ccba580b9abe23"
+SRCREV:rk3308 = "e65b97b511f1349156702db40694454c141d8fe2"


Could you please say a few words about this change? It seems that there are
still binaries for it in the SRCREV we already point to. I assume newer
should be better (though it's not always the case), so wondering what's
prompted this change?


Oooh, there is no TPL with uart0m0 support anymore... honestly not sure
it's a good idea to stay on a old blob version just for that? I assume you
should only be missing the uart in TPL but the moment you reach the SPL the
console should appear, doesn't it?


Exactly, I would prefer to be able to capture all of the console output all in
one place. It's annoying they randomly decided to change uarts for every other
update. As far as I'm concerned one binary blob is a good (or bad) as the
next, and if this one gives me diagnostic info in the console, then it wins
:-)



I think this is a bit too much to hope for :) In the commit logs for ddr-bin
updates in rkbin, I've seen a few mentions to DDR init stability/reliability
for example. So saying it's all the same is probably incorrect.


I did a test with the rk3308 binaries from the latest commit of rkbin that
don't support uart0. Specifically I tested with 
rk3308_ddr_589MHz_uart4_m0_v2.07.bin:
this also works.

Also, it's a lot less hassle to build (rather than rolling back to a release
that has a uart0 console for the rk3308). However, even though the console is
set to uart4, this binary also outputs a lot of data to uart0. I've tried both
1,500,000 baud (the standard rockchip baud) and 115,200 baud: neither are able
to interpret the data. U-Boot, apparently, doesn't try to reset the serial
port either, because the garbage output continues until the Linux kernel
finally takes over. Or perhaps maybe the gibberish that I'm seeing is from
U-Boot outputting to an uninitialized serial port?



So, the TPL (ddr.bin) we get from rockchip-rkbin isn't configurable and 
it outputs something on some UART controller for the user to be able to 
debug stuff.


Then, if U-Boot isn't properly supported (which is sadly often the case 
in the beginning or, for poorly supported SoCs... forever), it just 
simply does nothing for configuring the debug serial (or initializes the 
"wrong" one). I don't remember exactly if U-Boot does something with the 
serial device defined as main output in the DTB used by U-Boot or if it 
just expects the SPL to properly set up everything.


I think this should be fixed in U-Boot itself in any case. See what I 
had to do for PX30 a year ago for example: 
https://source.denx.de/u-boot/u-boot/-/commit/d0af506625ff909b123a298e435a95ae1b8ee3e7


I haven't looked into it in depth, but it seems only UART2 is supported 
currently on RK3308, c.f. 
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-rockchip/rk3308/rk3308.c?ref_type=heads#L178



Roll back to older rkbin checkout:
PRO:
- supports console on uart0 (same as linux kernel) and all messages from
   rkbin, u-boot, linux kernel, and console appear legibly on the terminal
CON:
- more cumbersome to build (recipe requires a bunch of rk3308-based
   overrides), perhaps a separate rkbin recipe would be better?
- uses older ddr initialization code

Use latest rkbin:
PRO:
- simpler recipe, no overrides necessary, simpler build
- uses the latest code (might include bug fixes or other improvements?)
CON:
- spews a bunch of gibberish to the serial console (from rkbin? from u-boot?
   from both?)
- the first legible messages only start once the linux kernel takes over,
   therefore the user can't interact with U-Boot (should they so wish)


This would be a blocker to me if I were to use this board, so I second 
your decision of going for older rkbin for now.


Cheers,
Quentin

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

Re: [yocto] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused?

[Alexander Kanavin]

On Thu, 2 Nov 2023 at 10:02, Alexander Kanavin via
lists.yoctoproject.org 
wrote:
> So here's what I'd like to try:
>
> - write a new populate_build_replica task that writes a few things
> under ${WORKDIR}/replica
> -- setup-layers json and script
> (another option is to copy the layer trees themselves like esdk does,
> which is left for maybe later. Completely offline replication is not
> an initial goal, and it's good to get to a minimally viable
> implementation asap.)
> -- meta-build-config layer with the local.conf/bblayer.conf template.
> -- sstate cache needed to fulfil the bitbake target that the task is
> for (this would reuse code from esdk that does the same as much as
> possible)
>
> All of this is then packaged into a self-extracting shell archive that:
> - unpacks itself
> - fetches layers using the json/script from the unpacked tree
> - sets up a build directory using the template from meta-build-config
> in the unpacked tree
> - tweaks site.conf to point to the prepackaged sstate
>
> And voila! (in theory) This should be the same build as the one that
> was produced elsewhere.

I started writing this as a bitbake task, but then quickly hit an
obstacle: bitbake-layers deadlocks when executed in a bitbake task.

At which point it dawned on me: all of the required functions are
available in command-line utility form, and so this should be a script
as well, with as many options as people find useful (as opposed to
bitbake tasks which are more difficult to parametrize).

So:
- bitbake -S lockedsigs to get the list of sstate objects
- gen-lockedsig-cache to populate a newly made sstate cache directory
with them (optional)
- bitbake-layers to save the layer configuration and build configuration

Then either leave all that in an unpacked form, or package it up in a
self-extracting shell archive or plain tarball. It would also contain
a script that would set up a plain bitbake build from what is in the
archive.

This could be poky/scripts/oe-replicate-build ?

Alex

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

[yocto] Call bitbake while bitbake is running

[Jörg Sommer via lists . yoctoproject . org]

Hi,

is it possible to run bitbake while bitbake is running? I'm starting
`bitbake -c menuconfig virtual/kernel` and would like to call
`diffconfig` while I'm doing configuration. The best would be from the
other window of tmux. Is this possible?

Kind regards

Jörg Sommer
-- 
Navimatix GmbH
Tatzendpromenade 2
D-07745 Jena
Geschäftsführer: Steffen Späthe, Jan Rommeley
Registergericht: Amtsgericht Jena, HRB 501480

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

Re: [yocto] [meta-zephyr][PATCH] intel-x86-64.conf: add intel_ prefix to x86 board names

[Jon Mason]

On Thu, Nov 02, 2023 at 02:41:38PM +0800, Naveen Saini wrote:
> Use newly added naming convention (intel_).
> 
> https://github.com/zephyrproject-rtos/zephyr/commit/03905f7e55d24788e0a38d1641dcadf529fce85d
> https://github.com/zephyrproject-rtos/zephyr/commit/2b757f1eca3e27f2405362a99d77fc9fc2b17619
> 
> Signed-off-by: Naveen Saini 

This resolves the intel-x86-64 build issue.  See
https://gitlab.com/jonmason00/meta-zephyr/-/pipelines/1058925479

> ---
>  meta-zephyr-bsp/conf/machine/intel-x86-64.conf | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/meta-zephyr-bsp/conf/machine/intel-x86-64.conf 
> b/meta-zephyr-bsp/conf/machine/intel-x86-64.conf
> index 74e8f6e..5112f28 100644
> --- a/meta-zephyr-bsp/conf/machine/intel-x86-64.conf
> +++ b/meta-zephyr-bsp/conf/machine/intel-x86-64.conf
> @@ -1,6 +1,6 @@
>  #@TYPE: Machine
>  #@NAME: intel-x86-64
> -#@DESCRIPTION: common MACHINE for 64-bit x86 boards. User must set 
> ${ZEPHYR_BOARD}. By default is set to 'ech_crb' board.
> +#@DESCRIPTION: common MACHINE for 64-bit x86 boards. User must set 
> ${ZEPHYR_BOARD}. By default is set to 'intel_ehl_crb' board.
>  
>  require conf/machine/include/tune-corei7-common.inc
>  
> @@ -10,5 +10,5 @@ ARCH:intel-x86-64 = "x86"
>  # ZEPHYR_BOARD ?= "acrn"
>  # ZEPHYR_BOARD ?= "acrn_ehl_crb"
>  # ZEPHYR_BOARD ?= "up_squared"
> -# ZEPHYR_BOARD ?= "ehl_crb_sbl"
> -ZEPHYR_BOARD ?= "ehl_crb"
> +# ZEPHYR_BOARD ?= "intel_ehl_crb_sbl"
> +ZEPHYR_BOARD ?= "intel_ehl_crb"
> -- 
> 2.34.1
> 
> 

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

[yocto] [yocto-autobuilder-helper][PATCH v4 1/2] config.json: Move AUH from custom scripts to config.json

[Yoann Congal]

setup-auh and run-auh were doing what the AB config.json does:
* creating repo checkouts: Now use NEEDREPOS
* configuring bitbake env: Now use extravars

This refactoring is needed to prepare adding AUH meta-oe support.

Signed-off-by: Yoann Congal 
---
 config.json  | 26 ++---
 scripts/auh-config/local.conf.append |  5 
 scripts/run-auh  | 34 
 scripts/setup-auh| 29 
 4 files changed, 23 insertions(+), 71 deletions(-)
 delete mode 100644 scripts/auh-config/local.conf.append
 delete mode 100755 scripts/run-auh
 delete mode 100755 scripts/setup-auh

diff --git a/config.json b/config.json
index 1b3c2b0..2e33c73 100644
--- a/config.json
+++ b/config.json
@@ -1454,9 +1454,29 @@
 "TEMPLATE" : "buildperf"
 },
 "auh" : {
-"EXTRAPLAINCMDS" : [
-"${SCRIPTSDIR}/setup-auh ${HELPERBUILDDIR}; 
${SCRIPTSDIR}/run-auh ${HELPERBUILDDIR} ${WEBPUBLISH_DIR}/pub/auh/"
-]
+"NEEDREPOS" : ["poky", "auto-upgrade-helper"],
+"extravars" :[
+"INHERIT += 'buildhistory'",
+"LICENSE_FLAGS_ACCEPTED = 'commercial'",
+"DISTRO_FEATURES:append:libc-glibc = ' systemd usrmerge'",
+"DISTRO_FEATURES:append = ' pam'"
+],
+"step1" : {
+"shortname" : "setup AUH",
+"EXTRAPLAINCMDS" : [
+"git config user.email a...@yoctoproject.org",
+"git config user.name 'Auto Upgrade Helper'",
+"git switch -C tmp-auh-upgrades HEAD",
+"install -D ${SCRIPTSDIR}/auh-config/upgrade-helper.conf 
./upgrade-helper/upgrade-helper.conf"
+]
+},
+"step2" : {
+"shortname" : "run AUH",
+"EXTRACMDS" : [
+"../auto-upgrade-helper/upgrade-helper.py -e all",
+"cp -rf ./upgrade-helper/* ${WEBPUBLISH_DIR}/pub/auh/"
+]
+}
 },
 "yocto-mirror" : {
 "MACHINE" : "qemux86-64",
diff --git a/scripts/auh-config/local.conf.append 
b/scripts/auh-config/local.conf.append
deleted file mode 100644
index ee7ee2d..000
--- a/scripts/auh-config/local.conf.append
+++ /dev/null
@@ -1,5 +0,0 @@
-
-INHERIT += "buildhistory"
-LICENSE_FLAGS_ACCEPTED = "commercial"
-DISTRO_FEATURES:append:libc-glibc = ' systemd usrmerge'
-DISTRO_FEATURES:append = ' pam'
diff --git a/scripts/run-auh b/scripts/run-auh
deleted file mode 100755
index 0419dd1..000
--- a/scripts/run-auh
+++ /dev/null
@@ -1,34 +0,0 @@
-#!/bin/bash
-#
-# SPDX-License-Identifier: GPL-2.0-only
-#
-# Run Auto Upgrade Helper in a directory set up by setup_auh.
-#
-# Called with $1 - the directory where the setup was created
-
-if [ -z $1 ]; then
-  echo "Use: $0 auh_setup_dir [publish_dir]"
-  exit 1
-fi
-
-full_dir=$(readlink -e $1)
-
-auh_dir=$full_dir/auto-upgrade-helper
-poky_dir=$full_dir/poky
-build_dir=$full_dir/build
-sstate_dir=$full_dir/build/sstate-cache
-
-pushd $poky_dir
-
-# Base the upgrades on poky master
-git fetch origin
-git checkout -B tmp-auh-upgrades origin/master
-
-source $poky_dir/oe-init-build-env $build_dir
-$auh_dir/upgrade-helper.py -e all
-
-if [ -n $2 ]; then
-  cp -rf $build_dir/upgrade-helper/* $2
-fi
-
-popd
diff --git a/scripts/setup-auh b/scripts/setup-auh
deleted file mode 100755
index d6b83fe..000
--- a/scripts/setup-auh
+++ /dev/null
@@ -1,29 +0,0 @@
-#!/bin/bash
-#
-# SPDX-License-Identifier: GPL-2.0-only
-#
-# Initialize Auto Upgrade Helper in a directory.
-#
-# Called with $1 - the directory to place the setup
-CONFIG_DIR=`dirname $0`/auh-config
-
-if [ -z $1 ]; then
-  echo "Use: $0 target_dir"
-  exit 1
-fi
-
-mkdir -p $1
-pushd $1
-
-git clone git://git.yoctoproject.org/poky
-pushd poky
-git config user.email a...@yoctoproject.org
-git config user.name "Auto Upgrade Helper"
-popd
-git clone git://git.yoctoproject.org/auto-upgrade-helper
-source poky/oe-init-build-env build
-mkdir -p upgrade-helper
-popd
-
-cp $CONFIG_DIR/upgrade-helper.conf $1/build/upgrade-helper
-cat $CONFIG_DIR/local.conf.append >> $1/build/conf/local.conf
-- 
2.30.2


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

[yocto] [yocto-autobuilder-helper][PATCH v4 0/2] Extend auto-upgrade helper to meta-openembedded

[Yoann Congal]

In order to extend AUH runs to meta-oe layers, we first need to refactor AUH
runs on oe-core a bit.

Then create a new builder dedicated to AUH runs on meta-oe layers.

v3->v4:
* Split patch between poky AUH refactoring and AUH extension to meta-oe
* Refactor/simplify AUH a bit more (helper script setup/run-auh inlined)

Yoann Congal (2):
  config.json: Move AUH from custom scripts to config.json
  config.json: Extend AUH to meta-openembedded layers

 config.json  | 152 ++-
 scripts/auh-config/local.conf.append |   5 -
 scripts/run-auh  |  34 --
 scripts/setup-auh|  29 -
 4 files changed, 149 insertions(+), 71 deletions(-)
 delete mode 100644 scripts/auh-config/local.conf.append
 delete mode 100755 scripts/run-auh
 delete mode 100755 scripts/setup-auh

-- 
2.30.2


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

[yocto] [yocto-autobuilder-helper][PATCH v4 2/2] config.json: Extend AUH to meta-openembedded layers

[Yoann Congal]

Add each a new builder "auh-meta-oe" and one step by meta-openembedded
layers.

Co-authored-by: David Pierret 
Signed-off-by: Yoann Congal 
---
 config.json | 126 
 1 file changed, 126 insertions(+)

diff --git a/config.json b/config.json
index 2e33c73..0caf6e6 100644
--- a/config.json
+++ b/config.json
@@ -1478,6 +1478,132 @@
 ]
 }
 },
+"auh-meta-oe": {
+"NEEDREPOS": ["poky", "auto-upgrade-helper", "meta-openembedded"],
+"extravars": [
+"INHERIT += 'buildhistory'",
+"LICENSE_FLAGS_ACCEPTED = 'commercial'",
+"DISTRO_FEATURES:append:libc-glibc = ' systemd usrmerge'",
+"DISTRO_FEATURES:append = ' pam'"
+],
+"ADDLAYER": [
+"${BUILDDIR}/../meta-openembedded/meta-oe",
+"${BUILDDIR}/../meta-openembedded/meta-python",
+"${BUILDDIR}/../meta-openembedded/meta-perl",
+"${BUILDDIR}/../meta-openembedded/meta-networking",
+"${BUILDDIR}/../meta-openembedded/meta-multimedia",
+"${BUILDDIR}/../meta-openembedded/meta-gnome",
+"${BUILDDIR}/../meta-openembedded/meta-xfce",
+"${BUILDDIR}/../meta-openembedded/meta-filesystems",
+"${BUILDDIR}/../meta-openembedded/meta-initramfs",
+"${BUILDDIR}/../meta-openembedded/meta-webserver"
+],
+"step1": {
+"shortname": "setup AUH for meta-oe layers",
+"EXTRAPLAINCMDS": [
+"git -C ./meta-openembedded config user.email 
a...@yoctoproject.org",
+"git -C ./meta-openembedded config user.name 'Auto Upgrade 
Helper'",
+"git -C ./meta-openembedded switch -C tmp-auh-upgrades 
HEAD",
+"install -D ${SCRIPTSDIR}/auh-config/upgrade-helper.conf 
./upgrade-helper/upgrade-helper.conf"
+]
+},
+"step2": {
+"shortname": "run AUH for layer meta-oe",
+"extravars": [
+"RECIPE_MAINTAINER:layer-openembedded-layer = 'Forced 
maintainer for AUH'"
+],
+"EXTRACMDS": [
+"../auto-upgrade-helper/upgrade-helper.py -e all 
--layer-dir ${BUILDDIR}/../meta-openembedded/ --layer-names meta-oe"
+]
+},
+"step3": {
+"shortname": "run AUH for layer meta-python",
+"extravars": [
+"RECIPE_MAINTAINER:layer-meta-python = 'Forced maintainer 
for AUH'"
+],
+"EXTRACMDS": [
+"../auto-upgrade-helper/upgrade-helper.py -e all 
--layer-dir ${BUILDDIR}/../meta-openembedded/ --layer-names meta-python"
+]
+},
+"step4": {
+"shortname": "run AUH for layer meta-perl",
+"extravars": [
+"RECIPE_MAINTAINER:layer-perl-layer = 'Forced maintainer 
for AUH'"
+],
+"EXTRACMDS": [
+"../auto-upgrade-helper/upgrade-helper.py -e all 
--layer-dir ${BUILDDIR}/../meta-openembedded/ --layer-names meta-perl"
+]
+},
+"step5": {
+"shortname": "run AUH for layer meta-networking",
+"extravars": [
+"RECIPE_MAINTAINER:layer-networking-layer = 'Forced 
maintainer for AUH'"
+],
+"EXTRACMDS": [
+"../auto-upgrade-helper/upgrade-helper.py -e all 
--layer-dir ${BUILDDIR}/../meta-openembedded/ --layer-names meta-networking"
+]
+},
+"step6": {
+"shortname": "run AUH for layer meta-multimedia",
+"extravars": [
+"RECIPE_MAINTAINER:layer-multimedia-layer = 'Forced 
maintainer for AUH'"
+],
+"EXTRACMDS": [
+"../auto-upgrade-helper/upgrade-helper.py -e all 
--layer-dir ${BUILDDIR}/../meta-openembedded/ --layer-names meta-multimedia"
+]
+},
+"step7": {
+"shortname": "run AUH for layer meta-gnome",
+"extravars": [
+"RECIPE_MAINTAINER:layer-gnome-layer = 'Forced maintainer 
for AUH'"
+],
+"EXTRACMDS": [
+"../auto-upgrade-helper/upgrade-helper.py -e all 
--layer-dir ${BUILDDIR}/../meta-openembedded/ --layer-names meta-gnome"
+]
+},
+"step8": {
+"shortname": "run AUH for layer meta-xfce",
+"extravars": [
+"RECIPE_MAINTAINER:layer-xfce-layer = 'Forced maintainer 
for AUH'"
+],
+"EXTRACMDS": [
+"../auto-u

Re: [yocto] [yocto-autobuilder-helper][PATCH v3] AUH: Add Openembedded auto-update-helper with list of layer to test

[Yoann Congal]

Hello,

Le 28/10/2023 à 10:27, Richard Purdie a écrit :
> Hi David,
> 
> On Thu, 2023-10-26 at 15:03 +0200, David Pierret wrote:
>> - Modify the setup-auh to use repositories cloned by the auto-builder.
>>   Manage the case where meta-openembedded is not used.
>>
>> - Modify the run-auh to manage the optional additional layer.
>>   Only 1 layer can be provided.
>>
>> - Add auh-meta-openembedded job with 1 step per layer.
>>
>> Signed-off-by: David Pierret 
>> ---
>>  config.json   | 102 --
>>  scripts/run-auh   |  39 --
>>  scripts/setup-auh |  34 ++--
>>  3 files changed, 146 insertions(+), 29 deletions(-)
> 
> This took a while to review. Firstly, this really should be written as
> a set of commits with incremental changes.
> 
> For example, changing the script to use poky from the autobuilder
> checkout instead of the local clone is one logical change. We could
> take and review/merge that independently of the other changes.
> 
> Another logical independent change is using auto-upgrade-helper from
> the checkout of the autobuilder. That did highlight an issue that the
> autobuilder does not provide a checkout of that repository.> 
> With that and this work in mind I added auh-meta-oe here:
> 
> https://git.yoctoproject.org/yocto-autobuilder2/commit/?id=47c0119b6e87f920566d2176793ef8d982cf31e2
> 
> and then added the auto-upgrade-helper repo here:
> 
> https://git.yoctoproject.org/yocto-autobuilder2/commit/?id=854a60ce8bf8ce0feec370bc6782cc12aa1e29a5
> 
> which then means this patch is closer to working.
> 
> I had to make some tweaks on top of the patch to make it work:
> 
> https://git.yoctoproject.org/yocto-autobuilder-helper/commit/?h=master-next&id=673745f473024020ed9efece26462e8c884dc819
> 
> where I found that:
> 
> * poky in the AB context is $1/.. since it is the top level 
>   container of the layers
> * meta-openembedded is located at ${HELPERBUILDDIR}/../meta-openembedded
> * we still need to source the build env script. The AB could be 
>   configured to do that for us but currently isn't.
> * we need to trim the machine_list down as mentioned
> * the naming we're using is auh-meta-oe, not auh-meta-openembedded
> * I've temporarily configured to use the test-list so we don't 
>   send lots of mail to all users
> * layer dependencies were missing in ADDLAYER. I hate having to do  
>   that but it is is what it is right now
I've just sent a reworked version of this patch :
https://lists.yoctoproject.org/g/yocto/message/61579
[yocto-autobuilder-helper][PATCH v4 0/2] Extend auto-upgrade helper to 
meta-openembedded
https://lists.yoctoproject.org/g/yocto/message/61580
[yocto-autobuilder-helper][PATCH v4 1/2] config.json: Move AUH from custom 
scripts to config.json
https://lists.yoctoproject.org/g/yocto/message/61581
[yocto-autobuilder-helper][PATCH v4 2/2] config.json: Extend AUH to 
meta-openembedded layers

While moving stuff from the scripts to config.json, I found the scripts to be 
mostly redundant and choose to remove them.
I've took most of RP's tweaks but not the test-list change.

I hope this one will be easier to review.

> With that, we get this "successful" build:
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/159/builds/5
> 
> which shows the exit code handling isn't great but probably deliberate
> to avoid autobuilder errors.
> 
> This gets us to the point where the code in the upgrade helper itself
> needs the layer support changing.
> 
> Since I've now had to look into that code, it seems the layer options
> are entirely missing from the commandline options parser. I'd strongly
> suggest dropping layer_machines variable and just use the machines
> value in all cases.
> 
> "layer-mode" seems pointless as you can determine if we're in "layer
> mode" if a layer is specified on the commandline (which needs adding).
> 
> I'm hoping you could use the layer overrides to be able to identify
> which recipes to upgrade.

I did not find how to use layer overrides here...
Maybe once AUH is more integrated into oe-core as RP suggested on IRC?

Regards,
-- 
Yoann Congal
Smile ECS - Tech Expert

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

[yocto] Package dependencies not generated?

[Michael Opdenacker via lists.yoctoproject.org]

Greetings,

I compiled rsyslog from meta-oe:
bitbake rsyslog

I set up a binary feed ("bitbake package-index") and a webserver to 
serve it, and when I try to install the rsyslog package, I get:

$ opkg install rsyslog
 * Solver encountered 1 problem(s):
 * Problem 1/1:
 *   - conflicting requests
 *   - nothing provides libestr0 >= 0.1.11 needed by 
rsyslog-8.2306.0-r0.core2-64


Indeed, no "*libestr*" package(s) got generated. Why not?

I checked RDEPENDS:rsyslog and it contains "logrotate" for which a 
package was indeed generated. I thought that shared libraries 
dependencies were automatically detected and added to runtime 
dependencies. That's confirmed by 
https://docs.yoctoproject.org/dev/overview-manual/concepts.html#automatically-added-runtime-dependencies 
. Why didn't it happen?


I checked that libestr got compiled (it's part of the DEPENDS for 
rsyslog), but I can't find any package for it, even in the working area.


It sounds like a very basic misconception between my keyboard and my 
chair. What did I get wrong?


Thanks in advance for your insights.

Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


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

Re: [yocto] [meta-rockchip][PATCH v2 0/1] rock-pi-s: add

[Trevor Woerner]

On Tue 2023-10-31 @ 08:58:04 AM, Trevor Woerner via lists.yoctoproject.org 
wrote:
> Add a new MACHINE: rock-pi-s
> 
> changes since v1:
> - while the actual patch to add the rock-pi-s was not merged, all of the
>   cleanup patches that were submitted in advance of the "add" patch (and
>   were part of the original series) were applied, therefore those patches
>   are dropped from this version
> - upstream master now contains a version of u-boot that supports the
>   rock-pi-s, therefore using rk3308-specific overrides in the u-boot
>   bbappend is no longer necessary
> - add a separate rk3308-rkbin recipe instead of loading the rockchip-rkbin
>   recipe with rk3308-specific overrides
> - allow the user to choose whether they want the rkbin and u-boot debug
>   messages to show up on the console (i.e. use an older version of rkbin)
>   or have gibberish until the linux kernel starts (use the latest version
>   of rkbin) by setting (or not) a variable; default is to use an older
>   version
> 
> Trevor Woerner (1):
>   rock-pi-s: add
> 
>  README  | 22 +++
>  conf/machine/include/rk3308.inc | 18 +
>  conf/machine/rock-pi-s.conf | 11 ++
>  recipes-bsp/rkbin/rk3308-rkbin_git.bb   | 41 +
>  recipes-bsp/rkbin/rockchip-rkbin_git.bb | 10 +
>  recipes-bsp/u-boot/u-boot%.bbappend |  8 
>  recipes-kernel/linux/linux-yocto_%.bbappend |  1 +
>  7 files changed, 111 insertions(+)
>  create mode 100644 conf/machine/include/rk3308.inc
>  create mode 100644 conf/machine/rock-pi-s.conf
>  create mode 100644 recipes-bsp/rkbin/rk3308-rkbin_git.bb

Applied to meta-rockchip, master branch.

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

[yocto] [layerindex-web][PATCH] layerindex/tools: add mark_yp_compatible_layers.py

[Tim Orling]

Add a script which can either mark one --layer --branch or
use data in a --from-file to mark multiple layer:branch objects
as Yocto Project Compatible.

The --from-file is a json file that is compatible with or which
can be generated by:

yocto-autobuilder-helper/scripts/list-yp-compatible-layers.py

[YOCTO #15093]

Signed-off-by: Tim Orling 
---
 layerindex/tools/mark_yp_compatible_layers.py | 142 ++
 1 file changed, 142 insertions(+)
 create mode 100755 layerindex/tools/mark_yp_compatible_layers.py

diff --git a/layerindex/tools/mark_yp_compatible_layers.py 
b/layerindex/tools/mark_yp_compatible_layers.py
new file mode 100755
index 000..1d2dc32
--- /dev/null
+++ b/layerindex/tools/mark_yp_compatible_layers.py
@@ -0,0 +1,142 @@
+#!/usr/bin/env python3
+
+# Mark layers that are Yocto Project Compatible (2.0) on the AutoBuilder
+#
+# Copyright (C) 2017 Intel Corporation
+# Author: Paul Eggleton 
+# Copyright (C) 2023 Konsulko Group
+# Author: Tim Orling 
+#
+# Licensed under the MIT license, see COPYING.MIT for details
+#
+# SPDX-License-Identifier: MIT
+#
+# Input json file can be for instance generated by:
+# 
https://git.yoctoproject.org/yocto-autobuilder-helper/tree/scripts/list-yp-compatible-layers.py
+
+import sys
+import os
+
+sys.path.insert(0, os.path.realpath(os.path.join(os.path.dirname(__file__), 
'..')))
+
+import argparse
+from argparse import ArgumentError
+from layerindex import utils
+import logging
+import json
+from json import JSONDecodeError
+
+class DryRunRollbackException(Exception):
+pass
+
+class LayerNotFoundException(Exception):
+pass
+
+class BranchNotFoundException(Exception):
+pass
+
+class YPCompatibleVersionNotFoundException(Exception):
+pass
+
+logger = utils.logger_create('LayerIndexYoctoProjectCompatible')
+
+
+
+def main():
+parser = argparse.ArgumentParser(description='Mark layers that are Yocto 
Project Compatible (2.0)')
+
+layer_branch_arg_group = parser.add_argument_group()
+layer_branch_arg_group.add_argument("-l", "--layer",
+help = "Layer to mark as Yocto Project Compatible",
+action="store", dest="layer")
+layer_branch_arg_group.add_argument("-b", "--branch",
+help = "Branch to mark as Yocto Project Compatible",
+action="store", dest="branch")
+file_or_layer_branch_arg_group = 
layer_branch_arg_group.add_mutually_exclusive_group()
+file_or_layer_branch_arg_group.add_argument("-f", "--from-file",
+help = "(Recommended) JSON file compatible with 
'list-yp-compatible-layers' script from 'yocto-autobuilder-helper' to use for 
input",
+action="store", dest="from_file")
+parser.add_argument("-v", "--compatible-version",
+help = "Yocto Project Compatible version",
+action="store", dest="yp_compatible_version", default="2.0")
+parser.add_argument("-n", "--dry-run",
+help = "Don't write any data back to the database",
+action="store_true", dest="dryrun")
+parser.add_argument("-d", "--debug",
+help = "Enable debug output",
+action="store_const", const=logging.DEBUG, dest="loglevel", 
default=logging.INFO)
+parser.add_argument("-q", "--quiet",
+help = "Hide all output except error messages",
+action="store_const", const=logging.ERROR, dest="loglevel")
+
+args = parser.parse_args()
+
+utils.setup_django()
+import settings
+from layerindex.models import Branch, LayerBranch, LayerItem, 
YPCompatibleVersion
+from django.db import transaction
+
+logger.setLevel(args.loglevel)
+
+def update_from_layer_branch(layer, branch, yp_compatible_version, dryrun):
+try:
+with transaction.atomic():
+try:
+layer_id=LayerItem.objects.filter(name__exact=layer)[0].id
+except IndexError:
+raise LayerNotFoundException( f'Layer {layer} not found in 
layerindex ddatabase')
+try:
+branch_id=Branch.objects.filter(name__exact=branch)[0].id
+except IndexError:
+raise BranchNotFoundException( f'Branch {branch} not found 
in layerindex database')
+try:
+
yp_compatible_version_instance=YPCompatibleVersion.objects.filter(name__exact=yp_compatible_version)[0]
+except IndexError:
+raise YPCompatibleVersionNotFoundException( f' Yocto 
Project Compatible Version {yp_compatible_version} not found in layerindex 
database')
+for layerbranch in 
LayerBranch.objects.filter(layer=layer_id,branch=branch_id):
+logger.debug(' BEFORE: Yocto Project Compatible %s   
%s:%s' % (layerbranch.yp_compatible_version, layerbranch.layer, 
layerbranch.branch))
+layerbranch.yp_compatible_version = 
yp_compatible_version_instance
+layerbranch.save()
+ 

Re: [yocto] QA notification for completed autobuilder build (yocto-4.3.rc2)

[Alexis Lothoré via lists . yoctoproject . org]

Hello,

On 10/19/23 23:55, Pokybuild User wrote:
> 
> A build flagged for QA (yocto-4.3.rc2) was completed on the autobuilder 
> and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-4.3.rc2
> 
> 
> Build URL: 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6080

Once again this release is lacking a proper regression report. I am reacting a
bit late, but I have moved forward with the diagnostic. As for yocto-4.3.rc1,
the report is empty because of a lack in the "base" tests results, which is here
tests results from yocto-4.2. Those are in fact the tests results that we have
pushed manually during summer, because those weren't pushed automatically
(because of another unrelated tagging issue which has been fixed since then).
But it looks like we have made a mistake/omission while doing so: the tag
associated with those results (which is required to make resulttool search for
it) is not present on the mickledore branch. This issue is pretty visible when
fetching the lasts commits on mickledore branch in testresults repository (see
https://git.yoctoproject.org/yocto-testresults/log/?h=mickledore)

So to fix this, my suggestion is for someone having the proper write access on
git://git.yoctoproject.org/yocto-testresults to manually apply the missing tag
on the proper commit and to push it:

git tag mickledore/70029-g21790e71d55f417f27cd51fae9dd47549758d4a0/1
5bf0165296b3686ab5c400869ed2e030f2269c8a

(adding Michael Halstead in CC since he is the one who helped me with the manual
import of missing tests results)

I have tested locally this fix (by tagging locally my clone of testresults +
hacking around in resulttool to prevent it from reading remote tags), and I have
been able to generate the report. Here it is :

https://pastebin.com/fvRcqes4

By the way, the report comes from a slightly modified resulttool run because it
has shown that the recent regression grouping addition needs some improvements
(among some other already discussed issues), so patch incoming.

Kind regards,

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


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

Re: [yocto] [OE-core] Yocto Project Status 31 October 2023 (WW44)

[Tim Orling]

On Tue, Oct 31, 2023 at 5:29 AM Neal Caidin 
wrote:

> Current Dev Position: YP 4.3 M4 (Feature Freeze)
>
> Next Deadline: 2nd October 2023 YP 4.3 M4 build date
>
> Next Team Meetings:
>
>-
>
>Bug Triage meeting Thursday November 2, 7:30 am PDT (
>https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
>-
>
>Weekly Project Engineering Sync Tuesday October 31st at 8 am PDT (
>https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09)
>
>-
>
>Twitch -  See https://www.twitch.tv/theyoctojester
>
>
> Key Status/Updates:
>
>-
>
>The YP 4.3 passed QA and is now pending finalizing the release notes
>and migration guide.
>-
>
>Work has continued on trying to track down the 32bit x86 non-kvm 6.5
>kernel early boot crash (thanks Paul).
>-
>
>Patchtest is now replying live on the mailing list for OE-Core. There
>are some open bugs including a threading/references issue but it is great
>to welcome it back, thanks Trevor.
>-
>
>The autobuilder generated ‘metrics’ target has been altered to work
>per branch and we’re close to support for testing other layers such as
>meta-openembedded.
>-
>
>Toaster automated testing is close to being usable again.
>-
>
>Recipetool is now able to better handle various python module formats
>for recipe creation (Thanks Julien and Tim).
>-
>
>Various pieces of security information and processes are being added
>to our documentation.
>
>
> Ways to contribute:
>
>-
>
>As people are likely aware, the project has a number of components
>which are either unmaintained, or have people with little to no time trying
>to keep them alive. These components include: patchtest, layerindex,
>devtool, toaster, wic, oeqa, autobuilder, CROPs containers, pseudo and
>more. Many have open bugs. Help is welcome in trying to better look after
>these components!
>-
>
>There are bugs identified as possible for newcomers to the project:
>https://wiki.yoctoproject.org/wiki/Newcomers
>-
>
>There are bugs that are currently unassigned for YP 4.3. See:
>
> https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_4.3_Unassigned_Enhancements.2FBugs
>-
>
>We’d welcome new maintainers for recipes in OE-Core. Please see the
>list at:
>
> http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/maintainers.inc
>and discuss with the existing maintainer, or ask on the OE-Core mailing
>list. We will likely move a chunk of these to “Unassigned” soon to help
>facilitate this.
>-
>
>Help is very much welcome in trying to resolve our autobuilder
>intermittent issues. You can see the list of failures we’re continuing to
>see by searching for the “AB-INT” tag in bugzilla:
>https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT.
>-
>
>Help us resolve CVE issues: CVE metrics
>
>-
>
>We have a growing number of bugs in bugzilla, any help with them is
>appreciated.
>
>
> YP 4.3 Milestone Dates:
>
>-
>
>YP 4.3 M3 was released.
>-
>
>YP 4.3 M4 build date  2023/10/02
>-
>
>YP 4.3 M4 Release date 2023/10/27
>
>
The "nanbield" Branch has been added to the layerindex. Errors in many
layers are to be expected when the update.py script runs. We will address
those errors as time permits.
https://layers.openembedded.org/layerindex/branch/nanbield/layers/
https://layers.openembedded.org/layerindex/updates/

Realizing that the above 4.3 M4 Release date is now impossible, the
layerindex 4.3 "Release" has been updated to 2023/11/06 as far as the
Recipe Reporting System (RRS) is concerned. This can be adjusted by a
layerindex admin if necessary.
https://layers.openembedded.org/rrs/recipes/OE-Core/4.3/M4/

Note that populating the "Upstream Status" and "Last Updated" is
work-in-progress. Currently the Auto Upgrade Helper (AUH) is the "source of
truth".

The 5.0 Release based on the schedule below has been added to RRS. Some
dates were adjusted to end on a Friday and begin on a Monday, which has
been the historic pattern.



> YP 5.0 Milestone Dates:
>
>-
>
>YP 5.0 M1 build date 2023/12/04
>-
>
>YP 5.0 M1 Release date 2023/12/15
>-
>
>YP 5.0 M2 build date  2024/01/15
>-
>
>YP 5.0 M2 Release date 2024/01/24
>-
>
>YP 5.0 M3 build date  2024/02/19
>-
>
>YP 5.0 M3 Release date 2024/03/01
>-
>
>YP 5.0 M4 build date  2024/04/01
>-
>
>YP 5.0 M4 Release date 2024/04/30
>
>
> Upcoming dot releases:
>
>-
>
>YP 3.1.29 build date 2023/10/30
>-
>
>YP 3.1.29 Release date 2023/11/10
>-
>
>YP 4.0.14 build date 2023/11/06
>-
>
>YP 4.0.14 Release date 2023/11/17
>-
>
>YP 4.2.4 build date 2023/11/13
>-
>
>YP 4.2.4 Release date 2023/11/24
>-
>
>YP 4.3.1 build d