From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7075595997826514944 X-Received: by 2002:a2e:914d:0:b0:24f:6374:3eba with SMTP id q13-20020a2e914d000000b0024f63743ebamr95366ljg.506.1652890847908; Wed, 18 May 2022 09:20:47 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:6512:3f16:b0:449:f5bf:6f6a with SMTP id y22-20020a0565123f1600b00449f5bf6f6als213308lfa.2.gmail; Wed, 18 May 2022 09:20:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzwBH1Uwe+kTZsVUAFSLUkZjV/4KkSTrcpZq82gwVQoDQW0r8CO09dlhYPXuSON6Y0EpTsX X-Received: by 2002:ac2:424f:0:b0:473:f8c7:1726 with SMTP id m15-20020ac2424f000000b00473f8c71726mr214887lfl.74.1652890846845; Wed, 18 May 2022 09:20:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652890846; cv=none; d=google.com; s=arc-20160816; b=Vrtr+M9GFh5hCtSjJ+C7fT5ZxvIC7RXQ5mO7WUQ6LxzSdIFXaXRVpYD2x8EOPq03RW gwPFX64ClPHHvZZgESYrKEK+fc1bgbQ7YqQHutlfnjdaWfMKTLhzr9KB/hK3AEymJCB1 QPKaQUqXLZltqLbO1lZM1Km0OaBeneOeBRFim8DL6MEYwgOPBeqJSOsgIIM3w2+LTNNm dP6Ir48wZ2X0Iuy8p5Wgp/FYaCuVGwh2MpK2i7K42rf7AOiBMq7O/oSU0Vhkh15YslLJ Bw9q8wWYZaJ+MX76X512Ll7pcsMI+wK1nth42yzsu9FegW5xk7aONkMZu2tNuo+QwhLB CJfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date; bh=qZiH4xgMwSTusSvvC4KDwDAz0f0GwIgg8yZNvwHp0eA=; b=qQ/MNKqnd6SPjgPP5fA5RqncbwKCxMONoOd+cesbVdZM0qBckBphue23Xwt31fscUH aYtj0+i5cPORHKBia5kyDy7Y/QjT6UoMdf0rGrS0RuvgHktlBaIwMBPccLVQs/qU/8jI P5GpKppVnM5UaEjmRK9kN1j4rHyBTMKGZY6oaRPE6DmTxrL1feQbgi/03DKCWvJrnJIs tcYlfR1G+TBR0DZ0aGTdNrGOUhwqyPitTH64EADJ5Q4UmfjakHdj6ah38mOsaYdXesS6 d3Hn6nqtRa1LM7HKclPuUiY0QmspoB1YH/sMiRHDc8HS5++IiteCd7MPGDpBqUB6FDQF jUJw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id o7-20020ac25e27000000b0047193d0273asi139540lfg.8.2022.05.18.09.20.46 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 18 May 2022 09:20:46 -0700 (PDT) Received-SPF: neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from ilbers.de (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) with ESMTPSA id 24IGKinP003139 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 18 May 2022 18:20:45 +0200 Date: Wed, 18 May 2022 18:20:44 +0200 From: Baurzhan Ismagulov To: "isar-users@googlegroups.com" Subject: Re: [PATCH v10 00/19] Sbuild/Schroot migration Message-ID: Mail-Followup-To: "isar-users@googlegroups.com" References: <20220505143934.16096-1-amikan@ilbers.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: +kUiy0ughJe4 On Thu, May 12, 2022 at 03:55:19PM +0000, Moessbauer, Felix wrote: > 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: Thanks for the input, I also think we should find a good way to merge sbuild soon. > Removal of do_install_builddeps task: Please add a bold statement about that in the API changelog The patch has been sent. > 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) In short, we should avoid any buildchroot preparations. The Debian way is to specify anything that is needed in the build dependencies, so that a dumb package builder can build any package in a cleanroom environment without knowing what is inside. We've done this for meta-iot2050. This works well for Debian which doesn't have many flavors (except a couple of kernels for x86 and arm). In the layers, we often want to customize stuff. Currently I'm aware of the environment way (like DEB_BUILD_OPTIONS), but that is handled in debian/rules; right now I don't know how to handle other stuff like build dependencies. If you have specific examples, I think we should discuss it with the upstream -- maybe they'd have suggestions, or we could collaborate on improvements. For the imagers, seems we'll have an schroot session API for now, but I'd prefer not to extend it to sbuild if at all possible. > 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. Well, we do prefer python and try-catch. We've tried that with mount rework and it works well. The issue is that downstreams are affected, and we couldn't find an elegant way to migrate away from shell scripts in downstreams. Longer-term, I think we'll have to do that, shell tasks are interfering with too much stuff. Till then, I'm afraid we have to live with shell. And its error handling, is, well, traps :) . > 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). Some of the stuff has been merged. > 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. Which in-flight version number do you mean? I'm only aware of the release info in /etc, which uses git to get the tag. With kind regards, Baurzhan.