[Pkg-xen-devel] Bug#1028251: Bug#1028251: xen: FTBFS when building xen binary packages for sid on x86_64

[Chuck Zmudzinski]

On 1/9/23 12:55 PM, Hans van Kranenburg wrote:
> Hi!
> 
> On 09/01/2023 18:44, Chuck Zmudzinski wrote:
>> Control: tag -1 + moreinfo
>> 
>> thanks
>> 
>> On 1/9/23 8:09 AM, Hans van Kranenburg wrote:
>>> Hi Chuck,
>>>
>>> On 1/8/23 23:18, Chuck Zmudzinski wrote:
>>>> [...]
>>>>
>>>> The build failed:
>>>>
>>>>    debian/rules override_dh_missing
>>>> make[1]: Entering directory '/home/chuckz/sources-sid/xen/xen-4.17.0'
>>>> dh_missing --list-missing
>>>> dh_missing: warning: usr/lib/modules-load.d/xen.conf exists in debian/tmp but is not installed to anywhere
>>>> dh_missing: warning: usr/lib/systemd/system/proc-xen.mount exists in debian/tmp but is not installed to anywhere
>>>> dh_missing: warning: usr/lib/systemd/system/xen-init-dom0.service exists in debian/tmp but is not installed to anywhere
>>>> dh_missing: warning: usr/lib/systemd/system/xen-qemu-dom0-disk-backend.service exists in debian/tmp but is not installed to anywhere
>>>> dh_missing: warning: usr/lib/systemd/system/xen-watchdog.service exists in debian/tmp but is not installed to anywhere
>>>> dh_missing: warning: usr/lib/systemd/system/xenconsoled.service exists in debian/tmp but is not installed to anywhere
>>>> dh_missing: warning: usr/lib/systemd/system/xendomains.service exists in debian/tmp but is not installed to anywhere
>>>> dh_missing: warning: usr/lib/systemd/system/xendriverdomain.service exists in debian/tmp but is not installed to anywhere
>>>> dh_missing: warning: usr/lib/systemd/system/xenstored.service exists in debian/tmp but is not installed to anywhere
>>>
>>> I cannot reproduce this error here locally and the CI build also succeeds:
>>>
>>> https://salsa.debian.org/xen-team/debian-xen/-/pipelines/481577
>> 
>> I thought I had a fairly clean sid install, but I think the problem
>> on my system could be caused by some obscure grandfathered in
>> setting because the sid I am using was updated from all the way back to
>> an original install of jessie many years ago...
>> 
>> It might be time for me to refresh my sid with a clean installation.
>> 
>> Out of curiosity and if you have time, can you answer a couple of
>> question if you know the answer?
>> 
>> 1. Do the builds on a clean environment produce the missing files
>> listed in my build?
> 
> No, after my local package build, there's no such things in there:
> 
> ~/build/xen/debian-xen/debian/tmp/usr/lib m (master) 1-$ ll
> total 0
> drwxr-xr-x 1 knorrie knorrie  110 Jan  8 23:51 debug
> drwxr-xr-x 1 knorrie knorrie 2048 Jan  8 23:50 x86_64-linux-gnu
> drwxr-xr-x 1 knorrie knorrie   20 Jan  8 23:51 xen-4.17
> 
>> 
>> 2. Are those systemd service files installed anywhere in the xen
>> binary packages, either in arch=x86_64 packages or for the arch=all
>> packages such as xen-utils-common?
> 
> No, they are not:
> 
> https://packages.debian.org/search?searchon=contents&keywords=xenconsoled.service&mode=path&suite=unstable&arch=any
> 
>> If you don't know the answer to these questions I will investigate
>> myself to find the answers, so you can work on more important things.
>> 
>>>
>>> How are you building the packages? In a clean build environment, using
>>> for example sbuild or pbuilder, or in an environment where unrelated
>>> other build dependencies could be present, that are not included in the
>>> xen list, but maybe 'wake up and do something' if they're present?
>> 
>> As I said, I am building on a sid install that might have some
>> stuff grandfathered in from old releases going back to jessie.
>> I also might have some stale stuff around from my private builds
>> of the traditional device model available from xen that is not
>> part of the Debian packages. I will investigate these possible causes.
>> 
>> I use debuild as a frontend to dpkg-buildpackage to build the packages.
> 
> Yes. So (I'm not entirely sure how it works, but as example, just making
> something up here): After doing something else first, you might end up
> with a system that has for example dh-systemd-yolo-all-the-things-helper
> installed. And, it might be that only it being present means that the
> package build process changes. It might even be a 'feature' of that
> helper... "just add it to your build depends, and it will automatically
> do all the things for you!!!~``1"
> 
> This is why it is very much recommended to build the packages using
> something like sbuild, so that you can be sure that every time it will
> start with a super minimal chroot which only has some essential things,
> and that the only build dependencies used will be the ones that are
> explicitly defined in the debian/control of the package.
>>> You can also compare your own build output with the full one from the CI
>>> job:
>>>
>>> https://salsa.debian.org/xen-team/debian-xen/-/jobs/3767564/raw

On my build:

checking for LIBNL3... yes
checking for SYSTEMD... no
checking for SYSTEMD... yes
checking for SYSTEMD... no
checking for SYSTEMD... yes
checking for bison... /usr/bin/bison

On the CI build:

checking for LIBNL3... no
configure: WARNING: Disabling support for Remus network buffering and COLO.
    Please install libnl3 libraries (including libnl3-route), command line tools and devel
    headers - version 3.2.8 or higher
checking for SYSTEMD... no
checking for SYSTEMD... no
checking for bison... /usr/bin/bison

It looks like my system having libnl3 is the culprit. It is causing extra checks
for systemd that succeed on my system, but all checks for systemd fail on the
CI build. That is why on my system it is trying to install systemd files.

On my system:

chuckz at debian:~$ dpkg-query -l \*libnl\*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                    Version      Architecture Description
+++-=======================-============-============-==========================================================
ii  libnl-3-200:amd64       3.7.0-0.2+b1 amd64        library for dealing with netlink sockets
ii  libnl-3-dev:amd64       3.7.0-0.2+b1 amd64        development library and headers for libnl-3
un  libnl-dev               <none>       <none>       (no description available)
ii  libnl-genl-3-200:amd64  3.7.0-0.2+b1 amd64        library for dealing with netlink sockets - generic netlink
ii  libnl-route-3-200:amd64 3.7.0-0.2+b1 amd64        library for dealing with netlink sockets - route interface
ii  libnl-route-3-dev:amd64 3.7.0-0.2+b1 amd64        development library and headers for libnl-route-3
un  libnl2-dev              <none>       <none>       (no description available)
un  libnl3-dev              <none>       <none>       (no description available)
chuckz at debian:~$ sudo apt-get -s remove libnl-3-200
...
The following packages will be REMOVED:
  ibverbs-providers iw libcephfs2 libibverbs-dev libibverbs1 libiscsi-dev libiscsi7 libnl-3-200 libnl-3-dev
  libnl-genl-3-200 libnl-route-3-200 libnl-route-3-dev librados-dev librados2 librbd-dev librbd1 librdmacm-dev
  librdmacm1 libvirt-glib-1.0-0 libvirt0 powertop virt-viewer wpasupplicant
...
chuckz at debian:~$

So I think this means xen currently suffers from ftbfs if wpa-supplicant or libvirt0 is installed.

libnl-3-200 is a not an old package from a prior release, amd64 version was uploaded on 9-6-2022:

https://snapshot.debian.org/package/libnl3/3.7.0-0.2/#libnl-3-200_3.7.0-0.2:2b:b1

Do you want me to look at the configure settings and see if I can find a
way to fix this?

Chuck