linux/poky.git/scripts/lib/devtool/upgrade.py, branch 5.2_M1

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

lib/oe/patch: Use git notes to store the filenames for the patches

2024-02-19T16:03:22+00:00

The old way of keeping track of the filenames for the patches that correspond to the commits was to add a special comment line to the end of the commit message, e.g., "%% original patch: ", using a temporary git hook. This method had some drawbacks, e.g.: * It caused problems if one wanted to push the commits upstream as the comment line had to be manually removed. * The comment line would end up in patches if someone used git format-path rather than devtool finish to generate the patches. * The comment line could interfere with global Git hooks used to validate the format of the Git commit message. * When regenerating patches with `devtool finish --force-patch-refresh`, the process typically resulted in adding empty lines to the end of the commit messages in the updated patches. A better way of keeping track of the patch filenames is to use Git notes. This way the commit messages remain unaffected, but the information is still shown when, e.g., doing `git log`. A special Git notes space, refs/notes/devtool, is used to not intefere with the default Git notes. It is configured to be shown in, e.g., `git log` and to survive rewrites (i.e., `git commit --amend` and `git rebase`). Since there is no longer any need for a temporary Git hook, the code that manipulated the .git/hooks directory has also been removed. To avoid potential problems due to global Git hooks, --no-verify was added to the `git commit` command. To not cause troubles for those who have done `devtool modify` for a recipe with the old solution and then do `devtool finish` with the new solution, the code will fall back to look for the old strings in the commit message if no Git note can be found. While not technically motivated like above, the way to keep track of ignored commits is also changed to use Git notes to avoid having different methods to store similar information. (From OE-Core rev: f5e6183b9557477bef74024a587de0bfcc2b7c0d) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie

devtool: use straight print in check-upgrade-status output

2024-01-02T22:51:01+00:00

'devtool check-upgrade-status' is for reporting upgradable status for recipes. The output should always be printed out. So we should just use 'print' instead of 'logger.info' as the latter will be suppressed if '-q' parameter is supplied to devtool. (From OE-Core rev: 2c7bf9c8a833bec13a1ebabdce30933cbe691108) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie

devtool: upgrade: Update all existing checksums for the SRC_URI

2023-12-08T16:58:34+00:00

In addition to updating the sha256sum and removing the md5sum, update all other existing checksums. If the only existing checksum is md5sum, then replace it with the default expected checksums (currently only sha256sum). (From OE-Core rev: 8ea8827ee49b7f0443b1c4bd47d1344a689d73a3) Signed-off-by: Peter Kjellerstedt Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

devtool: add support for git submodules

2023-12-01T11:48:25+00:00

Adding the support of submodules required a lot of changes on the internal data structures: * initial_rev/startcommit used as a starting point for looking at new / updated commits was replaced by a dictionary where the keys are the submodule name ("." for main repo) and the values are the initial_rev/startcommit * the extractPatches function now extracts patch for the main repo and for all submodules and stores them in a hierarchical way describing the submodule path * store initial_rev/commit also for all submodules inside the recipe bbappend file * _export_patches now returns dictionaries that contains the 'patchdir' parameter (if any). This parameter is used to add the correct 'patchdir=' parameter on the recipe Also, recipe can extract a secondary git tree inside the workdir. By default, at the end of the do_patch function, there is a hook in devtool that commits everything that was modified to have a clean repository. It uses the command: "git add .; git commit ..." The issue here is that, it adds the secondary git tree as a submodule but in a wrong way. Doing "git add " declares a submodule but do not adds a url associated to it, and all following "git submodule foreach" commands will fail. So detect that a git tree was extracted inside S and correctly add it using "git submodule add ", so that it will be considered as a regular git submodule (From OE-Core rev: 900129cbdf25297a42ab5dbd02d1adbea405c935) Signed-off-by: Julien Stephan Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie