On 03.11.2022 18:41, Rene Engelhard wrote: > Control: severity -1 important > Control: tags -1 - moreinfo > Control: tags -1 - unreproducible > thanks > > Am Sun, Oct 30, 2022 at 07:19:24AM +0100 schrieb Håvard F. Aasen: >>>> dh_missing >>>> dh_missing: warning: lib/systemd/system/oscap-remediate.service exists in >>>> debian/tmp but is not installed to anywhere >>>> dh_missing: warning: usr/bin/oscap-remediate-offline exists in debian/tmp >>>> but is not installed to anywhere >>>> dh_missing: warning: usr/libexec/oscap-remediate exists in debian/tmp but >>>> is not installed to anywhere >>>> dh_missing: warning: usr/share/man/man8/oscap-remediate-offline.8 exists >>>> in debian/tmp but is not installed to anywhere >>>> dh_missing: error: missing files, aborting >>>> The following debhelper tools have reported what they installed (with >>>> files per package) >>>> * dh_install: libopenscap-dev (4), libopenscap-perl (2), libopenscap25 >>>> (4), openscap-common (3), openscap-doc (2), openscap-scanner (2), >>>> openscap-utils (8), python3-openscap (1) >>>> * dh_installdocs: libopenscap-dev (3), libopenscap-perl (0), >>>> libopenscap25 (0), openscap-common (0), openscap-doc (0), openscap-scanner >>>> (1), openscap-utils (0), python3-openscap (0) >>>> * dh_installexamples: libopenscap-dev (0), libopenscap-perl (0), >>>> libopenscap25 (0), openscap-common (0), openscap-doc (0), openscap-scanner >>>> (1), openscap-utils (0), python3-openscap (0) >>>> * dh_installman: libopenscap-dev (0), libopenscap-perl (0), >>>> libopenscap25 (0), openscap-common (0), openscap-doc (0), openscap-scanner >>>> (1), openscap-utils (7), python3-openscap (0) >>>> If the missing files are installed by another tool, please file a bug >>>> against it. >>>> When filing the report, if the tool is not part of debhelper itself, >>>> please reference the >>>> "Logging helpers and dh_missing" section from the "PROGRAMMING" guide >>>> for debhelper (10.6.3+). >>>> (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz) >>>> Be sure to test with dpkg-buildpackage -A/-B as the results may vary >>>> when only a subset is built >>>> If the omission is intentional or no other helper can take care of this >>>> consider adding the >>>> paths to debian/not-installed. >>>> make: *** [debian/rules:68: binary] Error 25 >>>> dpkg-buildpackage: error: debian/rules binary subprocess returned exit >>>> status 2 >>>> debuild: fatal error at line 1182: >>>> dpkg-buildpackage -us -uc -ui -b failed >>>> >>>> Doesn't look related to xmlsec1 1.2.35 so I did a cross-check with sid >>>> and it also FTBFS there. >>>> >>> >>> Would you mind providing a complete build log? I actually can't reproduce >>> this on my end in unstable. This was also rebuilt in the main archive just >>> eight days ago, but sure, a lot can happen in that time. >>> >> >> I uploaded a new version to unstable with changes unrelated to this bug. That >> version successfully built in the main archive, I am therefore lowering the >> severity to normal. Please provide a build log if this is a problem. > > It would have been be helpful if you actually wrote to me instead of just the > bug > (n...@bugs.debian.org only goes to the bug), as the Reply-To: of each > bugreport already does (or do it manually, or use > nnn-submit...@bugs.debuan.org); so that people actually see it. I just > saw it by chance today when looking at my submitted bugs' page and saw > the downgrade. > > Anyways, buildlog attached. > > Note that this admittedly is a unclean chroot, but a FTBFS then also is > a bug (important I think, but see [1]. > cowbuilder login sid chroot + > apt-build-dep lasso + > apt-build-dep libaqbanking + > apt build-dep libreoffice + > apt-build-dep nordugrid-arc + > apt-build-dep oath-toolkit + > apt build-dep open-vm-tools > > is the actual chroot used. (Actually it was in my libreoffice build > chroot, so those were preexisting) > > Regards, > > Rene > > [1] > 18:32 < _rene_> what severity are "FTBFS in 'unclean' chroots" again? > 18:32 -!- KBDharunKrishna[m]1 [~kbdkmatri@2a01:4f9:c010:c8f3:1::28d] has > joined #debian-devel > 18:32 < _rene_> builds in a clean (as it only build-deps) apparently > 18:33 < kibi> important at most > 18:34 < kibi> (long time no see though, there might be special circumstances > that would make it warrant more) > 18:36 < Sebastinas> We recently had a bunch of "FTBFS with systemd installed" > recently which we treated as RC. > 18:36 < Sebastinas> (Triggered by some essential packages pulling systemd) > 18:37 < Sebastinas> So: depends(tm) > 18:37 < _rene_> that sounds related > 18:37 < _rene_> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023041) > 18:37 -zwiebelbot:#debian-devel- Debian#1023041: FTBFS: uninstalled files; > dh_missing errors out - https://bugs.debian.org/1023041 > 18:38 < _rene_> >> dh_missing: warning: > lib/systemd/system/oscap-remediate.service exists in debian/tmp but is not > installed to anywhere
Thanks for the replay Rene, I'll see if I can't tweak my mailing skills. As already stated in the provided IRC log, it's CMake that finds a systemd module, and therefore install some extra files. I'll probably include a patch from upstream and add an additional config option to CMake in d/rules. Should be fixed within a day or two. Håvard
