From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7133500741339054080 X-Received: by 2002:a05:6000:178e:b0:220:635f:eb13 with SMTP id e14-20020a056000178e00b00220635feb13mr3799498wrg.634.1660905156078; Fri, 19 Aug 2022 03:32:36 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:600c:3486:b0:3a5:a469:ba0a with SMTP id a6-20020a05600c348600b003a5a469ba0als2309277wmq.2.-pod-canary-gmail; Fri, 19 Aug 2022 03:32:35 -0700 (PDT) X-Google-Smtp-Source: AA6agR52DisYNDbboWJe8OPTzeDvgC2HI+JoQVtWryVoKlFPD4A4skjSgyKoEqCJs4FlmuROFTcF X-Received: by 2002:a05:600c:a08:b0:3a1:9319:ab78 with SMTP id z8-20020a05600c0a0800b003a19319ab78mr7408095wmp.158.1660905154962; Fri, 19 Aug 2022 03:32:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660905154; cv=none; d=google.com; s=arc-20160816; b=U0UNYTk4+AqaHpArrvTe+Lc2GlFsZkUsjC2jnzZWAR6QxPXOJX7zpdri/5qbBD/A4h /m0fJsZJ3fo4RumzRrCM2wKczxUAYwyLSdgTdY13G7V4vUnZHaYUuzcuvjpv+CuvhNKR 5ZESefBBvLY8OZKPwerEBzm/5+FqYWm04d+6Shp2aOZiEotTBwgP+i9+qiOqYbhGFD21 ZHQ4bFsVs+bHhrQVakm6tOZLAn79xXYRHovcsocvQo56v1efoiZovV2OC783Cdi3IA5b GLFg/kiwXoN1tYBEBMkUxG1GWZ5EpWeGdLnIGrVNaTnjR5xKDvvqTTgRPmMywnWK2k8U UR8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:mail-followup-to:message-id:subject:to:from :date; bh=kJ30cMzNcc9SEtnv4gUU4VUEt1iPvDDC8X0XxFb5HE0=; b=UeuG/jsEQd3Pt+9BYXYzOvPZI9m6Gn66bGI1THZiwOJ/wLWTJM1MHGBr98YoUgtYQc 6cgIhzFrTA6Z0gS+Mu9IeK8zML/Lcysazwl3vcVKyCm1uzgW3zxbnKUTUDRgOWFcbBcX wkIzflMAbkikFMchQm8HnMCSEkYEJPFllRbvO1LKiywfu2Vv9S9g6joOuWXX9uvkusdq w6woy3ssALqwT9Mi4VG9gZMO7xMzAtY6SSanT/HOQKfrJjFXqODhBQJefrFSp22gN7Ad iRxBAGKslXE27oGT4VBgj/NdYDwhu+3TFWDojtPmGX6qd4P2LAuPDfwjo7GyNSVAxK6U lI4A== 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 125-20020a1c1983000000b003a5a534292csi101237wmz.3.2022.08.19.03.32.34 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 19 Aug 2022 03:32:34 -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+deb9u1) with ESMTPSA id 27JAWES4007848 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 19 Aug 2022 12:32:33 +0200 Date: Fri, 19 Aug 2022 12:32:14 +0200 From: Baurzhan Ismagulov To: isar-users@googlegroups.com Subject: Re: sbuild migration problem: how to jump into SBUILD_CHROOT with build dependencies installed Message-ID: Mail-Followup-To: isar-users@googlegroups.com References: <5ac8a864-5a1b-6f03-2318-68c6b8d612f0@siemens.com> <4dd276e8-a0db-4215-6d2a-eb74282d0c94@ilbers.de> <195731f6-fdab-8355-3d76-a9dd997c07e4@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-9 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <195731f6-fdab-8355-3d76-a9dd997c07e4@siemens.com> 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: pPufvGUiz6g5 Hello Florian, On Fri, Aug 19, 2022 at 10:36:52AM +0200, Florian Bezdeka wrote: > >> dpkg_runbuild_prepend() { > >> ���� sudo chroot --userspec=$( id -u ):$( id -g ) ${BUILDCHROOT_DIR} \ > >> �������� sh -c "autoreconf -fi" > >> } > >> > >> In the pre-sbuild times this task was executed *after* the build > >> dependencies have been installed but *before* the dpkg_runbild task. > >> > >> With sbuild: > >> - There is no "install build dependencies" task anymore > >> �� Installation of build dependencies is done by sbuild internally > >> - The task is now executed *before* build dependencies are installed > >> - I still could chroot into ${SBUILD_CHROOT}, but the build dependencies > >> �� will not be there > >> > >> Is there any possibility to jump into the ${SBUILD_CHROOT} after build > >> dependencies are installed but before the actual packet build? > > > > Correct way to implement this is to move autoreconf into debian/rules. > > In this simple example for sure. But: There might be recipes where > debian/rules is not directly "accessable", forcing me to wait for 3rd > parties to update their build process (or patch things in my layer) and > all of this just because I tried to update Isar... > > If there is no way to jump into ${SBUILD_CHROOT} with build dependencies > installed we have a (very minor) regression. I'd like to spend a few words on the background: The sbuild change is not about the build tool per se; it's rather about re-using the Debian package building interface. In Debian, a developer prepares a standalone dsc file, uploads it to a build server, and buildd produces binary packages in a clean-room environment. No intermediate steps are taken in between; all necessary information is contained in the source package and its dependencies. Clean-room building is a requirement because otherwise binaries could be e.g. linked with libraries which were not intended by the developer. There are also architectural reasons like modifiability, etc. Yes, removing interfaces is technically a regression but the resulting functionality is more important. That is why we'd like to follow the Debian way and avoid custom steps. If this is not obviously applicable, we want to see the use cases and discuss them in detail. Regarding autoreconf, rebuilding the files can be done in debian/rules (there is also dh_autoreconf). That said, I personally prefer to generate the files during the development phase, commit them to the VCS, and disable maintainer mode for building. This saves time, reduces dependencies, and avoids a number of issues. Regarding the debian/rules being inaccessible, in that case I don't understand yet how you build it with Isar in the first place. I suggest that you share your source package (possibly offline) and we look what could be done. The idea is that any extra steps go either into preparing the source package, or into package patches -- so yes, patching may be required. We've seen a number of such source packages in e.g. meta-iot2050 and it does require some work if the upstream follows the "let's fetch 128 deps from everywhere and bootstrap ourselves" process. In many cases, you want to have clean source packages yourself to comply with license requirements w.r.t. rebuilding. It is also a big help for the users of the package, since anyone can then apt-get source pkg; sudo apt-get build-dep pkg; cd pkg-ver; dpkg-buildpackage -uc -us for any given package. So, custom package recipes should ideally just build the source package and leave building to Debian tools. With kind regards, Baurzhan