Re: Patching submodules


Yann Dirson
 

Hi Emily,

I'm not sure how the patch is generated, and (not using devtool myself) I may understood your problem wrongly
(showing the relevant part of your diff could help), but you could try to generate it yourself with
"git show --submodule=diff", that could be more palatable to quilt.


Le ven. 20 mars 2020 à 16:09, Paul Barker <pbarker@...> a écrit :
On Fri, 20 Mar 2020 at 04:10, Emily <easmith5555@...> wrote:
>
> Hi all -
>
> I have a recipe that I'd like to patch - the source is in a repo which has a submodule, and the patch occurs in the submodule. Is there a way I can apply this patch without getting an error? I do kind of understand why it's a problem - the patch is changing the pointer of the submodule to a commit which doesn't actually exist. Do I need to build the submodule as a separate recipe and patch it separately maybe?
>
> I used devtool for the patch and if I don't run the devtool reset command, then everything builds, but I think this is just because the workspace created by devtool was added as a layer, which probably isn't a good long term solution.
>
> The error I get (pasted below) says I can "enforce with -f" but I'm not sure where that option goes exactly. Thanks for the help!
>
> Emily
>
> Error on build:
> ERROR: opc-ua-server-gfex-1.0+gitAUTOINC+921c563309-r0 do_patch: Command Error: 'quilt --quiltrc /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0  Output:
> Applying patch 0001-Update-Poverty-to-point-to-boost-python3.patch
> File Poverty is not a regular file -- refusing to patch
> 1 out of 1 hunk ignored -- rejects in file
> Patch 0001-Update-Poverty-to-point-to-boost-python3.patch does not apply (enforce with -f)
> ERROR: opc-ua-server-gfex-1.0+gitAUTOINC+921c563309-r0 do_patch: Function failed: patch_do_patch

The issue appears to be that patches are applied using quilt which
doesn't understand a patch like this. I don't know of a good solution
to this other than making a new commit in the top level repository and
updating SRCREV.

Perhaps it's better to carry the diff within the submodule as a patch
- so you leave the submodule commit pointer where it is and instead
include all the necessary changes to the submodule in the patch. Would
that work for you?



--
Yann Dirson <yann@...>
Blade / Shadow -- http://shadow.tech

Join yocto@lists.yoctoproject.org to automatically receive all group messages.