Control: tags -1 - unreproducible moreinfo Control: retitle -1 mailutils: FTBFS with emacs installed in build environment
Hello again, On Sat, Jan 02, 2021 at 03:12:07PM -0600, Rob Browning wrote: [...] > dh_missing > dh_missing: warning: usr/share/emacs/site-lisp/mailutils-mh.el exists in > debian/tmp but is not installed to anywhere (related file: > "debian/tmp/usr/share/mailutils/mh/mailutils-mh.el") > dh_missing: warning: usr/share/emacs/site-lisp/mailutils-mh.elc exists in > debian/tmp but is not installed to anywhere [...] > dh_missing: error: missing files, aborting > make: *** [debian/rules:4: binary] Error 255 > dpkg-buildpackage: error: debian/rules binary subprocess returned exit > status 2 [...] Thanks for this info, it made it much easier to know where to look for the problem which is caused by having emacs installed in the build environment (which it isn't in a clean buildd chroot). The AM_PATH_LISPDIR macro will check for emacs xemacs and set the EMACS variable (which defaults to 'no' if not found). This in turn will cause the mailutils-mh.el to (also) be installed in the `lispdir` (in addition to the `mhlibdir`). I see these potential theoretical solutions: 1. Declare Build-Conflicts against any package that has emacs or xemacs. (... which seems like a really bad idea to me.) 2. just `rm -rf debian/tmp/usr/share/emacs` before dh_missing is ran. 3. Build-depend on (some variant of) emacs and install the emacs/site-lisp files. 4. Try to convince configure to enable emacs/lispdir without having emacs necessarily installed (possibly by passing --with-lispdir) and install the emacs/site-lisp files. (Probably a better idea than 3 if possible.) I'm don't know emacs stuff well enough to know if and why installing the same file in both paths would be a useful thing to do, maybe someone else can help shine some light on that? Doing 2/ is easy, fixes the problem, and gets the same content in the built package as the currently existing package in the archive, however it might be useful to understand what purpose having it in the emacs/site-lisp path serves and if that's actually preferred over just maintaining the status quo. Regards, Andreas Henriksson
