From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6982479695616933888 X-Received: by 2002:a05:6512:3c83:: with SMTP id h3mr35073434lfv.387.1626090446775; Mon, 12 Jul 2021 04:47:26 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:651c:a04:: with SMTP id k4ls2813456ljq.8.gmail; Mon, 12 Jul 2021 04:47:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwdszM6Cfh7KEoUgS99MsbWq5eKfDYnZ9FZodSTXpu5TJ+5zqGYlypmGTLXXkQzIFr37vx8 X-Received: by 2002:a2e:3101:: with SMTP id x1mr42947120ljx.70.1626090445649; Mon, 12 Jul 2021 04:47:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626090445; cv=none; d=google.com; s=arc-20160816; b=WFl2kpez1sA+k60g5kqQiv0xz79XI474/MEhM6vb7rbbLDEMaM9DdqyuMSO+ipv9Od 8s90kyoDXoUxVw1Ta/jOZSMnr8Sl20ZoDv7gwtQEI3u7+jya+N7dB0+Gttjna7nAIkVw cUKwMfVnOVzLCUaKI8jCnucMhdOEj88Fd7KnbXOBedUu6MXhLNpHWFKrjCdhghJl3BTw hXBcvw/lRUemUO7jE60Aln/A0KeMSZ23eQz7jxJWUb3a+gaMwIIYeLXnv0rJs0y6sQxK CXRRGLpP1kXZNSLnejxD9C228t3sfkF1+JJRPVWLTGTPAMNpnORKQi2sENA4Wd0Llhx/ wEYg== 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:cc:to:subject; bh=XQxEDUlCHdKHFR2KELMV5fT6LguNzYEnRjTxwtnyW2E=; b=NiygAGeC+f3Of8aGVAiIGWbJLVLiyaQL40jMONdDOXegsVoqu+vYB6SZFc9+x79j1e SE2xA6cexDSPPliYJO8KXKSQGbOeL0/ngWeUwpYVqIVvFZf5306jJTLattuNDZ+7mXFB QmQJ7UZ5Y5S8phsg20lcRClNJlMSobiyH5mdsn05qCPmaM2Lckh3NQ0vCBy4P7IZDd4v PB5ZvwRzJkzjrg+jzO6jerUSDKCbOpgxlbFkNKgnkq00xQI48YGpT6087H8g4bgMZugY 0MUwBMY7HCBewG9cqwhwuSHgIufMECmYbEA51uJhnRjldy0bWhDhGPIF8Zkq1VoS4vnQ WBjw== 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from gecko.sbs.de (gecko.sbs.de. [194.138.37.40]) by gmr-mx.google.com with ESMTPS id bn2si420044ljb.7.2021.07.12.04.47.25 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jul 2021 04:47:25 -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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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 16CBlOVM019601 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 12 Jul 2021 13:47:24 +0200 Received: from [167.87.3.139] ([167.87.3.139]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 16CBlNG5010866; Mon, 12 Jul 2021 13:47:24 +0200 Subject: Re: [RFC] using lightweight containers instead of chroot To: Helmut Grohne Cc: Cedric Hombourger , isar-users , Baurzhan Ismagulov , "MacDonald, Joe" References: <11b6ea24-b31a-a417-bcd9-0b32c5abe308@mentor.com> <009b570c-b5ba-a7ba-2db9-c3b77e14a9e3@siemens.com> From: Jan Kiszka Message-ID: Date: Mon, 12 Jul 2021 13:47:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: iTmYnn5YMFM7 On 12.07.21 12:54, Helmut Grohne wrote: > Hi Jan, > > On Mon, Jul 12, 2021 at 10:25:41AM +0200, Jan Kiszka wrote: >> On 08.07.21 21:34, Helmut Grohne wrote: >>> The reason to want DPKG_ROOT is to prepare the root filesystem for your >>> embedded board. If that's not what you want to do, DPKG_ROOT is not your >>> tool. >> >> We want it for both the board and the build env. We have the same issues >> to solve there, means installing packages in unprivileged manner, either >> for target arch or the builder arch (cross and native builds need to be >> supported). So I see DPKG_ROOT as a building block for both. In >> addition, it would overcome qemu-user, which is speed gain. > > No. Let us for a moment assume that DPKG_ROOT would just work for all > packages in Debian (and that is a far stretch really). Then you'd be > able to install your Build-Depends into a directory without using > chroot. But how do you build your package then? You need to chroot the > dpkg-buildpackage call. So you are back to requiring chroot, at which > point you can just install your whole build environment using chroot. > > DPKG_ROOT is the wrong tool for that job. The one thing that it fixes is > requiring qemu for the embedded filesystem image. Cross builds already > work entirely without qemu (including package installation). > We can't cross-build all packages, unfortunately. That's why we will continue to require native installations for some packages' buildchroots, just like we obviously do for the target rootfs. If you can create and also augment (install deps) those without qemu, you gain speed. Granted, those continue to require qemu for the actual build. Which brings me back to still having to add namespace support to binfmt_misc... >> Yes, we prepare (ad-hoc debianization) or patch or just use >> debian/control for that. Packages should then be taken from the >> configured deb repos, including local isar-apt, and using a pre-defined >> apt database (only updated once so that all builds use the same package >> versions). Local caching of the fetched deb packages is used in >> addition, both as optimization as well as a building block for offline >> builds. > > I'm sorry, but none of this explains why you need to patch a package > after it is unpacked. > > Before building starts, you can just download all the packages that are > to be patched, patch them and include the patched ones in isar-apt. At > that point, you can run without hooks. Which implies fetching and unpacking them first. Yes, that might happen in Isar without bothering the builder, and that might be a way to not having to intercept its regular run. We don't do that right now, we just kick off dpkg-buildpackage on the unpacked sources. We also do that so far for packages that don't come as source packages in the first place but as debianized repos or as ad-hoc debianized sources (deb_debianize or local debian/ folder coming from an Isar layer). Those would require an upfront source package creation as well, something that dpkg-buildpackage currently does while building. Possibly cleaner. > >> One purpose of Isar is ad-hoc fix-ups for upstream Debian packages. E.g. >> to inject patches before they are accepted upstream or to address issues >> that are not compatible with upstream packaging. Recent example: >> https://github.com/siemens/meta-iot2050/commit/a1d35d5a3494236b2cdb0bd310c3ff0d4600d955 >> (some patches not even accepted upstream yet but needed). > > I do see why you need to patch packages. I do not see why that needs to > happen inside the build. Why not do it before building? As long as it happens in the same Isar build run, that is fine, I agree. > >> This procedure should be automated and expressed with very few >> statements. The current approaches we have are far from optimal, but the >> vision remains that you just tell Isar the package, the patch, and then >> it does whatever is best from Debian perspective. That may include the >> mentioned source package patching upfront. That will have to go into our >> recipes and classes. > > That sounds a lot like your requirement is a consequence of your current > implementation and not an actual requirement. I fully agree that such > patching needs to be simple to perform and (unfortunately) is a frequent > thing to do. Just the how we do it is sub-optimal both in Isar and > rebootstrap. We are not bound to the current implementation, just the "user interface" should not be needlessly changed. Means that the user provides source URIs, artifacts etc. via bitbake recipes and gets a patched and (re-)built package when building the related target. > >> Sure. We are not building hundreds of packages, but it also not only >> about building one or two. The other reason is the mentioned identical >> versions in all buildchroots. Reproducing them must provide identical >> content (where common) for a single image build run. > > I think I already debunked the performance aspect. For reproducibility, > you do want a clean build to reproduce the artifacts of a previous one. > Reproducibility needs to work regardless of whether you cache the base > image. Indeed, the reproducible folks are working on reproducible > installations somewhat and the dpkg-root-demo explicitly verifies > reproducibility (given the same inputs, but you do cache them anyway for > offline builds). > > So again, the requirement of caching an image seems to be a consequence > of your current implementation. In parts but not generally, as you pointed out yourself ("given the same inputs"). > >> Currently, we have no secure container env. The container simply serves >> as deployment tool of Isar's dependencies and builder-side >> configurations so that you can run it on any distro, not only Debian. >> And you can run it in CI identically to your host. > > If your docker container is not setup securely, you can make it support > user namespaces and be done. :) You seem to confuse containers and docker. Our vision is unprivileged podman (or also docker-whatever, if that is still around by then) being able to build complete images. Still a long way to go, though. > >> Isar users use Isar, they usually do not modify the core. And the goal >> of Isar is to avoid that they have to but rather provide easy means to >> configure things that must be configurable. If the builder would fall >> under this, e.g. no one build would build all types of packages (hope >> that is not the case, so far it wasn't), it would become an Isar >> requirement to switching them without much effort. > > How would I disagree with that? Of course providing users with the > flexibility to switch their builder turns out to become a requirement > once users rely on it. However, the "without much effort" part is the > thing that mdbp is supposed to provide. In theory, your builder becomes > a shell command with a sane default and your user can change that one > command to switch the builder, because the API differences are hidden > behind a common mdbp API. > >> That is a valid point we need to keep an eye on. If mdbp solved that >> already, it would be one of the added values I mentioned that could make >> it relevant for Isar, even if not requiring to switch builders. > > Great. Given that builder-flexibility seems to be a non-requirement for > you, I suggest that you use sbuild and look into the mdbp-sbuild > implementation to figure what kind of settings you need to fix to make > it reproducible. That's also a form of using it. ;) > Good! :) Thanks, Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux