linux/poky.git/meta/lib, branch mickledore-next

oeqa ping.py: fail test if target IP address has not been set

2023-04-06T13:31:42+00:00

It is possible to call exported tests with --target-ip set to ":22" where IP address is not set at all. Detect this case and fail the test instead of calling ping without an IP address. (From OE-Core rev: 17c995c53775b8cee279ca4ced916092067e1195) Signed-off-by: Mikko Rapeli Signed-off-by: Richard Purdie

oeqa ping.py: avoid busylooping failing ping command

2023-04-06T13:31:42+00:00

Use a sleep on error path before trying again. For example when oeqa runtime tests are executed without setting target IP address correctly, the tests are drowning logs with messages: 2023-04-04 07:19:24,985 - runtime - INFO - test_ping (ping.PingTest.test_ping) ping: usage error: Destination address required ping: usage error: Destination address required ping: usage error: Destination address required ping: usage error: Destination address required ping: usage error: Destination address required ping: usage error: Destination address required ping: usage error: Destination address required ping: usage error: Destination address required ping: usage error: Destination address required ping: usage error: Destination address required ping: usage error: Destination address required ping: usage error: Destination address required ... 2023-04-04 07:19:55,002 - runtime - INFO - ... FAIL 2023-04-04 07:19:55,002 - runtime - INFO - Traceback (most recent call last): File \"/lava-62618/3/tests/3_oeqa-runtime-tests/image/lib/oeqa/runtime/cases/ping.py\", line 23, in test_ping output += proc.communicate()[0].decode('utf-8') ^^^^^^^^^^^^^^^^^^ File \"/usr/lib/python3.11/subprocess.py\", line 1194, in communicate stdout = self.stdout.read() ^^^^^^^^^^^^^^^^^^ File \"/lava-62618/3/tests/3_oeqa-runtime-tests/image/lib/oeqa/core/decorator/oetimeout.py\", line 18, in _timeoutHandler raise OEQATimeoutError(\"Timed out after %s \" oeqa.core.exception.OEQATimeoutError: Timed out after 30 seconds of execution (From OE-Core rev: 87ec75710b5cd7b3f35d886003844d62d3182b54) Signed-off-by: Mikko Rapeli Signed-off-by: Richard Purdie

selftest: efibootpartition.py: fix QEMU_USE_KVM usage

2023-04-06T13:31:42+00:00

* if you don't have QEMU_USE_KVM in local.conf it fails with: 2023-03-12 18:06:29,591 - oe-selftest - DEBUG - Checking if qemux86-64 is not this MACHINE 2023-03-12 18:06:29,594 - oe-selftest - INFO - ... ERROR 2023-03-12 18:06:29,594 - oe-selftest - INFO - Traceback (most recent call last): File "/OE/build/poky/meta/lib/oeqa/core/decorator/__init__.py", line 35, in wrapped_f return func(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^ File "/OE/build/poky/meta/lib/oeqa/selftest/cases/efibootpartition.py", line 18, in test_boot_efi if oe.types.qemu_use_kvm(self.td['QEMU_USE_KVM'], self.td["TARGET_ARCH"]): ~~~~~~~^^^^^^^^^^^^^^^^ KeyError: 'QEMU_USE_KVM' [YOCTO #12937] (From OE-Core rev: 7c32ca2f91beb98769c89470b37f06cb4b99aebb) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie

oeqa/selftest/bblogging: uncomment python stdout checks

2023-04-05T16:26:53+00:00

Since bitbake commit 81a58647b2f4fc0a2589b2978fc9d81b2bfe6aec [bitbake: build: Make python output print to stdout when running with -v (verbose)] we no longer need to comment out the python stdout checks. (From OE-Core rev: 67886a8473c511c8ab3db2e4587cc5a070979d11) Signed-off-by: Mark Asselstine Signed-off-by: Richard Purdie

oeqa/runtime: clean up deprecated backslash expansion

2023-04-03T10:39:59+00:00

(From OE-Core rev: 77085a05240c3f8226b9f2199c977f2555807789) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

selftest: runqemu: use better error message when asserts fail

2023-04-03T10:39:59+00:00

* It was showing whole log and that the runqemu command failed, but not where the log file is, nor why it thinks the runqemu failed [YOCTO #12937] (From OE-Core rev: ad4b72e6524114a3bdee10cab71f194ea143cd24) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie

selftest: runqemu: better check for ROOTFS: in the log

2023-04-03T10:39:59+00:00

* it was searching for line like this: ROOTFS: [/OE/build/poky/build/build-st-2023-03-20-esdk-runqemu-patch1/runqemu.RunqemuTests.test_boot_machine_ext4/build-st/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20230320081121.rootfs.ext4] but with IMAGE_NAME_SUFFIX changed to something else than default ".rootfs" or with my pending changes the line looks like this: ROOTFS: [/OE/build/poky/build/build-st-2023-03-20-esdk-runqemu-patch2/runqemu.RunqemuTests.test_boot_machine_ext4/build-st/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs-20230320085744.ext4] and test was failing. * Check for whole line starting with ROOTFS: and ending just with .ext4 [YOCTO #12937] (From OE-Core rev: 7a0f622f23aff2c4eeca0606e7682931eb53287a) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie

selftest: imagefeatures.py: don't mix tabs and spaces for indentation

2023-04-03T10:39:59+00:00

* introduced in: https://git.openembedded.org/openembedded-core/commit/?id=96d4486df6d870ef19e2055b026729e66bc118f3 (From OE-Core rev: 143f624116802579e7a6804c8d4b562f931880c8) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie

meta-selftest: provide a recipe for zvariant

2023-04-01T10:36:26+00:00

This recipe is for showing a "real world" example of a crate that depends on some git repositories. Usually, this kind of crate is built within a global workspace (here it is the zbus project) and so doesn't need a Cargo.lock on its own. For the sake of the demonstration, I had to tweak things a little to be able to compile zvariant in standalone (no relative path in dependency, no symlink to LICENSE provide a Cargo.lock) The use case where the crate had some git repository in dependency is very common for "private" crate that are not aimed to be published on crates.io. When the project grow bigger, it is common to have a bin and multiple lib developped in parallel, and these libs are surely on a git repostitory. A test case have been also added to check for: - the previous patch about git subpath parameter and devtool - the correctness of overriding dependencies (first patch of the series) (From OE-Core rev: 409e045f96f69877de6f36ed14c5c19a9cb74eaf) Signed-off-by: Frederic Martinsons Signed-off-by: Richard Purdie

patch: support of git patches when the source uri contained subpath parameter

2023-04-01T10:36:26+00:00

This is for a specific case where: - A recipe use a subpath on a git repo (e.g. git://repo.git/projects;subpath=subproject) - The recipe contains a patch to apply - a devtool modify is used on this recipe With these conditions, the patch cannot be applied at all. GitApplyTree class is used for handling patch under devtool, but when subpath is present in SRC_URI, the resulting git tree is dirty (every files and directories which was not in subpath are suppressed) and so "git am" refuse to apply patches. That would not be an issue since the GitApplyTree have a fallback to PatchTree in case of error, but during this error management, there is a "git reset --hard HEAD" call which suppress the subpath operation and finally prevents the patch to be applied even with PatchTree. When devtool is not involved, only PatchTree class is used and the above problem is irrelevant. To support git patching during devtool, the presence of subpath and the dirtyness of the repo are checked. If both conditions are met, we directly call PatchTree like it was already done in case of error during git apply. (From OE-Core rev: d86cac2759cf7e91f4ff240833385e28e729ab79) Signed-off-by: Frederic Martinsons Signed-off-by: Richard Purdie