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

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

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

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