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

Hans van Kranenburg hans at knorrie.org
Mon Jan 9 17:55:55 GMT 2023


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
> 
> I will take a look at that when I get a chance.
> 
> This is not a real high priority for me, so I am content to let this
> be until I get a chance to investigate the quirks of my current
> installation of sid, and I also added the moreinfo tag, so you can
> ignore this bug if you wish until I do some further research. 

Sure, no problem.

Have fun,
Hans



More information about the Pkg-xen-devel mailing list