Re: Question related to Sbuild CLEAN_SOURCE

[Uladzimir Bely <ubely@ilbers.de>]

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