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

[Jan Kiszka <jan.kiszka@siemens.com>]

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.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux