From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6982479695616933888 X-Received: by 2002:a5d:6804:: with SMTP id w4mr8008861wru.417.1626092994016; Mon, 12 Jul 2021 05:29:54 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:600c:3b14:: with SMTP id m20ls6883296wms.2.gmail; Mon, 12 Jul 2021 05:29:53 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz/F6zt7rTD4PAeC3uXmjfN0H0At8buzZ/8uziFL1az9xUHJ72D5VUNtmSM1tpS6K9w95i1 X-Received: by 2002:a1c:9dd6:: with SMTP id g205mr38217029wme.82.1626092993155; Mon, 12 Jul 2021 05:29:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626092993; cv=none; d=google.com; s=arc-20160816; b=dZ/DfJ3uFrvUR9d2FIIRH/pSHvgwSwlSeqnZ1iyRv1fVi9Ye/MS+uhLFkMdrDCC5u/ LdV+d/sMNfi50oLvXvLEyIZ9fiL9yzFSOCXuw3GOIMrg4mE+H/RTS8m901pc/Z4XjTSd hz4NPCGGV0kN1jovcGPQ7ozkjtMwgeCmbY14oegROzlJBgZQdog1G+PsTqOj4mSS61bj hggidivftM7ur9RGs5vGGgpF+/+lsHHEiGCCLlUnSsg5Oj6lhWJke2f6/IcccE05bXL+ As4OsaJmDTzK2WaYXEIQpbSzUxj6C5/cGanX7bVrfPBhV/6lmzHCNXJLjNfL2hK6PSGp A7IA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-language:content-transfer-encoding:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :ironport-sdr:ironport-sdr; bh=lpVWH680WV2NlqCzoEj0PutoqxcRrjE0yV2SmS5UKAo=; b=kyzKvo3PdbV7TFyVVjHhWfdr/mhGnB6xtHHDVewOS0v2eIFIkGJjGWsckLNPuWFob+ 5Cy/M3wSbQ/6/l3UWyN43moG0LhzWtrwLGr8vGR/HvLvUPa8eOr1Q0xqqBh7RJQxL22I U3LWmADmaa7XMhXAHPkVnnp+jZgEic+BF2ULRKKHh34quHNtGZM0Z3TiLissfsdJFB28 KSYQjG75ZmYgMFnIrHGJf2oUwTDQQ1jcmAlcfxQONjqi5TWRp6a4PzmRlPAyANJmbeBl VE871CtIrxy1vgHAKRMksMK2hIUGdeE8XNo3Q4lRyI9G4f8Urkq1S1Jzd2e6qr0yS9w0 tnPg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of cedric_hombourger@mentor.com designates 68.232.137.252 as permitted sender) smtp.mailfrom=Cedric_Hombourger@mentor.com Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com. [68.232.137.252]) by gmr-mx.google.com with ESMTPS id n5si454204wms.1.2021.07.12.05.29.52 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Jul 2021 05:29:53 -0700 (PDT) Received-SPF: pass (google.com: domain of cedric_hombourger@mentor.com designates 68.232.137.252 as permitted sender) client-ip=68.232.137.252; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of cedric_hombourger@mentor.com designates 68.232.137.252 as permitted sender) smtp.mailfrom=Cedric_Hombourger@mentor.com IronPort-SDR: 43lAIxdcIYCyFdL0hlwWJZfgqgKCv9R0g/d2K9mePs7EHjnvh0wrYMKH6XB8PX5GhFTTJXOHmr BZOyVOEy35GdCyMj5mbO41TXBSBqZQ/zVh2F6EC2TCKU9Z2Stru9U7NzUF+e75yeyPbXjt7Jo7 ivYpA6HnpZbVOCaczlkIOXsG2FzohEI05m2fGApTWOWUvELt5m7kw05pxVVgtxwIXHferm7igi ALGo0YqhJqryGrDuJjIE5Cpfb54IKn5dTF/3JcIC2PfmVU3iQ2qSPKjxw7Z3HrRmPHJccTRjaC Jls= X-IronPort-AV: E=Sophos;i="5.84,232,1620720000"; d="scan'208";a="63588000" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 12 Jul 2021 04:29:51 -0800 IronPort-SDR: m5UyYHvkrsKBhFx5B4u0hkdkn+2MyRwfAU0ApLfkibNm9TDsoWKQzdxXBo4Beo4ii0ELGub2f3 KXUCEQbEWsCtsE+YbbLS7lkgJgTllzCtPUwPXwe65909pWBX7aZAk6BRlhYKEArei3q8RwHYA4 dmY8bANQZBhK9pZMC5lfO9hX6boieoTfarROhha3erVMSBBwRcRJFcT9s1Fc/9D9ZmUhzasAic lwElNG7MdyjAYcTg4n5KBQgxd8u6IerUujDirZe9DaJeioaKldh8DEqIT6iekswWrHOYNw1keh Z24= Subject: Re: [RFC] using lightweight containers instead of chroot To: Jan Kiszka , Helmut Grohne CC: isar-users , Baurzhan Ismagulov , "MacDonald, Joe" References: <11b6ea24-b31a-a417-bcd9-0b32c5abe308@mentor.com> <009b570c-b5ba-a7ba-2db9-c3b77e14a9e3@siemens.com> From: Cedric Hombourger Message-ID: Date: Mon, 12 Jul 2021 14:29:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Return-Path: cedric_hombourger@mentor.com X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-07.mgc.mentorg.com (139.181.222.7) To SVR-IES-MBX-03.mgc.mentorg.com (139.181.222.3) X-TUID: PO7gu+sjcvtN On 7/12/2021 1:47 PM, Jan Kiszka wrote: > 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... there is that: https://patchwork.criu.org/series/3855/ I haven't checked if the author got any luck in getting his patchset accepted > >>> 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 >