From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7062656987288305664 X-Received: by 2002:a05:6512:32c8:: with SMTP id f8mr10262504lfg.222.1644832077629; Mon, 14 Feb 2022 01:47:57 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:ac2:43cc:: with SMTP id u12ls1085293lfl.2.gmail; Mon, 14 Feb 2022 01:47:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJxUAQXh21ifnH7dI630vYwjCRgHzNVGbRprv5rF+In5ajJEEzfTKV6MfGki7moh1Fne1cRA X-Received: by 2002:a05:6512:c26:: with SMTP id z38mr7705817lfu.186.1644832076543; Mon, 14 Feb 2022 01:47:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644832076; cv=none; d=google.com; s=arc-20160816; b=mHTIFK+NP8c4Y3WDCrvsoVJfDWByhE1+qBtoAxhPDezRpA9QYlJWYuqeN6HPS9nzNM FrZMquNm3Bk48cXhSU8b5ORrXK0MyGJRIs8kbONdlKXTzbjQvh9ybpsB2QUKToxuDhno 1jAtV2bIgLplwY+5zISch8/ptafJvbLPPJulCyZMgx8Z+H5bRIdh0vWnWp9UdP0Cpyjw UZGJNGEtxtRkH4G601sRUCakUjWi65B/PTRzavtokQeaOBO5Nz41G9436cDRwl/j+TxY 64HmvGCuIjgVGgCVCwYWB+G9Yl+UKqTHzJ9nH0gkqVDD6MptK7onZDl0k9w/txKoJdcA Poog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from; bh=c5KWaDWXf6+yiVBLJWwID80JIoCNj/NaG8qd1WVRDi4=; b=IjL0Pw2LQhJXobhVirGR3Dme6jpf0RAz3DTtFv4VicSDqDqwNVQDGimEjN97rRLM69 COboa63cg+eeBk+ypRO34SxM1T9i38Dzej4Ti7t/iHz5Z1QBbpKn9X3iz8SqTH6WwOJz Ry6Z8/rVMr8hKUhHbTYuUTjqBuZKN01whEMXSguTx1yKLZguM01ClUCujAbwxwkpgwif EyN8oCmB9pJAxk3RhocF3SL+LyAC3MEjlc7tkFi5WisQVwOP8XYjI3QI8MXeLd6mT+aY 3lrPaW05QL7ATQquC3Xz/OxWxuMuu0D2r8xjjSqJCmLibBfDO9e2ElCpPrKbnHJShgy6 COkw== 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 n22si1432236lji.7.2022.02.14.01.47.56 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 14 Feb 2022 01:47:56 -0800 (PST) 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 home.localnet (44-208-124-178-static.mgts.by [178.124.208.44] (may be forged)) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id 21E9lsSe015344 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Feb 2022 10:47:55 +0100 From: Uladzimir Bely To: isar-users@googlegroups.com, quirin.gylstorff@siemens.com, Jan Kiszka Subject: Re: Question related to Sbuild CLEAN_SOURCE Date: Mon, 14 Feb 2022 12:47:52 +0300 Message-ID: <274152143.ifERbkFSEj@home> In-Reply-To: References: <1b5ef299-ec8d-c180-c2b6-505294f5484b@siemens.com> <3349320.sQuhbGJ8Bu@home> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: TVp1wZ67tBBY In the email from Friday, 11 February 2022 14:20:10 +03 user Jan Kiszka wrote: > On 11.02.22 11:54, Uladzimir Bely wrote: > > In the email from Thursday, 10 February 2022 12:10:47 +03 user > > > > quirin.gylstorff@siemens.com wrote: > >> On 2/10/22 09:47, Uladzimir Bely wrote: > >>> In the email from Wednesday, 9 February 2022 18:14:22 +03 user > >>> > >>> quirin.gylstorff@siemens.com wrote: > >>>> On 2/9/22 12:52, Baurzhan Ismagulov wrote: > >>>>> On Wed, Feb 09, 2022 at 11:36:09AM +0100, quirin.gylstorff@siemens.com > >>> > >>> wrote: > >>>>>>>> - Is there are reason sbuild executes clean outside of the chroot? > >>>>> > >>>>> It would be interesting to hear what kind of issues you had due to > >>>>> that. > >>>> > >>>> If we rebuild a debian package with dpkg-gbp which uses for example > >>>> `dh-lua` (swupdate) the build will fail due to the missing > >>>> installation > >>>> of dh-lua in the host environment. The solution to this is to install > >>>> dh-* in the build environment. > >>>> > >>>> ``` > >>>> gbp:info: Performing the build > >>>> dpkg-source: info: using patch list from debian/patches/series > >>>> dpkg-source: info: applying use-gcc-compiler.diff > >>>> dh clean --with lua > >>>> dh: error: unable to load addon lua: Can't locate > >>>> Debian/Debhelper/Sequence/lua.pm in @INC (you may need to install the > >>>> Debian::Debhelper::Sequence::lua module) (@INC contains: /etc/perl > >>>> /usr/local/lib/x86_64-linux-gnu/perl/5.32.1 > >>>> /usr/local/share/perl/5.32.1 > >>>> /usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 > >>>> /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 > >>>> /usr/share/perl/5.32 /usr/local/lib/site_perl) at (eval 13) line 1. > >>>> BEGIN failed--compilation aborted at (eval 13) line 1. > >>>> ``` > >>>> > >>>> You can fix it with documentation but it needs to be addressed. > >>>> > >>>> A project where this can be tested is isar-cip-core with the current > >>>> preintegrated sbuild[1]. > >>>> [1]: https://gitlab.com/Quirin.Gy/isar-cip-core/-/tree/test/sbuild > >>> > >>> Hello. > >>> I've tried this repository (master branch) on my side. > >>> It currently builds OK with Isar revision 33b5aa65 (default mentioned > >>> kas- > >>> cip.yml), it works with current isar/next as well. Also, I successfully > >>> built it wth latest isar/ubely/sbuild revision. > >>> > >>> Maybe there are some more specific steps to reproduce the issue you are > >>> talking about that I could try to check on my side? > >> > >> Ah sorry, > >> > >> you need to add the SWUpdate option to the build. The kas command would > >> be: > >> > >> ``` > >> /kas-container --isar build > >> kas-cip.yml:kas/board/qemu-amd64.yml:kas/opt/ebg-swu.yml > >> ``` > >> > >> or you build SWUpdate from the devshell. > >> > >> Kind regards > >> Quirin > > > > I tried this - and yes, I also faced this problem with "dh_clean --with > > lua". > > > > There are 2 ways to deal with it: > > > > 1. We can simply add "--no-clean-source" to sbuild parameters. In this > > case > > sbuild itself doesn't trigger additional "dh_clean" before build. > > > > 2. We can switch to building from .dsc file instead of building from > > unpacked source directory (e.g., firstly create .dsc file by dpkg-source, > > sencodly, run sbuild passing .dsc as argument). In this case sbuild also > > doesn't call dh_clean. > > > > Both methods work, but the second looks more debian-friendly. > > Worse: The first one could erode over the time as it is no official > Debian method. > > > BTW, I faced some other build issues with "isar-cip-core": > > > > 1. "efibootguard" recipe attempts to deploy "efibootguardx64.efi" and > > "bg_setenv" binaries directly from source tree. This doesn't work with > > sbuild, especially in case of building from .dsc file. Moreover, > > "efibootguardx64.efi" binary doesn't even belong to any output .deb > > files. > > The first one is a known conversion pattern. The second one is actually > a bug: We should not use the deployment folder, we should use a deb > package installed into the buildchroot that installs the bootloader, > just like we do in all other cases. Seems I missed that in reviews. > > > I consider this binary should be added to .deb file and deploying should > > be > > done from it (e.g. using "dpkg --fsys-tarfile" for extraction). I can > > submit a patch if needed. > > Yes, please. > Submitted just now. Seems, my first attempt to send patch (previous week) failed due to missing subscription to cip-dev@lists.cip-project.org list. > > 2. "swupdate" is built from git branch "debian/master". I had to add > > "-git- > > ignore-branch" to GBP_EXTRA_OPTIONS, to skip the error, like "not master > > branch used". > > > > 3. Finally, I still have build error with "swupdate": > > > > "The following packages have unmet dependencies: > > sbuild-build-depends-main-dummy : Depends: sphinx but it is not > > installable" > You will likely need a better tool to get the explanation. apt itself > too primitive in complex cases. Usually, I jump in via devshell_nodeps, > install aptitude, try to install the failing dep and let aptitude > explain to my what goes wrong. > > Jan -- Uladzimir Bely