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

[Uladzimir Bely <ubely@ilbers.de>]

In the email from Monday, 16 Aug 2021 г. 14:01:43 +03 user Jan Kiszka wrote:
> On 16.08.21 12:45, 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.
> 
> In fact, I'm not even sure we have a problem here. This is what I just
> did over my patch queue:
> 
> bitbake mc:qemuarm64-buster:cowsay
> edit isar.patch
> bitbake mc:qemuarm64-buster:cowsay
> 
> And that succeeded, thus do_patch did a proper revert before trying to
> apply the updated patch again.
> 
> How exactly do you trigger the problem you still see?
> 
> Jan

One of the easiest way, for example:

bitbake -v mc:qemuamd64-buster:cowsay

edit conf/local.conf # (e.g, (un)comment something global, like 
ISAR_USE_CACHED_BASE_REPO)

bitbake -v mc:qemuamd64-buster:cowsay

-- 
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