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
