I've just sent a patchset as "[RFC 0/3] Fix gbp patching after 
configuration change" (sorry, with wrong tag RFC) after internal discussion.
четверг, 26 августа 2021 г. в 10:57:26 UTC+3, Jan Kiszka: 

> On 19.08.21 08:21, Jan Kiszka wrote:
> > On 19.08.21 08:17, Uladzimir Bely wrote:
> >> 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"
> >>
> > 
> > Ah, great, thanks for debugging! Please send a patch - for the patch.
> > 
>
> Did you send this patch already?
>
> Jan
>
> -- 
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux
>