From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7221425893476925440 X-Received: by 2002:a05:6214:2347:b0:625:1c04:6761 with SMTP id hu7-20020a056214234700b006251c046761mr13269404qvb.27.1687248354623; Tue, 20 Jun 2023 01:05:54 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:ad4:5912:0:b0:626:3bf3:c6bb with SMTP id ez18-20020ad45912000000b006263bf3c6bbls1831562qvb.1.-pod-prod-04-us; Tue, 20 Jun 2023 01:05:54 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7cqEm74W6Z1sGBsbPujyNQdtSobqAVI94JzSN8L0PC3qlKaS+vdcIoZ/772V+dsZoovXyt X-Received: by 2002:ad4:5ba4:0:b0:62d:f79f:32bf with SMTP id 4-20020ad45ba4000000b0062df79f32bfmr14087179qvq.27.1687248353962; Tue, 20 Jun 2023 01:05:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687248353; cv=none; d=google.com; s=arc-20160816; b=BXShWz0ghql5+R7iq42EsfcPi5IIDgFOVFwGUerFGrjIkrMvTs5pIzt+HWzAJI9zzX 5jchQEwWV1AHeA5qPlNYSvtj5YXukNc2086qivyWBAz5a41foal8yrljl/Gpt+/8nyO4 +pmImHGrjTDXOUEshuD22BTaMsQScMfdY2Bb1Kg/GukZu4G46VU7bAmJoZp7tNTjs5dJ DY5GAVapXggKzKhiUD3vgkC4MM0YuIPV7UD8EzKJy76U+AwjYTGONX3UzvFC/iBRpFan pptAS9op9Vbu5wPGK8laWI61YXzE1fRBvCPgWHryBflPzFEfFzfkFE1wodhPD3Ve8AZg TqUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id; bh=mk8dibIMtPBDmeOf5BpozyOK5vuGybDJiXMs7OUThKU=; b=oyBLeRo/zWaH11shCKDgCc2GhBB62tjlsXvM5ru9ARvpRPBpQJv+ACIUxxw9hKJ+0l ZYEPvhE8PYvpM19k6hkPGdmX58PnRiW0MbJderl6ZEmjbsqybdVpdU90xVrz8LsULs5+ 3PuCemSHMhdOStmHSNblLuNZjDA5eOJWqPIUSXp9oYPxZEBFxh6SY4WdkGS+3ZKFKdEe ++jWSRNCbHc6CqFHh1/64tpZoL4ZyEWVvMgnwEm37DetpPtFEIHTuJVhYrGmLatddAwx cXJuGM49cDLPTmOnalK9EqkuNoEPqnY48wh+7MKsh5PVQqM5zcrCg+z4LLZJPG1GjDG4 DaUQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=ubely@ilbers.de Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id c8-20020a0ce7c8000000b006261d48d4c2si140357qvo.0.2023.06.20.01.05.53 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 20 Jun 2023 01:05:53 -0700 (PDT) Received-SPF: pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=ubely@ilbers.de Received: from [IPv6:::1] (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPSA id 35K85ouY028876 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Jun 2023 10:05:51 +0200 Message-ID: <9bf66c024175106a960d4cc687402c6c8ecf948c.camel@ilbers.de> Subject: Re: [PATCH 1/2] add support for derived sbuild chroots From: Uladzimir Bely To: Moessbauer Felix , Jan Kiszka , isar-users@googlegroups.com, Baurzhan Ismagulov Date: Tue, 20 Jun 2023 11:05:40 +0300 In-Reply-To: <42d90e24f1ec43a8398a29e267729e55c7d4fc69.camel@ilbers.de> References: <20230413070026.3511123-1-felix.moessbauer@siemens.com> <902a5e9b613428bb7e7782ae6a5405b067c0333e.camel@ilbers.de> <05246f6a-cd48-60b2-766a-028db42100ea@siemens.com> <90d556c033d3266ce219880accb2aabdb2d9976c.camel@siemens.com> <42d90e24f1ec43a8398a29e267729e55c7d4fc69.camel@ilbers.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.3 (by Flathub.org) MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: x2QD5DI8Ql8X On Tue, 2023-06-20 at 09:25 +0300, Uladzimir Bely wrote: > On Mon, 2023-06-19 at 21:10 +0800, Moessbauer Felix wrote: > > On Mon, 2023-06-19 at 07:58 +0200, Jan Kiszka wrote: > > > On 13.06.23 08:24, Uladzimir Bely wrote: > > > > On Thu, 2023-04-13 at 07:00 +0000, 'Felix Moessbauer' via isar- > > > > users > > > > wrote: > > > > > This patch adds support to create derived sbuild chroots to > > > > > speedup > > > > > the > > > > > build process. For packages that share a large set of common > > > > > build > > > > > dependencies, a derived sbuild chroot can be created to avoid > > > > > the > > > > > overhead of installing all base build-deps on each sbuild > > > > > invocation. > > > > >=20 > > > > > Signed-off-by: Felix Moessbauer > > > > > > > > > > --- > > > > > =C2=A0doc/user_manual.md=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 27 > > > > > +++++++++++++++++++ > > > > > =C2=A0meta/classes/crossvars.bbclass=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 11 +++++-= -- > > > > > =C2=A0.../sbuild-chroot/sbuild-chroot.inc=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 7 ++++- > > > > > =C2=A03 files changed, 41 insertions(+), 4 deletions(-) > > > >=20 > > > > We are going to merge this in near few days in spite of an open > > > > question left in discussion. The reasons: > > > >=20 > > > > 1. It passes internal CI (dev/fast/full). > > > >=20 > > > > 2. It was useful in case of 'meta-iot2050' downstream for > > > > rewriting > > > > "npm.bbclass" in order not to use buildchroot.bbclass (that is > > > > going to > > > > be deleted with "Imager schroot migration" patchset that is to > > > > be > > > > merged soon too. > > >=20 > > > To track what I discussed with Baurzhan offlist: I would be good > > > to > > > have > > > some QA check running when using a derived sbuild chroot that the > > > package built has all extra packages as part of its Build-Depends > > > so > > > that we are not create again silently broken debianizations. Any > > > ideas > > > how to achieve that best, considering also implicit inclusions of > > > the > > > Build-Depends? > >=20 > > This is hard to achieve. The only way I could currently imagine is > > to > > run the same package build in the standard chroot and check if it > > still > > properly builds (by definition, the derived chroot has a superset > > of > > the packages). For the created artifact, too-many packages in a > > build > > chroot are not problematic. Given that, at least the created > > packages > > are fine. > >=20 >=20 > Could not it be some variable (disabled by default) that globally > prohibits changes of SBUILD_FLAVOR and > SBUILD_CHROOT_PREINSTALL_COMMON > by packages/bbclasses? >=20 > It could be enabled in CI in order to build all packages with "clean" > schroots, but disabled by default to speedup development process. >=20 I've experimented with such kind of "global disabling" derived schroots and in general it works, but some moments are not still clear for me. In the patch 2, we have SBUILD_FLAVOR=3D"clang" set for `samefile` package and that makes it use schroot with clang preinstalled. Also, debian rules file is modified with `export CC=3Dclang` in this case. As a result, we have a package built with clang. When I globally disable derived schroots, building `samefile` still works since it is now built with gcc (debian rules are not modified). I would expect a bit different behavior: debian rules files should not be modified. Instead, `clang` is preinstalled as a dependency in "clean" schroot and used as a compiler. So, in both cases (with specific schroot and without it) the same compiler should be used - the difference would be only in built time. Probably, for the demo purposes it's OK, but I would expect that any package is built with the same tools whether a derived schroot used or not. > > >=20 > > > Furthermore, I had a small comment on patch 2. > >=20 > > I would rather postpone the "derive chroot name" aspect to later. > > It > > is > > a minor thing and currently I lack the time to implement it. Feel > > free > > to add a patch on top. > >=20 > > Felix > >=20 > > >=20 > > > Jan > > >=20 > >=20 >=20