From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6667603680306397184 X-Received: by 2002:a5d:400b:: with SMTP id n11mr1060547wrp.7.1552550994584; Thu, 14 Mar 2019 01:09:54 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:81cb:: with SMTP id c194ls564817wmd.14.canary-gmail; Thu, 14 Mar 2019 01:09:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqzYqy3y0I14lP6AzOQO5JM5N0oevi/osAQfdOUYWHiXSC+MqFhePwnQTjqaj7lVvBCA0Oy+ X-Received: by 2002:a1c:80c3:: with SMTP id b186mr133960wmd.0.1552550878222; Thu, 14 Mar 2019 01:07:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552550878; cv=none; d=google.com; s=arc-20160816; b=OP/gKnEImAmyg5FL2AjzNYfSEPpZ71ndFDEj7u5Kjr7jTMKU6FajrHD8WD4EZbe+UW ywz0BxPho9qSkpCLGbxLy+RdgH44aK8RvFLPS5MkCRRMCclG8iC6JU6KjB0268aBqT/a dZ8v3/OjFVNIHcsH1yAeWV/z1GxhvrQhmSn1VhnjXbGSKrOCW8dTOlNK3Ik4Zq5QaOeE pjOmS/Q/ta2PqQ+2dWagYAtDXru1qVenAWDBmB/3SripFHdqQnJqW2j5gYjxL1i6LzIa VfXAGyUF0quY/lrL4fXw1o+XuhiKaNOGS9RbB3I24qGZFDkhogkrswdQy73AKsUDXdeT VW2w== 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=Dz8R7NTu4rT9YEGD0DhtTrcX8GShew/A3xXUMRCb5b4=; b=CNx5Mn1+y+q3vaKut2z96e9PhNvP2JUH/LCorjPqwaqmfdK0GcCBngobv2ehL6nlpi ojCX32SVvBRNBPNLcJxwNdu+lqy9ywVhG5GXq7HBgcEiHv1fycZ4q7CB0S3GmjqHBOEx HpP4Q98EAnPZlmAuLdeTqYUH91Te54WLUNIwC0fSKtDGnvfxZpj7gugr2Z5Jd8czlJln NtF4LZ/C9ksPE/98Nq1seXgKgv9hWty6bJU264AzmWcLnsz7PYhlUxmFPUDNPq9qslTx JzWv4FZK4w2eecI+8d9CpZu4fcb14sxCV0qXYmyVNW9q7agbzXJ7AdMgk6aTy9L+RdYQ wNKA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id m1si713268wrj.4.2019.03.14.01.07.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Mar 2019 01:07:58 -0700 (PDT) Received-SPF: pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.2 as permitted sender) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id x2E87vVT023180 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Mar 2019 09:07:57 +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 x2E87vYZ009850; Thu, 14 Mar 2019 09:07:57 +0100 Subject: Re: [PATCH 1/2] meta-isar: Separate images per MACHINE 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> From: Claudius Heine Message-ID: Date: Thu, 14 Mar 2019 09:07:57 +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: <6077c8f9-e72c-e51a-cbb2-d03645034c77@siemens.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: kjMPcKht8ZKV 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. 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