linux/poky.git/meta/lib/oeqa/targetcontrol.py, branch master-test

oeqa/targetcontrol: Attempt to fix log closure warning message

2020-07-03T19:17:29+00:00

We continue to see the warning message: WARNING: lib/bb/daemonize.py:76: ResourceWarning: unclosed file <_io.TextIOWrapper name='build/tmp/work/qemux86_64-poky-linux/oe-selftest-image/1.0-r0/testimage/qemurunner_log.20200703011821' mode='a' encoding='UTF-8'> I've been unable to reprodue this but believe its caused by garbage collection of the FileHandler used in QemuTarget being delayed until after a new tinfoil instance is created by a subseqent test. Force the log file to be closed when we stop using it to avoid this. [YOCTO #13961] (From OE-Core rev: e15cc7801ec611f867f5b31028741722ac718c87) Signed-off-by: Richard Purdie

oeqa/targetcontrol: Rework exception handling to avoid warnings

2020-06-04T12:27:31+00:00

We're seeing: WARNING: bitbake/lib/bb/cookerdata.py:136: ResourceWarning: unclosed file <_io.FileIO name='tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/testimage/qemurunner_log.20200601181912' mode='ab' closefd=True which can only be caused by the qemu.stop() method not being called. Tweak the error handling to fix the blanket exception handler which is likely meaning this function isn't getting called. (From OE-Core rev: ee707090848d793e3b2d82dd3861ae22222682c0) Signed-off-by: Richard Purdie

targetcontrol: Fix leaking log handler

2020-04-26T13:00:51+00:00

We had a mystery failure on the autobuilder where runqemu appeared to be failing as a logfile directory no longer existed. The key to reproducing was running a runqemu where the image was deleted (as devtool does), then running another runqemu test. E.g.: 'oe-selftest -r devtool.DevtoolExtractTests.test_devtool_deploy_target wic.Wic2.test_qemu_efi' This then tries to write to the logfile from the first test, the image directory was deleted and we get strange failures. The fix is to remove the logging handler when qemu is stopped. (From OE-Core rev: b59a2bbbf3c56b71f6118970ed2269dddfbdbe0c) Signed-off-by: Richard Purdie

oeqa/utils/qemurunner.py: Handle QEMU machines with a single serial

2019-11-27T13:25:18+00:00

Not all QEMU machines are capable of having more than one serial port, this is due to the machine emulating a physical device/board. Rework QemuRunner to handle machines that only have 1 serial port, where the serial port shares output of the kernel log buffer and a login console. In this case the output is mixed but enables the machine to boot and have QemuRunner detect the login prompt. QemuTarget uses SERIAL_CONSOLES to determine the number of available serial ports. (From OE-Core rev: 333897c4a00b41681ffe34312a08cae09274327e) Signed-off-by: Nathan Rossi Signed-off-by: Richard Purdie

classes/lib: Remove bb.build.FuncFailed

2019-08-06T10:24:26+00:00

Whilst seemingly a good idea, this exception doesn't really serve any purpose that bb.fatal() doesn't cover. Wrapping exceptions within exceptions isn't pythonic. Its not used in many places, lets clean up those and remove usage of it entirely. It may ultimately be dropped form bitbake entirely. (From OE-Core rev: efe87ce4b2154c6f1c591ed9d8f770c229b044ad) Signed-off-by: Richard Purdie

oeqa/targetcontrol.py: fix qemuparams not work in runqemu with launch_cmd

2019-05-15T16:53:29+00:00

As runqemu with launch_cmd means directly run the command, don't need set rootfs or env vars. Since commit [a847dd7202 runqemu: Let qemuparams override default settings] applied in oe-core, if launch_cmd contains "qemuparams='***'", it does not work, which is overridden by latter qemuparams="-serial tcp:127.0.0.1" in QemuRunner.launch(); So we set qemuparams as a parameter in runqemu, the fix makes it work (From OE-Core rev: 4f0a576fd5b9373cff4ca5ac92ec6af29499df89) Signed-off-by: Hongxu Jia Signed-off-by: Richard Purdie

meta/lib+scripts: Convert to SPDX license headers

2019-05-09T15:31:55+00:00

This adds SPDX license headers in place of the wide assortment of things currently in our script headers. We default to GPL-2.0-only except for the oeqa code where it was clearly submitted and marked as MIT on the most part or some scripts which had the "or later" GPL versioning. The patch also drops other obsolete bits of file headers where they were encoountered such as editor modelines, obsolete maintainer information or the phrase "All rights reserved" which is now obsolete and not required in copyright headers (in this case its actually confusing for licensing as all rights were not reserved). More work is needed for OE-Core but this takes care of the bulk of the scripts and meta/lib directories. The top level LICENSE files are tweaked to match the new structure and the SPDX naming. (From OE-Core rev: f8c9c511b5f1b7dbd45b77f345cb6c048ae6763e) Signed-off-by: Richard Purdie

oeqa: make it work for multiple users

2019-01-11T10:39:09+00:00

There are failures when multiple users run oe-selftest on the same host: PermissionError: [Errno 13] Permission denied: '/tmp/oe-saved- tests/201812250324_qemu' This is because /tmp/oe-saved-tests was created by user A, while user B tries to write data in it, then the error will happen. This patch can fix the problem. Move the dumped data to ${LOG_DIR}/runtime-hostdump/ rather than /tmp/oe-saved-tests/ to fix the problem. (From OE-Core rev: e219fe5329599cd6c3682f521eaee3852a2c8980) Signed-off-by: Robert Yang Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

oeqa: Fix for QEMU_USE_KVM

2019-01-08T11:16:44+00:00

Fixed: MACHINE = "qemux86" QEMU_USE_KVM = "qemux86" IMAGE_CLASSES += "testimage" $ oe-selftest -r runqemu.RunqemuTests.test_boot_rootfs [snip] File "/buildarea1/lyang1/poky/meta/lib/oe/types.py", line 122, in boolean raise ValueError("Invalid boolean value '%s'" % value) ValueError: Invalid boolean value 'qemux86' Now QEMU_USE_KVM can only be boolean, can not contain MACHINE any more, kvm will be enabled if target_arch == build_arch or both of them are x86 archs. (From OE-Core rev: 7c1a8a624cad8d967635c6cb5f99cf655bde3d44) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

oeqa/utils/qemurunner: set timeout to 60s for run_serial

2019-01-07T10:54:13+00:00

The 5s timeout for non-kvm is too short, especially when the load is high, which leads to unexpected errors, so set timeout to 60s by default. (From OE-Core rev: 8197d0f638a760fc03062c7a9009117d083d7ead) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie