Date   

[PATCH yocto-autobuilder-helper] config: build and test SDKs when using package_deb

Ross Burton <ross@...>
 

Signed-off-by: Ross Burton <ross.burton@arm.com>
---
config.json | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/config.json b/config.json
index ea2d86b..3286e57 100644
--- a/config.json
+++ b/config.json
@@ -580,8 +580,8 @@
"pkgman-deb-non-deb" : {
"MACHINE" : "qemux86",
"PACKAGE_CLASSES" : "package_deb",
- "BBTARGETS" : "core-image-sato core-image-sato-dev core-imag=
e-sato-sdk core-image-minimal core-image-minimal-dev",
- "SANITYTARGETS" : "core-image-minimal:do_testimage core-imag=
e-sato:do_testimage core-image-sato-sdk:do_testimage"
+ "BBTARGETS" : "core-image-sato core-image-sato-dev core-imag=
e-sato-sdk core-image-minimal core-image-minimal-dev core-image-sato:do_p=
opulate_sdk",
+ "SANITYTARGETS" : "core-image-minimal:do_testimage core-imag=
e-sato:do_testimage core-image-sato-sdk:do_testimage core-image-sato:do_t=
estsdk"
},
"pkgman-non-rpm" : {
"MACHINE" : "qemux86",
--=20
2.25.1


changing root password in readonly rootfs

Marek Belisko
 

Hi,

does anybody know if there is a way to have possibility to change root
pwd when readonly rootfs is used? I've added shadow package + overlay
/ect/shadow + /etc/passwd but chpasswd complains and changis is not
possible.

Thanks and BR,

marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com


Re: Regarding Mender integration

U RAVI KUMAR <uppadaravi2511@...>
 

HI robert,

    Thank you very much for your response.

Regards,
RAVI_UPPADA


On Wed, Feb 17, 2021 at 2:21 PM Robert Berger@... <robert.berger.yocto.user@...> wrote:
Hi,

Please see my comments in-line.

On 16/02/2021 19:48, U RAVI KUMAR wrote:
>     I have some issues while integrating the mender on the yocto
>     project.I have included meta-mener-core,meta-mender-raspberrypi
>     layers.And iam getting the following error:
>
>     ERROR: u-boot-1_2020.07-r0 do_patch: Command Error: 'quilt --quiltrc
>     /home/ravi_uppada/work/vm/sato/poky/build/tmp/work/raspberrypi4_64-poky-linux/u-boot/1_2020.07-r0/recipe-sysroot-native/etc/quiltrc
>     push' exited with 0  Output:
>     Applying patch 0001-configs-rpi-enable-mender-requirements.patch
>     patching file configs/rpi_0_w_defconfig
>     Hunk #1 FAILED at 19.

...

This looks like the patch you/mender try/tries to apply does not work
with your u-boot version.[0]

[0]
https://github.com/mendersoftware/meta-mender/tree/master/meta-mender-core/recipes-bsp/u-boot

Which Yocto version do you use?

Which Mender version do you use?

You could look into creating your own Mender integration[1] instead of
the mender class.

[1]
https://docs.mender.io/system-updates-yocto-project/board-integration/bootloader-support/u-boot/manual-u-boot-integration

I think the right place to ask Mender specific questions is here[2].

[2] https://hub.mender.io/

Regards,

Robert



Re: [meta-security] [PATCH 0/5] Some fixes for IMA/EVM

Dmitry Baryshkov
 

I suppose, patch 3 can be split into logical chunks.
Other patches are:

Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

ср, 17 февр. 2021 г. в 17:09, Ming Liu <liu.ming50@gmail.com>:


From: Ming Liu <liu.ming50@gmail.com>

Ming Liu (5):
ima-evm-utils: set native REQUIRED_DISTRO_FEATURES to empty
initramfs-framework-ima: fix a wrong path
meta: refactor IMA/EVM sign rootfs
initramfs-framework-ima: let ima_enabled return 0
ima-evm-rootfs.bbclass: avoid generating /etc/fstab for wic

meta-integrity/README.md | 4 ++-
meta-integrity/classes/ima-evm-rootfs.bbclass | 33 +++++++++----------
.../initrdscripts/initramfs-framework-ima.bb | 2 +-
.../initrdscripts/initramfs-framework-ima/ima | 3 +-
.../ima-evm-keys/ima-evm-keys_1.0.bb | 16 +++++++++
.../ima-evm-utils/ima-evm-utils_git.bb | 1 +
6 files changed, 38 insertions(+), 21 deletions(-)
create mode 100644 meta-integrity/recipes-security/ima-evm-keys/ima-evm-keys_1.0.bb

--
2.29.0



--
With best wishes
Dmitry


[meta-security] [PATCH 5/5] ima-evm-rootfs.bbclass: avoid generating /etc/fstab for wic

Ming Liu <liu.ming50@...>
 

From: Ming Liu <liu.ming50@gmail.com>

Or else wic will fail without "--no-fstab-update" option.

Signed-off-by: Ming Liu <liu.ming50@gmail.com>
---
meta-integrity/classes/ima-evm-rootfs.bbclass | 3 +++
1 file changed, 3 insertions(+)

diff --git a/meta-integrity/classes/ima-evm-rootfs.bbclass b/meta-integrity/classes/ima-evm-rootfs.bbclass
index 4359af0..0acd6e7 100644
--- a/meta-integrity/classes/ima-evm-rootfs.bbclass
+++ b/meta-integrity/classes/ima-evm-rootfs.bbclass
@@ -28,6 +28,9 @@ IMA_EVM_ROOTFS_HASHED ?= ". -depth 0 -false"
# the iversion flags (needed by IMA when allowing writing).
IMA_EVM_ROOTFS_IVERSION ?= ""

+# Avoid re-generating fstab when ima is enabled.
+WIC_CREATE_EXTRA_ARGS_append = "${@bb.utils.contains('DISTRO_FEATURES', 'ima', ' --no-fstab-update', '', d)}"
+
ima_evm_sign_rootfs () {
cd ${IMAGE_ROOTFS}

--
2.29.0


[meta-security] [PATCH 4/5] initramfs-framework-ima: let ima_enabled return 0

Ming Liu <liu.ming50@...>
 

From: Ming Liu <liu.ming50@gmail.com>

Otherwise, ima script would not run as intended.

Signed-off-by: Ming Liu <liu.ming50@gmail.com>
---
.../recipes-core/initrdscripts/initramfs-framework-ima/ima | 1 +
1 file changed, 1 insertion(+)

diff --git a/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/ima b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/ima
index 16ed53f..cff26a3 100644
--- a/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/ima
+++ b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/ima
@@ -6,6 +6,7 @@ ima_enabled() {
if [ "$bootparam_no_ima" = "true" ]; then
return 1
fi
+ return 0
}

ima_run() {
--
2.29.0


[meta-security] [PATCH 3/5] meta: refactor IMA/EVM sign rootfs

Ming Liu <liu.ming50@...>
 

From: Ming Liu <liu.ming50@gmail.com>

The current logic in ima-evm-rootfs.bbclass does not guarantee
ima_evm_sign_rootfs is the last function in IMAGE_PREPROCESS_COMMAND
by appending to it, for instance, if there are other "_append" being
used as it's the case in openembedded-core/meta/classes/image.bbclass:

| IMAGE_PREPROCESS_COMMAND_append = " ${@ 'systemd_preset_all;' \
| if bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d) \
| and not bb.utils.contains('IMAGE_FEATURES', 'stateless-rootfs', True,
| False, d) else ''} reproducible_final_image_task; "

and ima-evm-rootfs should be in IMAGE_CLASSES instead of in INHERIT
since that would impact all recipes but not only image recipes.

To fix the above issues, we introduce a ima_evm_sign_handler setting
IMA/EVM rootfs signing requirements/dependencies in event
bb.event.RecipePreFinalise, it checks 'ima' distro feature to decide if
IMA/EVM rootfs signing logic should be applied or not.

We also need split public keys to ima-evm-keys recipe, so it could be
added both in initramfs and rootfs, so initramfs recipe does not have to
inherit ima-evm-rootfs

Signed-off-by: Ming Liu <liu.ming50@gmail.com>
---
meta-integrity/README.md | 4 ++-
meta-integrity/classes/ima-evm-rootfs.bbclass | 30 ++++++++-----------
.../initrdscripts/initramfs-framework-ima.bb | 2 +-
.../ima-evm-keys/ima-evm-keys_1.0.bb | 16 ++++++++++
4 files changed, 32 insertions(+), 20 deletions(-)
create mode 100644 meta-integrity/recipes-security/ima-evm-keys/ima-evm-keys_1.0.bb

diff --git a/meta-integrity/README.md b/meta-integrity/README.md
index 4607948..5048fba 100644
--- a/meta-integrity/README.md
+++ b/meta-integrity/README.md
@@ -73,8 +73,10 @@ Adding the layer only enables IMA (see below regarding EVM) during
compilation of the Linux kernel. To also activate it when building
the image, enable image signing in the local.conf like this:

- INHERIT += "ima-evm-rootfs"
+ IMAGE_CLASSES += "ima-evm-rootfs"
IMA_EVM_KEY_DIR = "${INTEGRITY_BASE}/data/debug-keys"
+ IMA_EVM_PRIVKEY = "${IMA_EVM_KEY_DIR}/privkey_ima.pem"
+ IMA_EVM_X509 = "${IMA_EVM_KEY_DIR}/x509_ima.der"

This uses the default keys provided in the "data" directory of the layer.
Because everyone has access to these private keys, such an image
diff --git a/meta-integrity/classes/ima-evm-rootfs.bbclass b/meta-integrity/classes/ima-evm-rootfs.bbclass
index d6ade3b..4359af0 100644
--- a/meta-integrity/classes/ima-evm-rootfs.bbclass
+++ b/meta-integrity/classes/ima-evm-rootfs.bbclass
@@ -37,15 +37,6 @@ ima_evm_sign_rootfs () {
# reasons (including a change of the signing keys) without also
# re-running do_rootfs.

- # Copy file(s) which must be on the device. Note that
- # evmctl uses x509_evm.der also for "ima_verify", which is probably
- # a bug (should default to x509_ima.der). Does not matter for us
- # because we use the same key for both.
- install -d ./${sysconfdir}/keys
- rm -f ./${sysconfdir}/keys/x509_evm.der
- install "${IMA_EVM_X509}" ./${sysconfdir}/keys/x509_evm.der
- ln -sf x509_evm.der ./${sysconfdir}/keys/x509_ima.der
-
# Fix /etc/fstab: it must include the "i_version" mount option for
# those file systems where writing files is allowed, otherwise
# these changes will not get detected at runtime.
@@ -80,13 +71,16 @@ ima_evm_sign_rootfs () {
}

# Signing must run as late as possible in the do_rootfs task.
-# IMAGE_PREPROCESS_COMMAND runs after ROOTFS_POSTPROCESS_COMMAND, so
-# append (not prepend!) to IMAGE_PREPROCESS_COMMAND, and do it with
-# _append instead of += because _append gets evaluated later. In
-# particular, we must run after prelink_image in
-# IMAGE_PREPROCESS_COMMAND, because prelinking changes executables.
-
-IMAGE_PREPROCESS_COMMAND_append = " ima_evm_sign_rootfs ; "
+# To guarantee that, we append it to IMAGE_PREPROCESS_COMMAND in
+# RecipePreFinalise event handler, this ensures it's the last
+# function in IMAGE_PREPROCESS_COMMAND.
+python ima_evm_sign_handler () {
+ if not e.data or 'ima' not in e.data.getVar('DISTRO_FEATURES').split():
+ return

-# evmctl must have been installed first.
-do_rootfs[depends] += "ima-evm-utils-native:do_populate_sysroot"
+ e.data.appendVar('IMAGE_PREPROCESS_COMMAND', ' ima_evm_sign_rootfs; ')
+ e.data.appendVar('IMAGE_INSTALL', ' ima-evm-keys')
+ e.data.appendVarFlag('do_rootfs', 'depends', ' ima-evm-utils-native:do_populate_sysroot')
+}
+addhandler ima_evm_sign_handler
+ima_evm_sign_handler[eventmask] = "bb.event.RecipePreFinalise"
diff --git a/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima.bb b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima.bb
index dacdc8b..77f6f7c 100644
--- a/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima.bb
+++ b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima.bb
@@ -27,5 +27,5 @@ do_install () {

FILES_${PN} = "/init.d ${sysconfdir}"

-RDEPENDS_${PN} = "keyutils ${IMA_POLICY}"
+RDEPENDS_${PN} = "keyutils ima-evm-keys ${IMA_POLICY}"
RDEPENDS_${PN} += "initramfs-framework-base"
diff --git a/meta-integrity/recipes-security/ima-evm-keys/ima-evm-keys_1.0.bb b/meta-integrity/recipes-security/ima-evm-keys/ima-evm-keys_1.0.bb
new file mode 100644
index 0000000..62685bb
--- /dev/null
+++ b/meta-integrity/recipes-security/ima-evm-keys/ima-evm-keys_1.0.bb
@@ -0,0 +1,16 @@
+SUMMARY = "IMA/EMV public keys"
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+
+inherit features_check
+REQUIRED_DISTRO_FEATURES = "ima"
+
+ALLOW_EMPTY_${PN} = "1"
+
+do_install () {
+ if [ -e "${IMA_EVM_X509}" ]; then
+ install -d ${D}/${sysconfdir}/keys
+ install "${IMA_EVM_X509}" ${D}${sysconfdir}/keys/x509_evm.der
+ lnr ${D}${sysconfdir}/keys/x509_evm.der ${D}${sysconfdir}/keys/x509_ima.der
+ fi
+}
--
2.29.0


[meta-security] [PATCH 2/5] initramfs-framework-ima: fix a wrong path

Ming Liu <liu.ming50@...>
 

From: Ming Liu <liu.ming50@gmail.com>

/etc/ima-policy > /etc/ima/ima-policy.

Signed-off-by: Ming Liu <liu.ming50@gmail.com>
---
.../recipes-core/initrdscripts/initramfs-framework-ima/ima | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/ima b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/ima
index 8616f99..16ed53f 100644
--- a/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/ima
+++ b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/ima
@@ -46,7 +46,7 @@ ima_run() {
# ("[Linux-ima-user] IMA policy loading via cat") and we get better error reporting when
# checking the write of each line. To minimize the risk of policy loading going wrong we
# also remove comments and blank lines ourselves.
- if ! (set -e; while read i; do if echo "$i" | grep -q -e '^#' -e '^ *$'; then debug "Skipping IMA policy: $i"; else debug "Writing IMA policy: $i"; if echo $i; then sleep ${bootparam_ima_delay:-0}; else fatal "Invalid line in IMA policy: $i"; exit 1; fi; fi; done) </etc/ima-policy >/sys/kernel/security/ima/policy; then
+ if ! (set -e; while read i; do if echo "$i" | grep -q -e '^#' -e '^ *$'; then debug "Skipping IMA policy: $i"; else debug "Writing IMA policy: $i"; if echo $i; then sleep ${bootparam_ima_delay:-0}; else fatal "Invalid line in IMA policy: $i"; exit 1; fi; fi; done) </etc/ima/ima-policy >/sys/kernel/security/ima/policy; then
fatal "Could not load IMA policy."
fi
}
--
2.29.0


[meta-security] [PATCH 1/5] ima-evm-utils: set native REQUIRED_DISTRO_FEATURES to empty

Ming Liu <liu.ming50@...>
 

From: Ming Liu <liu.ming50@gmail.com>

'ima' does not have to be in native DISTRO_FEATURES, unset it to avoid
sanity check, this fixes a following error:

Signed-off-by: Ming Liu <liu.ming50@gmail.com>
---
.../recipes-security/ima-evm-utils/ima-evm-utils_git.bb | 1 +
1 file changed, 1 insertion(+)

diff --git a/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils_git.bb b/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils_git.bb
index 7f649c2..bd85583 100644
--- a/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils_git.bb
+++ b/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils_git.bb
@@ -26,6 +26,7 @@ S = "${WORKDIR}/git"
inherit pkgconfig autotools features_check

REQUIRED_DISTRO_FEATURES = "ima"
+REQUIRED_DISTRO_FEATURES_class-native = ""

EXTRA_OECONF_append_class-target = " --with-kernel-headers=${STAGING_KERNEL_BUILDDIR}"

--
2.29.0


[meta-security] [PATCH 0/5] Some fixes for IMA/EVM

Ming Liu <liu.ming50@...>
 

From: Ming Liu <liu.ming50@gmail.com>

Ming Liu (5):
ima-evm-utils: set native REQUIRED_DISTRO_FEATURES to empty
initramfs-framework-ima: fix a wrong path
meta: refactor IMA/EVM sign rootfs
initramfs-framework-ima: let ima_enabled return 0
ima-evm-rootfs.bbclass: avoid generating /etc/fstab for wic

meta-integrity/README.md | 4 ++-
meta-integrity/classes/ima-evm-rootfs.bbclass | 33 +++++++++----------
.../initrdscripts/initramfs-framework-ima.bb | 2 +-
.../initrdscripts/initramfs-framework-ima/ima | 3 +-
.../ima-evm-keys/ima-evm-keys_1.0.bb | 16 +++++++++
.../ima-evm-utils/ima-evm-utils_git.bb | 1 +
6 files changed, 38 insertions(+), 21 deletions(-)
create mode 100644 meta-integrity/recipes-security/ima-evm-keys/ima-evm-keys_1.0.bb

--
2.29.0


Re: Timing a recipe

Richard Purdie
 

On Tue, 2021-02-16 at 11:43 -0800, rustyhowell@gmail.com wrote:
"time bitbake recipe" is perfect for manual things. But I wanted to
also measure the recipe times when building the entire image.  I
ended up creating  a bbappend with new pre/post tasks for the main
tasks (fetch, unpack, configure, compile, install, package).   The
pre task drops a timestamp file and the post task reads the file,
calculates the elapsed time and logs it to a file.  It's a bit clunky
but it gives the information I want.  Thanks for the help.
As others have said, please look at the buildstats class and the data
it saves into TMPDIR/buildstats. It should do what you want and we have
tools like pybootchart which can show it visually.

Cheers,

Richard


Re: #av1 #armv6 #raspberrypi #neon #av1 #armv6 #raspberrypi #neon

Zoran
 

So, what is your MACHINE variable set to?

Maybe knowing that, somebody can help.

Zee


Re: Timing a recipe

Ross Burton <ross@...>
 

As said, buildstats is *exactly* what you want. There's a forked
pybootchart in oe-core that can visualise the data too.

Ross

On Mon, 15 Feb 2021 at 20:08, <rustyhowell@gmail.com> wrote:

Is there a way to automatically record build time of a recipe without modifying the recipe itself? I have a recipe that is a monster, it has many git URIs and produces many packages that are coupled. It should be broken up but company deadlines have kept us from taking the time to do this. I was talking to my boss about this. He said we really needs some concrete data about how much this monster recipe is costing us before green-lighting the massive effort to split up the recipe. I agree with him, so I would like to know how much time is spent repeatedly building this recipe. I figure I could do this by adding do_fetch_prepend() and writing the time to a file, and then do_install_append() and writing the time to the file. So after a week or so, I would have many start/end data points to discuss.

However, I did not want to modify the recipe itself. I was hoping to augment the recipe via local.conf. Another bbappend in a new layer would work I guess, but I was hoping there was something simpler. Thanks in advance.




#av1 #armv6 #raspberrypi #neon #av1 #armv6 #raspberrypi #neon

safouane maaloul
 

Hello folks,
 
I have an issue integrating av1  in yocto. I get the  compile  error "compiling simd-neon.h requires -mfpu=neon or equivalent". The problem is that i use armv6 (raspberrypi zero w) so i can't exactly do that. Anyone have a workaround this problem ?

Best regards,

Safouane.Maaloul


Re: Regarding Mender integration

Robert Berger
 

Hi,

Please see my comments in-line.

On 16/02/2021 19:48, U RAVI KUMAR wrote:
I have some issues while integrating the mender on the yocto
project.I have included meta-mener-core,meta-mender-raspberrypi
layers.And iam getting the following error:
ERROR: u-boot-1_2020.07-r0 do_patch: Command Error: 'quilt --quiltrc
/home/ravi_uppada/work/vm/sato/poky/build/tmp/work/raspberrypi4_64-poky-linux/u-boot/1_2020.07-r0/recipe-sysroot-native/etc/quiltrc
push' exited with 0  Output:
Applying patch 0001-configs-rpi-enable-mender-requirements.patch
patching file configs/rpi_0_w_defconfig
Hunk #1 FAILED at 19.
...

This looks like the patch you/mender try/tries to apply does not work with your u-boot version.[0]

[0] https://github.com/mendersoftware/meta-mender/tree/master/meta-mender-core/recipes-bsp/u-boot

Which Yocto version do you use?

Which Mender version do you use?

You could look into creating your own Mender integration[1] instead of the mender class.

[1] https://docs.mender.io/system-updates-yocto-project/board-integration/bootloader-support/u-boot/manual-u-boot-integration

I think the right place to ask Mender specific questions is here[2].

[2] https://hub.mender.io/

Regards,

Robert


Re: Keep .bbappend for older Yocto version

Khem Raj
 



On Tue, Feb 16, 2021 at 3:54 PM Jonas Vautherin <jonas.vautherin@...> wrote:
Thank you for the answer :-). Yes, that works, and it seems like it is commonly used already. But because there is a way to define which versions are supported in the machine configuration, I thought there may be a way without branches, i.e. having a layer that actually is compatible with multiple versions.

Yes in some layers they do work across releases but 
That does have some restrictions and maintenance costs eg if you are patching a recipe via a bbappend then use more liberal bbappend names using % wild characters and make sure same patch can apply to different versions of the package etc 

Usually maintaining per Releaee branch turns out to be less costly over time 


Otherwise what's the point of LAYERSERIES_COMPAT, if the way to move to another version is to branch away? Is that a legacy option?

Best,


On Wed, 17 Feb 2021, 00:32 Khem Raj, <raj.khem@...> wrote:
perhaps you should create a new branch for this layer which will be
compatible with gatesgarth, you can seed it with dunfell branch
and then make needed changes

On Tue, Feb 16, 2021 at 3:02 PM Jonas Vautherin
<jonas.vautherin@...> wrote:
>
> Good evening,
>
> I am using Yocto Gatesgarth, and I was just updating a layer that was written for Dunfell. In the `conf/layer.conf`, I can simply add "gatesgarth" to `LAYERSERIES_COMPAT_pocketbeagle`, like so:
>
> ```
> LAYERSERIES_COMPAT_pocketbeagle = "dunfell gatesgarth"
> ```
>
> However, this does not seem to work for a `.bbappend`. Let me use this particular layer as an example: it is a BSP that defines `linux-yocto_4.19.bbappend` for Dunfell. In my case, I want to define `linux-yocto_5.4.bbappend` for Gatesgarth. When building with Dunfell, I would like it to use the former, and when building with Gatesgarth, I would like it to use the latter.
>
> However, if I keep both `linux-yocto_4.19.bbappend` and `linux-yocto_5.4.bbappend` and try to build with Gatesgarth, it fails with:
>
> ```
> ERROR: No recipes in default available for:
>   /path/to/recipes-kernel/linux/linux-yocto_4.19.bbappend
> ```
>
> Which makes sense: Gatesgarth does not provide `linux-yocto_4.19`.
>
> Is there a way to keep both `*.bbappend` and have Yocto ignore the ones that do not correspond to its version? Or would that be bad practice anyway?
>
> Best Regards,
> Jonas
>
>
>


Re: Keep .bbappend for older Yocto version

Jonas Vautherin
 

Thank you for the answer :-). Yes, that works, and it seems like it is commonly used already. But because there is a way to define which versions are supported in the machine configuration, I thought there may be a way without branches, i.e. having a layer that actually is compatible with multiple versions.

Otherwise what's the point of LAYERSERIES_COMPAT, if the way to move to another version is to branch away? Is that a legacy option?

Best,


On Wed, 17 Feb 2021, 00:32 Khem Raj, <raj.khem@...> wrote:
perhaps you should create a new branch for this layer which will be
compatible with gatesgarth, you can seed it with dunfell branch
and then make needed changes

On Tue, Feb 16, 2021 at 3:02 PM Jonas Vautherin
<jonas.vautherin@...> wrote:
>
> Good evening,
>
> I am using Yocto Gatesgarth, and I was just updating a layer that was written for Dunfell. In the `conf/layer.conf`, I can simply add "gatesgarth" to `LAYERSERIES_COMPAT_pocketbeagle`, like so:
>
> ```
> LAYERSERIES_COMPAT_pocketbeagle = "dunfell gatesgarth"
> ```
>
> However, this does not seem to work for a `.bbappend`. Let me use this particular layer as an example: it is a BSP that defines `linux-yocto_4.19.bbappend` for Dunfell. In my case, I want to define `linux-yocto_5.4.bbappend` for Gatesgarth. When building with Dunfell, I would like it to use the former, and when building with Gatesgarth, I would like it to use the latter.
>
> However, if I keep both `linux-yocto_4.19.bbappend` and `linux-yocto_5.4.bbappend` and try to build with Gatesgarth, it fails with:
>
> ```
> ERROR: No recipes in default available for:
>   /path/to/recipes-kernel/linux/linux-yocto_4.19.bbappend
> ```
>
> Which makes sense: Gatesgarth does not provide `linux-yocto_4.19`.
>
> Is there a way to keep both `*.bbappend` and have Yocto ignore the ones that do not correspond to its version? Or would that be bad practice anyway?
>
> Best Regards,
> Jonas
>
>
>


Re: Keep .bbappend for older Yocto version

Khem Raj
 

perhaps you should create a new branch for this layer which will be
compatible with gatesgarth, you can seed it with dunfell branch
and then make needed changes

On Tue, Feb 16, 2021 at 3:02 PM Jonas Vautherin
<jonas.vautherin@gmail.com> wrote:

Good evening,

I am using Yocto Gatesgarth, and I was just updating a layer that was written for Dunfell. In the `conf/layer.conf`, I can simply add "gatesgarth" to `LAYERSERIES_COMPAT_pocketbeagle`, like so:

```
LAYERSERIES_COMPAT_pocketbeagle = "dunfell gatesgarth"
```

However, this does not seem to work for a `.bbappend`. Let me use this particular layer as an example: it is a BSP that defines `linux-yocto_4.19.bbappend` for Dunfell. In my case, I want to define `linux-yocto_5.4.bbappend` for Gatesgarth. When building with Dunfell, I would like it to use the former, and when building with Gatesgarth, I would like it to use the latter.

However, if I keep both `linux-yocto_4.19.bbappend` and `linux-yocto_5.4.bbappend` and try to build with Gatesgarth, it fails with:

```
ERROR: No recipes in default available for:
/path/to/recipes-kernel/linux/linux-yocto_4.19.bbappend
```

Which makes sense: Gatesgarth does not provide `linux-yocto_4.19`.

Is there a way to keep both `*.bbappend` and have Yocto ignore the ones that do not correspond to its version? Or would that be bad practice anyway?

Best Regards,
Jonas



Re: Yocto Technical Team Minutes, Engineering Sync, for Feb 16 2021

Trevor Woerner
 

On Tue 2021-02-16 @ 12:41:37 PM, akuster808 wrote:
On 2/16/21 11:10 AM, Trevor Woerner wrote:
Yocto Technical Team Minutes, Engineering Sync, for Feb 16 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit
Thanks for taking and sending the minutes.
You're welcome :-)

I take notes every week, but had stopped sending emails to the list at the end
of each meeting. A couple people mentioned privately that they appreciate the
notes being formatted for email and sent that way, so I picked it back up
again.


Keep .bbappend for older Yocto version

Jonas Vautherin
 

Good evening,

I am using Yocto Gatesgarth, and I was just updating a layer that was written for Dunfell. In the `conf/layer.conf`, I can simply add "gatesgarth" to `LAYERSERIES_COMPAT_pocketbeagle`, like so:

```
LAYERSERIES_COMPAT_pocketbeagle = "dunfell gatesgarth"
```

However, this does not seem to work for a `.bbappend`. Let me use this particular layer as an example: it is a BSP that defines `linux-yocto_4.19.bbappend` for Dunfell. In my case, I want to define `linux-yocto_5.4.bbappend` for Gatesgarth. When building with Dunfell, I would like it to use the former, and when building with Gatesgarth, I would like it to use the latter.

However, if I keep both `linux-yocto_4.19.bbappend` and `linux-yocto_5.4.bbappend` and try to build with Gatesgarth, it fails with:

```
ERROR: No recipes in default available for:
  /path/to/recipes-kernel/linux/linux-yocto_4.19.bbappend
```

Which makes sense: Gatesgarth does not provide `linux-yocto_4.19`.

Is there a way to keep both `*.bbappend` and have Yocto ignore the ones that do not correspond to its version? Or would that be bad practice anyway?

Best Regards,
Jonas

4721 - 4740 of 57064