четверг, 26 августа 2021 г. в 10:57:26 UTC+3, Jan Kiszka:
On 19.08.21 08:21, Jan Kiszka wrote:
> 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.
>
Did you send this patch already?
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux