From: Bruce Ashfield <bruce.ashfield@...>

Integrating the following commit(s) to linux-yocto/5.15:

6c085baf1838 tools: use basename to identify file in gen-mach-types

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
.../recipes-kernel/linux/linux-yocto_5.15.bbappend | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend
index 11e78e2be2..8d2ec873fa 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend
@@ -7,10 +7,10 @@ KMACHINE:genericx86 ?= "common-pc"
KMACHINE:genericx86-64 ?= "common-pc-64"
KMACHINE:beaglebone-yocto ?= "beaglebone"

-SRCREV_machine:genericx86 ?= "2fca0fd719812ea2ff67630b01355aa80481623e"
-SRCREV_machine:genericx86-64 ?= "2fca0fd719812ea2ff67630b01355aa80481623e"
-SRCREV_machine:edgerouter ?= "26de0a7a59c56b63833a55dc33dbf70a7984d140"
-SRCREV_machine:beaglebone-yocto ?= "3ec00e9ee0e41e4c402396425337c42da58c4d6f"
+SRCREV_machine:genericx86 ?= "6c085baf183868ed45d8c1d44408d7b24724cde5"
+SRCREV_machine:genericx86-64 ?= "6c085baf183868ed45d8c1d44408d7b24724cde5"
+SRCREV_machine:edgerouter ?= "e90573857c176458965737d77b1747be83fe7edc"
+SRCREV_machine:beaglebone-yocto ?= "d91bb88e58c575e7c3b9fb111b6711a206eba64b"

COMPATIBLE_MACHINE:genericx86 = "genericx86"
COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
--
2.19.1

From: Bruce Ashfield <bruce.ashfield@...>

Integrating the following commit(s) to linux-yocto/5.10:

80f5207b5abd tools: use basename to identify file in gen-mach-types

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
.../recipes-kernel/linux/linux-yocto_5.10.bbappend | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
index 975d6c6565..bfb36e173a 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
@@ -7,10 +7,10 @@ KMACHINE:genericx86 ?= "common-pc"
KMACHINE:genericx86-64 ?= "common-pc-64"
KMACHINE:beaglebone-yocto ?= "beaglebone"

-SRCREV_machine:genericx86 ?= "4d201ec392f149ecce321186ea5494a6e25e28f4"
-SRCREV_machine:genericx86-64 ?= "4d201ec392f149ecce321186ea5494a6e25e28f4"
-SRCREV_machine:edgerouter ?= "58eb61187e8c78dc0241b2b85cb7d2c958f0e1fd"
-SRCREV_machine:beaglebone-yocto ?= "aab4d3436476d643c68ac2efccb887a4386a35bb"
+SRCREV_machine:genericx86 ?= "80f5207b5abddf0dae8eeaa5e3bcfe0e23538e62"
+SRCREV_machine:genericx86-64 ?= "80f5207b5abddf0dae8eeaa5e3bcfe0e23538e62"
+SRCREV_machine:edgerouter ?= "43a7a15cfe433584b6065c2492b2a7f9be7954c5"
+SRCREV_machine:beaglebone-yocto ?= "3651cd48f159c3b2a3a60d645baccc9d34baed54"

COMPATIBLE_MACHINE:genericx86 = "genericx86"
COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
--
2.19.1

From: Bruce Ashfield <bruce.ashfield@...>

Integrating the following commit(s) to linux-yocto/5.15:

6c085baf1838 tools: use basename to identify file in gen-mach-types

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
.../linux/linux-yocto-rt_5.15.bb | 2 +-
.../linux/linux-yocto-tiny_5.15.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto_5.15.bb | 20 +++++++++----------
3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
index 61b1df04a9..f1f5de3b18 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
@@ -11,7 +11,7 @@ python () {
raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it")
}

-SRCREV_machine ?= "4132e425a2dee778212b42d99a9812fe1c78a03d"
+SRCREV_machine ?= "3a7da2af1ba40b8c2247bac03a1fae488a1abde2"
SRCREV_meta ?= "f122fe59e74365eba84bae800898ffd7329c628d"

SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
index 7c81b048dc..e271c6741a 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
@@ -14,7 +14,7 @@ DEPENDS += "openssl-native util-linux-native"
KMETA = "kernel-meta"
KCONF_BSP_AUDIT_LEVEL = "2"

-SRCREV_machine ?= "b2dcc4f70362059ef107000f9be5c76c2886911c"
+SRCREV_machine ?= "122de5742628e6b4303f0bbc653d409ff9f93557"
SRCREV_meta ?= "f122fe59e74365eba84bae800898ffd7329c628d"

PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.15.bb b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
index 3e22f8d570..1c090db7b8 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
@@ -13,16 +13,16 @@ KBRANCH:qemux86 ?= "v5.15/standard/base"
KBRANCH:qemux86-64 ?= "v5.15/standard/base"
KBRANCH:qemumips64 ?= "v5.15/standard/mti-malta64"

-SRCREV_machine:qemuarm ?= "3d2ffe77f277a0a650e7d012c5bfe3765a467e4b"
-SRCREV_machine:qemuarm64 ?= "1da6524b1508ca6e9b6602471b478d310bec1960"
-SRCREV_machine:qemumips ?= "4101fd448319edc00fec2bd822be407d19205bb9"
-SRCREV_machine:qemuppc ?= "651a0112fb207bae1be0d2609e9a910135fb4feb"
-SRCREV_machine:qemuriscv64 ?= "2fca0fd719812ea2ff67630b01355aa80481623e"
-SRCREV_machine:qemuriscv32 ?= "2fca0fd719812ea2ff67630b01355aa80481623e"
-SRCREV_machine:qemux86 ?= "2fca0fd719812ea2ff67630b01355aa80481623e"
-SRCREV_machine:qemux86-64 ?= "2fca0fd719812ea2ff67630b01355aa80481623e"
-SRCREV_machine:qemumips64 ?= "d518b9a80c938ca7ce11e56d2275c33b89dfc9c3"
-SRCREV_machine ?= "2fca0fd719812ea2ff67630b01355aa80481623e"
+SRCREV_machine:qemuarm ?= "41652fad285637467681f47d4e94a886ffb473cd"
+SRCREV_machine:qemuarm64 ?= "b28bd930f849c23a8f1576b22a8e59a0b2ac8cc1"
+SRCREV_machine:qemumips ?= "fb51b7d8d905883f2595f006428c142975231886"
+SRCREV_machine:qemuppc ?= "731587ce51ec087bfbb6255a1e9c763b4f71f7cb"
+SRCREV_machine:qemuriscv64 ?= "6c085baf183868ed45d8c1d44408d7b24724cde5"
+SRCREV_machine:qemuriscv32 ?= "6c085baf183868ed45d8c1d44408d7b24724cde5"
+SRCREV_machine:qemux86 ?= "6c085baf183868ed45d8c1d44408d7b24724cde5"
+SRCREV_machine:qemux86-64 ?= "6c085baf183868ed45d8c1d44408d7b24724cde5"
+SRCREV_machine:qemumips64 ?= "5fcf0d1536623c9ede2ee54d143a650c59ca9d59"
+SRCREV_machine ?= "6c085baf183868ed45d8c1d44408d7b24724cde5"
SRCREV_meta ?= "f122fe59e74365eba84bae800898ffd7329c628d"

# set your preferred provider of linux-yocto to 'linux-yocto-upstream', and you'll
--
2.19.1

From: Bruce Ashfield <bruce.ashfield@...>

Integrating the following commit(s) to linux-yocto/5.10:

80f5207b5abd tools: use basename to identify file in gen-mach-types

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
.../linux/linux-yocto-rt_5.10.bb | 2 +-
.../linux/linux-yocto-tiny_5.10.bb | 4 ++--
meta/recipes-kernel/linux/linux-yocto_5.10.bb | 20 +++++++++----------
3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb b/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
index a695740976..c705b7c07a 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
@@ -11,7 +11,7 @@ python () {
raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it")
}

-SRCREV_machine ?= "f481ff6adf4be55c3ab89d0cf7243bbca69205c9"
+SRCREV_machine ?= "2f72685aa16ee5e1c8c53df03457b223a6996540"
SRCREV_meta ?= "2f79722c50ad61cf055b40e8ba6d6f48e8dc6db0"

SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
index 41cad3d37e..6336ef544f 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
@@ -15,8 +15,8 @@ DEPENDS += "openssl-native util-linux-native"
KMETA = "kernel-meta"
KCONF_BSP_AUDIT_LEVEL = "2"

-SRCREV_machine:qemuarm ?= "cab1bb0e702f93b16762fc560d6be582fbf86a6a"
-SRCREV_machine ?= "5239dc7bbd53a3d4d5e31f8631612c2eb6cee0b8"
+SRCREV_machine:qemuarm ?= "3b951d9995d83be4e2985d6aa904d59cb9ac7692"
+SRCREV_machine ?= "f2b78db2b548501a7b0b17f76b9ee2f09978fb30"
SRCREV_meta ?= "2f79722c50ad61cf055b40e8ba6d6f48e8dc6db0"

PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.10.bb b/meta/recipes-kernel/linux/linux-yocto_5.10.bb
index fbee1874f4..96c77e6a87 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.10.bb
@@ -13,16 +13,16 @@ KBRANCH:qemux86 ?= "v5.10/standard/base"
KBRANCH:qemux86-64 ?= "v5.10/standard/base"
KBRANCH:qemumips64 ?= "v5.10/standard/mti-malta64"

-SRCREV_machine:qemuarm ?= "952586297dec710cba21ccf7f6fe4a1aadde0a5d"
-SRCREV_machine:qemuarm64 ?= "268aa738ea2454a1293dcb6c829c88552a5768d2"
-SRCREV_machine:qemumips ?= "bb9cabbe92165b556329cb0eed12ab67d2dee7a7"
-SRCREV_machine:qemuppc ?= "88ee9e4c24d32b6d0ec90756f0c7729954d3feae"
-SRCREV_machine:qemuriscv64 ?= "4d201ec392f149ecce321186ea5494a6e25e28f4"
-SRCREV_machine:qemuriscv32 ?= "4d201ec392f149ecce321186ea5494a6e25e28f4"
-SRCREV_machine:qemux86 ?= "4d201ec392f149ecce321186ea5494a6e25e28f4"
-SRCREV_machine:qemux86-64 ?= "4d201ec392f149ecce321186ea5494a6e25e28f4"
-SRCREV_machine:qemumips64 ?= "1a760ff71146a87cb5b7de87aed88db07a907ef1"
-SRCREV_machine ?= "4d201ec392f149ecce321186ea5494a6e25e28f4"
+SRCREV_machine:qemuarm ?= "8b54878acc1161bdcfa3a1153cb2fff39c675b89"
+SRCREV_machine:qemuarm64 ?= "2db48159f4444dcfa0c0dab5804769ea528bb6ed"
+SRCREV_machine:qemumips ?= "fc5fb9c35b8c52a3b1b2348a56237b6f1bb7fc6b"
+SRCREV_machine:qemuppc ?= "736b1667a61f21d7a1b8c88e8cedb648e79e687b"
+SRCREV_machine:qemuriscv64 ?= "80f5207b5abddf0dae8eeaa5e3bcfe0e23538e62"
+SRCREV_machine:qemuriscv32 ?= "80f5207b5abddf0dae8eeaa5e3bcfe0e23538e62"
+SRCREV_machine:qemux86 ?= "80f5207b5abddf0dae8eeaa5e3bcfe0e23538e62"
+SRCREV_machine:qemux86-64 ?= "80f5207b5abddf0dae8eeaa5e3bcfe0e23538e62"
+SRCREV_machine:qemumips64 ?= "2105a97021e3d0c565d84947e5cd45dd77be07e3"
+SRCREV_machine ?= "80f5207b5abddf0dae8eeaa5e3bcfe0e23538e62"
SRCREV_meta ?= "2f79722c50ad61cf055b40e8ba6d6f48e8dc6db0"

SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRANCH}; \
--
2.19.1

From: Bruce Ashfield <bruce.ashfield@...>

Richard,

The gen-mach-types patches are repeats of ones I sent before, but I've
included them to make the ordering clear.

After that, we have two -stable updates (getting ready for the "big"
CVE updates)

And then the pnmtologo fixes. That should be all the builpaths warnings.

I'm sending this all to oe-core fo simplicty sake, but obviously the
yocto-bsp ones are for the yocto layers.

Brue

The following changes since commit e65ee81d621e679107b5f4ef2dbbb8d1786e93ad:

ltp: fix builds when host ld doesn't know about target ELF formats (2022-07-14 10:08:57 +0100)

are available in the Git repository at:

git://git.yoctoproject.org/poky-contrib zedd/kernel
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Bruce Ashfield (10):
linux-yocto/5.10: fix buildpaths issue with gen-mach-types
linux-yocto/5.15: fix buildpaths issue with gen-mach-types
yocto-bsps/5.10: fix buildpaths issue with gen-mach-types
yocto-bsps/5.15: fix buildpaths issue with gen-mach-types
linux-yocto/5.15: update to v5.15.54
linux-yocto/5.10: update to v5.10.130
linux-yocto/5.15: fix buildpaths issue with pnmtologo
linux-yocto/5.10: fix buildpaths issue with pnmtologo
yocto-bsps/5.10: fix buildpaths issue with pnmtologo
yocto-bsps/5.15: fix buildpaths issue with pnmtologo

.../linux/linux-yocto_5.10.bbappend | 8 +++---
.../linux/linux-yocto_5.15.bbappend | 8 +++---
.../linux/linux-yocto-rt_5.10.bb | 6 ++---
.../linux/linux-yocto-rt_5.15.bb | 6 ++---
.../linux/linux-yocto-tiny_5.10.bb | 8 +++---
.../linux/linux-yocto-tiny_5.15.bb | 6 ++---
meta/recipes-kernel/linux/linux-yocto_5.10.bb | 24 ++++++++---------
meta/recipes-kernel/linux/linux-yocto_5.15.bb | 26 +++++++++----------
8 files changed, 46 insertions(+), 46 deletions(-)

--
2.19.1

On Wed, 2022-07-13 at 14:36 -0400, Bruce Ashfield wrote:

On Tue, Jul 12, 2022 at 11:19 PM Bruce Ashfield via
lists.yoctoproject.org
<bruce.ashfield=gmail.com@...> wrote:

On Tue, Jul 12, 2022 at 6:45 PM Richard Purdie
<richard.purdie@...> wrote:

On Tue, 2022-07-12 at 10:40 -0400, bruce.ashfield@... wrote:

From: Bruce Ashfield <bruce.ashfield@...>

Updating linux-yocto/5.15 to the latest korg -stable release that comprises
the following commits:

Thanks, this test build showed two warnings. I have no idea why this
only showed up now:

beaglebone:
WARNING: linux-yocto-5.15.52+gitAUTOINC+f122fe59e7_3ec00e9ee0-r0 do_package_qa: QA Issue: File /usr/src/debug/linux-yocto/5.15.52+gitAUTOINC+f122fe59e7_3ec00e9ee0-r0/linux-beaglebone_yocto-standard-build/arch/arm/include/generated/asm/mach-types.h in package linux-yocto-src contains reference to TMPDIR

beaglebond-alt:
WARNING: linux-yocto-5.10.128+gitAUTOINC+2f79722c50_aab4d34364-r0 do_package_qa: QA Issue: File /usr/src/debug/linux-yocto/5.10.128+gitAUTOINC+2f79722c50_aab4d34364-r0/linux-beaglebone_yocto-standard-build/arch/arm/include/generated/asm/mach-types.h in package linux-yocto-src contains reference to TMPDIR

Yet another generation script referencing itself .. they seem to like
doing that.

I don't get the warning, but I do have the file with the reference in
it here, so I'll send a SRCREV bump with a fix Wednesday.

As you can see, patches are on the list. This one was an awk fix.

So now we have: shell, python, perl and awk to fix the full path
issues ... what's the next scripting language to hack ?

Thanks!

I did work out why this has seemed like a game of whack-a-mole. When
the AB summarises warnings, it prints the first line. The actual log
has more lines to it which I wasn't seeing until I looked at the full
log. In the case of beaglebone, this now says:

WARNING: linux-yocto-5.15.52+gitAUTOINC+f122fe59e7_d91bb88e58-r0 do_package_qa: QA Issue: File /usr/src/debug/linux-yocto/5.15.52+gitAUTOINC+f122fe59e7_d91bb88e58-r0/linux-beaglebone_yocto-standard-build/drivers/video/logo/logo_linux_clut224.c in package linux-yocto-src contains reference to TMPDIR
File /usr/src/debug/linux-yocto/5.15.52+gitAUTOINC+f122fe59e7_d91bb88e58-r0/linux-beaglebone_yocto-standard-build/drivers/video/logo/logo_linux_mono.c in package linux-yocto-src contains reference to TMPDIR
File /usr/src/debug/linux-yocto/5.15.52+gitAUTOINC+f122fe59e7_d91bb88e58-r0/linux-beaglebone_yocto-standard-build/drivers/video/logo/logo_linux_vga16.c in package linux-yocto-src contains reference to TMPDIR [buildpaths]

so three left and they look related. Which language do you hope for
this time?! :)

[I really appreciate the help on this. I'm hoping we're close now]

Cheers,

Richard

Hi Senthamilarasi.M,

On 7/14/22 06:59, Senthamilarasi mathiyan wrote:

Hi Alexandre,
Good Morning!
I am not introducing any change to kernel.
This is one of my project requirement to enable coverage support to kernel
for specific build for my project.
In my project, Already we have few image recipes.
Ex: core_image_minimal.bb core_image_a.bb core_image_b.bb
These image recipes are using same kernel with same configuration, Apart
from default kernel configuration, I want to enable few driver support in
kernel to enable coverage support for specific requirement.
To enable coverage support in kernel, I have added coverage.cfg in
meta-layer.
Ex: /recipes-kernel/linux-msm/files/coverage.cfg
cat coverage.cfg
CONFIG_GCOV=y
CONFIG_DEBUG_FS=y
CONFIG_GCOV_KERNEL=y
If I add coverage.cfg in my kernel recipe(snippet below) - It will be taken
for all the image build. Whenever do bitbake of following recipe -
core_image_minimal.bb, core_image_a.bb, core_image_b.bb
The below changes will be added to the build, since this kernel is common
for all the image recipes(core_image_minimal.bb core_image_a.bb
core_image_b.bb).
Recipe content:
+++ b/recipes-kernel/linux-kernel/linux-kernel_5.x.bb
@@ -21,6 +21,7 @@ SRC_URI = "\
file://audio-kpi.cfg \
file://ptp-virtual.cfg \
file://xfs.cfg \
+ file://coverage.cfg \
${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '
file://systemd.cfg', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'virtualization', '
file://virtualization.cfg', '', d)} \
Similarly, I have patch for file other recipes.
In my case, I should not add this change to all the image build.
My requirement:
I want to create separate image recipe. Ex: core_image_myrecipe.bb
In this recipes
- I should include "inherit core-image-minimal" + "My specific
coverage_support changes".
As per project requirement, I should not create a separate meta layer to
maintain this patches.
Can you please help for creating a separate image recipe with specific
changes?

It is not possible to modify a recipe from another recipe. Meaning you cannot decide which config file to use for the kernel from the image recipe.

You have however two options:
- only include this configuration file for a given machine (you therefore need a new machine). This makes sense if the actual target HW is different,
- only include this configuration file for a given distro (you therefore need a new distro file). This makes sense if the actual target HW is the same for all configuration file of your kernel, just that they differ in terms of "policy".

If you're trying to build "a debug image", it is most likely a new distro you're after.

However, there could be a way to still do this with images and that is with the use of kernel modules. The plan would be to *always* build GCOV, DEBUG_FS and GCOV_KERNEL as modules (if even possible?). Yocto actually splits kernel modules in their own packages. Therefore, you could have the default configuration for your kernel used in all images, but have your special coverage image include also kernel-module-gcov/debug-fs/gcov-kernel/etc.. packages and modprobe/insmod them at boot when needed.

Cheers,
Quentin

Signed-off-by: Alex Kiernan <alex.kiernan@...>
---
.../bubblewrap/bubblewrap_0.6.2.bb | 23 +++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 recipes-security/bubblewrap/bubblewrap_0.6.2.bb

diff --git a/recipes-security/bubblewrap/bubblewrap_0.6.2.bb b/recipes-security/bubblewrap/bubblewrap_0.6.2.bb
new file mode 100644
index 000000000000..921defda9e9d
--- /dev/null
+++ b/recipes-security/bubblewrap/bubblewrap_0.6.2.bb
@@ -0,0 +1,23 @@
+DESCRIPTION = "Unprivileged sandboxing tool"
+HOMEPAGE = "https://github.com/containers/bubblewrap"
+LICENSE = "LGPL-2.0-or-later"
+LIC_FILES_CHKSUM = "file://COPYING;md5=5f30f0716dfdd0d91eb439ebec522ec2"
+
+DEPENDS = "libcap"
+
+SRC_URI = "https://github.com/containers/${BPN}/releases/download/v${PV}/${BP}.tar.xz"
+SRC_URI[sha256sum] = "8a0ec802d1b3e956c5bb0a40a81c9ce0b055a31bf30a8efa547433603b8af20b"
+
+UPSTREAM_CHECK_URI = "https://github.com/containers/bubblewrap/releases"
+UPSTREAM_CHECK_REGEX = "bubblewrap-(?P<pver>\d+(\.\d+)+)\.tar"
+
+inherit autotools bash-completion manpages pkgconfig
+
+PACKAGECONFIG ?= "${@bb.utils.filter('DISTRO_FEATURES', 'selinux', d)}"
+PACKAGECONFIG[manpages] = "--enable-man,--disable-man,libxslt-native docbook-xsl-stylesheets-native xmlto-native"
+PACKAGECONFIG[selinux] = "--enable-selinux,--disable-selinux,libselinux"
+PACKAGECONFIG[setuid] = "--with-priv-mode=setuid,--with-priv-mode=none"
+
+PACKAGES += "${PN}-zsh-completion"
+
+FILES:${PN}-zsh-completion = "${datadir}/zsh/site-functions"
--
2.35.1

On Tue, Jul 12, 2022 at 11:19 PM Bruce Ashfield via
lists.yoctoproject.org
<bruce.ashfield=gmail.com@...> wrote:

On Tue, Jul 12, 2022 at 6:45 PM Richard Purdie
<richard.purdie@...> wrote:

On Tue, 2022-07-12 at 10:40 -0400, bruce.ashfield@... wrote:

From: Bruce Ashfield <bruce.ashfield@...>

Updating linux-yocto/5.15 to the latest korg -stable release that comprises
the following commits:

Thanks, this test build showed two warnings. I have no idea why this
only showed up now:

beaglebone:
WARNING: linux-yocto-5.15.52+gitAUTOINC+f122fe59e7_3ec00e9ee0-r0 do_package_qa: QA Issue: File /usr/src/debug/linux-yocto/5.15.52+gitAUTOINC+f122fe59e7_3ec00e9ee0-r0/linux-beaglebone_yocto-standard-build/arch/arm/include/generated/asm/mach-types.h in package linux-yocto-src contains reference to TMPDIR

beaglebond-alt:
WARNING: linux-yocto-5.10.128+gitAUTOINC+2f79722c50_aab4d34364-r0 do_package_qa: QA Issue: File /usr/src/debug/linux-yocto/5.10.128+gitAUTOINC+2f79722c50_aab4d34364-r0/linux-beaglebone_yocto-standard-build/arch/arm/include/generated/asm/mach-types.h in package linux-yocto-src contains reference to TMPDIR

Yet another generation script referencing itself .. they seem to like
doing that.

I don't get the warning, but I do have the file with the reference in
it here, so I'll send a SRCREV bump with a fix Wednesday.

As you can see, patches are on the list. This one was an awk fix.

So now we have: shell, python, perl and awk to fix the full path
issues ... what's the next scripting language to hack ?

Bruce

Bruce

So at least it is down to one error in 5.10 and 5.15 for the same
platform!

I think we're mostly winning and nearly there :)

Cheers,

Richard

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

From: Bruce Ashfield <bruce.ashfield@...>

Integrating the following commit(s) to linux-yocto/5.15:

6c085baf1838 tools: use basename to identify file in gen-mach-types

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
.../recipes-kernel/linux/linux-yocto_5.15.bbappend | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend
index 11e78e2be2..8d2ec873fa 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.15.bbappend
@@ -7,10 +7,10 @@ KMACHINE:genericx86 ?= "common-pc"
KMACHINE:genericx86-64 ?= "common-pc-64"
KMACHINE:beaglebone-yocto ?= "beaglebone"

-SRCREV_machine:genericx86 ?= "2fca0fd719812ea2ff67630b01355aa80481623e"
-SRCREV_machine:genericx86-64 ?= "2fca0fd719812ea2ff67630b01355aa80481623e"
-SRCREV_machine:edgerouter ?= "26de0a7a59c56b63833a55dc33dbf70a7984d140"
-SRCREV_machine:beaglebone-yocto ?= "3ec00e9ee0e41e4c402396425337c42da58c4d6f"
+SRCREV_machine:genericx86 ?= "6c085baf183868ed45d8c1d44408d7b24724cde5"
+SRCREV_machine:genericx86-64 ?= "6c085baf183868ed45d8c1d44408d7b24724cde5"
+SRCREV_machine:edgerouter ?= "e90573857c176458965737d77b1747be83fe7edc"
+SRCREV_machine:beaglebone-yocto ?= "d91bb88e58c575e7c3b9fb111b6711a206eba64b"

COMPATIBLE_MACHINE:genericx86 = "genericx86"
COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
--
2.19.1

From: Bruce Ashfield <bruce.ashfield@...>

Integrating the following commit(s) to linux-yocto/5.10:

80f5207b5abd tools: use basename to identify file in gen-mach-types

Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
---
.../recipes-kernel/linux/linux-yocto_5.10.bbappend | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
index 975d6c6565..bfb36e173a 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_5.10.bbappend
@@ -7,10 +7,10 @@ KMACHINE:genericx86 ?= "common-pc"
KMACHINE:genericx86-64 ?= "common-pc-64"
KMACHINE:beaglebone-yocto ?= "beaglebone"

-SRCREV_machine:genericx86 ?= "4d201ec392f149ecce321186ea5494a6e25e28f4"
-SRCREV_machine:genericx86-64 ?= "4d201ec392f149ecce321186ea5494a6e25e28f4"
-SRCREV_machine:edgerouter ?= "58eb61187e8c78dc0241b2b85cb7d2c958f0e1fd"
-SRCREV_machine:beaglebone-yocto ?= "aab4d3436476d643c68ac2efccb887a4386a35bb"
+SRCREV_machine:genericx86 ?= "80f5207b5abddf0dae8eeaa5e3bcfe0e23538e62"
+SRCREV_machine:genericx86-64 ?= "80f5207b5abddf0dae8eeaa5e3bcfe0e23538e62"
+SRCREV_machine:edgerouter ?= "43a7a15cfe433584b6065c2492b2a7f9be7954c5"
+SRCREV_machine:beaglebone-yocto ?= "3651cd48f159c3b2a3a60d645baccc9d34baed54"

COMPATIBLE_MACHINE:genericx86 = "genericx86"
COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
--
2.19.1

On Wed, Jul 13, 2022 at 4:12 PM Ross Burton <ross.burton@...> wrote:

On 13 Jul 2022, at 14:40, simonblack.it via lists.yoctoproject.org <simonblack.it=yahoo.com@...> wrote:

Does yocto store all packages name that will be built from a recipe in a variable?

That *will* be built, no.

PACKAGES contains the packages which *can* be built, but also the do_package can create more. For example, it’s possible for a package which builds 20 plugins to dynamically create a package-per-plugin instead of the list being hardcoded.

If you want to know what packages a recipe created then you can use pkgdata. There is a tool to examine it:

$ oe-pkgdata-util list-pkgs —recipe glibc
glibc
glibc-dbg
glibc-dev
glibc-doc
glibc-extra-nss
glibc-pcprofile
glibc-src
glibc-staticdev
glibc-thread-db
glibc-utils
ldconfig
ldd
ldso
libmemusage
libnss-db
libsotruss
malloc-debug
nscd
sln
tzcode

this is nice. I mistook it for the dependencies

On 13 Jul 2022, at 14:40, simonblack.it via lists.yoctoproject.org <simonblack.it=yahoo.com@...> wrote:

Does yocto store all packages name that will be built from a recipe in a variable?

That *will* be built, no.

PACKAGES contains the packages which *can* be built, but also the do_package can create more. For example, it’s possible for a package which builds 20 plugins to dynamically create a package-per-plugin instead of the list being hardcoded.

If you want to know what packages a recipe created then you can use pkgdata. There is a tool to examine it:

$ oe-pkgdata-util list-pkgs —recipe glibc
glibc
glibc-dbg
glibc-dev
glibc-doc
glibc-extra-nss
glibc-pcprofile
glibc-src
glibc-staticdev
glibc-thread-db
glibc-utils
ldconfig
ldd
ldso
libmemusage
libnss-db
libsotruss
malloc-debug
nscd
sln
tzcode

Ross

Hi,

Does yocto store all packages name that will be built from a recipe in a variable?

BR,
Simon

Thanks Martin and Mike for your explanations and tips.

So, I've done a lot of testing today and it seems I simplified the
example in my first email a bit too much. The example as-is works fine
when switching DISTROs as far as I can tell. The problem only arises
when wildcards are used.

Changing my initial example like this should trigger the behaviour I've
initially described:

SRC_URI:append:mydistro-dev = " file://application-dbg.service"

do_install {
# ...snip...
# systemd service
install -d ${D}${systemd_system_unitdir}
install -m 0644 ${WORKDIR}/*.service ${D}${systemd_system_unitdir}
}

do_install:append:mydistro-dev() {
# debug systemd services
install -d ${D}${systemd_system_unitdir}
install -m 0644 ${WORKDIR}/application-dbg.service
${D}${systemd_system_unitdir}
}

Notice the *.service in do_install.

From my testing, this is how contamination happens:

1) Build with 'DISTRO=mydistro bitbake application'. All tasks for the
recipe are run and the directories in WORKDIR are populated, including
the "application.service" file.
2) Build with 'DISTRO=mydistro-dev bitbake application'. do_unpack is
rerun and places the additional "application-dbg.service" file in
WORKDIR.
3) Switching back to 'mydistro' will get the recipe from sstate cache,
which works fine.
4) Changing application.bb and rebuilding with 'DISTRO=mydistro bitbake
application' reruns do_install (as expected). This leads to the
packages do_install picking up the additional "application-dbg.service"
file left behind by the invocation in step 2).

Mike, Martin: Do you remember in which cases you encountered problems
when sharing the build directory?

On Tue, 2022-07-12 at 09:15 -0700, Khoi Dinh Trinh wrote:

Thank you Nicolas for asking this question since I will probably run
into this issue soon if not for this email thread. The answers so far
have been very helpful but I just want to clarify a bit more on why
doesn't the package get rebuilt? From my understanding, Yocto should
rerun a task when the signature of the task changes and since
do_install has an override on mydistro-dev, shouldn't the content and
thus the signature of do_install change when switching distro and so
Yocto should rerun it? 

As far as I can tell, all the relevant tasks are rerun correctly when
something is changed. Relevant tasks meaning only the tasks that are
actually different.

The specific issue I experienced is due to the WORKDIR not being
cleaned between different task invocations and the recipe (probably
wrongfully) relying on wildcards to gather files, see example above.

I have a lot of tasks with override not just on DISTRO but other
things like MACHINE or custom variables so I want to understand the
rebuild mechanism as best I can.

There's surely someone more knowledgeable here that could clarify the
inner workings of this mechanism a lot better than me.

Best,
Khoi Trinh

On Tue, Jul 12, 2022 at 8:05 AM Mike Looijmans
<mike.looijmans@...> wrote:

Quick answer: Don't build multiple distros in one build directory.

It's really a bummer that it's not reliably possible to switch between
DISTROs inside one build directory.

You might get away with setting TMPDIR = "tmp-${DISTRO}" to give
each
its own.

But I'd rather advice to set up two separate builds and just point
the
downloads and sstate-cache to the same location. It'll be faster
than
the TMPDIR option.

Or figure out how to put the difference in the IMAGE only. Then you
can
just build both images (in parallel, woot), which is faster, more
convenient and saves on diskspace.

As I'm currently working with something close to what you describe, I
think I'll try to stay away from multiple DISTROs if possible and
improve on what I'm already doing.

What I often do is have my-application.bb generate a
my-application-utils package that only gets installed in the "dev"
image
but not in the production one, which only installs "my-
application".

This is probably what Martin meant with his A.bb and A-xx.bb example.
It's so far one of the best approaches I've seen, thanks.

You could also create a "my-application-dev.bb" recipe that
includes
my-application.bb and just changes what it needs to be different.




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijmans@...
W: www.topic.nl

Please consider the environment before printing this e-mail
On 12-07-2022 15:37, Nicolas Jeker via lists.yoctoproject.org
wrote:

Hi all,

I'm currently using an additional layer and image to
differentiate
between a release and development build (enabling NFS, SSH, root
login,
etc.). To create a development build, I manually add the layer to
bblayers.conf. This works quite well, but feels a bit clumsy to
integrate into a CI/CD pipeline.

Per these past discussions here [1][2], I'm now trying to migrate
to
multiple DISTROs, something like "mydistro" and "mydistro-dev".

While migrating some of the changes, I discovered that I run into
caching(?) issues. I have a recipe for an internal application
and want
to include additional systemd service files in the development
image.

What I did was this:

Added "application-dbg.service" to recipes-
internal/application/files

Adapted application.bb recipe:

SRC_URI:append:mydistro-dev = " file://application-dbg.service"

do_install {
      # ...snip...
      # systemd service
      install -d ${D}${systemd_system_unitdir}
      install -m 0644 ${WORKDIR}/application.service
${D}${systemd_system_unitdir}
}

do_install:append:mydistro-dev() {
      # debug systemd services
      install -d ${D}${systemd_system_unitdir}
      install -m 0644 ${WORKDIR}/application-dbg.service
${D}${systemd_system_unitdir}
}


When I run "DISTRO=mydistro-dev bitbake application" followed by
"DISTRO=mydistro bitbake application", the debug service file is
still
present in the package. This seems to be caused by the "image"
directory in the recipe WORKDIR not being cleaned between
subsequent
do_install runs. Is this expected behaviour? What's the best
solution?

Kind regards,
Nicolas

[1]:
https://lore.kernel.org/yocto/CAH9dsRiArf_9GgQS4hCg5=J_Jk6cd3eiGaOiQd788+iSLTuU+g@mail.gmail.com/
[2]:
https://lore.kernel.org/yocto/VI1PR0602MB3549F83AC93A53785DE48677D3FD9@VI1PR0602MB3549.eurprd06.prod.outlook.com/

--
Mike Looijmans