Re: [PATCH v2 0/4] Make adjust_git work in both worlds

[Uladzimir Bely <ubely@ilbers.de>]

In the email from понедельник, 16 августа 2021 г. 13:45:12 +03 user Jan Kiszka 
wrote:
> On 16.08.21 10:27, Uladzimir Bely wrote:
> > In the email from понедельник, 16 августа 2021 г. 10:55:31 +03 user Jan
> > Kiszka> 
> > wrote:
> >> On 16.08.21 09:52, Uladzimir Bely wrote:
> >>> In the email from воскресенье, 15 августа 2021 г. 22:02:25 +03 user Jan
> >>> Kiszka>
> >>> 
> >>> wrote:
> >>>> On 13.08.21 14:40, Uladzimir Bely wrote:
> >>>>> When I previously looked at patch.bbclass, I noted, that we don't use
> >>>>> it
> >>>>> completely.
> >>>>> 
> >>>>> There are some patch_task_patch_prefunc() and patch_task_postfunc()
> >>>>> here
> >>>>> that are used in OE when PATCHTOOL='git'. But in our case they are
> >>>>> never
> >>>>> run due to not using PATCH_COMMIT_FUNCTIONS in isar.
> >>>>> 
> >>>>> I suppose (but can't be completely sure without deep look to OE) that
> >>>>> prefunc may fix this 'patch is allready applied' issue in OE.
> >>>> 
> >>>> If you can still reproduce the issue, just set PATCH_COMMIT_FUNCTIONS=1
> >>>> to check if it has any impact.
> >>>> 
> >>>> Browsing poky and OE-core, I only find devtool setting this var. But
> >>>> both aren't using git as patch tool anyway, a downstream layer/recipe
> >>>> needs to requests that.
> >>>> 
> >>>> Jan
> >>> 
> >>> Yes, I also tried this way.
> >>> 
> >>> Actually, enabling PATCH_COMMIT_FUNCTIONS also forces to make some more
> >>> changes in patch.bbclass (like sys.path.insert for OE lib path) that
> >>> makes
> >>> the difference increase.
> >>> 
> >>> Anyway, even if this set to "1", the problem of patch reapply is still
> >>> here - custom patch is going to be applied despite it was already done
> >>> on
> >>> previous build. So, reset to SRC_REV is still required.
> >> 
> >> Strange. Did you try the same procedure in an OE setup, to compare what
> >> happens there?
> >> 
> >> Jan
> > 
> > Not yet, while it's expected to take much time to compile.
> > 
> > Anyway, to catch the similar error, I need to find some package to rebuild
> > in Yocto/OE that follows the approach similar to one isar's cowsay uses:
> > a patch used by recipe that adds new patch to debian series.
> 
> Nope, this is unrelated. You just need to find a recipe that adds a
> patch, then switch to PATCHTOOL=git, and finally trigger the rebuild in
> a way that patch is re-run. That should be doable in OE without building
> a complete system. In fact, you only need to force-run patch for a
> specific recipe twice.
> 
> Jan

I finally found the reason of failing patch in ISAR, after debugging and 
comparing the oe/patch.py behaviour in ISAR and OE.

At the end, the problem of meta-isar/recipes-app/cowsay/files/isar.patch is 
that it's not in git format. So, when GitApplyTree class tries to apply it, it 
fails and switches to fallback PatchTree one.

That's why the patch can be applied only once - PatchTree class can't apply 
the same patch if it has already been applied at previous build.

When I modify isar.patch to be git-like ( recreate it with `git format-
patch`), everythong works OK. GitApplyTree is now able to understand that the 
same patch need to be skipped.

The difference in output:

> ubely@home /home/Work/isar/build-isar/tmp/work/debian-buster-amd64/cowsay/
git-r0/git $ PATCHFILE="isar.patch" git --work-tree=/home/Work/isar/build-
isar/tmp/work/debian-buster-amd64/cowsay/git-r0/git -c user.name="Isar" -c 
user.email="isar.patch@isar" am -3 --keep-cr -p1 /home/Work/isar/repo/meta-
isar/recipes-app/cowsay/files/isar.patch
> Patch format detection failed.

> ubely@home /home/Work/isar/build-isar/tmp/work/debian-buster-amd64/cowsay/
git-r0/git $ PATCHFILE="isar.patch" git --work-tree=/home/Work/isar/build-
isar/tmp/work/debian-buster-amd64/cowsay/git-r0/git -c user.name="Isar" -c 
user.email="isar.patch@isar" am -3 --keep-cr -p1 /home/Work/isar/repo/meta-
isar/recipes-app/cowsay/files/0001-original-patch-isar.patch.patch
> Applying: %% original patch: isar.patch
> Using index info to reconstruct a base tree...
> M       debian/patches/series
> Falling back to patching base and 3-way merge...
> No changes -- Patch already applied.

So, I guess, we need to reformat isar.patch to be sure it can properly work 
when PATCHTOOL="git"

-- 
Uladzimir Bely
Promwad Ltd.
External service provider of ilbers GmbH
Maria-Merian-Str. 8
85521 Ottobrunn, Germany
+49 (89) 122 67 24-0
Commercial register Munich, HRB 214197
General Manager: Baurzhan Ismagulov