From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6790334981638979584 X-Received: by 2002:a50:ce50:: with SMTP id k16mr16113278edj.70.1586958293637; Wed, 15 Apr 2020 06:44:53 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a50:eb0d:: with SMTP id y13ls5478563edp.9.gmail; Wed, 15 Apr 2020 06:44:52 -0700 (PDT) X-Google-Smtp-Source: APiQypKqViTPiPgs6irIAcU+A62Oxtn8jg/tzAneNRk0lcKmUD9M4v0RDOwLpWvOOUY+9GXoPGL2 X-Received: by 2002:a50:c112:: with SMTP id l18mr26070146edf.37.1586958292892; Wed, 15 Apr 2020 06:44:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586958292; cv=none; d=google.com; s=arc-20160816; b=EY3pLMzZmRxA3KuRPZl2FihHBCSWiKW8vGXUiyde7r0alrpRcYEuWzLmEy3XgNdwD0 hxSO8DuEPehvGVbPJahUHp3k37SkgUeCbYyd1SfU6KOMqVbn2T5y7/lowVJ/bt5YOoVO Wh+HK6bpdoEE4mKUTVyqyE4VrSZ63g0Nik52nBAX4Y/URya3pNsMDPu9Pbzs6yP0Rb/o wALy0nVhw9YixjZbmt8nAd3LIeuyKG6QRAQo8/dFPzf4vQ5Po3rDDV09HMpuMhb5RNY8 R0qCATDw7hBgwp8IgFR3ZNg2hflykomPDqzHAZEcU1gH2sxwIDLZ5gVh6wAdCKq0khGD b8Uw== 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:cc:to:subject; bh=mioMt/3BBDnHVV2XHWZT7rWZ1YMA1FqmlAzFw1zlHfw=; b=ga7cQcw7ERSPGYafoGr9wNKElwTc36bO3OFT42AM1Q2v5JVmmHCv805ebmofBwdg76 7cwrRLP8i1wpft/LKefw/B3kzTuO6Y/UpWHemPkk4LHV62N4JaMhXVU6VLM6QTlNLM0L fbeU5pn5XIMKhjip9oDM8s+/5SJCVmprmQ9WkFgzuMU4UOblDJcCPsc+RUDrvFtMkVbL BedXN5UO5viuq3JwwCemxn+D6sqxtiENYYIeDoGCLGrRZXJtjmIPD9vbMyiXcdyTwosp b0TIV/ISDWPU3f1KtpUN+E1AZFOn0mslraH3nziHkOvVYJDW4ff9nxN777V72pWJ6Zoe UgyA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 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 gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id f24si327933edw.3.2020.04.15.06.44.52 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Apr 2020 06:44:52 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 as permitted sender) client-ip=194.138.37.40; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 194.138.37.40 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 gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id 03FDipln016232 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 15 Apr 2020 15:44:51 +0200 Received: from [167.87.150.123] ([167.87.150.123]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 03FDinEx026708; Wed, 15 Apr 2020 15:44:50 +0200 Subject: Re: [PATCH v4 2/2] meta: cache deb srcs as part of postprocessing To: vijai kumar Cc: isar-users , Baurzhan Ismagulov References: <20200403130551.2158-1-Vijaikumar_Kanagarajan@mentor.com> <20200403130551.2158-2-Vijaikumar_Kanagarajan@mentor.com> <95fef6ff-5434-fd54-3b7f-9a656a725297@siemens.com> <89a4f747-29ef-4136-adee-8258c2e2960c@googlegroups.com> <20200408081315.hb3m2vrs5bbtnoif@yssyq.m.ilbers.de> <09bbc9ef-8200-73cb-452d-4a77d28afc27@siemens.com> From: Jan Kiszka Message-ID: <80128b93-c162-1479-ddc9-7ed18cb7d831@siemens.com> Date: Wed, 15 Apr 2020 15:44:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: ohqwPXhsxCc5 On 15.04.20 15:20, vijai kumar wrote: > On Wed, Apr 15, 2020 at 12:58 PM Jan Kiszka wrote: >> >> On 15.04.20 08:44, vijai kumar wrote: >>> Hi Baurzhan, >>> >>> Is the below okay? Or should I send that with the new debsrc series? >> >> I would say add a full feature first because Isar users cannot really >> benefit from the series on its own yet, can they? > > Patch 1 had its own use case though. It paves way for downstream > layers to add their own postprocess functions which rely on a working > chroot. Atleast I had one usecase downstream(deb-src caching). Since > deb-src caching is also moving upstream I dont really see any usecase > for P1. Postprocess commands can be ordered in such a way that caching > happens before finalize. The patch still paves way for the > functionality said above for downstream layers. But now I don't have > any use cases. It is just a good to have feature now. I'm not arguing for dropping patch 1. I think we had the discussion already that it's cleaner to hard-encode that the final step is final. > >> >> We need a way to feed the fetched sources into a repo or a recipe that >> generates a shippable OSS medium corresponding to a binary image or a >> script that applies patches to the original sources so that the result >> can be pushed to OSS license scanners. I.e. we need an in-tree use case >> with a test case. > > If I understand correctly, are we also planning for the OSS clearance( > tar containing source files with patches) code to be upstream? I was just listing possible example. Maybe the first one is of most common interest. However, preparing one or more "flat" (patches applied) code archives is not an uncommon requirement when you need to feed one of those license scanners, may they be free - like FOSSology or scancode - or commercial (not wanna promote any of those). Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux