linux/poky.git/bitbake/lib/bb/tests, branch nanbield

bitbake: selftest/fetch: Ensure top level directory timestamp doesn't break test

2023-10-06T10:42:46+00:00

The infrastructure changes highlighed an issue where the top level directory mtime stamp isn't included in the tarballs. This isn't an issue the test is meant to check for so ignore it. (Bitbake rev: 5a1e5b8dc55d6bb4d93bac3492f8c43ff957e712) Signed-off-by: Richard Purdie

bitbake: data: Add missing dependency handling of remove operator

2023-09-20T07:57:41+00:00

A recipe variable handles its dependencies even on the "contains" variables within the "inline Python expressions" like bb.utils.filter(). And it also handles those in the append operator correctly, but the problem is that it does not so in the remove operator. Fix it by adding the missing dependencies every time the remove operator has been handled. Also add a test case to check if the override operators handle dependencies correctly. (Bitbake rev: b90520eedb1dbc7f6a3928d089fe74fafb864eb5) Signed-off-by: Insu Park Signed-off-by: Richard Purdie

bitbake: siggen: Improve runtaskdeps data to fix sstate debugging

2023-08-09T12:23:33+00:00

The runtaskdep data in siginfo files was written out with full paths to the bb files, matching bitbake's internal "unique key" ID for recipes/tasks. When originally implemented this made sense. Over time, the main use for the data in siginfo files has become to match against other siginfo files to debug changes of hash calcuations. The recipename data is not useful for this as the siginfo filenames use PN instead which can often be derived from the recipe filename but not always. It is time to throw away the 'tid' data format and switch over the use a hybrid PN form which includes the multiconfig. That can be easily stripped off in the find_siginfo code in oe-core. The other purpose of having a sortable dependency ID is retained and the multiconfig needs to be included to allow the taskhashes to be processed and calculated correctly. PN is meant to be unique between recipes, only one would ever be built so using PN in this location is fine. The one risk of this change is there isn't any compatibility to the old format. I'm not convinced we should spend time complicating the code with it. This change will change the taskhashes everywhere so the only mixing of old and new siginfo files will be either through hash equivalence or through users using the tool against old and new info files manually which will give some weird output but it should be clear they're in different formats as there would be large paths from the old files not present in the new ones. We have options to add backwards compatibility if some issue is found to need that. (Bitbake rev: 637933e2e5a59228a8d17aae4160551cab5f2f61) Signed-off-by: Richard Purdie

bitbake: bb.tests.data: don't require the func flag for context functions

2023-08-04T10:37:56+00:00

Update test_python_snippet_function_reference to not require the 'func' flag, now that we know the real function will be returned for context functions without the flag. (Bitbake rev: 83f41281ec3d9b4327ffc8e2312e1fb8f53cbf02) Signed-off-by: Christopher Larson Signed-off-by: Richard Purdie

bitbake: tests.data: add test for builtin preferred over metadata value

2023-08-04T10:37:56+00:00

This test makes sure that '${@eval()}' calls the eval builtin, even if an 'eval' variable is defined in the metadata. (Bitbake rev: e9150447738a48f772240874b3512b08e982b19b) Signed-off-by: Christopher Larson Signed-off-by: Richard Purdie

bitbake: tests.codeparser: add test for exec of builtin from inline python

2023-08-04T10:37:55+00:00

This ensures that any change to the presence of builtins in inline python execs will be noticed. (Bitbake rev: ee22d3d51c60db2da97422b2be1e42239b7a2324) Signed-off-by: Christopher Larson Signed-off-by: Richard Purdie

bitbake: tests.data: add test for inline python calling a def'd function

2023-08-04T10:37:55+00:00

This is a test for an issue seen long ago, to avoid regressions, where a reference to a def'd function in the metadata would return the string value from the metadata rather than the function in inline python. (Bitbake rev: 9f7cb22febd557817c164e25a93f5660e9c06358) Signed-off-by: Christopher Larson Signed-off-by: Richard Purdie

bitbake: fetch2: Set maxsplit to match expected variables

2023-07-27T20:09:14+00:00

Set the maxsplit value to match the expected number of variables. This also avoids an unnecessary split as the parameters are in the form 'key=value' and the 'value' could contain the '=' character. (Bitbake rev: 3b17a7ed9bf6cd2808946c2d9c3ed9961af11f19) Signed-off-by: Dit Kozmaj Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

bitbake: bitbake: tests: Use assertLogs to test logging output

2023-06-27T14:28:56+00:00

By default, pytest captures all stdout and exposes it using its built-in fixtures (capsys, caplog etc), so stdout does not support getvalue(). To support running tests using both unittest and pytest, use assertLogs to capture logging and assert on the log output instead. (Bitbake rev: 2d28caa01bab9540d2bbaf713ae3e5c563d003f5) Signed-off-by: Peter Hoyes Signed-off-by: Richard Purdie

bitbake: bitbake: tests/fetch: Set git config if not already set

2023-06-27T14:28:56+00:00

git config returns an error code if user.email or user.name are not set, so bb.process.run raises an ExecutionError, failing the test. Improve the logic by catching the ExectionError and using this to set a default value. Change a direct invocation of 'git init' to use self.git_init so that it follows the code path above. Remove the related comment from the README now that git sets up the user details automatically. (Bitbake rev: 0c7079d0609a13713b890a9675abd9fba032f199) Signed-off-by: Peter Hoyes Signed-off-by: Richard Purdie