From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6597265115990458368 X-Received: by 2002:a50:ac45:: with SMTP id w5-v6mr9032826edc.4.1536135384977; Wed, 05 Sep 2018 01:16:24 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a50:f5e3:: with SMTP id x32-v6ls668563edm.0.gmail; Wed, 05 Sep 2018 01:16:24 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYLe1yTxQKXOSYhmL9OQJYj9TW0qbDGUBANRFLwjsRadSjfWCklQb+D8owDig0fjgumdcRO X-Received: by 2002:a50:b602:: with SMTP id b2-v6mr9081419ede.6.1536135384631; Wed, 05 Sep 2018 01:16:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536135384; cv=none; d=google.com; s=arc-20160816; b=GGzlJvC6E6LpbI6j13Y7B5vaMFeigPHy97MIJbNnwu92XFzl8m0ZMgaghKy+sKcoEw UfODtKNHvcq+ZsSmmLqjEsit9Je59PEpsUh1SFgltg91+illRuDSRGUkjAxKQhSejpoR 4a1J4TZgFH2KzhelyE9xV2CMWvdSfYvUJHS7S8oJQGrFP9tcqg+VZmJ0t5V5zskRuG/i 34uWl9i4nzENVIa/j9fWJNx4pxSreDyyGXiYDbNmbGjBYLX5HfhzbTtGRCl7Z1UV0tda ibqJaIg4/8BnS97RSul3GA/K2gx6PhunEei6nm71kwm3uDnFOH/D3Jqt/dZH+t4Kt/6k cTFA== 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=bswlH+0VoUoLWPdjanEPS/93ut5237i5fC8WQGT9yFk=; b=vxF5HoU8UPhHF/0PoeEjxwPhAYRuHZORtOvc4/Jdl1UtKoUePuU6jyTOT1btPEjCwP PNcy3QIFrMisjChoWm6yf9/RlDwDSSiJq4Ee0GklzxI/Z/VHQJoTjQMLiY9bqUqt4/9E 2m2OVPse7T1lgQW+yuSXihASGrOhq9e+f3lErw/g5IUY57DQkTnBAiv/eQlW/wEToLoS KNhZuP2WtkIq/5WY13izfUB5ZKA+uJrrUli1QiwctKM2tuPg2gt/qriuntD2EiulqrvH 1ZdBcBe5IpnC+W7KaXM8lwknJpDhokayJekvNtk1UkLprOoceQ9Nxsv1lxylxJVuVQ0Z vHUA== 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 o55-v6si65976edo.3.2018.09.05.01.16.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Sep 2018 01:16:24 -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 mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id w858GMao000741 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 5 Sep 2018 10:16:22 +0200 Received: from [139.25.69.181] (linux-ses-ext02.ppmd.siemens.net [139.25.69.181]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id w858GMb6030515; Wed, 5 Sep 2018 10:16:22 +0200 Subject: Re: [RFC] Interface for installing bootloaders To: Jan Kiszka , 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> <61083627-3554-2d07-564e-3da2eeb63bed@siemens.com> From: Claudius Heine Message-ID: <099ded53-78c0-2fa9-ed77-92e2ee39f2f8@siemens.com> Date: Wed, 5 Sep 2018 10:16:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <61083627-3554-2d07-564e-3da2eeb63bed@siemens.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: 6muXbmlLvOCo On 2018-09-05 10:05, Jan Kiszka wrote: > 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... Might not be necessary, but I think I started using it, because it makes the environment and run.* files easier to read. -- 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