linux/poky.git/meta/lib/oe/patch.py, branch mickledore-4.2.2

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

lib: Add copyright statements to files without one

2022-08-12T11:00:43+00:00

Where there isn't a copyright statement, add one to make it explicit. Also add license identifiers as MIT if there isn't one. (From OE-Core rev: bb731d1f3d2a1d50ec0aed864dbca54cf795b040) Signed-off-by: Richard Purdie

patch: handle if S points to a subdirectory of a git repo

2022-07-14T22:22:09+00:00

If PATCHTOOL = "git", SRC_URI fetches from a git repo and S points to a subdirectory of the checked out sources, then we were erroneously initialising the subdirectory as its own git repo. Check if the returned top-level repo directory is a subdirectory of WORKDIR and do not run initialise the source directory if that is the case. (This was a regression introduced with OE-Core revision 6184b56a7a0fc6f5d19fdfb81e7453667f7da940, however we didn't have a test that verified the behaviour.) (From OE-Core rev: 9cca53a2bcbf6809615ce5626c86c6ee481a7a76) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

patch.py: make sure that patches/series file exists before quilt pop

2022-05-31T14:24:18+00:00

* Since quilt upgrade to 0.67 some recipes sometimes fail in do_patch with errors like: ERROR: Applying patch 'GPLv2.patch' on target directory '/OE/build/oe-core/tmp-glibc/work/qemux86_64-oe-linux/keymaps/1.0-r31' CmdError('quilt --quiltrc /OE/build/oe-core/tmp-glibc/work/qemux86_64-oe-linux/keymaps/1.0-r31/recipe-sysroot-native/etc/quiltrc push', 0, 'stdout: stderr: File series fully applied, ends at patch GPLv2.patch ') * It affects only recipes with S = "${WORKDIR}", which wipe only ${S}/patches, because in other cases whole ${S} is wiped when do_unpack is re-executed. * It was originally added in: https://git.openembedded.org/openembedded-core/commit/?id=5fe5e6a15f26f23f0c5b863fafad7a0d382a55e2 since then it was extended to wipe whole ${S} when ${S} != ${WORKDIR} in: https://git.openembedded.org/openembedded-core/commit/?id=5fe5e6a15f26f23f0c5b863fafad7a0d382a55e2 https://git.openembedded.org/openembedded-core/commit/?id=eccae514b71394ffaed8fc45dea7942152a334a1 this is now causing issues to quilt-0.67 because it checks that ${S}/patches/series exists during 'quilt pop -a -f' which we call from QuiltTree.Clean to undo patches possibly already applied in ${S} in previous do_patch execution. * There are couple recipes affected by this e.g. keymaps (.patch already removed in oe-core), makedevs (.patch removal sent to ML yesterday https://lists.openembedded.org/g/openembedded-core/message/166172), devmem2 (https://lists.openembedded.org/g/openembedded-devel/message/97270), but there are other recipes with S = "${WORKDIR}" where you can trigger this e.g. by having a .patch file in DISTRO layer .bbappend (e.g. tzdata with webOS https://github.com/webosose/meta-webosose/blob/06e5298d9f5c47679b679081d9930f8d1c776142/meta-webos/recipes-extended/tzdata/tzdata.bbappend#L10) This do_patch issue is caused by: https://git.savannah.nongnu.org/cgit/quilt.git/commit/?id=8b39a960afcf45cd4f5804ae62b6b0656bdb191d introduced in kirkstone with: https://git.openembedded.org/openembedded-core/commit/?h=kirkstone&id=fa71afcee9ab42198c619333b77a15bd2ae02b20 The shortest sequence to reproduce this is just bitbake keymaps -c patch bitbake keymaps -c unpack -f bitbake keymaps -c patch with https://git.openembedded.org/openembedded-core/commit/?id=17d981005a0c0c97702ad88602b7181b69bcc9eb reverted. And the change in quilt behavior is causing QuiltTree.Clean (quilt pop -a -f) in: https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/patch.py?id=17d981005a0c0c97702ad88602b7181b69bcc9eb#n601 to silently fail with "No series file found" before undoing the patches in ${S} and then quilt push failing, because all the patches are _still_ applied in ${S}. Removing ".pc" doesn't help, because we really need quilt's help to undo the patches (in this case to delete COPYING file from WORKDIR before applying the .patch which tries to add it again), because do_unpack cannot just wipe S and start over (because S == WORKDIR) - nor selectively removing the files listed in SRC_URI, because COPYING file isn't listed there. Using skip_series_check in 'quilt pop' (partially reverting the change from upstream) does fix this as well and it's simple one line patch (just adding skip_series_check=1 in pop.in), but might be difficult to upstream, because it's this strange OE specific behavior that we remove 'patches' directory and then still need quilt pop to work. (From OE-Core rev: c9d36882044b1c633d8611a77df54cd68c9bee25) Signed-off-by: Martin Jansa Signed-off-by: Luca Ceresoli Signed-off-by: Richard Purdie

patch.py: Prevent git repo reinitialization

2022-02-25T12:41:23+00:00

There were few bugs in the _isInitialized() function which might trigger git repo to be reinitialized and patches failing to apply. (From OE-Core rev: 80500ecda4c1bc8812e6e078b6b0db5ec46624de) Signed-off-by: Pavel Zhukov Signed-off-by: Richard Purdie

patch.py: Initialize git repo before patching

2021-12-03T23:37:16+00:00

If PATCHTOOL="git" has been specified but workdir is not git repo bitbake fails to apply the patches with error message: Command Error: 'git rev-parse --show-toplevel' exited with 0 Output: fatal: not a git repository (or any of the parent directories): .git Fix this by initializing the repo before patching. This allows binary git patches to be applied. (From OE-Core rev: 6184b56a7a0fc6f5d19fdfb81e7453667f7da940) Signed-off-by: Pavel Zhukov Signed-off-by: Richard Purdie

lib/oe/patch.py: Ignore scissors line on applying patch

2021-02-03T21:45:49+00:00

The "devtool modify" could remove message body before scissors line, so patches re-generated from git tree were incorrectly modified. Adding --no-scissors to "git am" invocation to prevent this behaviour. [YOCTO #12674] (From OE-Core rev: 13ea33fbd197b9ee3cf913d9995617115f22798f) Signed-off-by: Tomasz Dziendzielski Signed-off-by: Richard Purdie

lib/oe/patch.py: Don't return command stderr from runcmd function

2021-01-30T10:41:04+00:00

If a function returns any stderr it will be passed to extractPatches and used as path to patch. For example subprocess command output can be: | sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8) | /tmp/oepatchhuqle8fj/0001-foo.patch | /tmp/oepatchhuqle8fj/0002-bar.patch that will result in: | FileNotFoundError: [Errno 2] No such file or directory: 'sh:' To fix this I separated output, made the function return stdout and print stderr only in case of command error. (From OE-Core rev: 482589e2cc7c3ddeefb0a0fb98d97a9cbb18c9ec) Signed-off-by: Tomasz Dziendzielski Signed-off-by: Richard Purdie

patch.py: Change to more strictly fuzz detection

2020-07-27T18:58:09+00:00

When applying patch subject is including a " fuzz ", do_patch_qa detect Fuzz. After the patch is applied, the following log message appears. Applying: meson: treat all fuzz cases as unit tests The current Fuzz detection checks for the presence of "fuzz" in this log message. The log in this example will be treated as Fuzz, despite its success. This patch change to more strictly fuzz detection. if log message is including " fuzz " and "Hunk " in log message, it will be treated as Fuzz. (From OE-Core rev: a8605c66ef5afe7c3583366781dfd90fe3526398) Signed-off-by: Naoto Yamaguchi Signed-off-by: Richard Purdie

Revert "lib/oe/patch: fix handling of patches with no header"

2020-06-04T12:27:29+00:00

* This reverts commit d9971f5dc8eb7de551fd6f5e058fd24770ef5d78. * With the missing Subject line fixed in GitApplyTree.prepareCommit() we should be able to revert, the fix which was trying to help it by parsing GitApplyTree.patch_line_prefix ("%% original patch:") also from Subject line, now GitApplyTree.patch_line_prefix should always end on separate line which is then skipped when copying the lines to resulting patch, see original commit message from Paul: lib/oe/patch: fix handling of patches with no header If a patch applied by a recipe has no header and we turn the recipe's source into a git tree (when PATCHTOOL = "git" or when using devtool extract / modify / upgrade), the commit message ends up consisting only of the original filename marker ("%% original patch: filename.patch"). When we come to do turn the commits back into a set of patches in extractPatches(), this first line ends up in the "Subject: " part of the file, but we were ignoring it because the line didn't start with the marker text. The end result was we weren't able to get the original patch name. Strip off any "Subject [PATCH x/y]" part before looking for the marker text to fix. This caused "devtool modify openssl" followed by "devtool update-recipe openssl" (without any changes in-between) to remove version-script.patch because that patch has no header and we weren't able to determine the original filename. (From OE-Core rev: d9e56db415d386447a299dd633b10f1eda0dd401) Signed-off-by: Richard Purdie