Ok, so... On 2/24/19 3:39 PM, Santiago Vila wrote: >> All of this seems to be related to the dh-exec usage for putting files >> in the xen-utils-common package with a different name. This is the first >> time this package is using dh-exec. >> >> [...] >> >> Interestingly, 'etc/default/xencommons => /etc/default/xen' does not >> result in a similar error? >> >> I also found this one, which seems to be related: >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831786 >> >> Do you have an idea / suggestion how we can deal with this? > > Based on your analysis, maybe applying the patch below. > > After all, the "fail-missing" thing is just an extra protection which > helps avoiding mistakes when installing things, but in this case > it seems to be more troublesome than helpful. > > --- a/debian/rules > +++ b/debian/rules > @@ -307,8 +307,11 @@ override_dh_compress: > > # By default, files in debian/tmp which are not handled by anything > # in rules are ignored. This makes them into errors. > -override_dh_missing: > - dh_missing --fail-missing > +# > +# Disabled because of Bug #831786 > +# > +# override_dh_missing: > +# dh_missing --fail-missing > > > # We are dropping the config file /etc/default/xen which appeared in
Oh right. This accidentally quoted line helped me find out that etc/default/xencommons is listed in debian/not-installed because it was not installed before. However, now it is again, but it was not removed from not-installed, and this solves the mystery of dh_missing not complaining about it. It seems useful to me to keep the dh_missing --fail-missing, so the workaround for the dh-exec bug will now be to also list etc/bash_completion.d/xl.sh in not-installed, with a short explanation in a comment. Now I can do dpkg-buildpackage -A without the error. https://salsa.debian.org/xen-team/debian-xen/commit/69f65e1f7676cb387c9742a4e8ab96ee53e36d1d (this commit hash will likely disapper again later, but today it'll be there :) ). Hans