There was one failure occurring in rust testing for qemuriscv64. Exclude
that test so we can enable in automated testing.
(From OE-Core rev: a7f6ea5b20aa91e4a1b00dbea7a6447effb9220d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, pseudo tracks all files referenced within its presence unless
they're listed in an exclusion list. The exclusion list has grown to be
fairly unwieldy.
This patch swaps PSEUDO_IGNORE_PATHS for PSEUDO_INCLUDE_PATHS which in
theory should be easier and more explicit to maintain.
This change does drop many directories from pseudo coverage including
/home and /tmp. There may be adapatations needed for recipes/classes
using pseudo in specific ways.
(From OE-Core rev: 2502da81709f25de499277b28d33c915638c45f6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a test that builds a SDK with specific packages in the host and
target sections, and verifies that they're listed in the manifest.
(From OE-Core rev: a1556c801feb56b79243ba2947b74b84f674072b)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Test recipe git repo URL is checked for newer commits and
mtd-utils-selftest check is sometimes failing due to server
errors. Use pseudo which uses Yocto Project in git servers
which should be reliable.
Fixes: [YOCTO #15855]
build/build-st-17692/tmp/hosttools"; export HOME="/srv/pokybuild"; git -c gc.autoDetach=false -c core.pager=cat -c safe.bareRepository=all -c clone.defaultRemoteName=origin ls-remote git://git.infradead.org/mtd-utils.git failed with exit code 128, output:
fatal: read error: Connection reset by peer
(From meta-yocto rev: a82be5486058c2e5a1e286dba17c33444889c982)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All qemu machines have ext4 in IMAGE_FSTYPES which makes
native mkfs.ext4 available at wic image build time.
genericarm64 defaults to only wic in IMAGE_FSTYPES
and this test was failing:
| DEBUG: Python function extend_recipe_sysroot finished
| DEBUG: Executing python function set_image_size
| DEBUG: 148548.400000 = 114268 * 1.300000
| DEBUG: 652644.400000 = max(148548.400000, 8192)[148548.400000] + 504096
| DEBUG: 652645.000000 = int(652644.400000)
| DEBUG: 652645 = aligned(652645)
| DEBUG: returning 652645
| DEBUG: Python function set_image_size finished
| DEBUG: Executing shell function do_image_wic
| INFO: Creating image(s)...
|
| ERROR: A native program mkfs.ext4 required to build the image was not found (see details above).
|
| Please make sure wic-tools have e2fsprogs-native in its DEPENDS, build it with 'bitbake wic-tools' and try again.
|
| WARNING: exit code 1 from a shell command.
NOTE: recipe core-image-minimal-1.0-r0: task do_image_wic: Failed
(From OE-Core rev: 59b5ec3d53058237dc6f3e85385851d1a8a97f97)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This test is failing on genericarm64 which includes all kernel
modules on rootfs by default. Recently added kernel modules
triggered the size limits to be exceeded. Fixes:
ERROR: Actual rootfs size (112884 kB) is larger than allowed size 102400 kB
Doubling the size to avoid issues like this on machines which
may include a lot of packages on default images. Size of the
rootfs does not matter for the test, only that the offsets are
correct in various usecases.
(From OE-Core rev: 1ff542318ea66514ef550d4817ba9b2ef688134c)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The wic test_exclude_path_with_extra_space does not succeed on debian-based
AB workers since they, by default, do not install the 'parted' utility. This
test installs the 'wic-tools' package, which includes the 'parted' utility,
but it is not being found/used for some unknown reason.
In the previous patch it was believed that doing some extra PATH handling
(as performed by some other tests with a python try...finally block) would
solve the issue. That turned out to not be the case. This patch starts by
reverting that change, since it has no benefit.
In order to use the native tools from the 'wic-tools' package, wic's
'--native-sysroot' can be used (as demonstrated in other tests). In fact
the wic help message explaining the purpose of this flag states that it is
for passing "...the path to the native sysroot containing the tools(parted
and mtools) to use"[sic].
Removing the host's 'parted' utility better simulates the situation found
on the debian workers for testing. This patch is seen to make this test pass
with no host 'parted' utility in place.
(From OE-Core rev: 306e4831f07d4a8db6ab880487813a6abd0ffa08)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Older versions do not compile with GCC 15. We had different versions to test
GPLv3 exclusion.
1.21 compiles with gcc 15 and 1.20.2 has a CFLAGS tweak to allow it to work
with gcc 15 too.
1.21 is licensed under GPL-2.0 so we need to rework some of the tests.
Tweak the gplv3 test by adding a special override of LICENSE to then test
the license exclusion code.
Modify the archiver selftests to use the new version.
Based on a patch from Khem Raj <raj.khem@gmail.com>
(From OE-Core rev: 3b17355ad1ecad17d12c5eb0e6403a59ef11f7d7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The wic test_exclude_path_with_extra_space test succeeds on non-debian AB
workers. Add PATH handling so parted from the wic-tools can be found on
debian-based AB workers.
Fixes [YOCTO #15838]
(From OE-Core rev: 3994e727f10c5a0143d52bdd6e1d9ca037296d59)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update the test whitespace to avoid bitbake warnings.
(From OE-Core rev: 8a324aa2111872138715bde7fbc86bcfc2d8b20e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the *.wks file contains a "--source rootfs" then
lib/wic/plugins/source/rootfs.py will be invoked to generate (what is assumed
to be) the rootfs partition. If the rootfs partition needs to be tweaked or
modified, the "rootfs.py" plugin will make a copy of the filesystem and then
perform the changes on that copy. In other words, if the "--source rootfs"
line of the *.wks file also contains any of:
--exclude-path
--include-path
--change-directory
--use-label (i.e. modify etc/fstab)
then the rootfs will be copied first, then the copy is modified.
If, for example, the unmodified IMAGE_ROOTFS is:
.../tmp/work/qemuarm64_secureboot-oe-linux/core-image-base/1.0/rootfs
then the copy would be made at:
.../tmp/work/qemuarm64_secureboot-oe-linux/core-image-base/1.0/tmp-wic/rootfs${LINENO}
where ${LINENO} is the line number where this "--source rootfs" line appears
in the *wks file.
When it comes time to make an actual partition of a specific filesystem type,
lib/wic/partition.py::prepare_rootfs() is called. It is in this function that
wic figures out if any extra size needs to be added. The bitbake variable used
to specify the ultimate rootfs size is ROOTFS_SIZE, and since this variable is
only valid for the rootfs (and not any other partitions), the code also
verifies that the partition being created is ${IMAGE_ROOTFS}:
rsize_bb = get_bitbake_var('ROOTFS_SIZE')
rdir = get_bitbake_var('IMAGE_ROOTFS')
if rsize_bb and rdir == rootfs_dir:
<use rsize_bb>
else:
<calculate the partition size using "du -ks $p">
As noted above, if lib/wic/plugins/source/rootfs.py has made a copy, then the
"rdir == rootfs_dir" clause will fail and the code will assume this partition
is not a rootfs since the strings do not compare equal.
Therefore, in order to determine if this is a rootfs, retain the existing
"rdir == rootfs_dir" comparison, but also add another one to check whether or
not this is a wic-generated copy of the rootfs.
STEPS TO REPRODUCE:
- start with the following *wks file:
bootloader --ptable gpt
part /boot --size=100M --active --fstype=ext4 --label boot
part / --source rootfs --fstype=ext4 --label root
- and the following extra variable in conf/local.conf:
IMAGE_ROOTFS_EXTRA_SPACE = "500000"
- build an image
- run it in qemu
$ runqemu slirp nographic serial
- verify the root partition has extra space:
root@qemuarm64-secureboot:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 721.5M 67.4M 600.6M 10% /
devtmpfs 477.7M 0 477.7M 0% /dev
tmpfs 40.0K 0 40.0K 0% /mnt
tmpfs 489.3M 92.0K 489.2M 0% /run
tmpfs 489.3M 68.0K 489.2M 0% /var/volatile
/dev/vda1 120.4M 19.9M 91.4M 18% /boot
- modify the "/" line of the *wks file to be:
part / --source rootfs --fstype=ext4 --label root --exclude-path boot/
- build image
when it fails:
root@qemuarm64-secureboot:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 73.4M 41.9M 25.8M 62% /
devtmpfs 477.7M 0 477.7M 0% /dev
tmpfs 40.0K 0 40.0K 0% /mnt
tmpfs 489.3M 92.0K 489.2M 0% /run
tmpfs 489.3M 68.0K 489.2M 0% /var/volatile
/dev/vda1 120.4M 19.9M 91.4M 18% /boot
after this fix:
root@qemuarm64-secureboot:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 721.5M 47.4M 620.6M 7% /
devtmpfs 477.7M 0 477.7M 0% /dev
tmpfs 40.0K 0 40.0K 0% /mnt
tmpfs 489.3M 92.0K 489.2M 0% /run
tmpfs 489.3M 68.0K 489.2M 0% /var/volatile
/dev/vda1 120.4M 19.9M 91.4M 18% /boot
Doing the math we see that the /boot partition is ~20MB and in the first image
the / partition contains this ~20MB in addition to the rest of the rootfs.
This ~20MB is completely wasted since it is used in the / partition, but then
the /boot partition is mounted on top of it, making the /boot directory of /
inaccessible. After the fix the / partition has an additional ~20MB since the
/boot portion is excluded.
Fixes [YOCTO #15555]
(From OE-Core rev: 1c690aa046ebca13d7b29de50d42b5d8a4a8486c)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upstream has released a new version (4.4) but not the tarball for it.
Adjust one of the devtool selftests, as it requires that the recipe
under test is using a tarball. Another selftest also needs to be
tweaked to correctly clean up its modifications to that same recipe on
test completion.
(From OE-Core rev: de635a9bc0392689ff36b50e7f91572d3fbaac09)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The base-files test for SPDX 2.2 did not give good coverage, since
base-files doesn't have any dependencies. Add building tar as another
test which more fully exercises the code
(From OE-Core rev: d678e25419c89e09c1c438363bf3a940ce903d43)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
cpio is not yet buildable with C23 standard which is default with
GCC 15, therefore ensure to apply needed bandage to keep it compiling
in C17 mode even with GCC 15
(From OE-Core rev: 0c637099887f1be421c8e1203f99631a1e040150)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Running, e.g., `devtool reset sdbus-c++` would result in the following
error:
re.error: multiple repeat at position 35
This was due to the ++ in the recipe name, which would be treated as an
incorrect regular expression in _reset().
Use re.escape() to make sure all characters in the recipe name are
treated literally.
(From OE-Core rev: 6e73bd9b3e6d529752db93879f2c0ed53873dd1a)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a new test function which checks that the device-tree of U-Boot
contains the public keys which are required for checking the signature
of the kernel FIT image at run-time.
Use this new _check_kernel_dtb function in the existing
test_sign_cascaded_uboot_fit_image test case which already creates a
build configuration with UBOOT_SIGN_ENABLE = "1" and keys for the kernel.
But so far there was no check that the keys for the kernel verification
got added to U-Boot's DTB.
This test case checks the configuration where only the configuration
nodes of the kernel FIT image are signed.
A new test case test_sign_uboot_kernel_individual checks the
configuration with two keys and signed image and signed configuration
nodes.
This test case covers the use case which recently broke with commit:
OE-Core rev: 259bfa86f384206f0d0a96a5b84887186c5f689e
u-boot: kernel-fitimage: Fix dependency loop if
UBOOT_SIGN_ENABLE and UBOOT_ENV enabled
and got fixed with commit
OE-Core rev: 0106e5efab99c8016836a2ab71e2327ce58a9a9d
u-boot: kernel-fitimage: Restore FIT_SIGN_INDIVIDUAL="1"
behavior
This patch also fixes a few more details:
- Simplify the code by moving all the U-Boot related variables to the
_fit_get_bb_vars function.
- Do not set FIT_GENERATE_KEYS = "1" without inheriting the
kernel-fitimage.bbclass which handles this variable.
(From OE-Core rev: dda1fcbc85c26d1851dda6ed235238b15939998e)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make the code slightly more robust by using e.g.
bb_vars.get('UBOOT_SIGN_ENABLE') instead of bb_vars['UBOOT_SIGN_ENABLE']
for variables which are potentially undefined.
This is a general cleanup but also a preparation for additional test
cases.
Log bb_vars in verbose mode.
Drop one no longer used log message.
(From OE-Core rev: 22a554e1d5a2449c4c1b34f4d5cfe1572a72a142)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The updated kmod build (using meson) causes the output which results from `info
line kmod_help` to change. Relax the regex so that both old and new reponses
will pass.
(From OE-Core rev: 8783e7b8109b02847cf3b07421582c4fdb18949c)
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Test with only one externally provided ssh key not only with two
keys generated by the kernel-fitimage.bbclass itself.
* Add a test which signs only the configuration but not the image nodes.
There was no test case which covered the probably much more important
use case of setting FIT_SIGN_INDIVIDUAL = "0".
* Cover also the unbundled initramfs use case. Also this use case is
probably much more relevant than the bundled initramnfs use case.
(From OE-Core rev: 0a5b65b83dcd9f8d1d22d074fdfad1f1e472827c)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a comprehensive cleanup of the fitImage related test cases.
The existing test cases were essentially the same code copied and pasted
9 times. All 9 test cases contained the code to parse an its file and to
parse the output of the dumpimage utility in slightly different variants.
Changing the kernel-fitimage.bbclass or the uboot-sign.bbclass would mean
changing 9 test cases individually. This is no longer maintainable.
This cleanup converts the code into reusable functions. The new test
code is more like a reverse implementation of the bbclasses to be tested
than a collection of straightforward test sequences.
This also means that the test code evaluates the same bitbake variables
as the implementation. This makes it much easier to add new test cases,
as a test case is basically just another local.conf file. The code is
not yet complete. But it can now be improved step by step in this
direction.
(From OE-Core rev: 1dfa03a182d9d9e9e38c410847c7dac4ed7e8ce6)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a trivial refactoring.
The goal is to have all tests for kernel-fitimage.bbclass and all tests
for uboot-sign.bbclass together. This refactoring greatly simplifies
the diff of the next commit.
(From OE-Core rev: 638abab58b653a1fb120368bd5e30bc80478757c)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For u-boot test cases (bitbake virtual/bootloader) inheriting the
kernel-fitimage.bbclass is no longer needed. Also setting any variable
which is evaluated by the kernel-fitimage.bbclass but not by
uboot-sign.bbclass is pointless since:
* Commit OE-Core rev: 5e12dc911d0c541f43aa6d0c046fb87e8b7c1f7e
changed the test case from
bitbake virtual/kernel
to
bitbake virtual/bootloader
* Commit OE-Core rev: 259bfa86f384206f0d0a96a5b84887186c5f689e has
finally removed the dependency of uboot-sign.bbclass on the
kernel-fitimage.bbclass completely.
Remove the related lines of code which are now without any effect.
The two test cases test_uboot_fit_image and test_uboot_sign_fit_image
do the exact same test. Both generate a binary equal its file:
/dts-v1/;
/ {
description = "A model description";
#address-cells = <1>;
images {
uboot {
description = "U-Boot image";
data = /incbin/("u-boot-nodtb.bin");
type = "standalone";
os = "u-boot";
arch = "arm";
compression = "none";
load = <0x80080000>;
entry = <0x80080000>;
};
fdt {
description = "U-Boot FDT";
data = /incbin/("u-boot.dtb");
type = "flat_dt";
arch = "arm";
compression = "none";
};
};
configurations {
default = "conf";
conf {
description = "Boot with signed U-Boot FIT";
loadables = "uboot";
fdt = "fdt";
};
};
};
The code diff between the two equal test cases looks like:
@@ -1,8 +1,9 @@
- def test_uboot_fit_image(self):
+ def test_uboot_sign_fit_image(self):
"""
Summary: Check if Uboot FIT image and Image Tree Source
(its) are built and the Image Tree Source has the
- correct fields.
+ correct fields, in the scenario where the Kernel
+ is also creating/signing it's fitImage.
Expected: 1. u-boot-fitImage and u-boot-its can be built
2. The type, load address, entrypoint address and
default values of U-boot image are correct in the
@@ -26,16 +27,15 @@
UBOOT_LOADADDRESS = "0x80080000"
UBOOT_ENTRYPOINT = "0x80080000"
UBOOT_FIT_DESC = "A model description"
-
-# Enable creation of Kernel fitImage
KERNEL_IMAGETYPES += " fitImage "
-KERNEL_CLASSES = " kernel-fitimage"
+KERNEL_CLASSES = " kernel-fitimage "
UBOOT_SIGN_ENABLE = "1"
FIT_GENERATE_KEYS = "1"
UBOOT_SIGN_KEYDIR = "${TOPDIR}/signing-keys"
UBOOT_SIGN_IMG_KEYNAME = "img-oe-selftest"
UBOOT_SIGN_KEYNAME = "cfg-oe-selftest"
FIT_SIGN_INDIVIDUAL = "1"
+UBOOT_MKIMAGE_SIGN_ARGS = "-c 'a smart U-Boot comment'"
"""
self.write_config(config)
Conclusion: The test case test_uboot_sign_fit_image looks redundant.
Contrary to its name, it does not insert any signature nodes into the
its-file and therefore does not test any type of signature.
Code history:
- Commit OE-Core rev: e71e4c617568496ae3bd6bb678f97b4f73cb43d8
introduces both test cases.
- Commit OE-Core rev: 5e12dc911d0c541f43aa6d0c046fb87e8b7c1f7e
changes both test cases like this:
- bitbake("virtual/kernel")
+ bitbake("virtual/bootloader")
It looks like the original implementation of test_uboot_sign_fit_image
was supposed to test the interaction between the kernel-fitimage.bbclass
and uboot-sign.bbclass which does not longer work like that.
When compiling u-boot, the variable that is relevant for creating an its
file with signature nodes is: SPL_SIGN_ENABLE. This is what the test
case test_sign_standalone_uboot_fit_image verifies. Lets just delete the
now obsolete test_uboot_sign_fit_image test case.
(From OE-Core rev: de8bfdff0f997f59a2bd27842a2ffcd365f725f3)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add "test_uboot_atf_tee_fit_image" test caste to check u-boot FIT image and
Image Tree Source(ITS) are built and the ITS has the correct fields.
Add "test_sign_standalone_uboot_atf_tee_fit_image" test case to check if u-boot
FIT image and Image Tree Source (ITS) are created and signed correctly for the
scenario where only the u-boot proper fitImage is being created and signed.
Currently, ATF and TEE(optee-os) recipes are placed in meta-arm layer.
OpenEmbedded-Core is a basic and core meta layer. To avoid OpenEmbedded-core
depends meta-arm, both test cases are used dummy images for testing.
(From OE-Core rev: 92e51452f8831f74e0907b960135eef8cecd012a)
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A few tests are getting failed with x86 arch.The unsupported/failing tests
are added to the exclude list and ignore the failing unit tests.
Upstream-Status: Pending
(From OE-Core rev: b1340173be2a3a91fbb135eb0e24e50c3b996425)
Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The tests don't need it. On top of that, this extra requirement
creates a dependency loop between systemd-systemctl-native and util-linux.
(From OE-Core rev: b5770d8c56036bdfef8d596d27433d8f408ee36f)
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With all the pieces in place, the self test can be re-enabled.
(From OE-Core rev: 46e8b94582ea9734117d20cd62c39fb4450c00c4)
Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 0d3901b768.
We've still having CDN issues so go back to the double attempt to
see if this improves things.
(From OE-Core rev: 136f0edb75d9601a0ae56e025419d3cddfb90219)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Introduce a new variable "OEQA_REPRODUCIBLE_TEST_LEAF_TARGETS".
It can be used like OEQA_REPRODUCIBLE_TEST_TARGET but will try to use
sstate for the dependencies.
This can be used to "quickly" test the reproducibility of a single recipe.
[YOCTO #15701]
(From OE-Core rev: e2440618bd12d7288a7f3f7cfb92d377ae61a3b4)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code line was moved in
commit 5a9a5ad6a7 ("reproducibility: continue testing in case of build failure")
(From OE-Core rev: b4b60941153ebeb5019b26eeed593d0a1cdb4012)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 'devtool' cases make a copy of 'poky', but before this patch, that
only included modifications to the 'meta/' subdirectory.
It's very frustrating to make changes to scripts/ and have them be
silently ignored by oe-selftest.
(From OE-Core rev: 35de7080c53808ade526b3b97cb54f528357deca)
Signed-off-by: Chris Laplante <chris.laplante@agilent.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adjust test_recipetool_go_create test to a smaller repository.
Combine test_recipetool_go_create and test_recipetool_go_replace_modules
tests into test_recipetool_go_create, the new test performs both tests.
(From OE-Core rev: d1256f8ff4a94d4f32b2b9ca855359dd2d691beb)
Signed-off-by: Alexander Yurkov <alexander.v.yurkov@gmail.com>
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The test code in poison was flawed: as long as one CPP/CC/CXX has fatal
poisoning enabled then the test passes. However, at the moment due to
a bad rebase only CPP has fatal poisoning and CC/CXX do not.
Rewrite the do_compile() task to more carefully check the output so the
test harness itself just has to bitbake the recipe.
Note that this results in the test failing:
ERROR: poison-1.0-r0 do_compile: C Compiler is not poisoned.
Exit status 0, output: cc1: warning: include location "/usr/include" is unsafe for cross-compilation [-Wpoison-system-directories]
ERROR: poison-1.0-r0 do_compile: C++ Compiler is not poisoned.
Exit status 0, output: cc1plus: warning: include location "/usr/include" is unsafe for cross-compilation [-Wpoison-system-directories]
(From OE-Core rev: 5b413d1fdb4bdbaec86d630bb52c3ccf68aae789)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Printed message looks like this:
2025-01-12 00:40:08,326 - oe-selftest - ERROR - reproducibleA build failed. Trying to compute built packages differences but the test will fail.
2025-01-12 00:40:08,326 - oe-selftest - INFO - Failure log for reproducibleA will be copied to <snip>/oe-reproducible-20250112-mza9w940/bitbake-reproducibleA.log
Fixes [YOCTO #15655] (first half).
(From OE-Core rev: 1c2287849a2742445d80c81d6a1c6c3e3668765e)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We want to ensure ARM nativesdk signatures match those for the 32 and 64 bit
x86 versions. Add a test to ensure this is the case.
(From OE-Core rev: dced735e2cc9663527ff8b386bf20a5e1fb9ab07)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The cve_check functionality to parse CVE IDs from the patch filename and
patch contents have been reworked to improve parsing and also utilize
tests. This ensures that the parsing works as intended.
Additionally, the new patched_cves dict has a few issues I tried to fix
as well. If multiple patch files exist for a single CVE ID, only the
last one will show up with the "resource" key. The value for the
"resource" key has been updated to hold a list and return all patch
files associated with a given CVE ID. Also, at the end of
get_patch_cves, CVE_STATUS can overwrite an existing entry in the dict.
This could cause an issue, for example, if a CVE has been addressed via
a patch, but a CVE_STATUS line also exists that ignores the given CVE
ID. A warning has been added if this ever happens.
(From OE-Core rev: 87c6da681609b4f8e048eca2a27ae8e068c724e1)
Signed-off-by: Colin McAllister <colinmca242@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows fine-tuning local configurations with pre-frabricated
configuration snippets in a structured, controlled way. It's also
an important building block for bitbake-setup.
The tool requires that each fragment contains a one-line summary, and one or more
lines of description, as BB_CONF_FRAGMENT_SUMMARY style metadata.
There are three (and a half) operations (list/enable/disable/disable all), and here's the 'list' output:
alex@Zen2:/srv/storage/alex/yocto/build-64$ bitbake-config-build list-fragments
NOTE: Starting bitbake server...
Available fragments in selftest layer located in /srv/work/alex/poky/meta-selftest:
Enabled fragments:
selftest/test-fragment This is a configuration fragment intended for testing in oe-selftest context
Unused fragments:
selftest/more-fragments-here/test-another-fragment This is a second configuration fragment intended for testing in oe-selftest context
(From OE-Core rev: fdb611e13bd7aa00360d3a68e4818ef5f05c8944)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With this release, as expected, deprecated openpgp support
has been fully removed and replaced with sequoia:
https://github.com/rpm-software-management/rpm-sequoia/
Alas, it's written in rust, and has no recipe, so for now
signing rpm packages has to be disabled.
Remove package name parameter to %prep in source archiving, as it's
been dropped in the new rpm, and wasn't needed to begin with.
Drop 0001-perl-disable-auto-reqs.patch
(files removed upstream).
(From OE-Core rev: 8c15b4577d5e554cc2dd5adfb88b816894b05a9a)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When used with `--newbuilddir` option, it replaces relative paths in
BBLAYERS variable with absolute paths by evaluating the final value of
the variable, converting paths and saving result by assignment
(`BBLAYERS =`) at the end of bblayers.conf.
This breaks tests when bblayers.conf contains BBLAYERS:append because
:append statements are evaluated after all assignments and we end up
with the appended layer added twice - first by evaluating final value
of the variable, then again by bitbake evaluating BBLAYERS:append.
The error is as follows:
AssertionError: Command 'bitbake -e' returned non-zero exit status 1:
ERROR: Found duplicated BBFILE_COLLECTIONS 'layer-name', check bblayers.conf or layer.conf to fix it.
(From OE-Core rev: 516c8e8f722ed0eb85a715a23b5e68d05abe9275)
Signed-off-by: Oleksandr Hnatiuk <ohnatiuk@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The SPDX code needs to be able to look up an Element by its SPDX ID,
locating the file that (should) contain the SPDX ID and opening it for
parsing. Previously, the code would do this be hashing each Element
SPDX ID and Alias, and the creating a symbolic link to the file that
contains the element with a name of the hash.
This worked well as it was possible to look up any arbitrary SPDX ID or
alias by simply hashing it and following the symbolic link to get the
file. However, the down side of this approach is that it creates a lot
of symbolic links, since it will make one or two per Element in the
document. This can be a problem when using SPDX_INCLUDE_SOURCES, for
example.
This change reworks this strategy so that the only Element that gets a
symbolic link based on the hash is the singular SpdxDocument that is
create for each file. All other Elements are assigned an alias with a
special prefix that encodes the hash of SpdxDocument alias. Thus, when
attempting to look up an arbitrary alias, the code sees the special
prefix, extract the hash, opens the file based on the symlink with that
hash name, then finds the matching Element in the file. This drastically
reduces the number of symbolic links by making only one per file.
This also means that the custom link extension can be removed since it
is now superfluous.
(From OE-Core rev: 838d64c09657ac53175737fc4e7fd6f01f3dcf47)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adds a test for several of the extra options provided by the SPDX
classes. In particular, these are the options that can produce
non-reproducible results, so are not enabled by default in OE core. This
test takes care to configure the build so that the tests do run in a
reproducible manner so that pre-built test objects can be pulled from
sstate
(From OE-Core rev: 14f534f15f7fe6362723d7f064d39783c5bd758f)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are several problems with these paths. Firstly they contain full
system paths which depend upon where the test was run. These are pretty
pointless and just take up a lot of space making the results files large.
Secondly, they contain the same path twice. The reference and target path
will always be the same thing in two different locations.
Strip off the prefix and remove the duplication. This does change the output
data but that can't really be avoided. It does shrink the results data and makes
it more readable.
(From OE-Core rev: 81a44de36e864b08687451fd85aeba7c529fd7f7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
