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