From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6683827867816558592 X-Received: by 2002:a2e:9c0a:: with SMTP id s10mr16388641lji.162.1557825751576; Tue, 14 May 2019 02:22:31 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:ac2:549c:: with SMTP id t28ls1007034lfk.12.gmail; Tue, 14 May 2019 02:22:31 -0700 (PDT) X-Google-Smtp-Source: APXvYqxhKqX4lfIYiYo3XvXoZ7r9Z3+vdtSDxB498lu0gy0pIz0FQA+dUCliv5sSA8/5meiDwnag X-Received: by 2002:a19:655a:: with SMTP id c26mr16864827lfj.97.1557825751088; Tue, 14 May 2019 02:22:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557825751; cv=none; d=google.com; s=arc-20160816; b=DyePAUy/d7cIar/fBZJZD4Pn0fODFGsD+wOI53G22QYy9EStQvfNSkQXCZ97/W59t0 79vvAxhW5i7rXBqgeZ27H4/qSxdcSvwj5rB2Z8mZIRJ2qPI+norLqkNWJ8S3cW83MBke CScjR4AG+IPMVHPADY9piFruLnLcDcKF8kPbOJdvLrG4SAG+59ta+0kjkClbarbqSs7b SUtuudv1zbHlrWY5MldtT2N65Cao/GSHm1eYYqvvJgQxLmJtgIK4LMjHG0UtJ7gCSzQs 12scG2IqIL6Q54++x60Y8baQFMBR9PyI/x8DzvH7wuGNLn/h2EPcODj0EhDDG53w6z1F u1cA== 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:cc:to:organization:from:references :subject; bh=tsrBFqSY47+o06IH7CY/qj4q7sTBroWGMDrOPvqVoSM=; b=q6G7LBhrdkdcaFC5/CCyV3ErXcNxjaGIDnTagiRXbA0jaYqJ85wghxERmklu8+OXx5 yHaZpOLEz4/nQmPuajKuRqRqN1vXZ07ZcdU/ZIrta4HerIiUJoJTftkm8p/qg7o3lUQr xlu11oXyN+i431JwqfglZ/ZYw5YSmKx6/4NIxgMm8IoEYPDXGP8OYbxlikB+RAPe8DrH 5KqxVMdkG5ohRC754021hbA19qTQjjwrLYglJK/01gPz1nkcXTGVB9K2rlO4XdMpg20q cR/caomG3yqoPKjAX/DYTWYB5RXBaXxCAXtRPuYukQtA+I7t+vNXhq5/vpar7S8YOO6L szsA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of mosipov@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=mosipov@ilbers.de Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id c22si3274738lfh.5.2019.05.14.02.22.30 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 14 May 2019 02:22:30 -0700 (PDT) Received-SPF: pass (google.com: domain of mosipov@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 mosipov@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=mosipov@ilbers.de Received: from [192.168.1.29] (115.165-131-109.adsl-dyn.isp.belgacom.be [109.131.165.115] (may be forged)) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id x4E9MPXo031706 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 14 May 2019 11:22:26 +0200 Subject: Fwd: Re: [PATCH v4 1/9] isar-bootstrap-host: disable DISTRO_APT_KEYS usage References: From: "Maxim Yu. Osipov" Organization: ilbers GmbH To: Claudius Heine Cc: isar-users X-Forwarded-Message-Id: Message-ID: <4226c9e3-cf1d-1825-1f2c-fcc1c5607679@ilbers.de> Date: Tue, 14 May 2019 11:22:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,URIBL_BLOCKED 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: kVPnb1SbAGNH Hi Claudius, Any feedback on Jan's question (see below)? I've applied v10 series "Fix usage of additional apt keys and repos" from Andreas, this results that your v4 series "Cleanup rootfs creation" has to be rebased. I can rebase it - no problem - but all pending questions should be answered first. Regards, Maxim. -------- Forwarded Message -------- Subject: Re: [PATCH v4 1/9] isar-bootstrap-host: disable DISTRO_APT_KEYS usage Date: Fri, 26 Apr 2019 13:50:50 +0200 From: Jan Kiszka To: Claudius Heine , Maxim Yu. Osipov , claudius.heine.ext@siemens.com, isar-users@googlegroups.com On 26.04.19 13:31, [ext] Jan Kiszka wrote: > On 26.04.19 09:36, Claudius Heine wrote: >> Hi Maxim, >> >> Quoting Maxim Yu. Osipov (2019-04-25 20:20:59) >>> On 4/25/19 3:44 PM, claudius.heine.ext@siemens.com wrote: >>>> From: Claudius Heine >>>> >>>> isar-bootstrap-host only supports bootstrapping Debian root file >>>> systems. Therefore deactivate any DISTRO_APT_KEYS from other >>>> distributions. >>>> >>>> Signed-off-by: Claudius Heine >>>> --- >>>>    meta/recipes-core/isar-bootstrap/isar-bootstrap-host.bb | 2 ++ >>>>    1 file changed, 2 insertions(+) >>>> >>>> diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap-host.bb >>>> b/meta/recipes-core/isar-bootstrap/isar-bootstrap-host.bb >>>> index 08b068f..3e96281 100644 >>>> --- a/meta/recipes-core/isar-bootstrap/isar-bootstrap-host.bb >>>> +++ b/meta/recipes-core/isar-bootstrap/isar-bootstrap-host.bb >>>> @@ -12,6 +12,8 @@ DEPLOY_ISAR_BOOTSTRAP = >>>> "${DEPLOY_DIR_BOOTSTRAP}/${HOST_DISTRO}-${HOST_ARCH}" >>>>    ISAR_BOOTSTRAP_LOCK = >>>> "${DEPLOY_DIR_BOOTSTRAP}/${HOST_DISTRO}-${HOST_ARCH}.lock" >>>>    require isar-bootstrap.inc >>>> +# We only build debian host buildchroot environments >>>> +DISTRO_APT_KEYS = "" >>> >>>   From the first glance this modification limits functionality. >>> It looks like a hack and I would suggest to avoid this modification. >> >> Well it is a fix and that limited functionality was already present but >> just implicit, hidden behind some bug and the cleanup just made it >> appear. >> >>> Some time ago I thought about introduction of HOST_DISTRO_APT_KEYS to >>> avoid confusion between target and host apt keys. >> >> Good idea. But that would be a new feature/improvement. >> > > If that is just about adding and documenting another variable, let's not discuss > about when and who because just doing that will already be faster, even if it's > a "drive-by" improvement /wrt this patchset. > OTOH, I don't get the problem yet from just reading the commit message: Wasn't DISTRO_APT_KEYS designed to be a superset of all needed keys? We are appending raspbian to it when using that distro. So, we are at least missing the reasoning here why that model didn't work and cannot be made working for the host/target case. And then we can refer to that when introducing split key sets. Thanks, Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux