linux/poky.git/scripts/lib/devtool, branch 4.3_M3

build-sysroots: target or native sysroot population need to be selected explicitly

2023-09-09T11:04:55+00:00

Running them in parallel is prone to races as postinsts from target sysroots rely on executables from native sysroots which may or may not be fully prepared yet. This was observed for example here: https://autobuilder.yoctoproject.org/typhoon/#/builders/146/builds/468/steps/12/logs/stdio https://autobuilder.yoctoproject.org/typhoon/#/builders/147/builds/467/steps/12/logs/stdio (From OE-Core rev: 38d7a2e45b883cf999a86af05bcc0eaa875bb47c) Signed-off-by: Alexander Kanavin Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

devtool/upgrade: raise an error if extracting source produces more than one directory

2023-08-04T10:44:28+00:00

This can happen if running unpack task produces unrelated files and directories (e.g. if recipe_qa or other tasks run); in this case it's better to stop, rather than allow devtool to continue and error out much later with a message that has nothing to do with where the problem originated. The idea here was to handle tarballs that don't contain a top level directory and thus the source tree is one level up; this basically never happens, and if it does we should find a less brittle way to handle such tarballs. (From OE-Core rev: b25e922b271794906b22450c7e6cc18fcab51ff8) Signed-off-by: Alexander Kanavin Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

devtool: do not run recipe_qa task when extracting source

2023-07-30T08:16:52+00:00

The immediate reason is that the task is sstate enabled, and due to the way devtool sets up source extraction this causes bogus values to appear in tmp/sstate-control/index-* files. Also, recipe_qa may contain hard failures in the future, and it would be counterproductive for the failures to prevent devtool workflows (which may perhaps be about fixing the failure). An alternative would have been to not insert recipe_qa task before fetch task, but that would greatly delay the checks in larger bitbake builds, and it's better to run them as early as possible. (From OE-Core rev: 6f9db3f8de3dca9b0c87382561c70857d5b39e0f) Signed-off-by: Alexander Kanavin Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

devtool: Fix the wrong variable in srcuri_entry

2023-06-15T08:53:38+00:00

devtool crashes when running "update-recipe" and append changes on the recipe. "$ devtool update-recipe -a " Traceback (most recent call last): ... File "/ovss/ovss_quanta/poky/scripts/lib/devtool/standard.py", line 1636, in srcuri_entry return 'file://%s%s' % (basepath, paramstr) ^^^^^^^^ NameError: cannot access free variable 'basepath' where it is not associated with a value in enclosing scope The input variable 'fname' should have the same meaning as the variable 'basepath'. Modify the 'fname' to 'basepath' and solve the issue. (From OE-Core rev: c3231756bbc2cb5641204414ad3670d7f8607ed3) Signed-off-by: Charlie Wu Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

meta: introduce KCONFIG_CONFIG_ENABLE_MENUCONFIG

2023-06-09T12:55:21+00:00

Currently, uboot do_menuconfig task is breaking when UBOOT_CONFIG is chosen rather than UBOOT_MACHINE, it simply fails with the following errors: | make: *** No rule to make target 'menuconfig'. Stio. | Command failed. | Press any key to continue... this is due to the work directory of do_menuconfig is set to ${B} but not ${B}/$config. We should distinguish two situations: 1) When there is only one config item in UBOOT_CONFIG, do_menuconfig should work just like how it works for UBOOT_MACHINE. 2) When there are multiple config items in UBOOT_CONFIG, do_menuconfig should print out some information saying it's not supported other than just failing. This patch mainly aims to fix that by introducing a extra variable KCONFIG_CONFIG_ENABLE_MENUCONFIG, it would be set to 'false' for situation 2), and when it's set to 'true', then set KCONFIG_CONFIG_ROOTDIR correctly in uboot-config.bbclass to let do_menuconfig task work. DEVTOOL_DISABLE_MENUCONFIG could be replaced by this new variable KCONFIG_CONFIG_ENABLE_MENUCONFIG. (From OE-Core rev: f9e834e317880cf47dbb4f8285bc36d743beae5e) Signed-off-by: Ming Liu Signed-off-by: Richard Purdie

devtool/upgrade: do not delete the workspace/recipes directory

2023-03-14T17:10:00+00:00

If it exists, there is no need to delete it, and if it does not, devtool prints an ugly traceback. (From OE-Core rev: af82e59e8f08369aabd5fa6eb43022982d4e59a7) Signed-off-by: Alexander Kanavin Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

devtool: ignore patch-fuzz errors when extracting source

2023-02-24T13:31:45+00:00

So that patch fuzz issues can actually be fixed, as extracting source with 'devtool modify' is the first step for that. (From OE-Core rev: 7067abd31d9dd4b98ec70c1c7effbe2904797cd1) Signed-off-by: Alexander Kanavin Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

meta: remove True option to getVar and getVarFlag calls (again)

2023-02-02T09:50:02+00:00

* True is default since 2016 and most layers were already updated not to pass this parameter where not necessary, e.g. oe-core was updated couple times, first in: https://git.openembedded.org/openembedded-core/commit/?id=7c552996597faaee2fbee185b250c0ee30ea3b5f Updated with the same regexp as later oe-core update: https://git.openembedded.org/openembedded-core/commit/?id=9f551d588693328e4d99d33be94f26684eafcaba with small modification to replace not only d.getVar, but also data.getVar as in e.g.: e.data.getVar('ERR_REPORT_USERNAME', True) and for getVarFlag: sed -e 's|$d\.getVarFlag \?$( \?$[^,()]*, \?[^,()]*$, \?True)|\1(\2)|g' \ -i $(git grep -E 'getVarFlag ?$ ?([^,()]*), ?([^,()]*), ?True$' \ | cut -d':' -f1 \ | sort -u) (From OE-Core rev: 26c74fd10614582e177437608908eb43688ab510) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie

devtool: process local files only for the main branch

2022-12-31T17:10:21+00:00

devtool modify/upgrade are not currently equipped to handle conditional local files in SRC_URI, and provide only the main no-override set in a workspace under source/component/oe-local-files/ (this is done via meta/classes/devtool-source.bbclass). On the other hand, updating the changes from workspace into a recipe is run iteratively against all overrides; this works for patches (as they all are directed into their own override branches in the workspace git source tree), but breaks down when trying to match local files in a workspace against local files in overridden SRC_URI lists, resulting in bad recipe breakage. (there's an additional twist here: existing code has a guard against this but the guard relies on metadata in workspace .bbappend that is only there in modify operations, but not upgrades. This commit replaces the guard with a general check that will work everywhere). Implementing multiple sets of local files is significant work; let's for now simply not touch local files in recipes except when on the no-override variant. Also, adjust the selftest cases to include conditional local files in sample recipes, so the situation is covered by the tests. (From OE-Core rev: 3a8654b860fa98f94e80c3c3fff359ffed14bbe7) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

devtool/upgrade: correctly handle recipes where S is a subdir of upstream tree

2022-12-18T19:48:00+00:00

'devtool modify' writes additional settings to workspace .bbappend so that this can be handled correctly, but 'devtool upgrade' does not. This adds the missing settings. In particular, local files should not anymore mysteriously disappear from SRC_URIs on upgrades. (From OE-Core rev: 0817aa5537a8d7cc9591c53dfaa1d225f4c327f7) Signed-off-by: Alexander Kanavin Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie