Re: Question related to Sbuild CLEAN_SOURCE

[quirin.gylstorff@siemens.com]

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