From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6667603680306397184 X-Received: by 2002:a05:6402:1659:: with SMTP id s25mr1807206edx.2.1552551641277; Thu, 14 Mar 2019 01:20:41 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a50:f5a3:: with SMTP id u32ls1192227edm.2.gmail; Thu, 14 Mar 2019 01:20:40 -0700 (PDT) X-Google-Smtp-Source: APXvYqwX7/p2Fqag3jf6ElRsUvDPM/cHzfFi3U7oWaMl1kV4JCqALQnePg3+AXWq1P8zd8Slk2GN X-Received: by 2002:a50:addd:: with SMTP id b29mr1793662edd.11.1552551640797; Thu, 14 Mar 2019 01:20:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552551640; cv=none; d=google.com; s=arc-20160816; b=sVQM/FxjrW1kYGKLetuxLQUsPcEVRbKvVKJ9nnlRv4CK1TvmoqaeUg4mrNdCAYGhO3 MA25tdjiR3Yt1wSJgnNon1K6h2u9IQNOrIoREwsK+kpLgrZI66tHQpN7pQJtCytEX21b ecZTcFvUEVLksgBY7oEnz06qtCSC3ResT3FCKIB7jUChd8R+9PxZsRAHtcITiwjEth04 aa88C67VQDL/sflvpBOU4ywWX/02uVUKPfzQADyju6x+OuNVCD92ja+2OipU7I28JX7J rlh/WqdWlB5dOV+Nib07DhFDixHw9Ry/lpZvwD0RoK0L9wyi9zev9tZ968ZFU5Tq7n6b Akjw== 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=JzC765kXYF19j7sf2Sy2/in6DRK5P1Rjt46d7jJzx9s=; b=YqT+KQ4eZqozU0WNXDqJX13s4JEa90t9AXfEZjNhmNcEDTNEwg6B/IDk4tbDsO/cRj 3pB534K17haIKQjJAUmw2b+EyNjek+PHT4eBYO/cCjBIy0/5ej1+zmrqt0BMRuJRdgzA v3q2GjtJutw0wSfzPKDxgew6NfWfZNMKZJatg1KmkF5OY7iJDu/r6KVuSm2OWjvO89NJ Xe48snGWOI56FS/waM3EDaSaQxYGEyExv0n7Hl/PcSvpsE70NpNKzgyWBCJySWBFTkbF VYrj74k2aqk3b0rP54Zz5jt1w9nE+RH7OZsZvzzoq4r4TQNaMUlvtmi+7D+cOjiR7PHl z4IA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Return-Path: Received: from gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id h5si195466ejq.0.2019.03.14.01.20.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Mar 2019 01:20:40 -0700 (PDT) Received-SPF: pass (google.com: domain of claudius.heine.ext@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 claudius.heine.ext@siemens.com designates 194.138.37.40 as permitted sender) smtp.mailfrom=claudius.heine.ext@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 x2E8Ke2j001164 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Mar 2019 09:20:40 +0100 Received: from [139.25.69.232] (linux-ses-ext02.ppmd.siemens.net [139.25.69.232]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id x2E8Kdfh002718; Thu, 14 Mar 2019 09:20:40 +0100 Subject: Re: [PATCH 1/2] meta-isar: Separate images per MACHINE From: Claudius Heine To: Jan Kiszka , "Maxim Yu. Osipov" , isar-users@googlegroups.com References: <20190312202713.18792-1-mosipov@ilbers.de> <7984d051-8bf0-dff1-804d-104ad2a17af7@siemens.com> <6077c8f9-e72c-e51a-cbb2-d03645034c77@siemens.com> Message-ID: <2b47142e-8e89-4d79-dbf0-c2959596fb74@siemens.com> Date: Thu, 14 Mar 2019 09:20:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.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-TUID: KcZgPxr8cu49 On 14/03/2019 09.07, [ext] Claudius Heine wrote: > Hi Jan, > > On 14/03/2019 08.28, Jan Kiszka wrote: >> On 14.03.19 08:21, [ext] Claudius Heine wrote: >>> Hi Maxim, >>> >>> On 13/03/2019 17.42, Maxim Yu. Osipov wrote: >>>> Hi everybody, >>>> >>>> Any feedback on this patch? >>>> This is a "fast track" patch as it fixes problem which delayed the >>>> release. >>>> >>>> Thanks, >>>> Maxim. >>>> >>>> On 3/12/19 9:27 PM, Maxim Yu. Osipov wrote: >>>>> Image directory gets overwritten when running for two targets >>>>> with the same pair DISTRO and DISTRO_ARCH, resulting >>>>> start_vm script failure. >>>>> >>>>> Note: >>>>> This patch affects the bitbake multiconfig target calling syntax: >>>>> PREVIOUS: "multiconfig:$MACHINE-$DISTRO:isar-image-base" >>>>> NEW: "multiconfig:$MACHINE-$DISTRO:isar-image-base-$MACHINE" >>>>> >>>>> Suggested-by: Jan Kiszka >>>>> Signed-off-by: Maxim Yu. Osipov >>>>> --- >>>>>   meta-isar/conf/conf-notes.txt                    |  6 ++-- >>>>>   meta-isar/recipes-core/images/isar-image-base.bb |  2 ++ >>>>>   meta-isar/recipes-core/images/isar-image-ubi.bb  |  2 ++ >>>>>   scripts/ci_build.sh                              | 40 >>>>> ++++++++++++------------ >>>>>   scripts/start_vm                                 | 16 +++++----- >>>>>   5 files changed, 35 insertions(+), 31 deletions(-) >>>>> >>>>> diff --git a/meta-isar/conf/conf-notes.txt >>>>> b/meta-isar/conf/conf-notes.txt >>>>> index 87bd2dc..84049e1 100644 >>>>> --- a/meta-isar/conf/conf-notes.txt >>>>> +++ b/meta-isar/conf/conf-notes.txt >>>>> @@ -1,4 +1,4 @@ >>>>>   Common targets are: >>>>> -    multiconfig:qemuarm-stretch:isar-image-base >>>>> -    multiconfig:qemuamd64-stretch:isar-image-base >>>>> -    multiconfig:rpi-jessie:isar-image-base >>>>> +    multiconfig:qemuarm-stretch:isar-image-base-qemuarm >>>>> +    multiconfig:qemuamd64-stretch:isar-image-base-qemuamd64 >>>>> +    multiconfig:rpi-jessie:isar-image-base-rpi >>> >>> I am not a big fan of having to specify the machine when building a >>> image. >>> >>> Would it be possible to have virtual recipes? >>> >>> IMO all isar-image-base-* would provide a isar-image-base. >> >> That would be useful if it has no unexpected side effects. Can we >> exclude that we end up with multiple providers in some scenario? It >> seems so, but I'm not 100% sure ATM. > > IIUC want is needed here is that the workdir of the images contain the > machine. We can do that indirectly via modifying the PN or directly via > modifying the WORKDIR. I looked at the bitbake.conf. PF would be better to contain the machine, since that will also affect the stamps. Like this: PF .= "-${MACHINE}" > > Maxim choose the first option in this patch and that changes how the > target name of that recipe as well. I don't know why he choose to change > the PN, but if that was what is required for other reasons, then ok. But > I am not in favor of changing the target name since that breaks the UX. > My suggestion is just the easiest way to fix the UX. > > We will end up with multiple providers if someone writes recipes that > provide the same target name, we cannot really do anything about this. > > IMO this patch should not be merged from one rc to the next, because it > breaks the user interface. Renaming the core targets is a pretty big > change. > > Cheers, > Claudius > -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de