From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6995471841453146112 X-Received: by 2002:a5d:440d:: with SMTP id z13mr2313410wrq.216.1629964646995; Thu, 26 Aug 2021 00:57:26 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a7b:cb09:: with SMTP id u9ls2292648wmj.1.gmail; Thu, 26 Aug 2021 00:57:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwgIOTOyR14J+/W9jWYOnOJ1f0l2lfbtldToaBKQkc/e5anpV2YY8xszGtBHt4JIzY6b0vl X-Received: by 2002:adf:eb4a:: with SMTP id u10mr2256759wrn.11.1629964645915; Thu, 26 Aug 2021 00:57:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629964645; cv=none; d=google.com; s=arc-20160816; b=KnrHxgRBzZJe4VRwDQnNhogeoObm8q+ESsVzPNYynelaQy7kT4NZ4qvzzBLoci07Z5 6231eFMU7Zgl2xEIXn2ykP6IkTXGTmH8QEtKK/nVG2+u2FlLIbqMLZPGoFw0IkHuzAuG ti81aomke/Zsws0x985HDJsJeSdEglHQDV4WoA0ptdBpW2ro8gUEgZJS2mXRiDSuaRE/ ycKO5jswR69q1RiG/+0tkjYg1X42AJIIzUFzlyUBDnYLn3375aykD0ZrgQZuntU6JMpW WvG0BbC5XTbaX1ndzlo85ja27hW0hwEUUZ2un6gIb/qu8HWr3yibpAAKUNR/XUUNp3Pj F8tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:references:to:from:subject; bh=uYYpnIhZkcYLAcJC03N0rsRQxFRh+IT9LtuhgY3dKMs=; b=lgdT7JlcY8Gv9KL58Gvx2zAb23oXUqLscaOqcr215Pj9W6ofFF9MjEVklrOKySHxU8 1BwyQocdtkAs9qZM0iWDeua8W8uRXPV0M4rUBMyFNWapD9SDyiuiPCow/RRZGxxFrLyX VzsHZc5vANwO5W+6zlRNN7cyXrnLFtGW35McmIHINsPmcPN4BVf6DjCr7Plr4CZvM45L QOZXSTJiy1wA3+yVUOY/v7QZfsEeeT9pNT1W0umtgwzUoGJXmbUElBRbco3tVASLB+f9 TYJodPa20ktTeRyAyhJl38QTMzp3CAwnb8Bo5jS7zNOywDcqcl3zIcCd+nVtPD8iOnU8 gOWg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id c4si89403wmq.0.2021.08.26.00.57.25 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Aug 2021 00:57:25 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id 17Q7vPKO010964 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 26 Aug 2021 09:57:25 +0200 Received: from [167.87.32.3] ([167.87.32.3]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 17Q7vOow020550; Thu, 26 Aug 2021 09:57:25 +0200 Subject: Re: [PATCH v2 0/4] Make adjust_git work in both worlds From: Jan Kiszka To: Uladzimir Bely , isar-users References: <5292418.rdbgypaU67@home> <4bdfae48-445b-d80a-ad1c-ce1315074788@siemens.com> <5307686.rdbgypaU67@home> <9f02a158-a230-795a-c4a6-ed471fe9793b@siemens.com> Message-ID: Date: Thu, 26 Aug 2021 09:57:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <9f02a158-a230-795a-c4a6-ed471fe9793b@siemens.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: rkviZlXUJPOi 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