[linux-yocto] [PATCH] octeontx-83xx: fix compilation issue caused by using uninitialized variable

2023-10-24 Thread Ruiqiang Hao via lists.yoctoproject.org 
From: Ruiqiang Hao 

commit 1a7449b36bec ("octeontx-83: domain based driver for 83xx") use
one uninitialized variable. Fix it to avoid following build warning:

drivers/net/ethernet/cavium/octeontx-83xx/pki_main.c: In function 
'pki_ecc_intr_handler':
drivers/net/ethernet/cavium/octeontx-83xx/pki_main.c:38:23: warning: 'pki' is 
used uninitialized [-Wuninitialized]
   38 | struct pki_t *pki = (struct pki_t *)pki;
  |   ^~~
drivers/net/ethernet/cavium/octeontx-83xx/pki_main.c:38:23: note: 'pki' was 
declared here
   38 | struct pki_t *pki = (struct pki_t *)pki;
  |   ^~~

Signed-off-by: Ruiqiang Hao 
---
 drivers/net/ethernet/cavium/octeontx-83xx/pki_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cavium/octeontx-83xx/pki_main.c 
b/drivers/net/ethernet/cavium/octeontx-83xx/pki_main.c
index 9800d283dfcb..83538710f09a 100644
--- a/drivers/net/ethernet/cavium/octeontx-83xx/pki_main.c
+++ b/drivers/net/ethernet/cavium/octeontx-83xx/pki_main.c
@@ -35,7 +35,7 @@ static irqreturn_t pki_gen_intr_handler(int irq, void 
*pki_irq)
 
 static irqreturn_t pki_ecc_intr_handler(int irq, void *pki_irq)
 {
-   struct pki_t *pki = (struct pki_t *)pki;
+   struct pki_t *pki = (struct pki_t *)pki_irq;
u64 reg;
 
dev_err(>pdev->dev, "Received ECC INT\n");
-- 
2.39.2


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

[linux-yocto][linux-yocto v6.1] kernel code for marvell octeon

2023-10-24 Thread Ruiqiang Hao via lists.yoctoproject.org 
Hi Bruce,

Please help to merge this patch into our linux-yocto repo.

repo:
linux-yocto
branch:
v6.1/standard/cn-sdkv5.15/octeon
v6.1/standard/preempt-rt/cn-sdkv5.15/octeon

Thanks,
Ruiqiang

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

[yocto] OpenEmbedded Happy Hour October 25 9pm/2100 UTC

2023-10-24 Thread Denys Dmytriyenko 
All,

You are cordially invited to the next OpenEmbedded Happy Hour on October 25 
for Asia/Pacific timezones @ 2100/9pm UTC (5pm ET / 2pm PT):

https://www.openembedded.org/wiki/Calendar
https://www.openembedded.org/wiki/Happy_Hours
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+Happy+Hour+October+25=20231025T21

Best regards,
Denys Dmytriyenko
OpenEmbedded Board of Directors

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

Re: [yocto] [Poky - Kirstone] About supporting kernel 6.1.

2023-10-24 Thread Ming Wen 
Hi Alex:
 
Got it. Thanks for your comments.
Have a nice day~~
 
Best Regards!
Ming Wen (闻明)
SDK Team | Ambarella Shanghai


-Original Message-
From: Alexander Kanavin  
Sent: Monday, October 23, 2023 7:38 PM
To: Ming Wen 
Cc: yocto@lists.yoctoproject.org
Subject: [EXT] Re: [yocto] [Poky - Kirstone] About supporting kernel 6.1.

Note that the SLTS support is not coming from the actual kernel upstream, but 
from a separate project called 'Civil Infrastructure
Platform':

https://urldefense.com/v3/__https://www.linuxfoundation.org/press/civil-infrastructure-platform-expands-slt-stable-kernel-program__;!!PeEy7nZLVv0!l2A7UskGA-DAiuSHrKccM5uJJUyZLSPftGMJRDU_uYH61D-QjbD0-rO7zD4TSVgSLeDWy6q4sRc7d_yJRdFf$
 

I think the right place for their kernels would be in a meta-cip-kernel layer 
or similar, which you are welcome to create and maintain.

Kirkstone has 5.10 and 5.15, both will continue to receive upstream support for 
the duration of kirkstone support window.

Personally I think ultra-long support windows are bad. It's an indicator of 
one's inability to do software updates properly, which usually comes from poor 
testing and qa practices.

Alex

On Mon, 23 Oct 2023 at 12:17, Ming Wen  wrote:
>
> Hi YOCTOers:
>
> As you may know, according to the recent news update from Linux community, 
> Linux Kernel V6.1 will be the SLTS being supported as LTS till 2033.
> I'm wondering what your plan is to support Kernel 6.1 on Poky - Kirstone.
>
> Thanks~~
> 
>

##
This EXTERNAL email has been scanned by Proofpoint Email Protect service.

**
This email and attachments contain Ambarella Proprietary and/or Confidential 
Information and is intended solely for the use of the individual(s) to whom it 
is addressed. Any unauthorized review, use, disclosure, distribute, copy, or 
print is prohibited. If you are not an intended recipient, please contact the 
sender by reply email and destroy all copies of the original message. Thank you.

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

Re: [yocto] [yocto-autobuilder-helper] [PATCH] config.json: Make meta-oe source mirror config wider coverage

2023-10-24 Thread Richard Purdie 
On Tue, 2023-10-24 at 10:15 -0700, Khem Raj wrote:
> On 10/24/23 4:03 AM, Richard Purdie wrote:
> > Some recipes depend on DISTRO_FEATURES, commercial licensing or compiler
> > config like fortran. Set these things so that we get wider soruce mirror
> > coverage and fewer warnings.
> > 
> > 'commercial' license usage is ok here since we're not building and then
> > shipping any binaries or using it, only mirroring the source code.
> > 
> > Signed-off-by: Richard Purdie 
> > ---
> >   config.json | 6 ++
> >   1 file changed, 6 insertions(+)
> > 
> > diff --git a/config.json b/config.json
> > index 0c35632..61cf374 100644
> > --- a/config.json
> > +++ b/config.json
> > @@ -1451,6 +1451,12 @@
> >   "${BUILDDIR}/../meta-openembedded/meta-initramfs",
> >   "${BUILDDIR}/../meta-openembedded/meta-webserver"
> >   ],
> > +"extravars" : [
> > +"LICENSE_FLAGS_ACCEPTED = 'commercial'",
> > +"DISTRO_FEATURES:append = ' pam systemd usrmerge'",
> > +"FORTRAN:forcevariable = ',fortran'",
> > +"RUNTIMETARGET:append:pn-gcc-runtime = ' libquadmath'"
> 
> I think RUNTIMETARGET should automatically be appended with libquadmath 
> if FORTRAN is set.

Perhaps but that is a change to work on in OE-Core and isn't going to
happen overnight or in previous releases.

Improvements welcome there or perhaps a bug to track it at least.

Cheers,

Richard

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

Re: [yocto] [yocto-autobuilder-helper] [PATCH] config.json: Make meta-oe source mirror config wider coverage

2023-10-24 Thread Khem Raj 

On 10/24/23 4:03 AM, Richard Purdie wrote:

Some recipes depend on DISTRO_FEATURES, commercial licensing or compiler
config like fortran. Set these things so that we get wider soruce mirror
coverage and fewer warnings.

'commercial' license usage is ok here since we're not building and then
shipping any binaries or using it, only mirroring the source code.

Signed-off-by: Richard Purdie 
---
  config.json | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/config.json b/config.json
index 0c35632..61cf374 100644
--- a/config.json
+++ b/config.json
@@ -1451,6 +1451,12 @@
  "${BUILDDIR}/../meta-openembedded/meta-initramfs",
  "${BUILDDIR}/../meta-openembedded/meta-webserver"
  ],
+"extravars" : [
+"LICENSE_FLAGS_ACCEPTED = 'commercial'",
+"DISTRO_FEATURES:append = ' pam systemd usrmerge'",
+"FORTRAN:forcevariable = ',fortran'",
+"RUNTIMETARGET:append:pn-gcc-runtime = ' libquadmath'"


I think RUNTIMETARGET should automatically be appended with libquadmath 
if FORTRAN is set.



+],
  "step1" : {
  "shortname" : "Sources pre-fetching",
  "BBTARGETS" : "universe -c fetch -k",







OpenPGP_0xBB053355919D3314.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

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

Re: [yocto] Clang LLVM do_package strip error

2023-10-24 Thread Khem Raj 
On Tue, Oct 24, 2023 at 6:33 AM Martin Townsend  wrote:
>
> On Mon, Oct 23, 2023 at 5:43 PM Khem Raj  wrote:
> >
> > On Mon, Oct 23, 2023 at 9:29 AM Martin Townsend  
> > wrote:
> > >
> > > Hi,
> > >
> > > I've updated the project I'm working on to kirkstone and using GCC it
> > > is working.  We want to move to Clang but I've seen a couple of
> > > recipes fail in do_package with a similar error.  Here is the output
> > > for runc-opencontainers, the package tini has something similar
> > >
> > >
> > > ERROR: runc-opencontainers-1.1.4+gitAUTOINC+974efd2dfc-r0 do_package:
> > > Fatal errors occurred in subprocesses:
> > > Command '['aarch64-poky-linux-llvm-objcopy', '--only-keep-debug',
> > > '/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/package/usr/bin/runc',
> > > '/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/package/usr/bin/.debug/runc']'
> > > returned non-zero exit status 1.
> > > Subprocess output:aarch64-poky-linux-llvm-objcopy: error: Link field
> > > value 47 in section .rela.plt is not a symbol table
> > >
> >
> > Its using clang and also binutils from llvm here and there has been
> > many fixes we had done to llvm
> > tools and things are better with clang 17, but since you are on
> > kirkstone, you might be using older clang
> > and llvm. So you can try if master branch solves the problem and maybe
> > next LTS you are set other
> > option which might be immediately useful would be to fall back to
> > using objcopy from binutils which you
> > can do via something like below in site.conf
> >
> >  OBJCOPY:pn-runc-opencontainers:toolchain-clang = "${HOST_PREFIX}objcopy"
> >
>
> Moving to master and modifying a few recipes has fixed these issues
> but now docker and containerd-opencontainers are not compiling, for
> containerd, grepping for error I can see

did you switch all layers in your project to respective master branches ?
if not perhaps that might be the first thing to look at.

>
> vendor/k8s.io/apimachinery/pkg/util/sets/byte.go:34:16: syntax error:
> unexpected [, expecting (
> vendor/k8s.io/apimachinery/pkg/util/sets/int.go:34:15: syntax error:
> unexpected [, expecting (
> vendor/k8s.io/apimachinery/pkg/util/sets/int32.go:34:17: syntax error:
> unexpected [, expecting (
> vendor/k8s.io/apimachinery/pkg/util/sets/int64.go:34:17: syntax error:
> unexpected [, expecting (
> vendor/k8s.io/apimachinery/pkg/util/sets/ordered.go:24:10: syntax
> error: unexpected |, expecting semicolon or newline or }
> vendor/k8s.io/apimachinery/pkg/util/sets/ordered.go:31:9: syntax
> error: unexpected |, expecting semicolon or newline or }
> vendor/k8s.io/apimachinery/pkg/util/sets/ordered.go:38:2: syntax
> error: unexpected ~, expecting method or interface name
> vendor/k8s.io/apimachinery/pkg/util/sets/ordered.go:45:2: syntax
> error: unexpected ~, expecting method or interface name
> vendor/k8s.io/apimachinery/pkg/util/sets/ordered.go:52:2: syntax
> error: unexpected ~, expecting method or interface name
> vendor/k8s.io/apimachinery/pkg/util/sets/set.go:24:12: syntax error:
> unexpected comparable, expecting ]
> vendor/k8s.io/apimachinery/pkg/util/sets/set.go:24:12: too many errors
>
> and
>
> make: *** [Makefile:264: bin/containerd-shim] Error 2
> make: *** [Makefile:268: bin/containerd-shim-runc-v1] Error 2
> make: *** [Makefile:272: bin/containerd-shim-runc-v2] Error 2
> make: *** [Makefile:255: bin/ctr] Error 2
> make: *** [Makefile:255: bin/containerd-stress] Error 2
> make: *** [Makefile:255: bin/containerd] Error 2
>
>
> It looks like it's compiling go, do I need to do anything special for
> clang to compile go? I tried updating the recipe to the latest from
> master and still the same error.
>
> The lines from the makefile are
>
> define BUILD_BINARY
> @echo "$(WHALE) $@"
> $(GO) build ${DEBUG_GO_GCFLAGS} ${GO_GCFLAGS} ${GO_BUILD_FLAGS} -o $@
> ${GO_LDFLAGS} ${GO_TAGS}  ./$<
> endef
>
> # Build a binary from a cmd.
> bin/%: cmd/% FORCE
> $(call BUILD_BINARY)
>
>
> > > ERROR: Logfile of failure stored in:
> > > /ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/temp/log.do_package.2936320
> > > ERROR: Task 
> > > (/ws/extra/octopus/octave-kirkstone/build-cad-devel/../sources/meta-virtualization/recipes-containers/runc/runc-opencontainers_git.bb:do_package)
> > > failed with exit code '1'
> > > Pseudo log:
> > > inode mismatch:
> > > '/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/image/usr/bin/docker-runc'
> > > ino 84410787 in db, 84431171 in request.
> > > Setup complete, sending SIGUSR1 to pid 2936321.
> > >
> > > I'm sure these used to compile with Clang in dunfell so could this be
> > > a toolchain problem?
> > >
> > > I'm

[yocto] Yocto Project Status 24 October 2023 (WW43)

2023-10-24 Thread Neal Caidin 
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 October 26th 7:30 am PDT (
   https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
   -

   Weekly Project Engineering Sync Tuesday October 24th 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 (M4) rc2 is in QA.
   -

   For the 4.3 release, the 6.5 serial port issues caused the rc1 build to
   fail. That combined with a serious patchtest behavior meant we rebuilt and
   submitted an rc2 to QA. There were several abandoned builds due to
   infrastructure issues. We are now using the upstream kernel serial fix.
   -

   Our release branch (nanbield) and master have now diverged to keep the
   patch backlog under control so development patches are merging to master.
   -

   Patchtest work is progressing and we’re nearly at the point where it
   will be replying live to emails on list. Examples of the responses can be
   seen on our test mailing list: https://lists.yoctoproject.org/g/test-list
   -

   Source mirroring and reproducibility testing for meta-openembedded are
   now available on the project autobuilder.
   -

   The project is now strongly suggesting source code repositories have a
   SECURITY.md file to ensure users know what to do if they encounter a
   security issue. We are trying to ensure all key project repositories
   contain these. Patches are welcome and we’re encouraging all maintainers to
   follow this best practice.
   -

   The layer index has seen development work to ensure it uses secure
   components, can handle changes in practice (such as main branches), can
   illustrate Yocto Project Compatible status and that the errors/warnings
   generated from builds are under control. Thanks Tim!
   -

   After consultation and discussions the project is now about to document
   its security processes to complete the work in this area. Please watch the
   mailing lists such as the architecture list if you have an interest in this
   area.


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


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 date 2023/11/27
   -

   YP 4.3.1 Release date 2023/12/08
   -

   YP 3.1.30 build date 2023/12/11
   -

   YP 3.1.30 Release date 2023/12/22
   -

   YP 4.0.15 build date 2023/12/18
   -

   YP 4.0.15 Release date 2023/12/29
   -

   YP 4.3.2 build date 2024/01/08
   -

   YP 4.3.2 Release date 2024/01/19
   -

   YP 3.1.31 build date 2024/01/22
   -

   YP 3.1.31 Release date 2024/02/02
   -

   YP

Re: [yocto] Clang LLVM do_package strip error

2023-10-24 Thread Martin Townsend 
On Mon, Oct 23, 2023 at 5:43 PM Khem Raj  wrote:
>
> On Mon, Oct 23, 2023 at 9:29 AM Martin Townsend  
> wrote:
> >
> > Hi,
> >
> > I've updated the project I'm working on to kirkstone and using GCC it
> > is working.  We want to move to Clang but I've seen a couple of
> > recipes fail in do_package with a similar error.  Here is the output
> > for runc-opencontainers, the package tini has something similar
> >
> >
> > ERROR: runc-opencontainers-1.1.4+gitAUTOINC+974efd2dfc-r0 do_package:
> > Fatal errors occurred in subprocesses:
> > Command '['aarch64-poky-linux-llvm-objcopy', '--only-keep-debug',
> > '/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/package/usr/bin/runc',
> > '/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/package/usr/bin/.debug/runc']'
> > returned non-zero exit status 1.
> > Subprocess output:aarch64-poky-linux-llvm-objcopy: error: Link field
> > value 47 in section .rela.plt is not a symbol table
> >
>
> Its using clang and also binutils from llvm here and there has been
> many fixes we had done to llvm
> tools and things are better with clang 17, but since you are on
> kirkstone, you might be using older clang
> and llvm. So you can try if master branch solves the problem and maybe
> next LTS you are set other
> option which might be immediately useful would be to fall back to
> using objcopy from binutils which you
> can do via something like below in site.conf
>
>  OBJCOPY:pn-runc-opencontainers:toolchain-clang = "${HOST_PREFIX}objcopy"
>

Moving to master and modifying a few recipes has fixed these issues
but now docker and containerd-opencontainers are not compiling, for
containerd, grepping for error I can see

vendor/k8s.io/apimachinery/pkg/util/sets/byte.go:34:16: syntax error:
unexpected [, expecting (
vendor/k8s.io/apimachinery/pkg/util/sets/int.go:34:15: syntax error:
unexpected [, expecting (
vendor/k8s.io/apimachinery/pkg/util/sets/int32.go:34:17: syntax error:
unexpected [, expecting (
vendor/k8s.io/apimachinery/pkg/util/sets/int64.go:34:17: syntax error:
unexpected [, expecting (
vendor/k8s.io/apimachinery/pkg/util/sets/ordered.go:24:10: syntax
error: unexpected |, expecting semicolon or newline or }
vendor/k8s.io/apimachinery/pkg/util/sets/ordered.go:31:9: syntax
error: unexpected |, expecting semicolon or newline or }
vendor/k8s.io/apimachinery/pkg/util/sets/ordered.go:38:2: syntax
error: unexpected ~, expecting method or interface name
vendor/k8s.io/apimachinery/pkg/util/sets/ordered.go:45:2: syntax
error: unexpected ~, expecting method or interface name
vendor/k8s.io/apimachinery/pkg/util/sets/ordered.go:52:2: syntax
error: unexpected ~, expecting method or interface name
vendor/k8s.io/apimachinery/pkg/util/sets/set.go:24:12: syntax error:
unexpected comparable, expecting ]
vendor/k8s.io/apimachinery/pkg/util/sets/set.go:24:12: too many errors

and

make: *** [Makefile:264: bin/containerd-shim] Error 2
make: *** [Makefile:268: bin/containerd-shim-runc-v1] Error 2
make: *** [Makefile:272: bin/containerd-shim-runc-v2] Error 2
make: *** [Makefile:255: bin/ctr] Error 2
make: *** [Makefile:255: bin/containerd-stress] Error 2
make: *** [Makefile:255: bin/containerd] Error 2


It looks like it's compiling go, do I need to do anything special for
clang to compile go? I tried updating the recipe to the latest from
master and still the same error.

The lines from the makefile are

define BUILD_BINARY
@echo "$(WHALE) $@"
$(GO) build ${DEBUG_GO_GCFLAGS} ${GO_GCFLAGS} ${GO_BUILD_FLAGS} -o $@
${GO_LDFLAGS} ${GO_TAGS}  ./$<
endef

# Build a binary from a cmd.
bin/%: cmd/% FORCE
$(call BUILD_BINARY)


> > ERROR: Logfile of failure stored in:
> > /ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/temp/log.do_package.2936320
> > ERROR: Task 
> > (/ws/extra/octopus/octave-kirkstone/build-cad-devel/../sources/meta-virtualization/recipes-containers/runc/runc-opencontainers_git.bb:do_package)
> > failed with exit code '1'
> > Pseudo log:
> > inode mismatch:
> > '/ws/extra/octopus/octave-kirkstone/build-cad-devel/tmp/work/cortexa53-crypto-poky-linux/runc-opencontainers/1.1.4+gitAUTOINC+974efd2dfc-r0/image/usr/bin/docker-runc'
> > ino 84410787 in db, 84431171 in request.
> > Setup complete, sending SIGUSR1 to pid 2936321.
> >
> > I'm sure these used to compile with Clang in dunfell so could this be
> > a toolchain problem?
> >
> > I'm using the kirkstone branch of meta-clang and have the following in
> > my distro conf
> > PREFERRED_PROVIDER_llvm = "clang"
> > PREFERRED_PROVIDER_llvm-native = "clang-native"
> > PREFERRED_PROVIDER_nativesdk-llvm = "nativesdk-clang"
> > PROVIDES:pn-clang = "llvm"
> > PROVIDES:pn-clang-native = "llvm-native"
> > PROVIDES:pn-nativesdk-clang = "nativesdk-llvm"
> >
> > and this in local.conf

[yocto] [meta-mingw] [PATCH] SECURITY.md: add file

2023-10-24 Thread Richard Purdie 
Add a SECURITY.md file with hints for security researchers and other
parties who might report potential security vulnerabilities.

Signed-off-by: Richard Purdie 
---
 SECURITY.md | 24 
 1 file changed, 24 insertions(+)
 create mode 100644 SECURITY.md

diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 000..7d2ce1f
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,24 @@
+How to Report a Potential Vulnerability?
+
+
+If you would like to report a public issue (for example, one with a released
+CVE number), please report it using the
+[https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Security Security 
Bugzilla].
+If you have a patch ready, submit it following the same procedure as any other
+patch as described in README.md.
+
+If you are dealing with a not-yet released or urgent issue, please send a
+message to security AT yoctoproject DOT org, including as many details as
+possible: the layer or software module affected, the recipe and its version,
+and any example code, if available.
+
+Branches maintained with security fixes
+---
+
+See [https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS Stable release 
and LTS]
+for detailed info regarding the policies and maintenance of Stable branches.
+
+The [https://wiki.yoctoproject.org/wiki/Releases Release page] contains a list 
of all
+releases of the Yocto Project. Versions in grey are no longer actively 
maintained with
+security patches, but well-tested patches may still be accepted for them for
+significant issues.
-- 
2.39.2


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

[yocto] [yocto-autobuilder2] [PATCH] SECURITY.md: Add file

2023-10-24 Thread Richard Purdie 
Add a SECURITY.md file with hints for security researchers and other
parties who might report potential security vulnerabilities.

Signed-off-by: Richard Purdie 
---
 SECURITY.md | 13 +
 1 file changed, 13 insertions(+)
 create mode 100644 SECURITY.md

diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index ..7ccecc1f
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,13 @@
+How to Report a Potential Vulnerability?
+
+
+If you would like to report a public issue (for example, one with a released
+CVE number), please report it using the
+[https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Security Security 
Bugzilla].
+If you have a patch ready, submit it following the same procedure as any other
+patch as described in README.md.
+
+If you are dealing with a not-yet released or urgent issue, please send a
+message to security AT yoctoproject DOT org, including as many details as
+possible: the layer or software module affected, the recipe and its version,
+and any example code, if available.
-- 
2.39.2


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

[yocto] [yocto-autobuilder-helper] [PATCH] SECURITY.md: Add file

2023-10-24 Thread Richard Purdie 
Add a SECURITY.md file with hints for security researchers and other
parties who might report potential security vulnerabilities.

Signed-off-by: Richard Purdie 
---
 SECURITY.md | 24 
 1 file changed, 24 insertions(+)
 create mode 100644 SECURITY.md

diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 000..7d2ce1f
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,24 @@
+How to Report a Potential Vulnerability?
+
+
+If you would like to report a public issue (for example, one with a released
+CVE number), please report it using the
+[https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Security Security 
Bugzilla].
+If you have a patch ready, submit it following the same procedure as any other
+patch as described in README.md.
+
+If you are dealing with a not-yet released or urgent issue, please send a
+message to security AT yoctoproject DOT org, including as many details as
+possible: the layer or software module affected, the recipe and its version,
+and any example code, if available.
+
+Branches maintained with security fixes
+---
+
+See [https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS Stable release 
and LTS]
+for detailed info regarding the policies and maintenance of Stable branches.
+
+The [https://wiki.yoctoproject.org/wiki/Releases Release page] contains a list 
of all
+releases of the Yocto Project. Versions in grey are no longer actively 
maintained with
+security patches, but well-tested patches may still be accepted for them for
+significant issues.
-- 
2.39.2


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

[yocto] [yocto-autobuilder-helper] [PATCH] config.json: Make meta-oe source mirror config wider coverage

2023-10-24 Thread Richard Purdie 
Some recipes depend on DISTRO_FEATURES, commercial licensing or compiler
config like fortran. Set these things so that we get wider soruce mirror
coverage and fewer warnings.

'commercial' license usage is ok here since we're not building and then
shipping any binaries or using it, only mirroring the source code.

Signed-off-by: Richard Purdie 
---
 config.json | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/config.json b/config.json
index 0c35632..61cf374 100644
--- a/config.json
+++ b/config.json
@@ -1451,6 +1451,12 @@
 "${BUILDDIR}/../meta-openembedded/meta-initramfs",
 "${BUILDDIR}/../meta-openembedded/meta-webserver"
 ],
+"extravars" : [
+"LICENSE_FLAGS_ACCEPTED = 'commercial'",
+"DISTRO_FEATURES:append = ' pam systemd usrmerge'",
+"FORTRAN:forcevariable = ',fortran'",
+"RUNTIMETARGET:append:pn-gcc-runtime = ' libquadmath'"
+],
 "step1" : {
 "shortname" : "Sources pre-fetching",
 "BBTARGETS" : "universe -c fetch -k",
-- 
2.39.2


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

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

2023-10-24 Thread Richard Purdie 
Hi David,

Comments below. I did try and sync up with Alex Kanavin so we have a
consistent direction.

On Tue, 2023-10-24 at 10:16 +0200, David PIERRET wrote:
> On Fri, Oct 20, 2023 at 4:57 PM Richard Purdie
>  wrote:
> > 
> > Hi David,
> > 
> > Thanks for revising this, it is heading in the right direction.
> > 
> > On Fri, 2023-10-20 at 16:05 +0200, David Pierret wrote:
> > > - Add setup and run script openembedded specific
> > > - Add job config
> > > 
> > > Signed-off-by: David Pierret 
> > > ---
> > >  config.json  |  6 ++
> > >  scripts/run-auh-oe   | 45 
> > >  scripts/setup-auh-oe | 34 +
> > >  3 files changed, 85 insertions(+)
> > >  create mode 100755 scripts/run-auh-oe
> > >  create mode 100755 scripts/setup-auh-oe
> > > 
> > > diff --git a/config.json b/config.json
> > > index 3acb710..bbd0aaf 100644
> > > --- a/config.json
> > > +++ b/config.json
> > > @@ -1420,6 +1420,12 @@
> > >  "${SCRIPTSDIR}/setup-auh ${HELPERBUILDDIR}; 
> > > ${SCRIPTSDIR}/run-auh ${HELPERBUILDDIR} ${WEBPUBLISH_DIR}/pub/auh/"
> > >  ]
> > >  },
> > > +"auh-openembedded" : {
> > 
> > This needs to be "auh-meta-oe" since "auh" is for openembedded-core and
> > this is otherwise going to be confusing.
> > 
> > > +"NEEDREPOS" : ["poky", "meta-openembedded"],
> > > +"EXTRAPLAINCMDS" : [
> > > +"${SCRIPTSDIR}/setup-auh-oe ${HELPERBUILDDIR}; 
> > > ${SCRIPTSDIR}/run-auh-oe ${HELPERBUILDDIR} ${WEBPUBLISH_DIR}/pub/auh/ 
> > > ${HELPERBUILDDIR}/meta-openembedded 
> > > ${HELPERBUILDDIR}/meta-openembedded/meta-oe 
> > > ${HELPERBUILDDIR}/meta-openembedded/meta-python 
> > > ${HELPERBUILDDIR}/meta-openembedded/meta-perl 
> > > ${HELPERBUILDDIR}/meta-openembedded/meta-networking 
> > > ${HELPERBUILDDIR}/meta-openembedded/meta-multimedia 
> > > ${HELPERBUILDDIR}/meta-openembedded/meta-gnome 
> > > ${HELPERBUILDDIR}/meta-openembedded/meta-xfce 
> > > ${HELPERBUILDDIR}/meta-openembedded/meta-filesystems 
> > > ${HELPERBUILDDIR}/meta-openembedded/meta-initramfs 
> > > ${HELPERBUILDDIR}/meta-openembedded/meta-webserver "
> > > +]
> > > +},
> > >  "a-quick" : {
> > >  "TEMPLATE" : "trigger-build"
> > >  },
> > 
> > Would it be better to have one setup-auh/run-auh script and add
> > ${HELPERTARGET}  as a parameter?
> > 
> > This should translate to "auh" or "auh-meta-oe" and the script can then
> > have conditionals in to handle both cases rather than duplicating the
> > script?
> 
> The setup-auh script is cloning its own repository instead of using
> the one initialized by CI.
> Any reason to not use them ? We could use the NEEDREPOS instead of the
> setup script,
> and add the auto-upgrade-helper repository in the config.

I think it does it's own clone for historical reasons from when it was
a standalone tool. I'm fine with letting the autobuilder handle this.

> > > diff --git a/scripts/run-auh-oe b/scripts/run-auh-oe
> > > new file mode 100755
> > > index 000..588755a
> > > --- /dev/null
> > > +++ b/scripts/run-auh-oe
> > 
> > Similarly, this should be run-auh-meta-oe.
> > 
> > > @@ -0,0 +1,45 @@
> > > +#!/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] [meta_dir] [meta_list]"
> > > +  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
> > > +meta_dir=$3
> > > +meta_list=${@:4}
> > > +machine_list="qemux86 qemux86-64 qemuarm qemumips qemuppc qemux86_musl"
> > 
> > Do we need to vary the machine_list per layer? At present it only seems
> > to support one list anyway so I'm not sure this does anything useful?
> 
> The list is the same as the one used for poky.

It matches the default in the scripts though so I was wondering why
this was specified?

FWIW I agree we should perhaps limit testing to qemux86-64, qemuarm and
qemux86_musl initially just to make things a little easier.

> > > +pushd $meta_dir || exit 1
> > > +
> > > +# Base the upgrades on meta_openembedded master
> > > +git fetch origin
> > > +git checkout -B tmp-auh-upgrades origin/main
> > > +
> > > +source $poky_dir/oe-init-build-env $build_dir
> > > +
> > > +# build the layer_names variable to me used in the command line
> > > +layer_names=""
> > > +for d in $meta_list; do
> > > +  layer_names+=" $(basename ${d})"
> > > +done
> > > +
> > > +$auh_dir/upgrade-helper.py -e --layer-dir ${meta_dir} --layer-names 
> > > ${layer_names} --layer-machines ${machine_list} -- all
> > 
> > Would it be simpler just to iterate, calling

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

2023-10-24 Thread Alexander Kanavin 
On Tue, 24 Oct 2023 at 10:17, David Pierret  wrote:

> The iteration over a list was my first approach, but aborted following
> review on patch v1.
> The V1 review asked to allow the AUH to accept dynamic layers as parameters.
> We maybe misunderstood each other.

I would suggest that AUH changes where dynamic layer configuration is
given over command line gets merged first, and this patch is adjusted
to use that. Then we can work out how to use that on higher levels.. I
also lean towards giving AUH only one layer to work on per invocation,
and specific layers being defined in autobuilder configurations. This
would allow more efficient autobuilder execution, if layers are worked
on in parallel (meta-oe as a whole is huge).

Alex

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

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

2023-10-24 Thread David Pierret 
Hi Richard,

Thanks for the review, please find my feedback in follow.

On Fri, Oct 20, 2023 at 4:57 PM Richard Purdie
 wrote:
>
> Hi David,
>
> Thanks for revising this, it is heading in the right direction.
>
> On Fri, 2023-10-20 at 16:05 +0200, David Pierret wrote:
> > - Add setup and run script openembedded specific
> > - Add job config
> >
> > Signed-off-by: David Pierret 
> > ---
> >  config.json  |  6 ++
> >  scripts/run-auh-oe   | 45 
> >  scripts/setup-auh-oe | 34 +
> >  3 files changed, 85 insertions(+)
> >  create mode 100755 scripts/run-auh-oe
> >  create mode 100755 scripts/setup-auh-oe
> >
> > diff --git a/config.json b/config.json
> > index 3acb710..bbd0aaf 100644
> > --- a/config.json
> > +++ b/config.json
> > @@ -1420,6 +1420,12 @@
> >  "${SCRIPTSDIR}/setup-auh ${HELPERBUILDDIR}; 
> > ${SCRIPTSDIR}/run-auh ${HELPERBUILDDIR} ${WEBPUBLISH_DIR}/pub/auh/"
> >  ]
> >  },
> > +"auh-openembedded" : {
>
> This needs to be "auh-meta-oe" since "auh" is for openembedded-core and
> this is otherwise going to be confusing.
>
> > +"NEEDREPOS" : ["poky", "meta-openembedded"],
> > +"EXTRAPLAINCMDS" : [
> > +"${SCRIPTSDIR}/setup-auh-oe ${HELPERBUILDDIR}; 
> > ${SCRIPTSDIR}/run-auh-oe ${HELPERBUILDDIR} ${WEBPUBLISH_DIR}/pub/auh/ 
> > ${HELPERBUILDDIR}/meta-openembedded 
> > ${HELPERBUILDDIR}/meta-openembedded/meta-oe 
> > ${HELPERBUILDDIR}/meta-openembedded/meta-python 
> > ${HELPERBUILDDIR}/meta-openembedded/meta-perl 
> > ${HELPERBUILDDIR}/meta-openembedded/meta-networking 
> > ${HELPERBUILDDIR}/meta-openembedded/meta-multimedia 
> > ${HELPERBUILDDIR}/meta-openembedded/meta-gnome 
> > ${HELPERBUILDDIR}/meta-openembedded/meta-xfce 
> > ${HELPERBUILDDIR}/meta-openembedded/meta-filesystems 
> > ${HELPERBUILDDIR}/meta-openembedded/meta-initramfs 
> > ${HELPERBUILDDIR}/meta-openembedded/meta-webserver "
> > +]
> > +},
> >  "a-quick" : {
> >  "TEMPLATE" : "trigger-build"
> >  },
>
> Would it be better to have one setup-auh/run-auh script and add
> ${HELPERTARGET}  as a parameter?
>
> This should translate to "auh" or "auh-meta-oe" and the script can then
> have conditionals in to handle both cases rather than duplicating the
> script?

The setup-auh script is cloning its own repository instead of using
the one initialized by CI.
Any reason to not use them ? We could use the NEEDREPOS instead of the
setup script,
and add the auto-upgrade-helper repository in the config.

>
> > diff --git a/scripts/run-auh-oe b/scripts/run-auh-oe
> > new file mode 100755
> > index 000..588755a
> > --- /dev/null
> > +++ b/scripts/run-auh-oe
>
> Similarly, this should be run-auh-meta-oe.
>
> > @@ -0,0 +1,45 @@
> > +#!/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] [meta_dir] [meta_list]"
> > +  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
> > +meta_dir=$3
> > +meta_list=${@:4}
> > +machine_list="qemux86 qemux86-64 qemuarm qemumips qemuppc qemux86_musl"
>
> Do we need to vary the machine_list per layer? At present it only seems
> to support one list anyway so I'm not sure this does anything useful?

The list is the same as the one used for poky.

>
> > +pushd $meta_dir || exit 1
> > +
> > +# Base the upgrades on meta_openembedded master
> > +git fetch origin
> > +git checkout -B tmp-auh-upgrades origin/main
> > +
> > +source $poky_dir/oe-init-build-env $build_dir
> > +
> > +# build the layer_names variable to me used in the command line
> > +layer_names=""
> > +for d in $meta_list; do
> > +  layer_names+=" $(basename ${d})"
> > +done
> > +
> > +$auh_dir/upgrade-helper.py -e --layer-dir ${meta_dir} --layer-names 
> > ${layer_names} --layer-machines ${machine_list} -- all
>
> Would it be simpler just to iterate, calling upgrade-helper once per
> sub-layer or meta-openembedded?

Is it prefered to set 1 step per layer ?
or keep the call to the script but iterate over a list of layers ?

>
> You may have considered that in which case I'd just like to understand
> why you ended up with this as the preferred way of doing things?
>
> In some ways a separate report/run may be useful for the way meta-oe
> maintainers might handle this?

The iteration over a list was my first approach, but aborted following
review on patch v1.
The V1 review asked to allow the AUH to accept dynamic layers as parameters.
We maybe misunderstood each other.

>
> > +
> > +if [ -n $2 ]; then
> > +  cp -rf $build_dir/upgrade-helper/* $2
> > +fi