linux/poky.git/scripts/lib/devtool, branch styhead-5.1.1

devtool: remove obsolete SRCTREECOVEREDTASKS handling

2024-09-04T11:38:44+00:00

devtool modify generates a bbappend for kernel recipes which contains: SRCTREECOVEREDTASKS="\ do_fetch \ do_kernel_checkout \ do_kernel_configcheck \ do_unpack \ do_validate_branches \ " do_patch[noexec] = "1" If the linux-yocto kernel is used, this is redundant. The linux-yocto.bbclass already does the same: linux-yocto sets SRCTREECOVEREDTASKS to SRCTREECOVEREDTASKS="\ do_fetch \ do_kernel_checkout \ do_kernel_configcheck \ do_patch \ do_unpack \ do_validate_branches \ " Also the do_patch[noexec] is redundant because the purpose of SRCTREECOVEREDTASKS is to delete these tasks if the externalsrc.bbclass is used. The default value of SRCTREECOVEREDTASKS initialized in externalsrc.bbclass is: SRCTREECOVEREDTASKS ?= "do_patch do_unpack do_fetch" This is fine for kernels which do not inherit the linux-yocto.bbclass. The code in devtool modify is redundant and therefore removed. (From OE-Core rev: 94ff1be36a1eeef7ddceb4fcf20425a03cd052de) Signed-off-by: Adrian Freihofer Signed-off-by: Richard Purdie

devtool: modify kernel adds append twice

2024-09-04T11:38:44+00:00

Drop the redundant generation of the do_configure:append section for the kernel. The same append is generated twice: if bb.data.inherits_class('kernel', rd): f.write('\ndo_configure:append() {\n' ' cp ${B}/.config ${S}/.config.baseline\n' ' ln -sfT ${B}/.config ${S}/.config.new\n' '}\n') KCONFIG_CONFIG_ENABLE_MENUCONFIG ??= "true" KCONFIG_CONFIG_ROOTDIR ??= "${B}" if rd.getVarFlag('do_menuconfig', 'task'): f.write('\ndo_configure:append() {\n' ' if [ ${@oe.types.boolean(d.getVar("KCONFIG_CONFIG_ENABLE_MENUCONFIG"))} = True ]; then\n' ' cp ${KCONFIG_CONFIG_ROOTDIR}/.config ${S}/.config.baseline\n' ' ln -sfT ${KCONFIG_CONFIG_ROOTDIR}/.config ${S}/.config.new\n' ' fi\n' '}\n') In contradiction to the first code block the second code block considers the variables which is correct. (From OE-Core rev: b0733c440e861ed7bf70efdd9b7a73afb4701218) Signed-off-by: Adrian Freihofer Signed-off-by: Richard Purdie

devtool/upgrade: rename RECIPE_UPDATE_EXTRA_TASKS -> RECIPE_UPGRADE_EXTRA_TASKS

2024-08-03T06:56:10+00:00

'UPDATE' as a name is somewhat unfortunate as the variable is intended only for the 'devtool upgrade' operation and devtool also has an 'update-recipe' operation. (From OE-Core rev: 4467aa0661e233f44c4ce029428c67d88fccfc07) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

devtool/upgrade: use PN instead of BPN for naming newly created upgraded recipes

2024-07-22T15:53:06+00:00

BPN isn't correct, as it is set to 'cmake' when 'cmake-native' is being upgraded (or libva for libva-initial etc.) (From OE-Core rev: e634316547f86ce5662fa4899440a5af1047d494) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

recipeutils/get_recipe_upgrade_status: group recipes when they need to be upgraded together

2024-07-22T15:53:06+00:00

This will allow 'lockstep upgrades' of such recipes, improving success rates in automated version updating process. devtool check-upgrade-status now prints: These recipes need to be upgraded together { glib-2.0 2.80.2 2.80.4 Anuj Mittal glib-2.0-initial 2.80.2 2.80.4 Anuj Mittal } These recipes need to be upgraded together { util-linux 2.39.3 2.40.2 Chen Qi util-linux-libuuid 2.39.3 2.40.2 Chen Qi } These recipes need to be upgraded together { cmake 3.29.3 3.30.0 Unassigned cmake-native 3.29.3 3.30.0 Unassigned } etc. (From OE-Core rev: 7874aea5c62be3e8dbd19e04fce5389c5ed7aab6) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

lib/oe/recipeutils: return a dict in get_recipe_upgrade_status() instead of a tuple

2024-07-22T15:53:06+00:00

Putting various things in a tuple is an anti-pattern of sorts, as the consumers have to unpack it into local variables for readability, or access items directly with indexes, which makes code pretty much unreadable. (From OE-Core rev: e86aa26d209eb9809198f6dd40cd058366318e3d) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

devtool upgrade: enable RECIPE_UPDATE_EXTRA_TASKS

2024-06-13T08:11:17+00:00

For some recipes, such as those that inherit cargo-update-recipe-crates, we need to run additional tasks once the new sources have been unpacked. Introduce a new variable RECIPE_UPDATE_EXTRA_TASKS which is a space- delimited list of tasks to run after the new sources have been unpacked in scripts/lib/devtool/upgrade.py ugrade() method. (From OE-Core rev: 59894f3b5b0bc257837d7ce4ea684f1d8c382cec) Signed-off-by: Tim Orling Signed-off-by: Richard Purdie

recipetool/devtool: Update to work correctly with UNPACKDIR

2024-05-22T21:26:30+00:00

Tweak recipetool and devtool to correctly use UNPACKDIR. This allows some simplification of the code. This patch makes things basically work but there are likely deeper improvements that can be made now that WORKDIR != UNPACKDIR. (From OE-Core rev: d2eeaa88b27a2875c419591d1d91bcc85d7b129c) Signed-off-by: Richard Purdie

devtool: Drop oe-local-files and simplify

2024-05-21T11:08:04+00:00

The only real reason for oe-local-files was to support S = WORKDIR. With changes to drop support for that, it makes sense to simplify devtool and to try and make both the code and the processes/workflows simpler. This patch drops support for S = WORKDIR, removes oe-local-files and then updates the test cases to match this new situation. At the code level, we assume we can always now track code changes using git and that things committed into git are handled as patches (as before) but delta against HEAD is saved as specific file level changes to the recipe. One test is disabled as it is no longer approproate. It is being keped until we can make WORKDIR != UNPACKDIR at which point it should be revisited. (From OE-Core rev: ce8190c519052fed10b5233697b69a75868db45a) Signed-off-by: Richard Purdie

devtool: modify: Catch git submodule error for go code

2024-05-15T15:39:19+00:00

One of the git submodule commands failed for source extracted for recipes using go.bbclass. The root cause is probably the path set up by go_do_unpack which makes S and gitroot not match. This patch does not fix the root problem, but at least it is no worse than before the git submodule support. The extracted source will still have two .git folders, one in S created by devtool and one in the go path which will contain the tru git history. [ YOCTO #15483 ] (From OE-Core rev: fe242408af40dd1f6e47d9b2b232bdc76756c80a) Signed-off-by: Anton Almqvist Signed-off-by: Ola x Nilsson Signed-off-by: Richard Purdie