From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6995471841453146112 X-Received: by 2002:a7b:c254:: with SMTP id b20mr12265687wmj.189.1629353865008; Wed, 18 Aug 2021 23:17:45 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:adf:a191:: with SMTP id u17ls175766wru.3.gmail; Wed, 18 Aug 2021 23:17:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx1AEaaAAT1iQakHhX//sUeCjfFqwD2iN+LdmdL69MoWubjSjv5Y/nLDsDhuIudNuwopbwa X-Received: by 2002:a5d:4ac5:: with SMTP id y5mr1642157wrs.125.1629353863961; Wed, 18 Aug 2021 23:17:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629353863; cv=none; d=google.com; s=arc-20160816; b=PJMfQYl09tHP9VyNiGBuRVrFhLFwnJwYdHWHzwL86GdbCYOvYMZHIpKIPujgu/4gr+ ByK3WQxPL3TZpjNgD9SDxzqpwJCKwSwYEdVEfwcQL080ROtuThlWxarFttdSLzkUzeaB xNEWhb9WAo03c+W5JtXoZDWZF7hVRK/VZoYGGiP/NZjGziNq23Jv7ydY023I2/JwdINA +C5X8/vqozteGhM91I9P7YASnBo3I227pRtx0aoKkTs8TRvYqUXhgn4b0IHEGUchkNbC v3YZkPV6ISEFCZ46P8AXBso0EesNXt35VKmzSPQW32GAhxDbMyyvvKDffUIcelveMSec 40VA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from; bh=7ha1yDejkFU/gtAuGPwxHomvRtNYi1nfMUO/D6EuD2g=; b=tl44U+nDAqrRRaTqVqUOgTP8CVP9iH9acCOFRc5AxsjlXstBI54QHn+U/jhJuIMKz1 kC062n6qJu3/5viEJvumyfreoPSVn2lwAM89i2tFZYXBijbKThAMPWnX88itmgCNQYxY FC3Ta3fRldHf6uO++JC2mKHIhx3pP8XLFCz1o3NnFyfMYyj9X6KV2ksNj0KA2i1g+VF/ Uhfj3h1GVwcLYrQhuDg+sJRvGSUlaien6x0beU44TrrR89NUA8WtylriGZYUM7vbuTiw 8jkOd8oA8gf7CKG7Dq6fpyInzTuobzwYvyEYZsGYm9NSNIAakhw316cSaZUguVVybl2w xHMw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=ubely@ilbers.de Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id z70si574380wmc.0.2021.08.18.23.17.43 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 18 Aug 2021 23:17:43 -0700 (PDT) Received-SPF: pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=ubely@ilbers.de Received: from home.localnet (44-208-124-178-static.mgts.by [178.124.208.44] (may be forged)) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id 17J6Ha2f016099 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Aug 2021 08:17:37 +0200 From: Uladzimir Bely To: isar-users , Jan Kiszka Subject: Re: [PATCH v2 0/4] Make adjust_git work in both worlds Date: Thu, 19 Aug 2021 09:17:35 +0300 Message-ID: <5307686.rdbgypaU67@home> In-Reply-To: <4bdfae48-445b-d80a-ad1c-ce1315074788@siemens.com> References: <5292418.rdbgypaU67@home> <4bdfae48-445b-d80a-ad1c-ce1315074788@siemens.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: uO6M+GgPnL/1 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 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> > >>>=20 > >>> wrote: > >>>> On 13.08.21 14:40, Uladzimir Bely wrote: > >>>>> When I previously looked at patch.bbclass, I noted, that we don't u= se > >>>>> it > >>>>> completely. > >>>>>=20 > >>>>> There are some patch_task_patch_prefunc() and 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. > >>>>>=20 > >>>>> I suppose (but can't be completely sure without deep look to OE) th= at > >>>>> prefunc may fix this 'patch is allready applied' issue in OE. > >>>>=20 > >>>> If you can still reproduce the issue, just set PATCH_COMMIT_FUNCTION= S=3D1 > >>>> to check if it has any impact. > >>>>=20 > >>>> 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. > >>>>=20 > >>>> Jan > >>>=20 > >>> Yes, I also tried this way. > >>>=20 > >>> Actually, enabling PATCH_COMMIT_FUNCTIONS also forces to make some mo= re > >>> changes in patch.bbclass (like sys.path.insert for OE lib path) that > >>> makes > >>> the difference increase. > >>>=20 > >>> 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. > >>=20 > >> Strange. Did you try the same procedure in an OE setup, to compare what > >> happens there? > >>=20 > >> Jan > >=20 > > Not yet, while it's expected to take much time to compile. > >=20 > > Anyway, to catch the similar error, I need to find some package to rebu= ild > > 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. >=20 > Nope, this is unrelated. You just need to find a recipe that 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 without building > a complete system. In fact, you only need to force-run patch for a > specific recipe twice. >=20 > Jan I finally found the reason of failing patch in ISAR, after debugging 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 tries 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 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 t= he=20 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=3D"isar.patch" git --work-tree=3D/home/Work/isar/bui= ld- 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/met= a- 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=3D"isar.patch" git --work-tree=3D/home/Work/isar/bui= ld- 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/met= a- 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= =20 when PATCHTOOL=3D"git" =2D-=20 Uladzimir Bely Promwad Ltd. External service provider of ilbers GmbH Maria-Merian-Str. 8 85521 Ottobrunn, Germany +49 (89) 122 67 24-0 Commercial register Munich, HRB 214197 General Manager: Baurzhan Ismagulov