After an "apt-get source mailutils/sid" with current unstable,
"debian/rules binary" fails here like this:

  Creating popauth.1...
  /home/vagrant/mailutils/mailutils-3.10/debian/tmp/usr/bin/popauth: error while loading shared libraries: libmu_dbm.so.7: cannot open shared object file: No such file or directory
  help2man: can't get `--help' info from /home/vagrant/mailutils/mailutils-3.10/debian/tmp/usr/bin/popauth
  Try `--no-discard-stderr' if option outputs to stderr
  make[1]: *** [debian/rules:52: override_dh_auto_install] Error 127
  make[1]: Leaving directory '/home/vagrant/mailutils/mailutils-3.10'
  make: *** [debian/rules:4: binary] Error 2

Hello,

I'm unable to reproduce your build problems. I've built mailutils
in a loop for a while now and every build succeeds for me.
[...]

Could you please try using `dpkg-buildpackage -uc -us`, rather than
directly invoking debian/rules, and see if it helps you detect any
misconfigurations in your build environment?

Could you please provide a full build log?

Can you think of anything that might be relevant why the build
would fail for you but not me?

Regards,
Andreas Henriksson

Andreas Henriksson <andreas@fatal.se> writes:

Just tried again in a new debian/testing64 VM (via vagrant).  It still
fails in the same way with "debian/rules binary", and fails in a new way
(dh_missing error) with "dpkg-buildpackage -uc -us".

Exact commands (suspect a current testing schroot would behave
similarly, but haven't tested that yet):

  $ mkdir tmp-mailutils-test
  $ cd tmp-mailutils-test
  $ vagrant init debian/testing64
  $ vagrant up
  $ vagrant ssh
  $ sudo -i
  # apt update
  # apt dist-upgrade
  # apt build-dep mailutils
  # apt source mailutils
  # cd mailutils-3.10
  # dpkg-buildpackage -uc -us
    ...
  make[1]: Entering directory '/root/mailutils-3.10'
  dh_fixperms -Xdotlock.mailutils
  make[1]: Leaving directory '/root/mailutils-3.10'
     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

          While detecting missing files, dh_missing noted some files with a similar name to those
          that were missing.  This error /might/ be resolved by replacing references to the
          missing files with the similarly named ones that dh_missing found - assuming the content
          is identical.

          As an example, you might want to replace:
           * debian/tmp/usr/share/mailutils/mh/mailutils-mh.el
          with:
           * usr/share/emacs/site-lisp/mailutils-mh.el
          in a file in debian/ or as argument to one of the dh_* tools called from debian/rules.
          (Note it is possible the paths are not used verbatim but instead directories
          containing or globs matching them are used instead)

          Alternatively, add the missing file to debian/not-installed if it cannot and should not
          be used.

          The following debhelper tools have reported what they installed (with files per package)
           * dh_install: libmailutils-dev (115), libmailutils7 (36), libmu-dbm7 (2), mailutils (10), mailutils-common (14), mailutils-comsatd (1), mailutils-doc (1), mailutils-guile (2), mailutils-imap4d
  (1), mailutils-mda (3), mailutils-mh (46), mailutils-pop3d (2), python3-mailutils (23)
           * dh_installdocs: libmailutils-dev (0), libmailutils7 (0), libmu-dbm7 (0), mailutils (0), mailutils-common (0), mailutils-comsatd (0), mailutils-doc (6), mailutils-guile (0), mailutils-imap4d (0), mailutils-mda (0), mailutils-mh (1), mailutils-pop3d (0), python3-mailutils (0)
           * dh_installexamples: libmailutils-dev (0), libmailutils7 (0), libmu-dbm7 (0), mailutils (1), mailutils-common (0), mailutils-comsatd (1), mailutils-doc (0), mailutils-guile (1), mailutils-imap4d (1), mailutils-mda (0), mailutils-mh (0), mailutils-pop3d (1), python3-mailutils (0)
           * dh_installman: libmailutils-dev (2), libmailutils7 (0), libmu-dbm7 (0), mailutils (10), mailutils-common (0), mailutils-comsatd (1), mailutils-doc (0), mailutils-guile (0), mailutils-imap4d (1), mailutils-mda (3), mailutils-mh (0), mailutils-pop3d (2), python3-mailutils (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.
  dh_missing: error: missing files, aborting
  make: *** [debian/rules:4: binary] Error 255
  dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

It's trivial to reproduce with those commands, so happy to gather any
addiitonal information you might like.

Thanks

Hello again,

On Sat, Jan 02, 2021 at 03:12:07PM -0600, Rob Browning wrote:
[...]
[...]
[...]

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

Andreas Henriksson <andreas@fatal.se> writes:

Ahh, sorry, clearly forgot to mention that I'd also run "apt install
emacs-nox" to do some editing.  Glad you figured it out.

No strong opinion, fwiw -- I was originally just concerned about the
build failure.

...or maybe a dh_missing debian/not-installed override or -X if that'll
work.

Seems like in the short run, we didn't have those bits before, so
perhaps fine to leave it that way for now.  And in the longer run, if we
decide we do want those files, and if there's much elisp code, it might
ought to be compiled at install time as with dh-elpa or other
emacsen-related packages, which might or might not suggest a
mailutils-el package or something.

If you do decide to head that route, I'd highly recommend #debian-emacs
on oftc.  Plenty of expertise there.

Thanks again

* Rob Browning <rlb@defaultvalue.org> [210403 00:45]:

Given building mailutils works in a clean environment, this bug is
not really severity: serious AFAICT.

Should still be fixed, obviously.

Chris