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.


On Friday, August 13, 2021 at 3:28:45 PM UTC+3 Jan Kiszka wrote:

> On 13.08.21 14:23, Uladzimir Bely wrote:
> > In addition to this series we still need something like I had done in
> > "[RFC,2/2] dpkg-gdb: Reset git to SRCREV revision before patching".
> > 
> > Because the problem with git has gone, but there is a problem that we
> > try apply patch on top of git tree where it's already applied.
> > 
> > Steps to reproduce are quite simple:
> > 
> > - Run first build: bitbake mc:qemuamd64-buster:isar-image-base
> > - Modify local.conf (e.g. set ISAR_USE_CACHED_BASE_REPO ?= "1" or do
> > something else that will cause packages rebuild)
> > - Run second build: bitbake mc:qemuamd64-buster:isar-image-base
> > 
> > It ends up with:
> > 
> > ERROR:mc:qemuamd64-buster:cowsay-git-r0 do_patch: Applying 'isar.patch'
> > failed:
> > The next patch would create the file debian/patches/isar.patch,
> > which already exists!  Assume -R? [n]
> > 
> > In CI tests we remove build/tmp, so that we don't face this problem.
> > 
>
> This is supposed to be handled by the patch class - when it works
> properly. Please check if quilt-based patching addresses this and only
> git is affected and, if yes, also cross-check how that works in OE. We
> either miss something from OE while using their patch class or there is
> actually an upstream issue.
>
> Jan
>
> -- 
> Siemens AG, T RDA IOT
> Corporate Competence Center Embedded Linux
>