From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6597265115990458368 X-Received: by 2002:adf:f40e:: with SMTP id g14-v6mr3298038wro.1.1536134704486; Wed, 05 Sep 2018 01:05:04 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a7b:c056:: with SMTP id u22-v6ls315609wmc.2.gmail; Wed, 05 Sep 2018 01:05:04 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaxjDJEo0VWXvFmvGwu6LEK07s79ryaJOFcCOXt7bkNezi3FPgYiQXES4KAtDGFLswjxotT X-Received: by 2002:a1c:705:: with SMTP id 5-v6mr1698842wmh.4.1536134704111; Wed, 05 Sep 2018 01:05:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536134704; cv=none; d=google.com; s=arc-20160816; b=BAzTWfxlV+NfBqBnd8ueb++eucSXR1gcvWnYu1YtQSxtvMFYa/+V0Sac7KI7YtTXfW 53axsg6zuCwiz5z/KqxIJ4EFNe4UyOleBu1VI65YYDo++WInA9ogWYcM56EFYjMWDqIR ccIJqY+40dF1ISUqAo630D46tpnFI1guuogmGuOmVLOAMm7QxiKC2kIBXsn8b/AwZzG+ SigLFC7XmniACvGJfZhBwMooPwN5ril+dWcd0lcZFOxKf4T6EbSTfkrSuoilJljVX02U x1NTKDgq0EWBCkUme4hjNimD18ZTe/rtzDxOjbR6QzkGXbC5DMJY4lTv3435QEOs9chf KTCA== 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=8hXU8SpyyAbmKzYn1NJvb3VcF5NhMxlcVO+7j79Ev1g=; b=QCE1WaaJH2B8EUQWYMJAUMGNPYTcGTOoLxFsyfMlt+bdzfqJTPCxZE1LHHdhAUkmOk gq0+ahhvTqqejDpGWyf82BwoIgRIKWOe3eAGVr5JAVOfBIUS45lh4l7JwdYGy0EWieYM P0D4YnhmPRd7DTGI4jLMUDHnTrOsJLqVZcIeq9ECS0rVrfBmXkhsattkacxj0UW+KYGs qA3JW/Me/nBk2/gf5HAW3A8XF+pMPclH2pcAMxV9p2ilXvv+6Fh3j+m6C2auCizqLxsm K/qpciJ0D4HjJTI5sOHRoo+wZbDfWgO+TxqBGz3uGBzDWwV3I1F0P15aEVGe8yWmmkm/ y+GA== 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 Return-Path: Received: from gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id b192-v6si46262wmd.2.2018.09.05.01.05.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Sep 2018 01:05:04 -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 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 w85852qe012638 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 5 Sep 2018 10:05:02 +0200 Received: from [167.87.2.38] ([167.87.2.38]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id w85851Km021732; Wed, 5 Sep 2018 10:05:01 +0200 Subject: Re: [RFC] Interface for installing bootloaders To: Claudius Heine , isar-users , Claudius Heine , Henning Schild , Andreas Reichel References: <0aeb9010-8fed-6094-ac12-41983c3831ae@siemens.com> <4ae0dc9d-7fa4-9fa0-7844-aab25579fdb7@siemens.com> <11e15a42-0fa6-cda7-c9c0-4c60ea2b551c@siemens.com> From: Jan Kiszka Message-ID: <61083627-3554-2d07-564e-3da2eeb63bed@siemens.com> Date: Wed, 5 Sep 2018 10:05:01 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: KlGCu7wghp8k On 2018-09-05 09:57, Claudius Heine wrote: > On 2018-09-05 09:47, Jan Kiszka wrote: >> On 2018-09-05 09:34, Claudius Heine wrote: >>> Hi Jan, >>> >>> On 2018-09-05 08:08, Jan Kiszka wrote: >>>> On 2018-09-04 11:27, Claudius Heine wrote: >>>>> Hi Jan, >>>>> >>>>> On 2018-09-04 09:17, [ext] Jan Kiszka wrote: >>>>>> Hi all, >>>>>> >>>>>> for installing a bootloader into an image, a number of packages >>>>>> have to be installed into the buildchroot. These can be prebuilt >>>>>> packages or packages we build via Isar. Currently, we only handle >>>>>> the case of WIC requiring prebuilt Debian packages, and that in a >>>>>> hacky way (no proper distro abstraction, unneeded installation of >>>>>> unused dependencies). This proposal aims at providing a more >>>>>> holistic solution: >>>>>> >>>>>> - Introduce new variables that express the two types of dependencies: >>>>>>     - BOOTLOADER_PREBUILT >>>>>>     - BOOTLOADER_CUSTOM >>>>>> >>>>>>    So there is no "WIC" in these, any imaging recipe can use them. >>>>>> >>>>>> - Imaging recipes (e.g. via classes/wic-img.bbclass) should >>>>>>     - install all packages from BOOTLOADER_PREBUILT and >>>>>> BOOTLOADER_CUSTOM >>>>>>       into the buildchroot >>>>>>     - DEPEND on all recipes in BOOTLOADER_CUSTOM >>>>>> >>>>>> - Define some common dependencies in conf/distro/${DISTRO}.conf: >>>>>>     - GRUB_PREBUILT >>>>>>     - GRUB_PREBUILT_append_${DISTRO_ARCH} >>>>>>     - SYSLINUX_PREBUILT >>>>>>     - ... >>>>>> >>>>>>    Those variables can then be used to initialize >>>>>> BOOTLOADER_PREBUILT as >>>>>>    needed and also replace those nasty BUILDCHROOT_PREINSTALL_WIC in >>>>>>    buildchroot-target.bb. >>>>>> >>>>>> - Set BOOTLOADER_PREBUILT or BOOTLOADER_CUSTOM in the >>>>>>    conf/machine/${MACHINE}.conf or some overriding conf file - >>>>>> basically >>>>>>    the same one that selects IMAGE_TYPE and WKS_FILE. >>>>>> >>>>>> Anything I missed? Better suggestions? Eventually, when we can >>>>>> derive bitbake recipe dependencies automatically from package >>>>>> dependencies, PREBUILT and CUSTOM could be folded together. Right >>>>>> now, we need that split. >>>>>> >>>>>> Jan >>>>> >>>>> I have a class that I use for the current project that allows >>>>> installing additional packages into the buildchroot from within the >>>>> image. I didn't had time to prepare patches for it for mainline >>>>> isar. But maybe that goes into to right direction. >>>>> >>>>> I attached it. >>>> >>>> ... >>>> >>>>> BUILDCHROOT_EXTRA_INSTALL ??= "" >>>>> >>>>> MOUNT_LOCKFILE = "${BUILDCHROOT_DIR}/mount.lock" >>>>> >>>>> BUILDCHROOT_DIR ??= "${BUILDCHROOT_TARGET_DIR}" >>>>> BUILDCHROOT_BUILD_DEP ??= "buildchroot-target:do_build" >>>>> >>>>> do_buildchroot_extra_install[depends] = "${BUILDCHROOT_BUILD_DEP}" >>>>> do_buildchroot_extra_install[deptask] = "do_deploy_deb" >>>>> do_buildchroot_extra_install[stamp-extra-info] = >>>>> "${DISTRO}-${MACHINE}" >>>>> do_buildchroot_extra_install() { >>>>>     PACKAGES="${@" ".join(d.getVar("BUILDCHROOT_EXTRA_INSTALL", >>>>> True).split())}" >>>>> >>>> >>>> Can you explain the magic dance in the line above? I don't see its >>>> need yet. >>>> >>>>>     if [ -z "$PACKAGES" ]; then >>>> >>>> ...provided you do "[ -z $VAR ]" here to catch VAR=" ". >>> >>> In sh i get: >>> >>>    $ tets="asdf asdf  asdf asdf" >>>    $ [ -z $tets ] && echo yes >>>    sh: 2: [: asdf: unexpected operator >> >> Ah, that's what I missed. But then we want to .strip() the variable >> for testing, rather than split/rejoin. > > Might work, but I don't like having possible '\n' and '\t' in between > package names. (Ok, '\n' might not be an issue, since I think bitbake > already escapes that.) > > For me that is the normal code snippet to convert bitbake 'arrays' into > shell strings. I find this pattern in pure form in exactly one poky recipe. Therefore I'm not sure we need it in order to make a list built under bitbake in various ways available as parameter string for a shell command. Let's see... Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux