From: Martin Jansa <martin.jansa@gmail.com>
To: "Andreas Müller" <schnitzeltony@gmail.com>
Cc: openembeded-devel <openembedded-devel@lists.openembedded.org>
Subject: Re: [meta-oe][PATCHv3] mozjs: refresh patches
Date: Tue, 27 Mar 2018 06:48:35 +0200 [thread overview]
Message-ID: <20180327044835.GA1536@jama> (raw)
In-Reply-To: <CALbNGRQFpVkRPVtMv10avhDoVgUStwMKhWsTRprX_57osSjRmg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2871 bytes --]
On Tue, Mar 27, 2018 at 01:02:02AM +0200, Andreas Müller wrote:
> On Tue, Mar 27, 2018 at 12:27 AM, Andreas Müller
> <schnitzeltony@gmail.com> wrote:
> > On Tue, Mar 27, 2018 at 12:11 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> >> 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,
> >>
> > Understood - but by moving the patches devtool has created to the
> > original location (often they are already there) and use git add -p
> > you can decide for each Hunk if that is necessary or not - but it's
> > not that important to start a longer thread for this :)
> >
> Just said 'don't want a longer thread' - and now this :)
>
> An example from V1 demonstrates what I mean (using 'git add -p' forget
> most of the rest) :
>
> -From da3929a96d9c74e11bf37d128890e18fcb745365 Mon Sep 17 00:00:00 2001
> +From 08b62f039e0fee50e9399ce2e48b56770f8f71e3 Mon Sep 17 00:00:00 2001
> ^ This is not necessary
> From: Lei Maohui <leimaohui@cn.fujitsu.com>
> Date: Mon, 26 Jan 2015 08:53:19 +0900
> Subject: [PATCH] mozjs17.0.0: fix the compile bug of powerpc
> @@ -10,14 +10,16 @@ argument '5' to 'JSBool
> TryArgumentFormatter(JSContext*, const char**,
> JSBool, jsval**, __va_list_tag (*)[1])'
>
> Signed-off-by: Lei Maohui <leimaohui@cn.fujitsu.com>
> +
> +
> ^ same here
> ---
> - jscpucfg.h | 6 ++++++
> + js/src/jscpucfg.h | 6 ++++++
> 1 file changed, 6 insertions(+)
> ^ This is wrong - devtool does not take care for 'S =
> "${WORKDIR}/${BPN}${PV}/js/src"' in recipe (I should open a bug for
> that)
That's why I've added patchdir=../.. to all the patches in SRC_URI, some
already had it. As bonus it makes it easily applicable with git am.
Where it really didn't work was 0004-Add-AArch64-support.patch which was
loosing the diff for mfbt/double-conversion/utils.h (which is outside S,
maybe because devtool was trying to be clever and include only diff
inside S).
Regards,
>
> You'd noticed that by checking in each hunk interactively that's all I
> wanted to suggest. Devtool is a very strong helper - I use it - but I
> just don't agree with all it suggests and try to the patch diffs
> small.
>
> Time for zzz..
>
> Andreas
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 201 bytes --]
next prev parent reply other threads:[~2018-03-27 4:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-21 16:51 [meta-oe][PATCH 1/4] krb5: refresh patches Martin Jansa
2018-03-21 16:52 ` [meta-oe][PATCH 2/4] libqmi: refresh patch Martin Jansa
2018-03-21 16:52 ` [meta-oe][PATCH 3/4] mozjs: refresh patches Martin Jansa
2018-03-21 17:03 ` [meta-oe][PATCHv2 " Martin Jansa
2018-03-26 20:57 ` Martin Jansa
2018-03-26 21:43 ` [meta-oe][PATCHv3] " Martin Jansa
2018-03-26 22:02 ` Andreas Müller
2018-03-26 22:11 ` Martin Jansa
2018-03-26 22:27 ` Andreas Müller
2018-03-26 23:02 ` Andreas Müller
2018-03-27 4:48 ` Martin Jansa [this message]
2018-03-21 16:52 ` [meta-oe][PATCH 4/4] pidgin: " Martin Jansa
2018-03-21 16:57 ` [meta-oe][PATCH 1/4] krb5: " Martin Jansa
2018-03-21 17:03 ` [meta-oe][PATCHv2 " Martin Jansa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180327044835.GA1536@jama \
--to=martin.jansa@gmail.com \
--cc=openembedded-devel@lists.openembedded.org \
--cc=schnitzeltony@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox