From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7221425893476925440 X-Received: by 2002:a05:6214:dc6:b0:62f:fd63:bfc3 with SMTP id 6-20020a0562140dc600b0062ffd63bfc3mr16285811qvt.47.1687242350012; Mon, 19 Jun 2023 23:25:50 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:ad4:4baf:0:b0:626:3bf3:c6c1 with SMTP id i15-20020ad44baf000000b006263bf3c6c1ls2112648qvw.1.-pod-prod-09-us; Mon, 19 Jun 2023 23:25:49 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4gOjv5C7FWhgLTbBD3iZY7UaQq4LXfnMx0dt/R03yN/rHMhEyL4hH/IQ5ZcrSB3k/H4CAD X-Received: by 2002:a05:6102:3674:b0:440:abf3:4c3e with SMTP id bg20-20020a056102367400b00440abf34c3emr1544464vsb.25.1687242348957; Mon, 19 Jun 2023 23:25:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687242348; cv=none; d=google.com; s=arc-20160816; b=uqdtxBocCgh8s2TG3hXQrZ8mVQpT0cJMrEk43wK8CsrEVJHuAu58mR5QEsWksAwgbu 0m08ri7WsvfkdRZhW3DeH6U7AoalapnuzOeQPVNhgywVlq9UhWEZ0EgSiNWmy9ggxhQs uLyrSJPw6sz3aAzcUTGVOCUMJnXCB6Cd584gQeaY4WBB3dtedspWExgq6ILf71hB3uw8 3/sgVOsxFUMbjBgReqjSTItEoBPjVdRetFubOkflZcEtUBdfcpHLxAGUAow7lnABdGTM Y+2vwow7u/nyEl4bZyP0lrL6IKei1DhiyWqB9qKOgCcpG/l53u2sOPBu8t3bz55+lMGs olEg== 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=c3aaK6DeXssQ6nRs2IINhVEIRabJi7a3LGp+rxWLcq0=; b=EXcWRsx78X8dEtRreZc/Oi6QW8oVWqi5s4IbeyxiVWZABdW7AfOdOJrmMLjVqgwDQ6 wG20PN+jk6hcNYFl9bR1wyhKKIzuPdkQIgQ8f8YehNcAYzWG7Le1zkbrEh/7BVpJcQWT ZtbQ4MSVc/SUXGldlSmbZNuQf4q9p+dzF9l634CWXJAvLbiKz/vHosqRRz/by7EIMs8A H9i2WoxCv5CkFu7+B4LgJLtEdCnG+LoyInO2vJnu/oflG/CJ1348eoT8Aome+eDkwWHC DiGKgiLL6MH+TKVIEuuzZiNBX/yUdmyB7btCZuwsV/b6lE7sZ27zhhETHxez1n1rk5Zy fXjA== 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 x38-20020a05613000a600b0078f4a94f20bsi105884uaf.2.2023.06.19.23.25.48 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 19 Jun 2023 23:25:48 -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 35K6PjKX028068 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Jun 2023 08:25:46 +0200 Message-ID: <42d90e24f1ec43a8398a29e267729e55c7d4fc69.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 09:25:36 +0300 In-Reply-To: <90d556c033d3266ce219880accb2aabdb2d9976c.camel@siemens.com> References: <20230413070026.3511123-1-felix.moessbauer@siemens.com> <902a5e9b613428bb7e7782ae6a5405b067c0333e.camel@ilbers.de> <05246f6a-cd48-60b2-766a-028db42100ea@siemens.com> <90d556c033d3266ce219880accb2aabdb2d9976c.camel@siemens.com> 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: VzNLiDLZiR/m 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 Could not it be some variable (disabled by default) that globally prohibits changes of SBUILD_FLAVOR and SBUILD_CHROOT_PREINSTALL_COMMON by packages/bbclasses? It could be enabled in CI in order to build all packages with "clean" schroots, but disabled by default to speedup development process. > >=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