Hi again Steven,
- I've been using mh for decades (literally!), so I no longer remember
why I originally chose to configure using --with-hash-backup.
This is now fixed on the master branch, if Ken or David are happy then
it can get cherry-picked across to branch 1.7-release.
http://git.savannah.nongnu.org/cgit/nmh.git/commit/?id=47b86722957cca6057bf5fcd07c9d1f01b4516f8
./test/mhfixmsg/test-mhfixmsg: test failed, outputs are in
/big/local/pkg/nmh/nmh-1.7/test/testdir/Mail/inbox/31 and
/big/local/pkg/nmh/nmh-1.7/test/testdir/test-mhfixmsg2494.actual.
first named test failure: pass through message with relative folder
path with parse error
FAIL: test/mhfixmsg/test-mhfixmsg
Is this something I can safely ignore?
Well, if you don't use mhfixmsg, then probably. :-) I'll have a look,
though I don't think it will be something obvious. Do you have
valgrind(1) on that system? You could run just that test, for speed,
with
make TESTS=test/mhfixmsg/test-mhfixmsg check
and adding an environment variable makes the harness run executables
under valgrind.
NMH_VALGRIND=1 make TESTS=test/mhfixmsg/test-mhfixmsg check
- It would be really nice if configure and Makefile.in didn't force
a trailing /nmh on the pathnames I supply for libexecdir and
sysconfdir.
Do you use a different subdirectory instead? Here, for example,
/usr/lib/nmh ends up with executables that shouldn't be in PATH.
ap fmtdump mkstemp rcvdist rcvstore slocal viamail
dp mhl post rcvpack rcvtty spost
They shouldn't sit in /usr/lib either. Are you saying the default
should end in /nmh, but if the user tells configure or Makefile the
location then the append shouldn't happen?
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers