[oe] [meta-oe][PATCHv3] mozjs: refresh patches

Martin Jansa martin.jansa at gmail.com
Mon Mar 26 22:11:55 UTC 2018


Mostly because I find the proper patch headers useful.

When doing the refresh now, I find it useful to also add original author
and patch headers even to patches which currently apply cleanly, so that
next time I can just use "git am foo/*" (or use git as a PATCHTOOL) and get
usable results.

I understand that it adds unnecessary changes (not needed to fix the
WARNING), but IMHO better in separate "refresh patches" commit, than next
time someone uses devtool for actual mozjs upgrade which might refresh the
patches even more to make them applicable on new base version.

Regards,

On Tue, Mar 27, 2018 at 12:02 AM, Andreas Müller <schnitzeltony at gmail.com>
wrote:

> On Mon, Mar 26, 2018 at 11:43 PM, Martin Jansa <martin.jansa at gmail.com>
> wrote:
> > WARNING: mozjs-17.0.0-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 <recipe>
> >     devtool finish --force-patch-refresh <recipe> <layer_path>
> >
> > 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). Further information:
> > http://lists.openembedded.org/pipermail/openembedded-core/
> 2018-March/148675.html
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=10450
> > Details:
> > Applying patch Manually_mmap_heap_memory_esr17.patch
> > patching file js/src/gc/Memory.cpp
> > Hunk #1 succeeded at 309 with fuzz 1 (offset 3 lines).
> > Hunk #2 succeeded at 391 (offset 3 lines).
> >
> > Now at patch Manually_mmap_heap_memory_esr17.patch
> >
> Why don't you adjust the patch mentioned in the warning only? Might
> sound lazy but touching all patches is dangerous business. I have seen
> cases where devtool does unexpected/unnecessary modifications so I
> tend to keep diff small. My workflow:
> * run devtool commands
> * if the patches are at different place (files -> recipename) -> move
> them back (of course only those build complained)
> * remove / checkout those patches which were OK
> * use git add -p <patchfile> to check in only those parts important
> * git checkout remaining changes
> * commit
>
> Andreas
>



More information about the Openembedded-devel mailing list