From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6690944878080163840 X-Received: by 2002:a7b:cf1a:: with SMTP id l26mr7376146wmg.18.1558527353205; Wed, 22 May 2019 05:15:53 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a5d:6904:: with SMTP id t4ls246338wru.12.gmail; Wed, 22 May 2019 05:15:52 -0700 (PDT) X-Google-Smtp-Source: APXvYqzCE6TjOuhO8ob2YYB8MbrNpmntuAI2nVC5/1d95y2d8ZqJ2d5a2RG4fGxQ8LbZpa14T1ek X-Received: by 2002:a05:6000:1284:: with SMTP id f4mr42882557wrx.325.1558527352648; Wed, 22 May 2019 05:15:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558527352; cv=none; d=google.com; s=arc-20160816; b=NU+q5ez9t+f7dV1udbLO6cEFYIQyWsL394vrFrEmEsp/vtuwibj20TpCuQtZbw1NJT 9HEaxUv8SHW2nC1w1x0hh2ccrie0SRa1vwWaf6e/HLmAeZZ/BOwKJldqRHaiLwgHxCH9 sdliFInFl2LEF4NlazL/eZFOEP94uliLEjqkLSKhKqQel2jd+VMBXmZJd9fcAGO5RGuk E+o1krmOX6BLkqd2vKSB+cQ3ESXy7ucknFsoY/um+Waew2ypq0PXoTHF3x/xzFa3vkpY 4t6O9+DuhO4RwKcSP6NwCUPrlsy+KoJ8N6GXYhPuBV8F/GSM3C3QclrWCagtS8l01g6e 16lg== 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=gtfHAWvFRikoM5l2N8X7CLFX7NT83sGCG3N1e/6zSLM=; b=STKqf9UJ14Q6DDqz+OrrXpMzKlhOyW0eKuji8MJAlXwxNAGz2RBV+EQvdEatcN722k hhjoOXZtIrzGAsMbdmogMcCKOoyeR+ZMO8itcdDeDm85JefB+dw52Yq6PlKMSp9ZP33C bhYE2ftV2d1Ju4O/IlU9u/T9dqiLUpkW+2Fmm4Kf0NJqDcxIjqy1n+h8WGFfAOQM2P9A GgmlxGjBuJUFGkiYaxqQWA0pWVWbHljG0XQzFdrQVf8mA9NQi8zT2SJZIjhX6CBLYCs4 8lkiwMvH6HEcQPjbizLlfPDg0oKhcpTOxSMBVC17zRfquxA4UzB3yy7NHp4Dxb0kjXau /T6Q== 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 z127si203621wmc.1.2019.05.22.05.15.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 May 2019 05:15: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 mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id x4MCFqAp005327 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 May 2019 14:15:52 +0200 Received: from [139.25.68.37] (md1q0hnc.ad001.siemens.net [139.25.68.37] (may be forged)) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id x4MCFpZ1029079; Wed, 22 May 2019 14:15:51 +0200 Subject: Re: [PATCH v6 1/9] isar-bootstrap-host: disable DISTRO_BOOTSTRAP_KEYS usage To: Claudius Heine , "Maxim Yu. Osipov" , isar-users@googlegroups.com Cc: Claudius Heine References: <20190515101149.22187-1-claudius.heine.ext@siemens.com> <20190515101149.22187-2-claudius.heine.ext@siemens.com> <3745f4ba-e3c9-4d59-22e4-9746c6497f6b@siemens.com> <80d56fc5-00fa-5508-7fb1-976b4b5c61db@siemens.com> <514b7749-f950-ec44-b5a2-affcbfb91e6d@siemens.com> From: Jan Kiszka Message-ID: Date: Wed, 22 May 2019 14:15:52 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <514b7749-f950-ec44-b5a2-affcbfb91e6d@siemens.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: LFtYf9iTq/gp On 22.05.19 13:39, Claudius Heine wrote: > On 22/05/2019 13.35, Jan Kiszka wrote: >> On 22.05.19 09:31, Claudius Heine wrote: >>> Hi Jan, >>> >>> On 22/05/2019 09.02, Jan Kiszka wrote: >>>> On 22.05.19 08:55, Maxim Yu. Osipov wrote: >>>>> On 5/22/19 8:37 AM, Claudius Heine wrote: >>>>>> Hi Jan, >>>>>> >>>>>> On 21/05/2019 18.56, Jan Kiszka wrote: >>>>>>> On 15.05.19 12:11, [ext] claudius.heine.ext@siemens.com wrote: >>>>>>>> From: Claudius Heine >>>>>>>> >>>>>>>> isar-bootstrap-host only supports bootstrapping Debian root file >>>>>>>> systems. Therefore deactivate any DISTRO_BOOTSTRAP_KEYS from other >>>>>>>> distributions. >>>>>>> >>>>>>> Actually not totally true, as I just realized: What about bootstrapping >>>>>>> the buildchroot from a custom debian repo that was differently signed >>>>>>> (e.g. because it is a condensed version of upstream)? Seems we do need >>>>>>> HOST_DISTRO_BOOTSTRAP_KEYS, right? >>>>>> >>>>>> You are right, I haven't considered that case. Well, the next task on the >>>>>> todo list should probably be to refactor and streamline the >>>>>> isar-bootstrap, and especially the host bootstrap process and fix those >>>>>> kind of issues while doing that. >>>>>> >>>>>> There are a lot of possible customization options gained if the current >>>>>> giant bootstrap function would be split up, similar to how the rootfs >>>>>> system works in the pre-processing patchset. >>>>>> >>>>>> Maybe it makes sense to also start renaming "host" and "target" to be >>>>>> compatible with the gcc nomenclature [1] in that patchset. I am a bit >>>>>> reluctant to do so, because of the breakage involved. But the further we >>>>>> wait, to more stuff will break downstream. >>>>>> >>>>>> The plan would be to rename all occurrences of "host" to "build" and >>>>>> "target" to "host". That would lead to the following recipe changes: >>>>> >>>>> >>>>>> "buildchroot-host" -> "buildchroot-build" >>>>>> "buildchroot-target" -> "buildchroot-host" >>>>>> "isar-bootstrap-host" -> "isar-bootstrap-build" >>>>>> "isar-bootstrap-target" -> "isar-bootstrap-host" >>>>> >>>>> >>>>>> I am on the fence of that change. Correctness vs. no-breakage >>>>>> >>>>>> Any comments about that? >>>>> >>>>> I would prefer to avoid such a renaming taking into account needed efforts >>>>> and possible confusion for current Isar users. >>>>> >>>> >>>> Is that build/host scheme then also in line with Debian naming? Then there >>>> will be eventually no way around it anyway. But we really need to do this >>>> thoroughly, specifically /wrt to user-visible interfaces, so that it will be >>>> one cut only. >>> >>>  From dpkg-buildpackage(1): >>> >>> [...] >>>         -a, --host-arch architecture >>>                Specify  the  Debian  architecture  we  build  for (long >>> option since dpkg >>>                1.17.17).  The architecture of the  machine  we  build on  is >>> determined >>>                automatically, and is also the default for the host machine. >>> [...] >>>         --target-arch architecture >>>                Specify  the  Debian architecture the binaries built will >>> build for (since >>>                dpkg 1.17.17).  The default value is the host machine. >>> [...] >>> >> >> Then the current naming scheme is already accurate for Debian. > > No? That is not how I read that documentation. "Host" is what we build for and > 'Target' is what the binaries we build generate code for (which makes only sense > for compilers) https://wiki.debian.org/BuildingCrossCompilers "Nomenclature TARGET is the architecture the compiler builds code for. HOST [...] is the architecture the compiler runs on." Mapping that on our buildchroots: buildchroot-host is where the compiler runs natively, buildchroot-target is where it runs on the target architecture. Thus, no need to flip anything. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux