From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7062656987288305664 X-Received: by 2002:a05:6402:40d2:: with SMTP id z18mr13993964edb.152.1644828880896; Mon, 14 Feb 2022 00:54:40 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a17:907:3e1d:: with SMTP id hp29ls6646773ejc.11.gmail; Mon, 14 Feb 2022 00:54:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJwAb1O40hHMDFYQFqGZA8a6PNxud6GnwIasdHFUon3iGg4ekSyMNy953vn1bh9QLgd+Ye5e X-Received: by 2002:a17:907:d91:: with SMTP id go17mr11183915ejc.301.1644828879963; Mon, 14 Feb 2022 00:54:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644828879; cv=none; d=google.com; s=arc-20160816; b=Lwt6veee5AWXivT+1dsIt6gzxURo7bJLOQcm9CC7imlUSBvojf0odu7hoQOja+K5m9 A2aXJQa4AJJI4Rjq53d+YqSTQvb33WKs15Cl6AZU5mOEgQDRzoHhNfpbW37OMGlU7fqJ DixdS2B24dW+vMoh/Sf05Uzn1/ET1/dsxrnCmsxRcQTga6vLhiVKheTMVRShromL7Jzq 0uz86YK6YazVqCOpsZ0+XOQf8b0XxeVyTm7HwXjhuCU0+yGQJ+tAeyIvRtpv/6MiNZfK uFXYzMqL8mgPHG1rbvx0IZhqhav0a0/tlTEMQJE0/kmFBM+UHNxj7Coa3eKZFjJQHb2Y /sqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=feedback-id:content-transfer-encoding:in-reply-to:subject :organization:from:references:to:content-language:mime-version:date :message-id:dkim-signature; bh=syXqJsS4jwvKPmQwB/7xMZYZVd5RYgfTxlf0Hawa1Is=; b=OQRBx8mtZpsp/6F1XFRzqLC2uuTZOlUlbSaQBPY4sgJDiU1K5/Rm88T1KnCbyrTa2u W8KEYANhCWOlyzrhHcdK+SCqFPyeypo6aXE5GXl50HDPd601Y9mSQt3Xw/Zbo5iKq0dk nLFq4D0LxwOxUEosaSaMi0jhA3/sw4UsF919DC1VEDOBSPxg3sP0UKYRNnvTWWV/j5RQ qnAsC9hytbaEm2JmbflmL330nb9tPhxHpi5HOGwXYG7l9g/WIqtKRlDoc4irFUQGp15k YixSWk5v6c+eeSIDm8iS3HuzmKsoGfDC7AeobZkyvzFpg3TPUdHHo7ewcwTswkoxoVaZ 88mA== ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@siemens.com header.s=fm1 header.b=O5lhdFnB; spf=pass (google.com: domain of fm-51332-202202140854392489579f9c0240147e-nqqczt@rts-flowmailer.siemens.com designates 185.136.65.225 as permitted sender) smtp.mailfrom=fm-51332-202202140854392489579f9c0240147e-NqqCZT@rts-flowmailer.siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from mta-65-225.siemens.flowmailer.net (mta-65-225.siemens.flowmailer.net. [185.136.65.225]) by gmr-mx.google.com with ESMTPS id s15si1386911eji.1.2022.02.14.00.54.39 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Feb 2022 00:54:39 -0800 (PST) Received-SPF: pass (google.com: domain of fm-51332-202202140854392489579f9c0240147e-nqqczt@rts-flowmailer.siemens.com designates 185.136.65.225 as permitted sender) client-ip=185.136.65.225; Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@siemens.com header.s=fm1 header.b=O5lhdFnB; spf=pass (google.com: domain of fm-51332-202202140854392489579f9c0240147e-nqqczt@rts-flowmailer.siemens.com designates 185.136.65.225 as permitted sender) smtp.mailfrom=fm-51332-202202140854392489579f9c0240147e-NqqCZT@rts-flowmailer.siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: by mta-65-225.siemens.flowmailer.net with ESMTPSA id 202202140854392489579f9c0240147e for ; Mon, 14 Feb 2022 09:54:39 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=fm1; d=siemens.com; i=quirin.gylstorff@siemens.com; h=Date:From:Subject:To:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:References:In-Reply-To; bh=syXqJsS4jwvKPmQwB/7xMZYZVd5RYgfTxlf0Hawa1Is=; b=O5lhdFnBQRu2waDcPS02cLQHqmH65Pr73kP4s+NTXzlqKYZ4xIkaxGmmnbPi0saNKnYbFQ 6XHze8GscBZAvPFJpiVsukUzoQjNFsBXrqR7oJxneU6bGc8ZcRonbiql8Ax/+htg1Emmm9YZ 53fcyo6I8lXWq2eLOTMWOYGddtSyY=; Message-ID: <8cac137d-475a-b217-4208-151e4bc7476a@siemens.com> Date: Mon, 14 Feb 2022 09:54:38 +0100 MIME-Version: 1.0 Content-Language: en-US To: Jan Kiszka , Uladzimir Bely , isar-users@googlegroups.com References: <1b5ef299-ec8d-c180-c2b6-505294f5484b@siemens.com> <2591024.vuYhMxLoTh@home> <29092d94-9261-07d6-7ebf-240dbbb435c4@siemens.com> <3349320.sQuhbGJ8Bu@home> From: quirin.gylstorff@siemens.com Organization: Siemens Subject: Re: Question related to Sbuild CLEAN_SOURCE In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Flowmailer-Platform: Siemens Feedback-ID: 519:519-51332:519-21489:flowmailer X-TUID: ol3v7p3IuTqR On 2/11/22 12:20, 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. Is this extraction working with sstate? I had some problems with rebuilding from sstate with this pattern. > >> >> 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" >> This looks like https://salsa.debian.org/debian/swupdate/-/commit/d666b84435e1b1abebc6070252872ed390ac4df8. The profile `nodoc` should be set. > > 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. Quirin