Re: Question related to Sbuild CLEAN_SOURCE

[Jan Kiszka <jan.kiszka@siemens.com>]

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.

> 
> 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

-- 
Siemens AG, Technology
Competence Center Embedded Linux