linux/poky.git/meta/lib/oe/patch.py, branch warrior-next

meta/lib+scripts: Convert to SPDX license headers

2019-06-18T10:28:58+00:00

This adds SPDX license headers in place of the wide assortment of things currently in our script headers. We default to GPL-2.0-only except for the oeqa code where it was clearly submitted and marked as MIT on the most part or some scripts which had the "or later" GPL versioning. The patch also drops other obsolete bits of file headers where they were encoountered such as editor modelines, obsolete maintainer information or the phrase "All rights reserved" which is now obsolete and not required in copyright headers (in this case its actually confusing for licensing as all rights were not reserved). More work is needed for OE-Core but this takes care of the bulk of the scripts and meta/lib directories. The top level LICENSE files are tweaked to match the new structure and the SPDX naming. (From OE-Core rev: 3248a9e3c5a197321b1c4417509b9309cc3bae97) Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

patch/insane: Rework patch fuzz handling

2019-04-09T12:44:39+00:00

Currently there are three issues which can be enhanced: 1. Fuzz warnings cannot be configured as errors for hardening. It happened often to me that these warnings were overseen and detected after commits were already out. 2. The output is too verbose - particularly when more than one file is affected. Meanwhile all users should know why patch fuzz check is performed. So move links with background information to insane.bbclass. 3. Reduce copy & paste effort slightly by printing PN (nit: was not a correct suggestion e.g for native extended recipe - see example below) To achieve patch.py drops patch-fuzz info encapsulated by a header- and footer- string into log.do_patch. With this insane.bbclass can drop warnings/errors depending on 'patch-fuzz' in ERROR_QA or WARN_QA. Default remains unchanged: Spit out warnings only. A message for two fuzzed patches and 'pact-fuzz' in ERROR_QA now looks like: | ERROR: autoconf-native-2.69-r11 do_patch: Fuzz detected: | | Applying patch autoreconf-exclude.patch | patching file bin/autoreconf.in | Hunk #1 succeeded at 73 with fuzz 1 (offset -3 lines). | Hunk #2 succeeded at 143 (offset 6 lines). | Hunk #3 succeeded at 167 (offset 6 lines). | Hunk #4 succeeded at 177 (offset 6 lines). | Hunk #5 succeeded at 281 (offset 15 lines). | Hunk #6 succeeded at 399 (offset 15 lines). | Hunk #7 succeeded at 571 (offset 20 lines). | Hunk #8 succeeded at 612 (offset 20 lines). | Hunk #9 succeeded at 636 (offset 20 lines). | Hunk #10 succeeded at 656 (offset 20 lines). | Hunk #11 succeeded at 683 (offset 20 lines). | | Applying patch autoreconf-gnuconfigize.patch | patching file bin/autoreconf.in | Hunk #1 succeeded at 55 with fuzz 1 (offset -3 lines). | Hunk #3 succeeded at 663 (offset 18 lines). | | The context lines in the patches can be updated with devtool: | | devtool modify autoconf-native | devtool finish --force-patch-refresh autoconf-native | | Don't forget to review changes done by devtool! | | ERROR: autoconf-native-2.69-r11 do_patch: QA Issue: Patch log indicates that patches do not apply cleanly. [patch-fuzz] (From OE-Core rev: c762c0be43a3854a43cb4b9db559b03126d50706) Signed-off-by: Andreas Müller Signed-off-by: Richard Purdie

lib/oe/patch.py: Fix applying a directory as a patch

2019-01-27T13:05:17+00:00

If a SRC_URI content ends with '.patch' bitbake is trying to apply it as it's a patch file. It causes that if we use git repository for 'patch' package the bare clone is extracted to a directory (i.e. build/downloads/git2/git.mirror.org.patch/) which is considered to be a patch file, so patch.py tries to apply that directory as a patch which ends up with a failure. (From OE-Core rev: 1e38d74a2ca7638b1f54e2bb5617903c2683e484) Signed-off-by: Tomasz Dziendzielski Signed-off-by: Richard Purdie

lib/oe/patch.py: Fix the function comment

2019-01-27T13:05:17+00:00

If it's not a patch the function returns nothing. (From OE-Core rev: cc4a75c7ebf24fb3b7b35552a090e8844985e45e) Signed-off-by: Tomasz Dziendzielski Signed-off-by: Richard Purdie

meta: Fix Deprecated warnings from regexs

2019-01-16T15:35:07+00:00

Fix handling of escape characters in regexs and hence fix python Deprecation warnings which will be problematic in python 3.8. Note that some show up as: """ meta/classes/package.bbclass:1293: DeprecationWarning: invalid escape sequence \. """ where the problem isn't on 1293 in package.bbclass but in some _prepend to a package.bbclass function in a different file like mesa.inc, often from do_package_split() calls. (From OE-Core rev: 4b1c0c7d5525fc4cea9e0f02ec54e92a6fbc6199) Signed-off-by: Richard Purdie

lib/oe/patch.py: Clean up getstatusoutput usage

2018-08-23T17:02:23+00:00

We can't use subprocess.check_output() or subprocess.call() here since the one who invokes runcmd() needs handle CmdError() exception (error out or ignore it). (From OE-Core rev: c3e7739987d804f7865428442479d5bece5ff2dd) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

patch.py: Use git format-patch with --no-signature --no-numbered params

2018-03-20T09:59:32+00:00

* --no-signature saves unnecessary .patch modifications when executed on host with different git version * --no-numbered saves unnecessary .patch modifications when number of the applied patches is changed (the number is still in the filename so the order how they should be applied is still preserved) * both options exist for very long time, I've tested them with git 1.9.1 from Ubuntu 14.04 and I'm quite sure they were available even in much older releases, so there shouldn't be any issue on relatively new sanity tested distros (From OE-Core rev: ad76fa92c3a5be38962aff09df070ffd9756f777) Signed-off-by: Martin Jansa Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

lib/oe/patch.py: add a warning if patch context was ignored

2018-03-15T13:27:18+00:00

Ignoring patch context increases the chances of patches being applied incorrectly. Depending on what code is being patched, this can go completely unnoticed and create subtle bugs, sometimes with security implications. Please see here for a specific example: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450 On the other hand, we cannot simply force all patch context to match exactly: doing this would break a lot of recipes suddenly, across all layers. So let's try a softer approach: issue a warning, and gently update patches over a longer span of time. When most of the warnings are eliminated, we can start enforcing a strict patch application policy. I do understand that this patch creates a lot of warnings all of a sudden, however I believe the problem does need to be addressed. All of oe-core recipes have their context already fixed. Sample warning: WARNING: vulkan-1.0.61.1-r0 do_patch: Some of the context lines in patches were ignored. This can lead to incorrectly applied patches. The context lines in the patches can be updated with devtool: devtool modify devtool finish --force-patch-refresh Then the updated patches and the source tree (in devtool's workspace) should be reviewed to make sure the patches apply in the correct place and don't introduce duplicate lines (which can, and does happen when some of the context is ignored). Details: Applying patch demos-Don-t-build-tri-or-cube.patch patching file demos/CMakeLists.txt Hunk #1 succeeded at 63 (offset 2 lines). Hunk #2 succeeded at 76 with fuzz 1 (offset 2 lines). [YOCTO #10450] (From OE-Core rev: 5133fd46bccf14e21680f8d94e952914edccb113) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

meta/lib/oe/patch.py: do not leave .orig files if a patch isn't perfectly matching

2018-03-11T13:26:59+00:00

Particularly, this was causing 'devtool modify' to erroneously add those .orig files into commits. This was getting in the way, if the goal was to amend/update those existing patches. (From OE-Core rev: f4f3406c3bd9599d7a19275475d52bda4c42f2ab) Signed-off-by: Alexander Kanavin Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

lib/oe/patch: add missing import

2018-01-02T17:24:39+00:00

This module refers to oe.types, so it needs to actually import oe.types. Fixes errors when parsing certain OE-Core recipes within the layer index update script. (From OE-Core rev: 26ff9d2835a24a84c7f2bf9c829a13ed568c9ea0) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie