From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7022692424202846208 X-Received: by 2002:aa7:dbca:: with SMTP id v10mr26300704edt.280.1635163085530; Mon, 25 Oct 2021 04:58:05 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:907:d29:: with SMTP id gn41ls7588439ejc.3.gmail; Mon, 25 Oct 2021 04:58:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw1Dn16NlR29Zb8GoB+lJ9aHm24HBE6reicdPrXX24HAYCf8q5wgPbcvnTrOxQsTqY2ecid X-Received: by 2002:a17:906:660b:: with SMTP id b11mr22011107ejp.427.1635163084626; Mon, 25 Oct 2021 04:58:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1635163084; cv=none; d=google.com; s=arc-20160816; b=1LnFB/9J/mXF7rTktBC+qnpOziA346liXXwA6MvfofQ7T2X2PKHhQo6q9Mjeak2T/s /lLXh8xRHbzMhuNKOzCIlJEPdYPtP+ZMPTnT21e6Xfghbstrd2feVu9sb+J2dZt4aNe3 KFvmeDRP/30caS1vWxUut3kpd7Fn1sbg8LkZ/vmpr2fqc2fWQW92wmEwvotgMusa1oYR yex/YP63SKxx5QAxFiiP7QeS0Kv/+yy2oycESA4Tq2+I+pEQa5e4pM9aCuAJwfoKRLB7 /pgboO5sbWuhuSRSuMBP7G0KG0wjzReRVS3JjYi+fBAt8b4KLOTYHiacVNEKZTU2qSLN T5Og== 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=muC4lSi4KY0N90SEzp9+W2UNL8iTjDSLuXOl1Vo1eCw=; b=sY9m4+hyV4dIwibCT9Cm5kp2dtrpoHQhW8VsqFHyE0ztKGF2SlbQX6l/GfuKEOrbBx bIEuw13d1UhpGRzvIg5RwG4BiJCReS4JgNYmoWmCIs9K6E7jSkTenTq5qyTebwpJeg4D L/P8bZELCR34r4Fa1dVkWbrzC0OXwsRCyXFiya5sn5IALx6L1LcWzAU1R2Jg8YenD19/ XAzrVTL3XJGfbr3LBgmUTwhysvXB8c0VMoihJ3hXs4NN940xpGp95tsjqzOV9UBwkvgw Cd9eEqE3kom9W/Zf940696B/uZRMjtQ4vPUGiAg9SnJRWkkOwiD2Pl06i7UNCKkiLH7K /Ogg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id q4si982532edj.3.2021.10.25.04.58.04 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Oct 2021 04:58:04 -0700 (PDT) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id 19PBw3Es014781 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 25 Oct 2021 13:58:03 +0200 Received: from md1za8fc.ad001.siemens.net ([139.22.32.154]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id 19PBw3SQ017952; Mon, 25 Oct 2021 13:58:03 +0200 Date: Mon, 25 Oct 2021 13:58:00 +0200 From: Henning Schild To: ydirson@free.fr Cc: isar-users@googlegroups.com Subject: Re: status of meta-eid ? Message-ID: <20211025135800.090f75e1@md1za8fc.ad001.siemens.net> In-Reply-To: <647230114.1341501698.1635160542010.JavaMail.root@zimbra39-e7> References: <20211025100202.0da43e3a@md1za8fc.ad001.siemens.net> <647230114.1341501698.1635160542010.JavaMail.root@zimbra39-e7> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: jfoMtCOWiPR+ Am Mon, 25 Oct 2021 13:15:42 +0200 (CEST) schrieb ydirson@free.fr: > Hi Henning, > > > Am Sun, 24 Oct 2021 21:18:53 +0200 (CEST) > > schrieb ydirson@free.fr: > > > > > Hi Baurzhan, > > > > > > > sbuild preview is available in [1]. > > > > > > Nice! > > > > > > > If you are interested, we could share the current state. > > > > > > I still have quite a lot in dig in right now, so don't divert > > > efforts > > > :) > > > > > > My main focus for now is a bit far from this - I still need to get > > > familiar with the current state of things, with in mind the idea > > > of possibly using ISAR as a next-gen build system[1] for > > > QubesOS[0] (a bit of a personal research project to see if it can > > > help to improve the dev workflow there) > > > > > > [0] https://qubes-os.org/ > > > [1] > > > https://forum.qubes-os.org/t/ideas-for-next-generation-qubes-builder/6402 > > > > > > > Cater as a build system for an OSS project like qubes-os would be > > cool. > > I looked into 1 and it seems qubes-os is currently based on fedora. > > > > Making isar work for that would be possible but not an easy task. It > > is > > already hard to keep all the different flavours/versions of debian > > maintained and working. Plus we are building on top of > > qemu-debootstrap > > for native builds of non-host architectures. A very powerful thing > > that > > might be missing some bits in other distros. > > > > In fact Isar is not a lot of code, and most of it is very much > > debian specific. The easiest way to go might be switching base > > distros, which > > might bring you "back in time" and on a slower release cycle your > > might > > be used to. And if you carry a lot of your own spec-files, those > > will need translation into "debian/" folders. > > > > Also note that Isars main feature is building complete bootable > > images, > > or OTA-update rootfss. For more than just a rootfs, partitioning and > > bootloader stuff come into play. It also builds debian package repos > > for later offline rebuild or for shipping package-based updates with > > apt. > > If your main concern is building packages, and maybe package repos > > ... > > it might be too big of a gun (but will work). On the other hand full > > bootable image is what you might still need for automated continous > > testing in qemu or on real devices. > > > QubesOS encompasses quite a number of things, the most prominent ones > from my PoV being: > > - the virtualization layer and dom0, which happen to be fedora-based > today, but will likely not stay that way in the long run, see eg. > [0]. This one will for a start essentially benefit from better > package-building capabilities (eg. don't rebuild all dependent > packages every time) I guess that once can be moved to isar, and you might see some benefits ... depending on your current situation. For xen you might need to mess with wic plugins. (the things that do partitioning and bootloader install/configuration) But here you can change the ones in place or heave custom ones in a layer. Last time i did use xen (very long time ago) it involved several changes to the bootloader config to describe the dom0 loading. > - the VM templates, which include as standard Fedora, Debian, and > Whonix. They are indeed OS images, and it will not be a large amount > of work to produce those for Debian with ISAR, as all VM tools > already come with Debian packaging. Indeed, a VM is in fact the standard isar demo case and kind of the lowest hanging fruit. If all tools are in debian it will boil down to "IMAGE_PREINSTALL +=". Or if you have customizations it might be packages that do stuff in "postinst" (like /etc/issue /etc/motd) and pull in packages via DEBIAN_DEPENDS. These packages would then end up in IMAGE_INSTALL. > - the assembled OS itself, which is out of my scope for now (as I > understand it, it is mostly a customized installer for the dom0 OS) We have several layers where we do image-in-image. i.e. Isar built containers in isar-built rootfs. Or isar-based VM in isar based host image. > This last point excluded, the first 2 ones both need to build some > custom packages and modified versions of upstream ones, so ISAR > features still seem to address a big part of the needs. > > My plan (as outline in [1]) is to have a closer look at rootfs and > package building, to get a measure of the amount of work to adapt for > a rpm distro. I guess most of it can live in a separate meta-isar-rpm > layer, and a meta-isar-qubes can be build on top of that. Sure, get back here if you have any questions or are looking for a "pattern" to solve a particiular problem. Many things that can be done are not too obvious, or hidden in layers that are not OSS. Good public example layers are i.e. xenomai-image and jailhouse-images and isar-cip-core. Henning > > [0] https://forum.qubes-os.org/t/alpine-linux-in-dom0/7077/4 > [1] > https://forum.qubes-os.org/t/ideas-for-next-generation-qubes-builder/6402/2 >