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
