From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6655521619015892992 X-Received: by 2002:a1c:2088:: with SMTP id g130mr1066342wmg.6.1549643280234; Fri, 08 Feb 2019 08:28:00 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a5d:544c:: with SMTP id w12ls1276570wrv.13.gmail; Fri, 08 Feb 2019 08:27:59 -0800 (PST) X-Google-Smtp-Source: AHgI3Ia/MJ8kskjPc5v42Ml+6fPuYtcx1LTECjrzXLL9ABcVCWki9yu+biZkYkfB/QIMivOVpEz5 X-Received: by 2002:a5d:564d:: with SMTP id j13mr179892wrw.27.1549643279654; Fri, 08 Feb 2019 08:27:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549643279; cv=none; d=google.com; s=arc-20160816; b=Jl7Kd1E3qSJHsMl/WZ0O4PdUUss8TnBQDFxUrPuGMaI5SH669PTPHK688OUX/7npAY ts1T0Jvwm02KxUw6UyHvb8twaU+V8bGba0l9PfwxIdJzyVbINK0PrkpJjFTPMOrftj2S EkwZbPssDEiW36U+aX5aL0/2da0/SpzrV54qFQcnggjche8xnBrDEz+qJ6bIIggOlqKX qA1+a00mdGuTG0C+dPCBfZo88FyEFs7/pUNudk39GModRUIhfPEVmZoGkciYxKZwaPlv GYYbzhHYpCJstw2j4LgcH6RwogzL1kwqHPvHnJRIkmXF2EJB18gIhE//64gztHNXozTW P1og== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date; bh=VDz4EFQpHa08GXuK25AN2oRwTgh8WmRrSWu/iro5kS0=; b=x4p1vOEwTzpUWv4CTKXI8xf5KduGCSBsgGGUKKxHMIPM5wVZxv8T4qYHp2/kzJBKr/ ZF2HTwm6Td/U9pvvQiVH+L+pu0t8Bw/NRSw5r9OrZ5ekWZcnzA15b2H+dbm3hxIfGMhf mKKwNb1CVXyQJ8ELADJUEDdbpCLCVe84HQrCD3eUH6ZCTlKhZQIEISJUBx1xjHlRD3xF rc/JZ1LnBBPrv3XqZ+sGBYyrurr1popo6FMafzWNcic7nZZVdWiWLQDvQz9F73x8cEzd JOVYGRoBiB8F9lg4xT+n7u7SCMOQ5+dDAN5bkCE3T+Jga88BQHUvd613b9HzyZ3NJMS2 b0Pw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id l22si362886wmg.4.2019.02.08.08.27.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Feb 2019 08:27:59 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@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 henning.schild@siemens.com designates 192.35.17.2 as permitted sender) smtp.mailfrom=henning.schild@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 x18GRweR021394 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 8 Feb 2019 17:27:58 +0100 Received: from md1za8fc.ad001.siemens.net ([139.25.0.64]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id x18GRxnd003282; Fri, 8 Feb 2019 17:27:59 +0100 Date: Fri, 8 Feb 2019 17:27:58 +0100 From: Henning Schild To: Jan Kiszka Cc: Cedric Hombourger , Subject: Re: [PATCH] wic-img: handle variables in .wks files Message-ID: <20190208172758.38f7e6c1@md1za8fc.ad001.siemens.net> In-Reply-To: <723aeb7d-85be-0907-fa22-f41fd02e7daa@siemens.com> References: <1549609367-1025-1-git-send-email-Cedric_Hombourger@mentor.com> <20190208152832.4a1a88b2@md1za8fc.ad001.siemens.net> <723aeb7d-85be-0907-fa22-f41fd02e7daa@siemens.com> X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: xOWlh/fe76cD Am Fri, 8 Feb 2019 15:31:48 +0100 schrieb Jan Kiszka : > On 08.02.19 15:28, [ext] Henning Schild wrote: > > Not sure i get all the context right ... But if you are introducing > > a template mechanism to generate .wks files, have a look at the > > patches from Claudius that are currently pending. > > He introduces a generic templating mechanism which may be useful for > > generating .wks files as well. > > That is a different mechanism, not intended for patching recipe files > (which wks files are). We align with OE here as far as I can see. I would not agree. wks-Files are configuration for a tool we call in a recipe, just like debian/ is for dpkg-buildpackage. I guess the following should work with Claudius patches SRC_URI+=file:///my.wks.tmpl and WKS_FILE=WORKDIR/my.wks WICVARS are another way of passing configuration to wic, here it is about all the bitbake vars that your plugins want to access, not about vars that you might want to substitute in a .wks.tmpl before even calling wic. Afaik wks files can not contain variables anymore. But i guess we should all see the examples to understand where the code is coming from and what it is for. Henning > Jan > > > > > [PATCH v2 1/1] meta: added do_transform_template task as templating > > system and switch > > > > You could give that a try and maybe still vote for or against that > > mechanism. At the moment i would say it is likely to go in, and > > consequently other/future templating mechanism will we be > > questioned. > > > > Henning > > > > Am Fri, 8 Feb 2019 08:02:47 +0100 > > schrieb Cedric Hombourger : > > > >> Isar will now generate .wks from user-specified templates with > >> variables such as $ROOTFS_TYPE or $ROOTFS_SIZE replaced with their > >> values. Custom variables may be substituted by adding them to > >> WKSVARS (WKSVAR += FOO) > >> > >> Signed-off-by: Cedric Hombourger > >> --- > >> doc/user_manual.md | 2 ++ > >> meta/classes/wic-img.bbclass | 31 ++++++++++++++++++++++++++++++- > >> 2 files changed, 32 insertions(+), 1 deletion(-) > >> > >> diff --git a/doc/user_manual.md b/doc/user_manual.md > >> index ebc31c6..ea3b4bd 100644 > >> --- a/doc/user_manual.md > >> +++ b/doc/user_manual.md > >> @@ -197,6 +197,8 @@ A bootable disk image is generated if you set > >> IMAGE_TYPE to 'wic-img'. Behind th $ bitbake > >> multiconfig:qemuamd64-stretch:isar-image-base ``` > >> > >> +Note: `.wks` files may use the ROOTFS_SIZE and ROOTFS_TYPE > >> variables (as well as any other bitbake variables added to > >> WKSVARS). + In order to run the EFI images with `qemu`, an EFI > >> firmware is required and available at the following address: > >> https://github.com/tianocore/edk2/tree/3858b4a1ff09d3243fea8d07bd135478237cb8f7 > >> diff --git a/meta/classes/wic-img.bbclass > >> b/meta/classes/wic-img.bbclass index 76602d8..16bbc53 100644 > >> --- a/meta/classes/wic-img.bbclass > >> +++ b/meta/classes/wic-img.bbclass > >> @@ -81,6 +81,32 @@ addtask do_rootfs_wicenv after > >> do_copy_boot_files before do_wic_image do_rootfs_wicenv[vardeps] > >> += "${WICVARS}" do_rootfs_wicenv[prefuncs] = 'set_image_size' > >> > >> +WKSVARS += "ROOTFS_SIZE ROOTFS_TYPE" > >> + > >> +python do_rootfs_wksenv () { > >> + wksvars = d.getVar('WKSVARS', True) > >> + if not wksvars: > >> + return > >> + > >> + stdir = d.getVar('STAGING_DIR', True) > >> + outdir = os.path.join(stdir, d.getVar('MACHINE', True), > >> 'imgdata') > >> + bb.utils.mkdirhier(outdir) > >> + basename = d.getVar('IMAGE_BASENAME', True) > >> + with open(os.path.join(outdir, basename) + '-wks.sh', 'w') as > >> envf: > >> + for var in wksvars.split(): > >> + value = d.getVar(var, True) > >> + if value: > >> + envf.write('%s="%s" \\\n' % (var, value.strip())) > >> + envf.write("envsubst '") > >> + for var in wksvars.split(): > >> + envf.write('$%s ' % var) > >> + envf.write("'\n") > >> +} > >> + > >> +addtask do_rootfs_wksenv after do_rootfs_wicenv before > >> do_wic_image +do_rootfs_wksenv[vardeps] += "${WKSVARS}" > >> +do_rootfs_wksenv[prefuncs] = 'set_image_size' > >> + > >> WIC_IMAGE_FILE ="${DEPLOY_DIR_IMAGE}/${IMAGE_FULLNAME}.wic.img" > >> > >> do_build[stamp-extra-info] = "${DISTRO}-${DISTRO_ARCH}" > >> @@ -99,8 +125,11 @@ do_wic_image() { > >> export BUILDDIR=${BUILDDIR} > >> export MTOOLS_SKIP_CHECK=1 > >> > >> + /bin/sh > >> ${STAGING_DIR}/${MACHINE}/imgdata/${IMAGE_BASENAME}-wks.sh \ > >> + <${WKS_FULL_PATH} > >>> ${BUILDCHROOT_DIR}/tmp/${IMAGE_FULLNAME}.wks + > >> sudo -E chroot ${BUILDCHROOT_DIR} \ > >> - ${ISARROOT}/scripts/wic create ${WKS_FULL_PATH} \ > >> + ${ISARROOT}/scripts/wic create /tmp/${IMAGE_FULLNAME}.wks > >> \ --vars "${STAGING_DIR}/${MACHINE}/imgdata/" \ > >> -o /tmp/${IMAGE_FULLNAME}.wic/ \ > >> -e ${IMAGE_BASENAME} ${WIC_CREATE_EXTRA_ARGS} > > >