Yocto mickledore introduced the addpylib directive for explicitly adding
layer paths to the PYTHONPATH.
Standalone OEQA test suite discovery does not require this directive but
it is required to import test cases from other layers, e.g. to extend
and modify the test cases.
Signed-off-by: Peter Hoyes <Peter.Hoyes@arm.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
If PACKAGECONFIG is not defined in local.conf then
its default value is not included in cls.tc.td map.
Signed-off-by: Anton Antonov <Anton.Antonov@arm.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Fixes:
ERROR: Missing SRC_URI checksum, please add those to the recipe:
SRC_URI[parsec-service-1.2.0.sha256sum] = "f58e7ba859c22cc1904dc8298b1a7d94ee1ba3b4d4808f28e4cc0c96ddb149c9"
Needed to S dir too.
Signed-off-by: Armin Kuster <akuster808@gmail.com>
v2]
Fix patch applying
FIxes:
ERROR: Missing SRC_URI checksum, please add those to the recipe:
SRC_URI[parsec-tool-0.6.0.sha256sum] = "f51d5d7f0caca1c335324b52482fa5edbf6c9cfd2e6865e5cb22716d52dcb367"
Needed to have the package version included in the name.
Fixes:
ERROR: parsec-tool-0.6.0-r0 do_populate_lic: QA Issue: parsec-tool: LIC_FILES_CHKSUM points to an invalid file:
and
error: manifest path `/home/akuster/oss/clean/poky/build/tmp/work/cortexa53-poky-linux/parsec-tool/0.6.0-r0/parsec-tool-0.6.0//Cargo.toml` does not exist
Set S to CARGO_VENDORING_DIRECTORY/BP to fix the LIC_FILES_CHKSUM and compile errors.
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Had to delete some wonky Cargo.toml files to get update_crates to work.
Manually updated one crate to a newer version included by update_crates as it would not compile.
Manually applied several crates missed by update_crates.
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Drop setuid-log-folder.patch, using sed instead.
Refresh patch check-setuid-use-more-portable-find-args.patch
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Currently CVE-2023-22745 does not show up in kirkstone CVE report.
This fixes that.
Products from yocto's CVE check NVD database:
sqlite> select * from products where product like "tpm2%";
CVE-2017-7524|tpm2-tools_project|tpm2.0-tools|||1.1.0|<=
CVE-2020-24455|tpm2_software_stack_project|tpm2_software_stack|||2.4.3|<
CVE-2020-24455|tpm2_software_stack_project|tpm2_software_stack|3.0.0|>=|3.0.1|<
CVE-2021-3565|tpm2-tools_project|tpm2-tools|5.1|>=|5.1.1|<
CVE-2021-3565|tpm2-tools_project|tpm2-tools|||4.3.2|<
CVE-2023-22745|tpm2_software_stack_project|tpm2_software_stack|||4.0.0|<=
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Building documentation fails due to missing asciidoc, xsltproc etc
so it's better to just disable building them by default.
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
When using the kernel module parameter "dm-mod.create=" [1] to create
the device-mapper device, the hash offset address we passed to kernel
module is the hash block number. That means the hash offset address
would have to be aligned to the max(data_block_size, hash_block_size),
otherwise there would be no way to set the correct hash offset address
via "dm-mo.create=".
[1] https://www.kernel.org/doc/Documentation/admin-guide/device-mapper/dm-init.rst
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
This is meant to augment the generic dm-verity instructions with
the board specifics for this platform.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
As things stand currently, the only way to learn about the Yocto
specific settings for implementing dm-verity is by reading the source.
Here we try and capture some of the basic information that exists
out there in mailing list posts and get that in-tree.
Board specific settings/tips will be stored in board specific files.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Fixes warning
```
SyntaxWarning: "is not" with a literal. Did you mean "!="?
```
Signed-off-by: Eero Aaltonen <eero.aaltonen@vaisala.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
This file was forked from the generic (non verity) version in
meta-yocto, but it would seem that due to limited use, an update
in the parent never made it here, even after two years:
[commit 0c679ac53b52e631a7c961872ce58f5cf74b8629 in meta-yocto]
From: Kevin Hao <kexin.hao@windriver.com>
Date: Tue, 23 Mar 2021 17:35:29 +0800
Subject: [PATCH] meta-yocto-bsp: beaglebone: Set a fixed size for boot
partition in WIC image
After the dosfstools has been updated to v4.2 by commit b522f24723e1
("dosfstools: update 4.1 -> 4.2"), the commit b29eb5be67e9 ("mkfs.fat:
Align total number of sectors to be multiple of sectors per track") in
v4.2 has caused a regression in beagebone black board. The reason is
that the real total sectors of the fat filesystem created by the mkdosfs
may not be the same size as what we requested due to align with the
sectors per track, this change seem no side effect to linux kernel,
but it breaks the beaglebone black boot ROM and make it can't load the
MLO. In order to fix this issue, we choose to set a fixed size for the
boot partition to make sure that the total sectors always are aligned
with the sectors per track.
[Yocto #14306]
Bring the same change across, so dm-verity doesn't face the same
frustrating silent boot failure with zero console output.
With this change in place, and allowing for read-only rootfs, we see:
device-mapper: verity: sha256 using implementation "sha256-generic"
EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null). Quota mode: disabled.
INIT: version 3.01 booting
Note that the above is from booting on real hardware on Kirkstone.
Cc: Kevin Hao <kexin.hao@windriver.com>
Cc: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
The priority change on sumo version without any description.
Since then is very hard to add in other layers a new version
of any recipe on this layer with such priority so these patch
reverts the priority back to 6.
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
The priority change on sumo version without any description.
Since then is very hard to add in other layers a new version
of any recipe on this layer with such priority so these patch
reverts the priority back to 6.
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
The priority change on sumo version without any description.
Since then is very hard to add in other layers a new version
of any recipe on this layer with such priority so these patch
reverts the priority back to 6.
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
These bbappends apply to multiple kernel versions so no
need to make them version dependent. Fixes recipe parsing when
using meta-security master branch on kirkstone. In our custom layer we
set layer compatibility for kirkstone and I understand why meta-security
upstream would not want to do that:
LAYERSERIES_COMPAT_security-layer += 'kirkstone'
LAYERSERIES_COMPAT_parsec-layer += 'kirkstone'
LAYERSERIES_COMPAT_tpm-layer += 'kirkstone'
While I work towards supporting also yocto master branch and newer
releases than kirkstone, I would appreciate if I would not have to
branch off layers over minor details like this.
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
OE-Core changed the cache handling which made the use of ${BPN} no fail.
| Parsing recipes...WARNING: .../samhain-standalone.bb: Exception during build_dependencies for do_configure
| WARNING: .../samhain-standalone.bb: Error during finalise of .../samhain-standalone.bb
| ERROR: ExpansionError during parsing .../samhain-standalone.bb
| Traceback (most recent call last):
| File "Var <MODE_NAME>", line 1, in <module>
| bb.data_smart.ExpansionError: Failure expanding variable MODE_NAME, expression was ${@d.getVar('BPN').split('-')[1]} which triggered exception IndexError: list index out of range
| The variable dependency chain for the failure is: MODE_NAME -> SAMHAIN_MODE -> do_configure
Simplify the setting of MODE_NAME and SAMHAIN_MODE by setting them
in the recipe files where we know their values.
bitbake:
ee89ade5 cache/codeparser: Switch to a new BB_CACHEDIR variable for cache location
oe-core:
7c15e03dd3 bitbake.conf: Add BB_HASH_CODEPARSER_VALS
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
swig has switched to use libpcre2, we need to add libpcre to
DEPENDS to avoid do_configure failure.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
