From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6667603680306397184 X-Received: by 2002:a17:906:1c46:: with SMTP id l6mr5744527ejg.9.1552566169297; Thu, 14 Mar 2019 05:22:49 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a50:9e41:: with SMTP id z59ls1378255ede.8.gmail; Thu, 14 Mar 2019 05:22:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqyjqoWnmpAL05wD4cFuyVh5VsOeIgfcASNGbq5HTV1t6A8gzTeKaXYAMORAq87P4VTYCvTN X-Received: by 2002:aa7:d914:: with SMTP id a20mr1968983edr.10.1552566168894; Thu, 14 Mar 2019 05:22:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552566168; cv=none; d=google.com; s=arc-20160816; b=P1WMCO/3lmrWV9+pB+J0lp9ToA46OEcSE1zdKDYIOSA+M+qv6FjgWH1ynHNDn0LtqA h0/ruiWsIJ7zzIOI7lsbAlBV06l0m7ySK5KL24yM3S7HOwInJzScAJBms2EtCIPChxuH 01U4JouF6tkk/vm0rimZ3jj0qPrD9p8QDKhngIxoag5MePNORbQ7SQUWBddXxiJpzZxR oCZbfytCAjEtQKwiqD0JysQZmwl6WE9nZXjpKl8WU4TNC8XZpT1t2HE36/LO0JdOcF17 cKtm2RiWu0bCakCxy570NETyKy8Nc5rtd8wyTXqWjkih1N4NRrix8uRrQ32RtjKrzlvy hGBw== 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=5RD8IXjbu3RLaNai4hpYjPcfwIsNyeSDgRDUtn7nRrk=; b=tNt/e1BF+IE32v79FzulvNGxYzx9JAFPz9/igfILIgjgUcfiuPi54iR7xj6h/JKrA0 wugOVK+isdobZH2wcCKIa+qply3bf5AArNFquX7cSibMhMoN2EbS9kuS/IkTx20iyl9o O9o78hT4+jOPtzpU1RIpO0WCPIkUtrtMYH5nAB8fx8tDDT8zZBEMZnIB+rv2Zq+YOKCG RlJ+birPallYH7uz0FESY7tWwj1GYuiZnKzjOAea0PTtUUjV8bYSEk2oAkUgXXVPB/8D VKRt9jVBMpwfTqOuf+gjhSkrvuI3/5m/i+iKp5qRmnhFk4SYKt/37cDWB0erZYvBtEMz wJqg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id i16si195828ede.0.2019.03.14.05.22.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Mar 2019 05:22:48 -0700 (PDT) Received-SPF: pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id x2ECMm5V002257 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Mar 2019 13:22:48 +0100 Received: from [139.25.69.232] (linux-ses-ext02.ppmd.siemens.net [139.25.69.232]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id x2ECMm7Z015730; Thu, 14 Mar 2019 13:22:48 +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> <2b47142e-8e89-4d79-dbf0-c2959596fb74@siemens.com> Message-ID: <03edfec6-0507-830f-0b19-995adcbaa7f1@siemens.com> Date: Thu, 14 Mar 2019 13:22:48 +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: <2b47142e-8e89-4d79-dbf0-c2959596fb74@siemens.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: HEtlXe6tom2y On 14/03/2019 09.20, [ext] Claudius Heine wrote: > 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}" Well isar-image.bbclass does not use PF for the WORKDIR. It has this entry: WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}" while the default in the bitbake.conf is: WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PF}" If images are really version-less, then I would would recommend something like this: WORKDIR .= "-${MACHINE}" PF .= "-${MACHINE}" This way the stamps should be correctly placed as well as the work dir not collide with work dirs of other machines. Cheers, Claudius > >> >> 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