RE: [PATCH v10 00/19] Sbuild/Schroot migration

["Moessbauer, Felix" <felix.moessbauer@siemens.com>]

> -----Original Message-----
> From: Anton Mikanovich <amikan@ilbers.de>
> Sent: Thursday, May 12, 2022 2:55 PM
> To: isar-users@googlegroups.com
> Cc: Schmidt, Adriaan (T CED SES-DE) <adriaan.schmidt@siemens.com>;
> Moessbauer, Felix (T CED SES-DE) <felix.moessbauer@siemens.com>; Kiszka,
> Jan (T CED) <jan.kiszka@siemens.com>; Schild, Henning (T CED SES-DE)
> <henning.schild@siemens.com>; Baurzhan Ismagulov <ibr@ilbers.de>
> Subject: Re: [PATCH v10 00/19] Sbuild/Schroot migration
> 
> 05.05.2022 17:39, Anton Mikanovich wrote:
> > This is a patchset showing how sbuild/schroot tools can be integrated
> > into Isar build system.
> >
> > Base schroot images are created with sbuild-chroot-target or, in case
> > of cross-build, sbuild-chroot-host recipes. These images are based on
> > isar-bootstrap ones, but include some build-related stuff preinstalled.
> >
> > To use these changes you need to have sbuild and schroot installed and
> > configured. User who runs build should be added to sbuild group.
> >
> > Currently, sbuild-related stuff is supported in latest kas.
> >
> > If Gilab CI is used, the following configuration changes are required:
> > - external dir for schroot overlay should be set in the config
> > /etc/gitlab-runner/config.toml:
> >
> > volumes = ["/path/to/overlay:/var/lib/schroot/union/overlay"]
> >
> > The patchset was tested with 'meta-iot2050' and 'xenomai-images'
> > downstreams in combination with kas image mentioned above.
> >
> > Current limitations:
> > - parallel building of several packages requires more free space in
> > comparison with buildchroot-based architecture. This happens due the
> > sbuild architecture which uses some basic layer (common for all
> > packages) and per-package separate layer (where builddeps are
> > downloaded and installed).
> 
> Does anything speak against merging this patchset?
> If not, we would like to do it next week.

Hi,

thanks for all the effort regarding the sbuild support.
We tested that on a couple of layers and it mostly worked quite well.
The following aspects are worth thinking about, but should not result in another delay in the integration of sbuild:

Removal of do_install_builddeps task: Please add a bold statement about that in the API changelog

Manual actions in a package schroot: Some layers (like meta-coral) require additional work to be done inside the buildchroot to prepare things prior to the debuild / sbuild.
Mounting the correct schroot and working there works, but this is totally undocumented ground. We should really guide the ISAR users how to do that correctly (otherwise a ton of partially working patterns will evolve downstream).
A public example, where this is necessary can be found in [1] (still pre-sbuild)

Setup and teardown of schroots:
The teardown should always be executed, no matter if the job was successful or not.
Currently this is handled by shell-traps, but we should really think about simplifying that for the users.
Either a post-task handler could be registered for cleanup, or we use bitbake functions which are called from python with a try / catch / finally pattern.
Maybe @Adriaan can comment on that, as he has built up quite some experience around cleanups when working on the mount patch series.

Integration of other patch series:
At least personally I would really prefer to see other patch series being merged first.
Examples are: cachability improvements, sstate scripts, mounting of /dev/pts (at least the bugfix series).
It is likely that pre-sbuild ISAR will be around for quite some time as layers need time to adopt.

New ISAR release: Once Sbuilder is in, the old ISAR should be tagged and the in-flight version number of ISAR should be increased.

Happy Coding!
Felix

[1] https://github.com/siemens/meta-coral/blob/main/classes/dpkg-bazel.bbclass