From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6995471841453146112 X-Received: by 2002:ac2:5e84:: with SMTP id b4mr9084351lfq.169.1629354097782; Wed, 18 Aug 2021 23:21:37 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:9d43:: with SMTP id y3ls829456ljj.4.gmail; Wed, 18 Aug 2021 23:21:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyuYD94q9e9mUw1wjp5QhQpt6k6K+htzfFhbj/7rW4/VlSLg4YIgRjRoX7//VkMMXfusf0b X-Received: by 2002:a2e:bc29:: with SMTP id b41mr10616368ljf.176.1629354096517; Wed, 18 Aug 2021 23:21:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629354096; cv=none; d=google.com; s=arc-20160816; b=cjPUTlKyyONKF/cjxPNlTmR3zJIMDibvSzc1sahs3xT4lT9pAX74sosDNcvr/H7HK2 bx6sTAc67OXxQ2e9hNNI22iP4jx5DokqEdTJr94d3M+xEyRkMLdfDLZLfzRnBwc0IHRz 9g5jBLgS0fIAbn4++CgkvqvONdB8OVLdpWIw5RyNFLRBns30lHvqk/gVSpMgAO6f0OYF bBKl9vgpfLFIeAmFbqgwvAQjMnEllzwzBFf1Om2QaLljKdW2Wnas1LF0IXJJira4hAE6 03I+JeK+rKr8mI7gz4416bKc4upFgBnFM/7Oiz0TDlw7Uv7opMjlqa4/F5330pCugBhz /fLA== 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:from:references:to:subject; bh=DXYISfiMQy1i4vdJnEtCP9rhBJEBRjfEa5/QbCaw2iI=; b=lYFPTD7dDiMRLsDN78eJLlc630NIxIliETM1lWAaXz2nGYdv/yw+UHbFVtHAVoRfUC 8aUuClx5zgb/f8xrMRwkpeqGlYBn1pUvtwnP2w9XVnmrsw9JLrxH9T4w4y2Ckbl/7Xq/ sQxxN0EwZlOOgXlES3x+fjfj7Rt7WXrZkDf00EUeNHkQkBkK1JpXsfrHNgoPkBHLek5Y L2cBvGZG8X5f1T4NU2W5FkVUNQt9wQS1P6QYHtzRwAu9vVLucv9dBz/upR9pd4lsENln CjiFl0fV6+TVvY1bT/6WNEzT6JjsQGodkAcpp7HnkZ5MFq41nSDcvt6hCbO8We2PLuU+ ZkTg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 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 lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id h11si148303lfc.4.2021.08.18.23.21.36 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Aug 2021 23:21:36 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 as permitted sender) client-ip=194.138.37.39; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.39 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 lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id 17J6LZit002777 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 19 Aug 2021 08:21:35 +0200 Received: from [167.87.0.29] ([167.87.0.29]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 17J6LYpu027032; Thu, 19 Aug 2021 08:21:35 +0200 Subject: Re: [PATCH v2 0/4] Make adjust_git work in both worlds To: Uladzimir Bely , isar-users References: <5292418.rdbgypaU67@home> <4bdfae48-445b-d80a-ad1c-ce1315074788@siemens.com> <5307686.rdbgypaU67@home> From: Jan Kiszka Message-ID: <9f02a158-a230-795a-c4a6-ed471fe9793b@siemens.com> Date: Thu, 19 Aug 2021 08:21:34 +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: <5307686.rdbgypaU67@home> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: qh04l0lfnEog 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. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux