From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6995471841453146112 Date: Fri, 27 Aug 2021 01:39:55 -0700 (PDT) From: "ub...@ilbers.de" To: isar-users Message-Id: In-Reply-To: References: <5292418.rdbgypaU67@home> <4bdfae48-445b-d80a-ad1c-ce1315074788@siemens.com> <5307686.rdbgypaU67@home> <9f02a158-a230-795a-c4a6-ed471fe9793b@siemens.com> Subject: Re: [PATCH v2 0/4] Make adjust_git work in both worlds MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5612_1118074249.1630053595546" X-TUID: JeR1KrAbkUzt ------=_Part_5612_1118074249.1630053595546 Content-Type: multipart/alternative; boundary="----=_Part_5613_1455174793.1630053595546" ------=_Part_5613_1455174793.1630053595546 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've just sent a patchset as "[RFC 0/3] Fix gbp patching after=20 configuration change" (sorry, with wrong tag RFC) after internal discussion= . =D1=87=D0=B5=D1=82=D0=B2=D0=B5=D1=80=D0=B3, 26 =D0=B0=D0=B2=D0=B3=D1=83=D1= =81=D1=82=D0=B0 2021 =D0=B3. =D0=B2 10:57:26 UTC+3, Jan Kiszka:=20 > On 19.08.21 08:21, Jan Kiszka wrote: > > On 19.08.21 08:17, Uladzimir Bely wrote: > >> In the email from =D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C=D0= =BD=D0=B8=D0=BA, 16 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2021 =D0=B3.= 13:45:12 +03 user Jan=20 > Kiszka=20 > >> wrote: > >>> On 16.08.21 10:27, Uladzimir Bely wrote: > >>>> In the email from =D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB=D1=8C= =D0=BD=D0=B8=D0=BA, 16 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2021 =D0= =B3. 10:55:31 +03 user=20 > Jan > >>>> Kiszka>=20 > >>>> wrote: > >>>>> On 16.08.21 09:52, Uladzimir Bely wrote: > >>>>>> In the email from =D0=B2=D0=BE=D1=81=D0=BA=D1=80=D0=B5=D1=81=D0=B5= =D0=BD=D1=8C=D0=B5, 15 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2021 =D0= =B3. 22:02:25 +03 user=20 > 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=20 > use > >>>>>>>> it > >>>>>>>> completely. > >>>>>>>> > >>>>>>>> There are some patch_task_patch_prefunc() and=20 > patch_task_postfunc() > >>>>>>>> here > >>>>>>>> that are used in OE when PATCHTOOL=3D'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)= =20 > that > >>>>>>>> prefunc may fix this 'patch is allready applied' issue in OE. > >>>>>>> > >>>>>>> If you can still reproduce the issue, just set=20 > PATCH_COMMIT_FUNCTIONS=3D1 > >>>>>>> to check if it has any impact. > >>>>>>> > >>>>>>> Browsing poky and OE-core, I only find devtool setting this var.= =20 > But > >>>>>>> both aren't using git as patch tool anyway, a downstream=20 > layer/recipe > >>>>>>> needs to requests that. > >>>>>>> > >>>>>>> Jan > >>>>>> > >>>>>> Yes, I also tried this way. > >>>>>> > >>>>>> Actually, enabling PATCH_COMMIT_FUNCTIONS also forces to make some= =20 > more > >>>>>> changes in patch.bbclass (like sys.path.insert for OE lib path) th= at > >>>>>> makes > >>>>>> the difference increase. > >>>>>> > >>>>>> Anyway, even if this set to "1", the problem of patch reapply is= =20 > still > >>>>>> here - custom patch is going to be applied despite it was already= =20 > 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= =20 > 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= =20 > rebuild > >>>> in Yocto/OE that follows the approach similar to one isar's cowsay= =20 > 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=3Dgit, and finally trigger the rebuil= d in > >>> a way that patch is re-run. That should be doable in OE without=20 > 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= =20 > and=20 > >> comparing the oe/patch.py behaviour in ISAR and OE. > >> > >> At the end, the problem of=20 > meta-isar/recipes-app/cowsay/files/isar.patch is=20 > >> that it's not in git format. So, when GitApplyTree class tries to appl= y=20 > it, it=20 > >> fails and switches to fallback PatchTree one. > >> > >> That's why the patch can be applied only once - PatchTree class can't= =20 > apply=20 > >> 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= =20 > that the=20 > >> same patch need to be skipped. > >> > >> The difference in output: > >> > >>> ubely@home=20 > /home/Work/isar/build-isar/tmp/work/debian-buster-amd64/cowsay/ > >> git-r0/git $ PATCHFILE=3D"isar.patch" git=20 > --work-tree=3D/home/Work/isar/build- > >> isar/tmp/work/debian-buster-amd64/cowsay/git-r0/git -c user.name=3D"Is= ar"=20 > -c=20 > >> user.email=3D"isar.patch@isar" am -3 --keep-cr -p1=20 > /home/Work/isar/repo/meta- > >> isar/recipes-app/cowsay/files/isar.patch > >>> Patch format detection failed. > >> > >>> ubely@home=20 > /home/Work/isar/build-isar/tmp/work/debian-buster-amd64/cowsay/ > >> git-r0/git $ PATCHFILE=3D"isar.patch" git=20 > --work-tree=3D/home/Work/isar/build- > >> isar/tmp/work/debian-buster-amd64/cowsay/git-r0/git -c user.name=3D"Is= ar"=20 > -c=20 > >> user.email=3D"isar.patch@isar" am -3 --keep-cr -p1=20 > /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= =20 > work=20 > >> when PATCHTOOL=3D"git" > >> > >=20 > > Ah, great, thanks for debugging! Please send a patch - for the patch. > >=20 > > Did you send this patch already? > > Jan > > --=20 > Siemens AG, T RDA IOT > Corporate Competence Center Embedded Linux > ------=_Part_5613_1455174793.1630053595546 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I've just sent a patchset as "[RFC 0/3] Fix gbp patching after configuratio= n change" (sorry, with wrong tag RFC) after internal discussion.
=D1=87=D0=B5=D1= =82=D0=B2=D0=B5=D1=80=D0=B3, 26 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 = 2021 =D0=B3. =D0=B2 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 =D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5=D0=BB= =D1=8C=D0=BD=D0=B8=D0=BA, 16 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 202= 1 =D0=B3. 13:45:12 +03 user Jan Kiszka=20
>> wrote:
>>> On 16.08.21 10:27, Uladzimir Bely wrote:
>>>> In the email from =D0=BF=D0=BE=D0=BD=D0=B5=D0=B4=D0=B5= =D0=BB=D1=8C=D0=BD=D0=B8=D0=BA, 16 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0= =B0 2021 =D0=B3. 10:55:31 +03 user Jan
>>>> Kiszka>=20
>>>> wrote:
>>>>> On 16.08.21 09:52, Uladzimir Bely wrote:
>>>>>> In the email from =D0=B2=D0=BE=D1=81=D0=BA=D1= =80=D0=B5=D1=81=D0=B5=D0=BD=D1=8C=D0=B5, 15 =D0=B0=D0=B2=D0=B3=D1=83=D1=81= =D1=82=D0=B0 2021 =D0=B3. 22:02:25 +03 user Jan
>>>>>> Kiszka>
>>>>>>
>>>>>> wrote:
>>>>>>> On 13.08.21 14:40, Uladzimir Bely wrote:
>>>>>>>> When I previously looked at patch.bbcl= ass, I noted, that we don't use
>>>>>>>> it
>>>>>>>> completely.
>>>>>>>>
>>>>>>>> There are some patch_task_patch_prefun= c() and patch_task_postfunc()
>>>>>>>> here
>>>>>>>> that are used in OE when PATCHTOOL=3D&= #39;git'. But in our case they are
>>>>>>>> never
>>>>>>>> run due to not using PATCH_COMMIT_FUNC= TIONS in isar.
>>>>>>>>
>>>>>>>> I suppose (but can't be completely= sure without deep look to OE) that
>>>>>>>> prefunc may fix this 'patch is all= ready applied' issue in OE.
>>>>>>>
>>>>>>> If you can still reproduce the issue, just= set PATCH_COMMIT_FUNCTIONS=3D1
>>>>>>> to check if it has any impact.
>>>>>>>
>>>>>>> Browsing poky and OE-core, I only find dev= tool setting this var. But
>>>>>>> both aren't using git as patch tool an= yway, 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 des= pite 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 s= etup, 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 som= e package to rebuild
>>>> in Yocto/OE that follows the approach similar to one i= sar's cowsay uses:
>>>> a patch used by recipe that adds new patch to debian s= eries.
>>>
>>> Nope, this is unrelated. You just need to find a recipe th= at adds a
>>> patch, then switch to PATCHTOOL=3Dgit, and finally trigger= the rebuild in
>>> a way that patch is re-run. That should be doable in OE wi= thout building
>>> a complete system. In fact, you only need to force-run pat= ch for a
>>> specific recipe twice.
>>>
>>> Jan
>>
>> I finally found the reason of failing patch in ISAR, after deb= ugging and=20
>> 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=20
>> that it's not in git format. So, when GitApplyTree class t= ries to apply it, it=20
>> fails and switches to fallback PatchTree one.
>>
>> That's why the patch can be applied only once - PatchTree = class can't apply=20
>> the same patch if it has already been applied at previous buil= d.
>>
>> When I modify isar.patch to be git-like ( recreate it with `gi= t format-
>> patch`), everythong works OK. GitApplyTree is now able to unde= rstand that the=20
>> same patch need to be skipped.
>>
>> The difference in output:
>>
>>> ubely@home /home/Work/isar/build-isar/tmp/work/debian-bust= er-amd64/cowsay/
>> git-r0/git $ PATCHFILE=3D"isar.patch" git --work-tre= e=3D/home/Work/isar/build-
>> isar/tmp/work/debian-buster-amd64/cowsay/git-r0/git -c user.name=3D"Isar" -c=20
>> user.email=3D"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-bust= er-amd64/cowsay/
>> git-r0/git $ PATCHFILE=3D"isar.patch" git --work-tre= e=3D/home/Work/isar/build-
>> isar/tmp/work/debian-buster-amd64/cowsay/git-r0/git -c user.name=3D"Isar" -c=20
>> user.email=3D"isar.patch@isar" am -3 --keep-cr -p1 /= home/Work/isar/repo/meta-
>> isar/recipes-app/cowsay/files/0001-original-patch-isar.patch.p= atch
>>> 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=20
>> when PATCHTOOL=3D"git"
>>
>=20
> Ah, great, thanks for debugging! Please send a patch - for the pat= ch.
>=20

Did you send this patch already?

Jan

--=20
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
------=_Part_5613_1455174793.1630053595546-- ------=_Part_5612_1118074249.1630053595546--