From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7221425893476925440 X-Received: by 2002:a2e:a175:0:b0:2b2:1f2f:705f with SMTP id u21-20020a2ea175000000b002b21f2f705fmr7276868ljl.4.1687251115957; Tue, 20 Jun 2023 01:51:55 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:651c:1694:b0:2b4:6606:100c with SMTP id bd20-20020a05651c169400b002b46606100cls16040ljb.0.-pod-prod-01-eu; Tue, 20 Jun 2023 01:51:54 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4xRWldyMzwbiiPm62A4jGdgUdlJO2meLlBjwQXuWiIV4Id0+GyTf93d8zZ8283sw2AZzFJ X-Received: by 2002:a2e:9d84:0:b0:2b4:6f70:c381 with SMTP id c4-20020a2e9d84000000b002b46f70c381mr4054338ljj.42.1687251114030; Tue, 20 Jun 2023 01:51:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687251114; cv=none; d=google.com; s=arc-20160816; b=aw0diAaRSMuf3j8i6NGjyw9hYCMVxvfkpOSv5NspXxdncB06vBiFhDTyLZjU3R+vte YHf4Sd7KRDA3RSsfJSvcZj9L9XCDySh0hvF4h/EzRBvstv08y3w5Tt/goS6WWKCZ+yXv 7xl2eRNcUVkeR6AyZ0td8S38rapUzxN2hLx2/GCqIDW0RE/aGt32ZpatK5qLs4CQXMEb 3sL5/ISYlTuXvc7Shuc8gUThMKx+0dV2ew58WLgp7NuFxgSX4qUa069agslxcRmNN/sz BXjd0Jcic6UjvKvSCBvrfovpHBEusQKj+XBWts/szkBzkbuVahqDhSyd0EW5nFA8n06g o5lg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=feedback-id:mime-version:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:dkim-signature; bh=oDLoxlUArKJ8yL0LyG9w/VafaVWHVkHlWtg8WUYUh74=; b=XkeuKSCGh8cHOd9zbvhETw+7jNZzQ3lq3+ogn3pgKcjmRPauP0rYICrleU7Rz9ukGM xH8KMpIgaT+eE1mZtCqqP7qHYNMKJAPdpvDYt3AJdosiaogFLILdAwJ2NkEk402ZkcGq 2tDe43W9DrYY/pM1p6/W6FJjESMpU7cwG0HwDKpa8glDvyYcOSB7k8GNt67xRxJqOIpj QH29NoOBKXijLv0LVpiYm2xf5x5vK1LFj8DyPu2l8ue3JR8gxfEnVPlBjMQoM+mMgyWH wDWrPMMSNE3XASANfK7vY3APlXWedGugidPZ4oPX9S6nUWkcsEV6IJ2VyMbMWmhx85zY rxew== ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@siemens.com header.s=fm1 header.b="YkViRl/h"; spf=pass (google.com: domain of fm-72506-20230620085153a040ef2d65bc98d10d-rjls7m@rts-flowmailer.siemens.com designates 185.136.65.226 as permitted sender) smtp.mailfrom=fm-72506-20230620085153a040ef2d65bc98d10d-rJLS7m@rts-flowmailer.siemens.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=siemens.com Return-Path: Received: from mta-65-226.siemens.flowmailer.net (mta-65-226.siemens.flowmailer.net. [185.136.65.226]) by gmr-mx.google.com with ESMTPS id z1-20020a2ebcc1000000b002b481b84f4bsi75496ljp.7.2023.06.20.01.51.53 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Jun 2023 01:51:54 -0700 (PDT) Received-SPF: pass (google.com: domain of fm-72506-20230620085153a040ef2d65bc98d10d-rjls7m@rts-flowmailer.siemens.com designates 185.136.65.226 as permitted sender) client-ip=185.136.65.226; Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@siemens.com header.s=fm1 header.b="YkViRl/h"; spf=pass (google.com: domain of fm-72506-20230620085153a040ef2d65bc98d10d-rjls7m@rts-flowmailer.siemens.com designates 185.136.65.226 as permitted sender) smtp.mailfrom=fm-72506-20230620085153a040ef2d65bc98d10d-rJLS7m@rts-flowmailer.siemens.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=siemens.com Received: by mta-65-226.siemens.flowmailer.net with ESMTPSA id 20230620085153a040ef2d65bc98d10d for ; Tue, 20 Jun 2023 10:51:53 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=fm1; d=siemens.com; i=felix.moessbauer@siemens.com; h=Date:From:Subject:To:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:References:In-Reply-To; bh=oDLoxlUArKJ8yL0LyG9w/VafaVWHVkHlWtg8WUYUh74=; b=YkViRl/hxVYY0L7x1tmUhgmEmezeDamAReHr8UIZuMCf+zuilP1+YJTY+uN9c7MHKQj1na kI4pEDOavjGgEozlMuMJHSr4KRqhHARv0omkc5BQWSJ9N9vjNnwZNHZXxF2aJEWny/SOS7Gl JgXyidkGovqZU3jeabgN0FRpTiSRs=; Message-ID: <3e423324069e4e7e29df13dd666f39038b5a8fe9.camel@siemens.com> Subject: Re: [PATCH 1/2] add support for derived sbuild chroots From: Moessbauer Felix To: Uladzimir Bely , Jan Kiszka , isar-users@googlegroups.com, Baurzhan Ismagulov Date: Tue, 20 Jun 2023 16:51:47 +0800 In-Reply-To: <9bf66c024175106a960d4cc687402c6c8ecf948c.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> <9bf66c024175106a960d4cc687402c6c8ecf948c.camel@ilbers.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Flowmailer-Platform: Siemens Feedback-ID: 519:519-72506:519-21489:flowmailer X-TUID: bNV9MGc0H2aM On Tue, 2023-06-20 at 11:05 +0300, Uladzimir Bely wrote: > 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 >=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. >=20 > 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. That's the idea. Compilers are never added explicitly as build dependencies. We however have to enforce to use clang, as gcc is still installed as the buildchroot is derived from the global one. >=20 > When I globally disable derived schroots, building `samefile` still > works since it is now built with gcc (debian rules are not modified). >=20 > 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. I would expect, that this simply breaks. But it looks like an invalid CC variable is simply ignored. >=20 > 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. Agree. But this is just for demonstration. Feel free to remove this test. Felix >=20 > > > >=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 >=20