Update ${base_prefix}/lib to ${nonarch_base_libdir} to fix a package QA
issue when usrmerge is enabled in DISTRO_FEATURES.

QA Issue: tpm2-tss package is not obeying usrmerge distro feature. /lib
should be relocated to /usr. [usrmerge]

Signed-off-by: Ricardo Salveti <ricardo@foundries.io>
---
meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_3.0.3.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_3.0.3.bb b/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_3.0.3.bb
index b2486e5..cc4f191 100644
--- a/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_3.0.3.bb
+++ b/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_3.0.3.bb
@@ -17,7 +17,7 @@ PACKAGECONFIG ??= ""
PACKAGECONFIG[oxygen] = ",--disable-doxygen-doc, "
PACKAGECONFIG[fapi] = "--enable-fapi,--disable-fapi,json-c "

-EXTRA_OECONF += "--enable-static --with-udevrulesdir=${base_prefix}/lib/udev/rules.d/"
+EXTRA_OECONF += "--enable-static --with-udevrulesdir=${nonarch_base_libdir}/udev/rules.d/"
EXTRA_OECONF_remove = " --disable-static"


@@ -73,6 +73,6 @@ FILES_libtss2-dev = " \
${libdir}/libtss2*so"
FILES_libtss2-staticdev = "${libdir}/libtss*a"

-FILES_${PN} = "${libdir}/udev ${base_prefix}/lib/udev"
+FILES_${PN} = "${libdir}/udev ${nonarch_base_libdir}/udev"

RDEPENDS_libtss2 = "libgcrypt"
--
2.31.1

On Thu, May 20, 2021 at 9:18 AM Jasper Orschulko
<Jasper.Orschulko@iris-sensing.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

OK, maybe I did not make the issue clear enough:

I have a package A which statically links package B at compile time
(using DEPENDS).
As a result the package A is "tainted" with source code from package B.
However, as package B is only in the DEPENDS, not in the RDEPENDS, it
is not included in the license.manifest. As a result, the output image
violates the license terms of package B.

Now my idea comes into play:
Add package B to the RDEPENDS (even though the ${PN} package is empty
after the packages-split), which should result in package B's inclusion
in the license.manifest. Or am I approaching this completely wrong?

I see, this is a workaround that will work in this case but may not
work in case where the PN is not empty
but static linking it happening. So I think in cases of static linking
the parent recipe has to reflect that chage

- --
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@iris-sensing.com

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Ostendstraße 1-14 | 12459 Berlin

https://iris-sensing.com/




On Thu, 2021-05-20 at 09:04 -0700, Khem Raj wrote:

On Thu, May 20, 2021 at 9:00 AM Jasper Orschulko
<Jasper.Orschulko@iris-sensing.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Khem,

thanks for your reply. As far as I understand, the "proper" way is
to
use dynamic linked libraries whenever possible? I have done some
more
thinking on the matter, and at least in our case the packages in
question are empty (the base package that is, everything else is in
${PN}-src ${PN}-devstatic etc), so I believe the easiest way to
include
these into the license manifest is to also add them to RDEPENDS and
set
ALLOW_EMPTY_${PN} = "1". This should not change the output image,
but
include the packages in the build, thus adding them to the license
manifest. What do you think?

I am not sure why you will include empty packages in your manifest

- --
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@iris-sensing.com

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Ostendstraße 1-14 | 12459 Berlin

https://iris-sensing.com/




On Mon, 2021-05-17 at 15:56 -0700, Khem Raj wrote:

On 5/17/21 10:44 AM, Jasper Orschulko wrote:

Hi,

my question more or less reiterates the following:
https://www.yoctoproject.org/pipermail/yocto/2018-July/041854.html

I am trying to find a way to list statically linked libraries
in
the
license manifest, but so far I am at a loss. To my
understanding
Yocto
does not understand packages included using DEPENDS and not
RDEPENDS as
part of the resulting image, however technically source code
from
the
dependee can (and will) end up on the image as part of the
dependent
package. This is a serious issue from a legal point of view, as
the
developer ultimately might end up with an incomplete list of
licenses,
when relying on the Yocto license manifest.

Please, do correct me if I'm wrong :)

partly yes. there is a provision to disable static linking using
DISABLE_STATIC, so atleast some of packages can be cleared of.
depends
are effective during build time and its the linking which decides
on
that but you can perhaps easily write a probe and extract this
information from linker cmdline perhaps by dumping linker map and
post
processing it.

>
>
>
>
>

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmCmh3EACgkQYgqew07V
MNWiXAf9GPbvZjlzAW+ref/+RKP/9GbtSBpajVUkn+x4DYdO0DmSq6JwOGeLblW8
qu2wjw9cLwgDAL4YRLESrgA3XAbflFgf0IZBuEMbT6WONW7fgHeQ7+jPrEQ7dkgx
POrePcququDSDi2idjjrdTuqHxLl0Il09g8vJz9oktZhIKwCesqWQE8VjSLcjBaj
u+7nHLY77fV/a1o/Ka7PkH2AjbWsmn/iHC1hLN91yNVG6EyzAneHQYKDo7Y5kRVn
YWNSgmmab7uiigrN2KqFOblazkBaA5/rIKD1PpeOjqOTtF7+UfWkL5DZZArdh/KG
+E3VauRz6agqxbb0VUWZZjE6if07Qg==
=UCmd
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmCmi5gACgkQYgqew07V
MNURUQf+J7XVwVWvY8fFiOqXyiUFQXzeKpru3v9QNx6RRfXSxUXvs1taKPHEdKOG
vhBvnEIagC6Hzg0+QRBamk8c7KdgQXlS7FGNzMAbybE0Is/ocY1dpiQABSKTP8Za
4/EFNBZ64fzPMfFq3gX3mzko4vf7Ub6R3hmXkZTZnJVUTU9fMCNnxt94mXDvwSB4
bK54TRs2Zpg9s77XxL/nxvaEpkdYC2GBMxIgjahVLVhbxgmn03Sozt2zawbawGRK
NpvagP06+6o0gSgwKBJ3bU2H3i9nQGLOETTGvMjnsbqOANusNZ6QR2WTtJrFirZN
j10vjBt7b+0/GOqU0ONGnVDQYSx74A==
=foGh
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

OK, maybe I did not make the issue clear enough:

I have a package A which statically links package B at compile time
(using DEPENDS).
As a result the package A is "tainted" with source code from package B.
However, as package B is only in the DEPENDS, not in the RDEPENDS, it
is not included in the license.manifest. As a result, the output image
violates the license terms of package B.

Now my idea comes into play:
Add package B to the RDEPENDS (even though the ${PN} package is empty
after the packages-split), which should result in package B's inclusion
in the license.manifest. Or am I approaching this completely wrong?

- --
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@iris-sensing.com

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Ostendstraße 1-14 | 12459 Berlin

https://iris-sensing.com/




On Thu, 2021-05-20 at 09:04 -0700, Khem Raj wrote:

On Thu, May 20, 2021 at 9:00 AM Jasper Orschulko
<Jasper.Orschulko@iris-sensing.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Khem,

thanks for your reply. As far as I understand, the "proper" way is
to
use dynamic linked libraries whenever possible? I have done some
more
thinking on the matter, and at least in our case the packages in
question are empty (the base package that is, everything else is in
${PN}-src ${PN}-devstatic etc), so I believe the easiest way to
include
these into the license manifest is to also add them to RDEPENDS and
set
ALLOW_EMPTY_${PN} = "1". This should not change the output image,
but
include the packages in the build, thus adding them to the license
manifest. What do you think?

I am not sure why you will include empty packages in your manifest

- --
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@iris-sensing.com

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Ostendstraße 1-14 | 12459 Berlin

https://iris-sensing.com/




On Mon, 2021-05-17 at 15:56 -0700, Khem Raj wrote:

On 5/17/21 10:44 AM, Jasper Orschulko wrote:

Hi,

my question more or less reiterates the following:
https://www.yoctoproject.org/pipermail/yocto/2018-July/041854.html

I am trying to find a way to list statically linked libraries
in
the
license manifest, but so far I am at a loss. To my
understanding
Yocto
does not understand packages included using DEPENDS and not
RDEPENDS as
part of the resulting image, however technically source code
from
the
dependee can (and will) end up on the image as part of the
dependent
package. This is a serious issue from a legal point of view, as
the
developer ultimately might end up with an incomplete list of
licenses,
when relying on the Yocto license manifest.

Please, do correct me if I'm wrong :)

partly yes. there is a provision to disable static linking using
DISABLE_STATIC, so atleast some of packages can be cleared of.
depends
are effective during build time and its the linking which decides
on
that but you can perhaps easily write a probe and extract this
information from linker cmdline perhaps by dumping linker map and
post
processing it.

 >
 >
 >
 >
 >

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmCmh3EACgkQYgqew07V
MNWiXAf9GPbvZjlzAW+ref/+RKP/9GbtSBpajVUkn+x4DYdO0DmSq6JwOGeLblW8
qu2wjw9cLwgDAL4YRLESrgA3XAbflFgf0IZBuEMbT6WONW7fgHeQ7+jPrEQ7dkgx
POrePcququDSDi2idjjrdTuqHxLl0Il09g8vJz9oktZhIKwCesqWQE8VjSLcjBaj
u+7nHLY77fV/a1o/Ka7PkH2AjbWsmn/iHC1hLN91yNVG6EyzAneHQYKDo7Y5kRVn
YWNSgmmab7uiigrN2KqFOblazkBaA5/rIKD1PpeOjqOTtF7+UfWkL5DZZArdh/KG
+E3VauRz6agqxbb0VUWZZjE6if07Qg==
=UCmd
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmCmi5gACgkQYgqew07V
MNURUQf+J7XVwVWvY8fFiOqXyiUFQXzeKpru3v9QNx6RRfXSxUXvs1taKPHEdKOG
vhBvnEIagC6Hzg0+QRBamk8c7KdgQXlS7FGNzMAbybE0Is/ocY1dpiQABSKTP8Za
4/EFNBZ64fzPMfFq3gX3mzko4vf7Ub6R3hmXkZTZnJVUTU9fMCNnxt94mXDvwSB4
bK54TRs2Zpg9s77XxL/nxvaEpkdYC2GBMxIgjahVLVhbxgmn03Sozt2zawbawGRK
NpvagP06+6o0gSgwKBJ3bU2H3i9nQGLOETTGvMjnsbqOANusNZ6QR2WTtJrFirZN
j10vjBt7b+0/GOqU0ONGnVDQYSx74A==
=foGh
-----END PGP SIGNATURE-----

On Thu, May 20, 2021 at 9:00 AM Jasper Orschulko
<Jasper.Orschulko@iris-sensing.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Khem,

thanks for your reply. As far as I understand, the "proper" way is to
use dynamic linked libraries whenever possible? I have done some more
thinking on the matter, and at least in our case the packages in
question are empty (the base package that is, everything else is in
${PN}-src ${PN}-devstatic etc), so I believe the easiest way to include
these into the license manifest is to also add them to RDEPENDS and set
ALLOW_EMPTY_${PN} = "1". This should not change the output image, but
include the packages in the build, thus adding them to the license
manifest. What do you think?

I am not sure why you will include empty packages in your manifest

- --
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@iris-sensing.com

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Ostendstraße 1-14 | 12459 Berlin

https://iris-sensing.com/




On Mon, 2021-05-17 at 15:56 -0700, Khem Raj wrote:

On 5/17/21 10:44 AM, Jasper Orschulko wrote:

Hi,

my question more or less reiterates the following:
https://www.yoctoproject.org/pipermail/yocto/2018-July/041854.html

I am trying to find a way to list statically linked libraries in
the
license manifest, but so far I am at a loss. To my understanding
Yocto
does not understand packages included using DEPENDS and not
RDEPENDS as
part of the resulting image, however technically source code from
the
dependee can (and will) end up on the image as part of the
dependent
package. This is a serious issue from a legal point of view, as the
developer ultimately might end up with an incomplete list of
licenses,
when relying on the Yocto license manifest.

Please, do correct me if I'm wrong :)

partly yes. there is a provision to disable static linking using
DISABLE_STATIC, so atleast some of packages can be cleared of.
depends
are effective during build time and its the linking which decides on
that but you can perhaps easily write a probe and extract this
information from linker cmdline perhaps by dumping linker map and
post
processing it.

>
>
>
>
>

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmCmh3EACgkQYgqew07V
MNWiXAf9GPbvZjlzAW+ref/+RKP/9GbtSBpajVUkn+x4DYdO0DmSq6JwOGeLblW8
qu2wjw9cLwgDAL4YRLESrgA3XAbflFgf0IZBuEMbT6WONW7fgHeQ7+jPrEQ7dkgx
POrePcququDSDi2idjjrdTuqHxLl0Il09g8vJz9oktZhIKwCesqWQE8VjSLcjBaj
u+7nHLY77fV/a1o/Ka7PkH2AjbWsmn/iHC1hLN91yNVG6EyzAneHQYKDo7Y5kRVn
YWNSgmmab7uiigrN2KqFOblazkBaA5/rIKD1PpeOjqOTtF7+UfWkL5DZZArdh/KG
+E3VauRz6agqxbb0VUWZZjE6if07Qg==
=UCmd
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Khem,

thanks for your reply. As far as I understand, the "proper" way is to
use dynamic linked libraries whenever possible? I have done some more
thinking on the matter, and at least in our case the packages in
question are empty (the base package that is, everything else is in
${PN}-src ${PN}-devstatic etc), so I believe the easiest way to include
these into the license manifest is to also add them to RDEPENDS and set
ALLOW_EMPTY_${PN} = "1". This should not change the output image, but
include the packages in the build, thus adding them to the license
manifest. What do you think?

- --
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@iris-sensing.com

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Ostendstraße 1-14 | 12459 Berlin

https://iris-sensing.com/




On Mon, 2021-05-17 at 15:56 -0700, Khem Raj wrote:

On 5/17/21 10:44 AM, Jasper Orschulko wrote:

Hi,

my question more or less reiterates the following:
https://www.yoctoproject.org/pipermail/yocto/2018-July/041854.html

I am trying to find a way to list statically linked libraries in
the
license manifest, but so far I am at a loss. To my understanding
Yocto
does not understand packages included using DEPENDS and not
RDEPENDS as
part of the resulting image, however technically source code from
the
dependee can (and will) end up on the image as part of the
dependent
package. This is a serious issue from a legal point of view, as the
developer ultimately might end up with an incomplete list of
licenses,
when relying on the Yocto license manifest.

Please, do correct me if I'm wrong :)

partly yes. there is a provision to disable static linking using
DISABLE_STATIC, so atleast some of packages can be cleared of.
depends
are effective during build time and its the linking which decides on
that but you can perhaps easily write a probe and extract this
information from linker cmdline perhaps by dumping linker map and
post
processing it.

 >
 >
 >
 >
 >

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmCmh3EACgkQYgqew07V
MNWiXAf9GPbvZjlzAW+ref/+RKP/9GbtSBpajVUkn+x4DYdO0DmSq6JwOGeLblW8
qu2wjw9cLwgDAL4YRLESrgA3XAbflFgf0IZBuEMbT6WONW7fgHeQ7+jPrEQ7dkgx
POrePcququDSDi2idjjrdTuqHxLl0Il09g8vJz9oktZhIKwCesqWQE8VjSLcjBaj
u+7nHLY77fV/a1o/Ka7PkH2AjbWsmn/iHC1hLN91yNVG6EyzAneHQYKDo7Y5kRVn
YWNSgmmab7uiigrN2KqFOblazkBaA5/rIKD1PpeOjqOTtF7+UfWkL5DZZArdh/KG
+E3VauRz6agqxbb0VUWZZjE6if07Qg==
=UCmd
-----END PGP SIGNATURE-----

From: Richard Purdie <richard.purdie@linuxfoundation.org>

The autobuilders have 128GB memory, we don't want them using 50% which is
the default, 5% should be enough. Also limit the number of threads down
from 48 to something reasonable. This may be partly causing some of our
performance issues?

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 19b4e74b3960174238acc79fd112f55706bc7385)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
config.json | 2 ++
1 file changed, 2 insertions(+)

diff --git a/config.json b/config.json
index e77a8fe..b62035b 100644
--- a/config.json
+++ b/config.json
@@ -44,6 +44,8 @@
"BB_GENERATE_MIRROR_TARBALLS = '1'",
"BB_NUMBER_THREADS = '16'",
"PARALLEL_MAKE = '-j 16'",
+ "XZ_MEMLIMIT = '5%'",
+ "XZ_THREADS = '8'",
"BB_TASK_NICE_LEVEL = '5'",
"BB_TASK_NICE_LEVEL_task-testimage = '0'",
"BB_TASK_IONICE_LEVEL = '2.7'",
--
2.25.1

Hello Yocto developers,

I have few problems running the following self proprietary script from
one of my public git repos:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/yocto-setup.sh

I recall that last time I used the script (I used then Fedora 31), the
./yocto setup dunfell worked seamlessly, did setup the environment,
and upon bitbake -k core-image-minimal completed the tasks without any
problem.

Now, I am using Fedora 33 (in the meantime I did two Fedora version upgrades).

The problem is that while compiling the cannelloni package, the
following errors were issued (please, look into the attached file
cmake_problem.txt).

This cmake problem was introduced after switching from Fedora 31 to Fedora 33 ?!

Any clue/idea why this is happening??? What is the cause of the problem?

Thank you,
Zoran
_______

zephyr can be build for 'acrn' with following configuration:

MACHINE = "intel-x86-64"
ZEPHYR_BOARD = "acrn"

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
conf/machine/acrn.conf | 9 ---------
1 file changed, 9 deletions(-)
delete mode 100644 conf/machine/acrn.conf

diff --git a/conf/machine/acrn.conf b/conf/machine/acrn.conf
deleted file mode 100644
index c044933..0000000
--- a/conf/machine/acrn.conf
+++ /dev/null
@@ -1,9 +0,0 @@
-#@TYPE: Machine
-#@NAME: acrn
-#@DESCRIPTION: Machine for Zephyr BOARD acrn
-
-require conf/machine/include/qemu.inc
-require conf/machine/include/tune-corei7-common.inc
-ZEPHYR_INHERIT_CLASSES += "zephyr-qemuboot"
-
-ARCH_acrn = "x86"
--
2.17.1

User need to specify board value to ZEPHYR_BOARD in local.conf
ZEPHYR_BOARD = "minnowboard"

By default it set to MinnowBoard Max 'minnowboard'

Currently 32-bit supported boards:
* up_squared_32
* minnowboard

Ref:
https://docs.zephyrproject.org/latest/boards/x86/index.html

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
conf/machine/include/tune-core2-common.inc | 6 ++++++
conf/machine/intel-x86-32.conf | 12 ++++++++++++
2 files changed, 18 insertions(+)
create mode 100644 conf/machine/include/tune-core2-common.inc
create mode 100644 conf/machine/intel-x86-32.conf

diff --git a/conf/machine/include/tune-core2-common.inc b/conf/machine/include/tune-core2-common.inc
new file mode 100644
index 0000000..012f078
--- /dev/null
+++ b/conf/machine/include/tune-core2-common.inc
@@ -0,0 +1,6 @@
+DEFAULTTUNE ?= "core2-32"
+require conf/machine/include/tune-core2.inc
+require conf/machine/include/x86-base.inc
+
+# Add x86 to MACHINEOVERRIDES
+MACHINEOVERRIDES =. "x86:"
diff --git a/conf/machine/intel-x86-32.conf b/conf/machine/intel-x86-32.conf
new file mode 100644
index 0000000..06f6da5
--- /dev/null
+++ b/conf/machine/intel-x86-32.conf
@@ -0,0 +1,12 @@
+#@TYPE: Machine
+#@NAME: intel-x86-32
+#@DESCRIPTION: common MACHINE for 32-bit x86 boards. User must set ${ZEPHYR_BOARD}. By default is set to 'minnowboard' board.
+
+require conf/machine/include/tune-core2-common.inc
+
+ARCH_intel-x86-32 = "x86"
+
+# Supported Boards:
+# ZEPHYR_BOARD ?= "minnowboard"
+# ZEPHYR_BOARD ?= "up_squared_32"
+ZEPHYR_BOARD ?= "minnowboard"
--
2.17.1

User need to specify board value to ZEPHYR_BOARD in local.conf
ZEPHYR_BOARD = "ehl_crb"

By default it set to Elkhart Lake CRB 'ehl_crb'

Currently 64-bit supported boards:
* up_squared
* ehl_crb_sbl
* ehl_crb
* acrn
* acrn_ehl_crb

Ref:
https://docs.zephyrproject.org/latest/boards/x86/index.html

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
conf/machine/include/tune-corei7-common.inc | 3 +++
conf/machine/intel-x86-64.conf | 14 ++++++++++++++
2 files changed, 17 insertions(+)
create mode 100644 conf/machine/intel-x86-64.conf

diff --git a/conf/machine/include/tune-corei7-common.inc b/conf/machine/include/tune-corei7-common.inc
index 7ad9516..509d190 100644
--- a/conf/machine/include/tune-corei7-common.inc
+++ b/conf/machine/include/tune-corei7-common.inc
@@ -1,3 +1,6 @@
DEFAULTTUNE ?= "corei7-64"
require conf/machine/include/tune-corei7.inc
require conf/machine/include/x86-base.inc
+
+# Add x86 to MACHINEOVERRIDE
+MACHINEOVERRIDES =. "x86:"
diff --git a/conf/machine/intel-x86-64.conf b/conf/machine/intel-x86-64.conf
new file mode 100644
index 0000000..2935cff
--- /dev/null
+++ b/conf/machine/intel-x86-64.conf
@@ -0,0 +1,14 @@
+#@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.
+
+require conf/machine/include/tune-corei7-common.inc
+
+ARCH_intel-x86-64 = "x86"
+
+# Supported Boards:
+# ZEPHYR_BOARD ?= "acrn"
+# ZEPHYR_BOARD ?= "acrn_ehl_crb"
+# ZEPHYR_BOARD ?= "up_squared"
+# ZEPHYR_BOARD ?= "ehl_crb_sbl"
+ZEPHYR_BOARD ?= "ehl_crb"
--
2.17.1

With zephyr v2.5.0, EFI binary support has been added for x86 board (64-bit mode).

To achieve this, an python tool[1] has been added to convert zephyr ELF file
into an EFI appliable. But currently this does not work with Yocto
cross-compilation env.
This patch fix this issue and allow to build zephyr.efi

Ref:
[1]https://github.com/zephyrproject-rtos/zephyr/commit/928d31125f0b4eb28fe1cf3f3ad02b0ae071d7fd

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
...ry-generation-issue-in-cross-compila.patch | 80 +++++++++++++++++++
.../zephyr-kernel/zephyr-kernel-src-2.5.0.inc | 3 +
.../zephyr-kernel/zephyr-kernel-src.inc | 8 +-
3 files changed, 87 insertions(+), 4 deletions(-)
create mode 100644 recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch

diff --git a/recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch b/recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch
new file mode 100644
index 0000000..fd6fc6b
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch
@@ -0,0 +1,80 @@
+From cfde3b1018c3151b6cc1fbe3e9e163d0aaf16954 Mon Sep 17 00:00:00 2001
+From: Naveen Saini <naveen.kumar.saini@intel.com>
+Date: Tue, 11 May 2021 13:46:39 +0800
+Subject: [PATCH] x86: fix efi binary generation issue in cross compilation env
+
+Set root directory for headers.
+
+Upstream-Status: Inappropriate [Cross-compilation specific]
+
+Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
+---
+ arch/x86/zefi/zefi.py | 6 +++++-
+ boards/x86/ehl_crb/CMakeLists.txt | 1 +
+ boards/x86/qemu_x86/CMakeLists.txt | 1 +
+ boards/x86/up_squared/CMakeLists.txt | 1 +
+ 4 files changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/arch/x86/zefi/zefi.py b/arch/x86/zefi/zefi.py
+index d3514391a8..b9eccbfa10 100755
+--- a/arch/x86/zefi/zefi.py
++++ b/arch/x86/zefi/zefi.py
+@@ -106,7 +106,10 @@ def build_elf(elf_file):
+ # + We need pic to enforce that the linker adds no relocations
+ # + UEFI can take interrupts on our stack, so no red zone
+ # + UEFI API assumes 16-bit wchar_t
+- cmd = [args.compiler, "-shared", "-Wall", "-Werror", "-I.",
++
++ # Pass --sysroot path for cross compilation
++ sysrootarg = "--sysroot=" + args.sysroot
++ cmd = [args.compiler, "-shared", "-Wall", "-Werror", "-I.", sysrootarg,
+ "-fno-stack-protector", "-fpic", "-mno-red-zone", "-fshort-wchar",
+ "-Wl,-nostdlib", "-T", ldscript, "-o", "zefi.elf", cfile]
+ verbose(" ".join(cmd))
+@@ -145,6 +148,7 @@ def parse_args():
+ parser.add_argument("-o", "--objcopy", required=True, help="objcopy to be used")
+ parser.add_argument("-f", "--elf-file", required=True, help="Input file")
+ parser.add_argument("-v", "--verbose", action="store_true", help="Verbose output")
++ parser.add_argument("-s", "--sysroot", required=True, help="Cross compilation --sysroot=path")
+
+ return parser.parse_args()
+
+diff --git a/boards/x86/ehl_crb/CMakeLists.txt b/boards/x86/ehl_crb/CMakeLists.txt
+index 0d572eff30..6a228107dc 100644
+--- a/boards/x86/ehl_crb/CMakeLists.txt
++++ b/boards/x86/ehl_crb/CMakeLists.txt
+@@ -5,6 +5,7 @@ set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
+ -c ${CMAKE_C_COMPILER}
+ -o ${CMAKE_OBJCOPY}
+ -f ${PROJECT_BINARY_DIR}/${CONFIG_KERNEL_BIN_NAME}.elf
++ -s ${SYSROOT_DIR}
+ $<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
+ WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
+ )
+diff --git a/boards/x86/qemu_x86/CMakeLists.txt b/boards/x86/qemu_x86/CMakeLists.txt
+index 1131a5c7ce..489f17192b 100644
+--- a/boards/x86/qemu_x86/CMakeLists.txt
++++ b/boards/x86/qemu_x86/CMakeLists.txt
+@@ -4,6 +4,7 @@ set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
+ -c ${CMAKE_C_COMPILER}
+ -o ${CMAKE_OBJCOPY}
+ -f ${PROJECT_BINARY_DIR}/${CONFIG_KERNEL_BIN_NAME}.elf
++ -s ${SYSROOT_DIR}
+ $<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
+ WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
+ )
+diff --git a/boards/x86/up_squared/CMakeLists.txt b/boards/x86/up_squared/CMakeLists.txt
+index 0eaa9753fc..2e8ce7cfbc 100644
+--- a/boards/x86/up_squared/CMakeLists.txt
++++ b/boards/x86/up_squared/CMakeLists.txt
+@@ -5,6 +5,7 @@ set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
+ -c ${CMAKE_C_COMPILER}
+ -o ${CMAKE_OBJCOPY}
+ -f ${PROJECT_BINARY_DIR}/${CONFIG_KERNEL_BIN_NAME}.elf
++ -s ${SYSROOT_DIR}
+ $<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
+ WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
+ )
+--
+2.17.1
+
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
index 6350d86..5d66f0f 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
@@ -8,3 +8,6 @@ SRCREV_libmetal = "9d4ee2c3cfd5f49861939447990f3b7d7bf9bf94"
SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"

PV = "2.5.0+git${SRCPV}"
+
+SRC_URI_append = " file://0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch \
+ "
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
index 5ee40d4..b3b9565 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -1,10 +1,6 @@
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"

-# Default to a stable version
-PREFERRED_VERSION_zephyr-kernel ??= "2.5.0"
-include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc
-
inherit cmake

# This file might be included from other places (like other layers) and not
@@ -23,3 +19,7 @@ SRC_URI = "\
file://0001-cmake-add-yocto-toolchain.patch \
"
S = "${WORKDIR}/git"
+
+# Default to a stable version
+PREFERRED_VERSION_zephyr-kernel ??= "2.5.0"
+include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc
--
2.17.1

(1) zephyr-kernel-src: fix efi generation failure for x86 boards

With zephyr v2.5.0, EFI binary generation support has been added for x86 board (64-bit mode).
To achieve this, an python tool[1] has been added to convert zephyr EFL file
into an EFI appliable. But unfortunately at current this does not work with Yocto cross-compilation env.
This patch fix this issue and allow to build zephyr.efi for ehl_crb and up_squared boards.


(2)
Instead of creating machine configuration for each
supported boards, I would like to have common machine configurations for
supported boards. One for 64-bit (intel-x86-64.conf) and one for 32-bit
(intel-x86-32.conf).

User need to specify board value to ZEPHYR_BOARD in local.conf based on
targeted board i.e
ZEPHYR_BOARD = "ehl_crb"

64-bit supported boards:
* up_squared
* ehl_crb_sbl
* ehl_crb (default)
* acrn
* acrn_ehl_crb

32-bit supported boards:
* up_squared_32
* minnowboard (default)

(3) Dropped acrn MACHINE configuration, which can be build with
MACHINE = "intel-x86-64"
ZEPHYR_BOARD = "acrn"

---
v2:
Fixed build for Zephyr 2.4.0
Dropped ACRN configuration

Naveen Saini (4):
zephyr-kernel-src: fix efi generation failure for x86 boards
intel-x86-64.conf: add common MACHINE for x86 (64-bit) BOARDS
intel-x86-32.conf: add common MACHINE for x86 (32-bit) BOARDS
acrn.conf: drop acrn machine configuration

conf/machine/acrn.conf | 9 ---
conf/machine/include/tune-core2-common.inc | 6 ++
conf/machine/include/tune-corei7-common.inc | 3 +
conf/machine/intel-x86-32.conf | 12 +++
conf/machine/intel-x86-64.conf | 14 ++++
...ry-generation-issue-in-cross-compila.patch | 80 +++++++++++++++++++
.../zephyr-kernel/zephyr-kernel-src-2.5.0.inc | 3 +
.../zephyr-kernel/zephyr-kernel-src.inc | 8 +-
8 files changed, 122 insertions(+), 13 deletions(-)
delete mode 100644 conf/machine/acrn.conf
create mode 100644 conf/machine/include/tune-core2-common.inc
create mode 100644 conf/machine/intel-x86-32.conf
create mode 100644 conf/machine/intel-x86-64.conf
create mode 100644 recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch

--
2.17.1

On 5/20/21 4:32 AM, Nicolas Dechesne wrote:

On Thu, May 20, 2021 at 10:16 AM Quentin Schulz <
quentin.schulz@streamunlimited.com> wrote:

Hi Khem, all,

On Wed, May 19, 2021 at 10:09:12AM -0700, Khem Raj wrote:

On Wed, May 19, 2021 at 9:56 AM Nicolas Dechesne
<nicolas.dechesne@linaro.org> wrote:

On Wed, May 19, 2021 at 6:49 PM Jasper Orschulko <

Jasper.Orschulko@iris-sensing.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear all,

there have been recent reports of a hostile takeover of the freenode
service, as described in
https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409

The Yocto Project should verify these reports and take the necessary
actions, in order to protect its users.

Thanks for your email. We are aware, and have started to look into

that.

It looks like some open source communities have started to move to

https://www.oftc.net/ or https://libera.chat/.. If anyone wants to bring
any insights or recommendations... feel free!

perhaps good time to consider matrix

I disagree. Matrix just does not work. I've been using with a few
friends with mixed homeservers, chat.privacytools.io, matrix.org,
converser.eu and self-hosted homeservers... I've sometimes not received
tens of messages in a row, usually for a duration of at least 15 mins
and there's obviously no indication whatsoever that I didn't receive
messages except that the discussion does not make sense at all. And this
happened to three other people on the room, each on a different homeserver
than the other, so not a PEBKAC :) Sometimes there are delays for
messages too (I've seen 30min delays), so the whole context is lost.

For a federated chat solution, that's really a bummer that its main
feature is just so buggy it's unusable.

If YP is ok with potentially not receiving questions or having people
ask questions and not receive answers, then fine by me :)

I'm probably among the small (?) minority of people experiencing those
issues but that's not a bet I'd take with my projects.

My 2¢.

I think the question of setting up Matrix for our community is a valid
question, though I think it's orthogonal to the current problem. If
freenode goes away , we need an alternate plan to move *right away* to
another IRC server. If we want to setup addition communications means (such
as Matrix or anything else) that needs to be discussed and it might take
more time.

We have registered #oe and #yocto on libera already, so we can easily
transition irc servers as the situation develops.

Philip

Cheers,
Quentin

On Thu, May 20, 2021 at 10:16 AM Quentin Schulz <quentin.schulz@...> wrote:

Hi Khem, all,

On Wed, May 19, 2021 at 10:09:12AM -0700, Khem Raj wrote:
> On Wed, May 19, 2021 at 9:56 AM Nicolas Dechesne
> <nicolas.dechesne@...> wrote:
> >
> >
> >
> > On Wed, May 19, 2021 at 6:49 PM Jasper Orschulko <Jasper.Orschulko@...> wrote:
> >>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA256
> >>
> >> Dear all,
> >>
> >> there have been recent reports of a hostile takeover of the freenode
> >> service, as described in
> >> https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409
> >>
> >> The Yocto Project should verify these reports and take the necessary
> >> actions, in order to protect its users.
> >
> >
> > Thanks for your email. We are aware, and have started to look into that.
> >
> > It looks like some open source communities have started to move to https://www.oftc.net/ or https://libera.chat/.. If anyone wants to bring any insights or recommendations... feel free!
>
> perhaps good time to consider matrix
>

I disagree. Matrix just does not work. I've been using with a few
friends with mixed homeservers, chat.privacytools.io, matrix.org,
converser.eu and self-hosted homeservers... I've sometimes not received
tens of messages in a row, usually for a duration of at least 15 mins
and there's obviously no indication whatsoever that I didn't receive
messages except that the discussion does not make sense at all. And this
happened to three other people on the room, each on a different homeserver
than the other, so not a PEBKAC :) Sometimes there are delays for
messages too (I've seen 30min delays), so the whole context is lost.

For a federated chat solution, that's really a bummer that its main
feature is just so buggy it's unusable.

If YP is ok with potentially not receiving questions or having people
ask questions and not receive answers, then fine by me :)

I'm probably among the small (?) minority of people experiencing those
issues but that's not a bet I'd take with my projects.

My 2¢.

I think the question of setting up Matrix for our community is a valid question, though I think it's orthogonal to the current problem. If freenode goes away , we need an alternate plan to move *right away* to another IRC server. If we want to setup addition communications means (such as Matrix or anything else) that needs to be discussed and it might take more time.

First let me say, there is nothing wrong with matrix, have used it every day for years

Second

the discussion is now about libre

there's a relay to relay stuff between libera and freenode?!
magic
LiberaRelay (relay@2607:f5a0:0:7::9) has joined #hardenedbsd
[Libera] R​elay (relay@user/relay) has joined #hardenedbsd
xmj: sup ? Libra?? whats dat ?
new irc net, made by freenode staffers that have been booted
freenode went through a hostile takeover
... in case you haven't noticed ;p

https://kline.sh/

 

Cheers,
Quentin

Hello All,

This is the full report for yocto-3.3.1.rc1:
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,
Sangeeta

Hi Khem, all,

On Wed, May 19, 2021 at 10:09:12AM -0700, Khem Raj wrote:

On Wed, May 19, 2021 at 9:56 AM Nicolas Dechesne
<nicolas.dechesne@linaro.org> wrote:

On Wed, May 19, 2021 at 6:49 PM Jasper Orschulko <Jasper.Orschulko@iris-sensing.com> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear all,

there have been recent reports of a hostile takeover of the freenode
service, as described in
https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409

The Yocto Project should verify these reports and take the necessary
actions, in order to protect its users.

Thanks for your email. We are aware, and have started to look into that.

It looks like some open source communities have started to move to https://www.oftc.net/ or https://libera.chat/.. If anyone wants to bring any insights or recommendations... feel free!

perhaps good time to consider matrix

I disagree. Matrix just does not work. I've been using with a few
friends with mixed homeservers, chat.privacytools.io, matrix.org,
converser.eu and self-hosted homeservers... I've sometimes not received
tens of messages in a row, usually for a duration of at least 15 mins
and there's obviously no indication whatsoever that I didn't receive
messages except that the discussion does not make sense at all. And this
happened to three other people on the room, each on a different homeserver
than the other, so not a PEBKAC :) Sometimes there are delays for
messages too (I've seen 30min delays), so the whole context is lost.

For a federated chat solution, that's really a bummer that its main
feature is just so buggy it's unusable.

If YP is ok with potentially not receiving questions or having people
ask questions and not receive answers, then fine by me :)

I'm probably among the small (?) minority of people experiencing those
issues but that's not a bet I'd take with my projects.

My 2¢.

Cheers,
Quentin

Hi Jon,

From: Mingli Yu <mingli.yu@windriver.com>

Fixes:
| In function 'memset',
| inlined from 'test_table_stub' at test_table_tables.c:151:4:
| /buildarea/tmp/work/intel_x86_64-wrs-linux/dpdk/19.11.5-r0/recipe-sysroot/usr/include/bits/string_fortified.h:59:10: error: '__builtin_memset' offset [0, 31] is out of the bounds [0, 0] [-Werror=array-bounds]

Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
---
...001-test-table-fix-build-with-GCC-11.patch | 56 +++++++++++++++++++
recipes-extended/dpdk/dpdk_19.11.5.bb | 3 +-
2 files changed, 58 insertions(+), 1 deletion(-)
create mode 100644 recipes-extended/dpdk/dpdk/0001-test-table-fix-build-with-GCC-11.patch

diff --git a/recipes-extended/dpdk/dpdk/0001-test-table-fix-build-with-GCC-11.patch b/recipes-extended/dpdk/dpdk/0001-test-table-fix-build-with-GCC-11.patch
new file mode 100644
index 0000000..4f76290
--- /dev/null
+++ b/recipes-extended/dpdk/dpdk/0001-test-table-fix-build-with-GCC-11.patch
@@ -0,0 +1,56 @@
+From 33c12ac5ba5f09727c6de807e71403dd260a7bbc Mon Sep 17 00:00:00 2001
+From: Ferruh Yigit <ferruh.yigit@intel.com>
+Date: Mon, 17 May 2021 16:57:39 +0100
+Subject: [PATCH] test/table: fix build with GCC 11
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Build error:
+../app/test/test_table_tables.c: In function ‘test_table_stub’:
+../app/test/test_table_tables.c:31:9:
+ warning: ‘memset’ offset [0, 31] is out of the bounds [0, 0]
+ [-Warray-bounds]
+ memset((uint8_t *)mbuf + sizeof(struct rte_mbuf) + 32, 0, 32); \
+ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+../app/test/test_table_tables.c:151:25:
+ note: in expansion of macro ‘PREPARE_PACKET’
+ 151 | PREPARE_PACKET(mbufs[i], 0xadadadad);
+ | ^~~~~~~~~~~~~~
+
+'key' points to mbuf header + 32 bytes, and memset clears next 32 bytes
+of 'key', so overall there needs to be 64 bytes after mbuf header.
+Adding a mbuf size check before memset.
+
+The original code has an assumption that mbuf data buffer follows mbuf
+header, this patch accepts same assumption.
+
+Bugzilla ID: 677
+Fixes: 5205954791cb ("app/test: packet framework unit tests")
+Cc: stable@dpdk.org
+
+Upstream-Status: Backport [https://github.com/DPDK/dpdk/commit/33c12ac5ba5f09727c6de807e71403dd260a7bbc]
+
+Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
+Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
+---
+ app/test/test_table_tables.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/app/test/test_table_tables.c b/app/test/test_table_tables.c
+index 1aa269f95..4ff6ab16a 100644
+--- a/app/test/test_table_tables.c
++++ b/app/test/test_table_tables.c
+@@ -28,7 +28,8 @@ table_test table_tests[] = {
+ APP_METADATA_OFFSET(0)); \
+ key = RTE_MBUF_METADATA_UINT8_PTR(mbuf, \
+ APP_METADATA_OFFSET(32)); \
+- memset(key, 0, 32); \
++ if (mbuf->priv_size + mbuf->buf_len >= 64) \
++ memset(key, 0, 32); \
+ k32 = (uint32_t *) key; \
+ k32[0] = (value); \
+ *signature = pipeline_test_hash(key, NULL, 0, 0); \
+--
+2.17.1
+
diff --git a/recipes-extended/dpdk/dpdk_19.11.5.bb b/recipes-extended/dpdk/dpdk_19.11.5.bb
index 8410c8a..2ae9b43 100644
--- a/recipes-extended/dpdk/dpdk_19.11.5.bb
+++ b/recipes-extended/dpdk/dpdk_19.11.5.bb
@@ -4,7 +4,8 @@ SRC_URI += " \
file://dpdk-16.04-add-RTE_KERNELDIR_OUT-to-split-kernel-bu.patch \
file://dpdk-16.07-add-sysroot-option-within-app-makefile.patch \
file://0001-Starting-from-Linux-5.9-get_user_pages_remote-API-do.patch \
- file://usertools-devbind-fix-binding-for-built-in-kernel-dr.patch"
+ file://usertools-devbind-fix-binding-for-built-in-kernel-dr.patch \
+ file://0001-test-table-fix-build-with-GCC-11.patch"


STABLE = "-stable"
--
2.29.2