using devtool for rebasing patches

using devtool for rebasing patches

[Alexander Kanavin]

Hello Paul,

it would be very useful if devtool offered support for rebasing source 
patches when they fail to apply, but currently there does not seem to be 
any such feature:

ak@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$

What devtool could do here is apply the patches that can be applied and 
then partially apply the patches that fail. Then give the developer some 
kind of UI for dealing with the rejected hunks (which typically means 
finding the place in the target file where the changes should go and 
then manually editing them in, while looking at the original patch).

Without this feature devtool is half as useful as it could be 
particularly for recipe version updates.

Thanks,
Alex

Re: using devtool for rebasing patches

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]

On Thu, Nov 3, 2016 at 9:01 AM, Alexander Kanavin <
alexander.kanavin@linux.intel.com> wrote:

> it would be very useful if devtool offered support for rebasing source
> patches when they fail to apply, but currently there does not seem to be
> any such feature:
>
> ak@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$
>
> What devtool could do here is apply the patches that can be applied and
> then partially apply the patches that fail. Then give the developer some
> kind of UI for dealing with the rejected hunks (which typically means
> finding the place in the target file where the changes should go and then
> manually editing them in, while looking at the original patch).
>
> Without this feature devtool is half as useful as it could be particularly
> for recipe version updates.
>

That would be useful, indeed.

git already provides such a UI, afaik devtool just needs to use git-am to
apply the patches, ideally passing -3 to it, and let the user use git am to
resolve and continue applying patches.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 2402 bytes --]

Re: using devtool for rebasing patches

[Alexander Kanavin]

On 11/03/2016 06:29 PM, Christopher Larson wrote:
> git already provides such a UI, afaik devtool just needs to use git-am
> to apply the patches, ideally passing -3 to it, and let the user use git
> am to resolve and continue applying patches.

I don't think git am has any UI that helps with rebasing the rejects, 
and -3 is often not useful here, as we don't have the commit history, if 
the source is coming from tarball.

What you need to do here is to use git am --reject, which would 
partially apply the patch, then find all the *.rej files and let the 
user manually edit them in, then complete the patch application with git 
am --continue.


Alex

Re: using devtool for rebasing patches

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 1178 bytes --]

On Thu, Nov 3, 2016 at 9:35 AM, Alexander Kanavin <
alexander.kanavin@linux.intel.com> wrote:

> On 11/03/2016 06:29 PM, Christopher Larson wrote:
>
>> git already provides such a UI, afaik devtool just needs to use git-am
>> to apply the patches, ideally passing -3 to it, and let the user use git
>> am to resolve and continue applying patches.
>>
>
> I don't think git am has any UI that helps with rebasing the rejects, and
> -3 is often not useful here, as we don't have the commit history, if the
> source is coming from tarball.
>

Fairly sure that’s not actually correct. See below.


> What you need to do here is to use git am --reject, which would partially
> apply the patch, then find all the *.rej files and let the user manually
> edit them in, then complete the patch application with git am --continue.


With -3, it’ll merge it into the file with conflict markers, which is a lot
more pleasant to deal with than .rej files, even without the merge-base
being available.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 1855 bytes --]

Re: using devtool for rebasing patches

[Patrick Ohly]

On Thu, 2016-11-03 at 10:14 -0700, Christopher Larson wrote:
> 
> On Thu, Nov 3, 2016 at 9:35 AM, Alexander Kanavin
> <alexander.kanavin@linux.intel.com> wrote:
> 
>         What you need to do here is to use git am --reject, which
>         would partially apply the patch, then find all the *.rej files
>         and let the user manually edit them in, then complete the
>         patch application with git am --continue.
> 
> 
> With -3, it’ll merge it into the file with conflict markers, which is
> a lot more pleasant to deal with than .rej files, even without the
> merge-base being available.

That's also what I would prefer.

To deal with recipes that have something other than git as source one
could create a local git repo with a branch that contains two commits
(old version and new version), apply the patches on a second branch on
top of the old version, then do the normal rebase with conflictstyle =
diff3. At least I find that configstyle useful and have it in my
~/.gitconfig.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: using devtool for rebasing patches

[Paul Eggleton]

On Thu, 03 Nov 2016 20:14:04 Patrick Ohly wrote:
> On Thu, 2016-11-03 at 10:14 -0700, Christopher Larson wrote:
> > On Thu, Nov 3, 2016 at 9:35 AM, Alexander Kanavin
> > 
> > <alexander.kanavin@linux.intel.com> wrote:
> >         What you need to do here is to use git am --reject, which
> >         would partially apply the patch, then find all the *.rej files
> >         and let the user manually edit them in, then complete the
> >         patch application with git am --continue.
> > 
> > With -3, it’ll merge it into the file with conflict markers, which is
> > a lot more pleasant to deal with than .rej files, even without the
> > merge-base being available.
> 
> That's also what I would prefer.
> 
> To deal with recipes that have something other than git as source one
> could create a local git repo with a branch that contains two commits
> (old version and new version), apply the patches on a second branch on
> top of the old version, then do the normal rebase with conflictstyle =
> diff3. At least I find that configstyle useful and have it in my
> ~/.gitconfig.

FYI this is what "devtool upgrade" already does. It's just that it's geared 
towards upgrading so it expects the version to be changing at the same time.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: using devtool for rebasing patches

[Khem Raj]

[-- Attachment #1.1: Type: text/plain, Size: 2350 bytes --]


> On Nov 3, 2016, at 9:29 AM, Christopher Larson <clarson@kergoth.com> wrote:
> 
> 
> On Thu, Nov 3, 2016 at 9:01 AM, Alexander Kanavin <alexander.kanavin@linux.intel.com <mailto:alexander.kanavin@linux.intel.com>> wrote:
> it would be very useful if devtool offered support for rebasing source patches when they fail to apply, but currently there does not seem to be any such feature:
> 
> ak@kanavin-desktop:~/development/poky/build$ devtool modify libksba
> Parsing recipes..done.
> NOTE: Fetching libksba...
> NOTE: Unpacking...
> NOTE: Patching...
> ERROR: Applying 'ksba-add-pkgconfig-support.pa <http://ksba-add-pkgconfig-support.pa/>tch' failed:
> checking file Makefile.am
> Hunk #1 FAILED at 21.
> 1 out of 1 hunk FAILED
> checking file configure.ac <http://configure.ac/>
> Hunk #1 succeeded at 414 (offset 14 lines).
> checking file ksba.pc.in <http://ksba.pc.in/>
> checking file src/ksba.m4
> ERROR: Function failed: patch_do_patch
> ak@kanavin-desktop:~/development/poky/build$
> 
> What devtool could do here is apply the patches that can be applied and then partially apply the patches that fail. Then give the developer some kind of UI for dealing with the rejected hunks (which typically means finding the place in the target file where the changes should go and then manually editing them in, while looking at the original patch).
> 
> Without this feature devtool is half as useful as it could be particularly for recipe version updates.
> 
> That would be useful, indeed.
> 
> git already provides such a UI, afaik devtool just needs to use git-am to apply the patches, ideally passing -3 to it, and let the user use git am to resolve and continue applying patches.

this seems good. Although, I have seen that all patches are not git am applicable, then I use git apply, something even that does not work, then third option is
to use patch  < patch and this works if it does not work then patch needs manual work.

> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #1.2: Type: text/html, Size: 4013 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: using devtool for rebasing patches

[Patrick Ohly]

On Thu, 2016-11-03 at 18:01 +0200, Alexander Kanavin wrote:
> Hello Paul,
> 
> it would be very useful if devtool offered support for rebasing source 
> patches when they fail to apply

+1 for that.

I tried it the other way around: first "devtool modify", then rebasing
using git (which only works when the recipe fetches from a git repo),
and finally changing the recipe such that it refers to the version I
rebased onto. But that version change in the recipe confused "devtool
update-recipe" considerably (as in "added all patches between the
version", if I remember correctly).

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

Re: using devtool for rebasing patches

[Paul Eggleton]

Hi Alex,

On Thu, 03 Nov 2016 18:01:27 Alexander Kanavin wrote:
> it would be very useful if devtool offered support for rebasing source
> patches when they fail to apply, but currently there does not seem to be
> any such feature:
> 
> ak@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$
> 
> What devtool could do here is apply the patches that can be applied and
> then partially apply the patches that fail. Then give the developer some
> kind of UI for dealing with the rejected hunks (which typically means
> finding the place in the target file where the changes should go and
> then manually editing them in, while looking at the original patch).
> 
> Without this feature devtool is half as useful as it could be
> particularly for recipe version updates.

"devtool upgrade" is designed specifically to handle the upgrade case and 
tries to rebase the old patches onto the new version, putting you into 
resolution mode with "git am" if it fails to apply a patch. I appreciate that 
you may now be working through sorting out all of the patches to reduce the 
fuzziness when applying, and that won't help in that scenario, but it would 
definitely be worth considering for upgrades.

I'm open to implementing better support for handling patch application failure 
for devtool modify - in fact there is a bug open for just that:

  https://bugzilla.yoctoproject.org/show_bug.cgi?id=8325

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: using devtool for rebasing patches

[Paul Eggleton]

On Fri, 04 Nov 2016 08:29:26 Paul Eggleton wrote:
> Hi Alex,
> 
> On Thu, 03 Nov 2016 18:01:27 Alexander Kanavin wrote:
> > it would be very useful if devtool offered support for rebasing source
> > patches when they fail to apply, but currently there does not seem to be
> > any such feature:
> > 
> > ak@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$
> > 
> > What devtool could do here is apply the patches that can be applied and
> > then partially apply the patches that fail. Then give the developer some
> > kind of UI for dealing with the rejected hunks (which typically means
> > finding the place in the target file where the changes should go and
> > then manually editing them in, while looking at the original patch).
> > 
> > Without this feature devtool is half as useful as it could be
> > particularly for recipe version updates.
> 
> "devtool upgrade" is designed specifically to handle the upgrade case and
> tries to rebase the old patches onto the new version, putting you into
> resolution mode with "git am" if it fails to apply a patch. I appreciate
> that you may now be working through sorting out all of the patches to
> reduce the fuzziness when applying, and that won't help in that scenario,
> but it would definitely be worth considering for upgrades.
> 
> I'm open to implementing better support for handling patch application
> failure for devtool modify - in fact there is a bug open for just that:
> 
>   https://bugzilla.yoctoproject.org/show_bug.cgi?id=8325

(Although admittedly that was mostly for an earlier issue - we ought to add a 
bit of description of where to go from here.)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: using devtool for rebasing patches

[Alexander Kanavin]

On 11/03/2016 09:29 PM, Paul Eggleton wrote:

> "devtool upgrade" is designed specifically to handle the upgrade case and
> tries to rebase the old patches onto the new version, putting you into
> resolution mode with "git am" if it fails to apply a patch. I appreciate that
> you may now be working through sorting out all of the patches to reduce the
> fuzziness when applying, and that won't help in that scenario, but it would
> definitely be worth considering for upgrades.

Fair enough, although I was not aware of this feature of devtool until 
now, despite being a major contributor of package upgrades to oe-core :) 
We have had a miscommunication issue, it seems.

> I'm open to implementing better support for handling patch application failure
> for devtool modify - in fact there is a bug open for just that:
>
>   https://bugzilla.yoctoproject.org/show_bug.cgi?id=8325

THanks, I just wrote a comment there, and made the patch fuzz bug depend 
on this one :)

Alex