On 1/13/23 7:39 AM, Marek Marczykowski-Górecki wrote: > On Fri, Jan 13, 2023 at 12:58:29AM -0500, Chuck Zmudzinski wrote: >> On 1/11/2023 10:58 PM, Chuck Zmudzinski wrote: >> > 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 >> >> Regarding the systemd files causing ftbfs, this explains it: >> >> https://salsa.debian.org/xen-team/debian-xen/-/blob/master/m4/systemd.m4#L119 >> >> and this: >> >> https://salsa.debian.org/xen-team/debian-xen/-/blob/master/tools/configure.ac#L480 >> >> The comments indicate that using AX_AVAILABLE_SYSTEMD() will >> by default enable systemd if systemd development files are on the >> build system, and AX_ALLOW_SYSTEMD() means --enable-systemd >> must explicitly be passed to tools/configure to enable it. Upstream >> uses the former, so build systems with systemd development files >> by default will ftbfs because that produces missing files that dh_missing >> in debian/rules does not like. >> >> So the reason there is ftbfs on my system is that my system has >> the systemd development package installed. > > By the way, maybe a better fix would be to pass --enable-systemd, add > libsystemd-dev > build-dep and list them in the package? They might require patching to > support Debian-specific upgrade machinery, though... > > Not installing xendriverdomain.service is one of things missing for > driver domains support > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=922033). >
Hi Marek, I wouldn't be against fixing it that way. In fact, I would prefer that Debian packaged Xen with full support for native systemd units. I am willing to wait until if/when the package maintainers have full systemd support in the Xen packages. Perhaps this is an opportunity for you to try to fix 922033 again. I see it has been sitting there for a few years now. Let's see what Hans thinks. Kind regards, Chuck