linux/poky.git/meta/lib/oe/patch.py, branch yocto-5.0.14

patch.py: set commituser and commitemail for addNote

2025-04-16T13:41:24+00:00

When PATCHTOOL is set to 'git', and user don't setup user.name and user.email for git, do_patch fail with the following error, fix by passing -c options. CmdError("git notes --ref refs/notes/devtool append -m 'original patch: 0001-PATCH-increase-to-cpp17-version.patch' HEAD", 0, 'stdout: stderr: Author identity unknown *** Please tell me who you are. Run git config --global user.email "you@example.com" git config --global user.name "Your Name" (From OE-Core rev: 9de38ac99c2b19f549c00ea5277faf621c6f4e65) Signed-off-by: Changqing Li Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

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

lib/oe/patch: Add GitApplyTree.commitIgnored()

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

This function can be used to create a commit that devtool will ignore when creating/updating the patches. (From OE-Core rev: 94f0838b9223b7ece7affaa707e54a5d784da25e) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie

lib/oe/patch: Make extractPatches() not extract ignored commits

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

If a commit is marked with "%% ignore" it means it is used by devtool to keep track of changes to the source code that are not the result of running do_patch(). These changes need to actually be ignored when extracting the patches as they typically make no sense as actual patches in a recipe. This also adds a new test for oe-selftest that verifies that there are no patches generated from ignored commits. (From OE-Core rev: c3d43de7e54189bf09fbe8e87ddb976e42ebf531) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie

lib/oe/patch: handle creating patches for CRLF sources

2023-12-06T22:55:49+00:00

Using devtool to patch CRLF based sources creates patch files which have mixed end of lines : LF for headers and CRLF for source context and modified lines. Python open(..., newline=None) (default for newline arg)does detect end-of-line in this mixed file but only outputs LF EOL data. This result in patch files that does not apply on the original sources. Switching to open(..., newline='') allows to detect end-of-line but keep the original end-of-line intact. This generate correct patches for CRLF based sources. Fixes [YOCTO #15285] (From OE-Core rev: 58f845499c0277a2b8069eefa235430b5f5f7661) Signed-off-by: Yoann Congal 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

lib/oe/patch: ensure os.chdir restoring always happens

2023-11-22T14:08:48+00:00

If we chdir(), do the chdir back to the original directory in a finally block so they always run. (From OE-Core rev: cdc40292818683b6df1c814498c7589450a163fa) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

patch.py: use --absolute-git-dir instead of --show-toplevel to retrieve gitdir

2023-08-29T08:41:07+00:00

[YOCTO #14141] Currently the gitdir is manually constructed using `git rev-parse --show-toplevel` and appending `.git`. This is most of the time correct but not always: `.git` can be a file with the following content: gitdir: This is the case for submodules, so when using devtool modify on a recipe using submodules *and* patching files inside one of the submodules, do_patch fails with the following error: ERROR: Error executing a python function in exec_func_python() autogenerated: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_func_python() autogenerated', lineno: 2, function: 0001: *** 0002:patch_do_patch(d) 0003: File: '<..>/poky/meta/classes-global/patch.bbclass', lineno: 157, function: patch_do_patch 0153: except Exception as exc: 0154: bb.utils.remove(process_tmpdir, True) 0155: bb.fatal("Importing patch '%s' with striplevel '%s'\n%s" % (parm['patchname'], parm['striplevel'], repr(exc).replace("\\n", "\n"))) 0156: try: *** 0157: resolver.Resolve() 0158: except bb.BBHandledException as e: 0159: bb.utils.remove(process_tmpdir, True) 0160: bb.fatal("Applying patch '%s' on target directory '%s'\n%s" % (parm['patchname'], patchdir, repr(e).replace("\\n", "\n"))) 0161: File: '<..>/poky/meta/lib/oe/patch.py', lineno: 769, function: Resolve 0765: def Resolve(self): 0766: olddir = os.path.abspath(os.curdir) 0767: os.chdir(self.patchset.dir) 0768: try: *** 0769: self.patchset.Push() 0770: except Exception: 0771: import sys 0772: os.chdir(olddir) 0773: raise File: '<..>/poky/meta/lib/oe/patch.py', lineno: 274, function: Push 0270: else: 0271: next = 0 0272: 0273: bb.note("applying patch %s" % self.patches[next]) *** 0274: ret = self._applypatch(self.patches[next], force) 0275: 0276: self._current = next 0277: return ret 0278: File: '<..>/poky/meta/lib/oe/patch.py', lineno: 556, function: _applypatch 0552: if os.path.lexists(hooks_dir_backup): 0553: raise Exception("Git hooks backup directory already exists: %s" % hooks_dir_backup) 0554: if os.path.lexists(hooks_dir): 0555: shutil.move(hooks_dir, hooks_dir_backup) *** 0556: os.mkdir(hooks_dir) 0557: commithook = os.path.join(hooks_dir, 'commit-msg') 0558: applyhook = os.path.join(hooks_dir, 'applypatch-msg') 0559: with open(commithook, 'w') as f: 0560: # NOTE: the formatting here is significant; if you change it you'll also need to Exception: NotADirectoryError: [Errno 20] Not a directory: '<..>/build/tmp/work/core2-64-poky-linux/vulkan-samples/git/devtooltmp-n87_zx1i/workdir/git/third_party/spdlog/.git/hooks' Using `git rev-parse --absolute-git-dir` instead of `git rev-parse --show-toplevel` ensure we get the correct gitdir (From OE-Core rev: f74879dd95b19504ce8a8554636d2310d0336806) Signed-off-by: Julien Stephan Signed-off-by: Luca Ceresoli Signed-off-by: Richard Purdie

patch.py: Use shlex instead of deprecated pipe

2023-04-14T15:44:24+00:00

The pipe library is deprecated in Python 3.11 and will be removed in Python 3.13. pipe.quote is just an import of shlex.quote anyway. Clean up imports while we're at it. (From OE-Core rev: 5f33c7b99a991c380d1813da8248ba5470ca4d4e) Signed-off-by: Ola x Nilsson Signed-off-by: Luca Ceresoli Signed-off-by: Richard Purdie

patch: support of git patches when the source uri contained subpath parameter

2023-04-01T10:36:26+00:00

This is for a specific case where: - A recipe use a subpath on a git repo (e.g. git://repo.git/projects;subpath=subproject) - The recipe contains a patch to apply - a devtool modify is used on this recipe With these conditions, the patch cannot be applied at all. GitApplyTree class is used for handling patch under devtool, but when subpath is present in SRC_URI, the resulting git tree is dirty (every files and directories which was not in subpath are suppressed) and so "git am" refuse to apply patches. That would not be an issue since the GitApplyTree have a fallback to PatchTree in case of error, but during this error management, there is a "git reset --hard HEAD" call which suppress the subpath operation and finally prevents the patch to be applied even with PatchTree. When devtool is not involved, only PatchTree class is used and the above problem is irrelevant. To support git patching during devtool, the presence of subpath and the dirtyness of the repo are checked. If both conditions are met, we directly call PatchTree like it was already done in case of error during git apply. (From OE-Core rev: d86cac2759cf7e91f4ff240833385e28e729ab79) Signed-off-by: Frederic Martinsons Signed-off-by: Richard Purdie