| Summary: | devtool modify could handle patch failure more usefully | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Paul Eggleton <bluelightning> |
| Component: | Scripts and Tools | Assignee: | Paul Eggleton <bluelightning> |
| Status: | RESOLVED OBSOLETE | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Medium+ | CC: | alex.kanavin, cpanceac, kergoth, randy.macleod, ross.burton |
| Version: | 1.8 | ||
| Target Milestone: | 4.99 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
Hmm, so it turns out that in the case of unzip the patch failed to apply because of a bug in lib/oe/patch.py rather than the patch being already applied. Having said that the above is still valid - a recent example of a recipe where this happened (which I am about to send a patch for) is qt4-x11-free. I just ran into a patch failure with modify -x today, not because of the different PATCHTOOL, it was failing with a regular build too, but I was thinking it'd be nice if devtool could be used as a nicer patch resolution workflow than either PATCHRESOLVE or manual. I.e. if devtool used git-am to apply the multiple patches at once, then you could drop into the in-progress tree, fix the conflicts, git add the files, git am --resolved, and continue. of course, devtool woudlnt' be able to do any postprocessing after those fixups unless modify -x had its own --continue, but it's something to consider, anyway. The current yocto workflow for resolving patch application failures rather sucks :) Thanks to some improvements in the underlying patch code, the name of the failed patch is now being reported. The traceback is also fixed. I'm therefore changing this to an enhancement. I'd like 'devtool modify' to be able to rebase patches in a way similar to 'devtool upgrade'. Currently it simply fails altogether: k@kanavin-desktop:~/development/poky/build$ devtool modify libksba Parsing recipes..done. NOTE: Fetching libksba... NOTE: Unpacking... NOTE: Patching... ERROR: Applying 'ksba-add-pkgconfig-support.patch' failed: checking file Makefile.am Hunk #1 FAILED at 21. 1 out of 1 hunk FAILED checking file configure.ac Hunk #1 succeeded at 414 (offset 14 lines). checking file ksba.pc.in checking file src/ksba.m4 ERROR: Function failed: patch_do_patch ak@kanavin-desktop:~/development/poky/build$ Instead it could use 'git am' to assist with conflict resolution - if something fails, indicate what it was and let the user edit the files containing conflict resolution markers. There was a discussion about this on oe-core list: http://lists.openembedded.org/pipermail/openembedded-core/2016-November/128368.html This feature would be needed for updating patches so that they contain correct context, across all layers: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450 Paul, Will this medium Enhancement and the medium+ defect that it blocks ( https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450 ) will move to 2.4? Is there anything that we can do to help move things along? I think people are not sure of the implications of patch fuzz variations and they are concerned that YP some misapplied patches that could affect system quality. I suspect but don't have the proof that this is not the case. If you have any stats on the occurrence of (silent) errors, please add them to one of these defects. Anything new here? We would be happy to have the feature requested by Alexander, in order to quicken the 'fuzz' issues fix. I have played with 'git am' and 'git apply', and I believe there is actually no way to make it work. Three-way resolution works only if git has a tree to which the patch can be applied correctly. In this case, there is no such tree: all we have is the single, current version of the recipe (unlike devtool upgrade). We can also partially apply the patches, but that's pretty cumbersome, and error-prone. However, I have suggested a different way to move forward with the issue: please refer to bug 10450 for more details. Reopening - I think we can still do something here, whether it arrives in time to be useful for this exercise is another question, but I'll try. The fuzz issue has now been fixed, please refer to https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450#c20 for details. Instead of using devtool modify to rebase the patches, we use devtool finish/update-recipe to refresh them. Whether something useful could be done with 'devtool modify' and failing patches is up to Paul to research and decide. The issue is totally obsolete by this point - I haven't seen it in years. |
Because we're effectively using PATCHTOOL = "git" when we apply patches within "devtool modify" or "devtool extract", which is not the default (the default during a normal build for most recipes is "quilt"), sometimes patching fails where it does not during a normal build due to someone leaving a patch that's already been applied in the recipe - quilt doesn't error on these by default. Here's an example (from poky master at 75bad1b64bd485a50af69ed1f8663a0dadbb5f9e): ------------ snip ------------ $ devtool extract unzip /tmp/unzip Parsing recipes..done. NOTE: Fetching unzip... NOTE: Unpacking... NOTE: Patching... ERROR: Command Error: exit status: 1 Output: checking file extract.c Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 2 out of 2 hunks ignored ERROR: Command Error: exit status: 1 Output: checking file extract.c Reversed (or previously applied) patch detected! Assume -R? [n] Apply anyway? [n] Skipping patch. 2 out of 2 hunks ignored Traceback (most recent call last): File "/home/paul/poky/poky/scripts/devtool", line 290, in <module> ret = main() File "/home/paul/poky/poky/scripts/devtool", line 279, in main ret = args.func(args, config, basepath, workspace) File "/home/paul/poky/poky/scripts/lib/devtool/standard.py", line 184, in extract initial_rev = _extract_source(srctree, args.keep_temp, args.branch, rd) File "/home/paul/poky/poky/scripts/lib/devtool/standard.py", line 350, in _extract_source task_executor.exec_func('do_patch', False) File "/home/paul/poky/poky/scripts/lib/devtool/standard.py", line 215, in exec_func bb.build.exec_func(func, localdata) FuncFailed: Function failed: patch_do_patch ------------ snip ------------ A couple of things that aren't ideal here: 1) There's a traceback shown, we don't need one 2) We're seeing the error message twice (perhaps due to multiple log handlers bitbake's own and devtool maybe?) 3) Most annoyingly, it doesn't actually tell you which patch failed to apply (this logic is in patch.bbclass) Additionally, it may be that we have a mode that devtool can enable to allow these "previously applied" patches to generate a warning instead of a failure given the default behaviour with quilt.