Fix mh on debathena

[tabbott]

We should fix mh on Debathena. I think we've still got the mhl and defaults problems remaining.

[mitchb]

The solution to the mhl issue is to add this line to the debian/rules file before the
include lines:

DEB_BUILD_OPTIONS = noopt

Without that, debuild by default uses -O2, and this causes uip/mhlsbr.c to segfault while
processing headers on a call to strcasecmp on line 904 where it refers to a global struct
and ends up with a null pointer.

So, we've now fixed the MTA problem and the mhl problem, and the only thing that I believe
is left is figuring out the right answer for the mhn.defaults issue. The obvious choices
are to let it run the configuration script and end up with a minimal list of MIME types
we can display, or come up with a more appropriate static version of the file for Debathena,
which maybe could use attachandrun scripts or something similar if you have that in Debathena,
but of course that type of strategy won't work on a machine that doesn't have AFS, for
example. So, what do we do?

[andersk]

Is it possible we could switch to the upstream Debian nmh package (which is 1.2 instead of 1.0), possibly with minimal patches? This would make the package a lot easier to maintain.

[mitchb]

Is it possible we could switch to the upstream Debian nmh package (which is 1.2 instead of 1.0),
possibly with minimal patches? This would make the package a lot easier to maintain.

Yes, possibly. I had sort of wondered why Debathena went with the old one, and figured that
you had a good reason. Thinking harder about it, the reason may have been "taking the one
from the Athena tree with its patches wholesale was easier." Having looked through it when
I was debugging these problems, it really doesn't seem like we have a large number of local
patches. I'm curious what the current version of nmh supports in terms of authentication
schemes... maybe it solves our krb5 transition problem.

But in the meantime, it essentially doesn't work for people aside from me who would like to
use it on linerva, so I'd love it if we could make a decision on how to fix the mhn.defaults
file, turn off build-time optimization, and get the new package pushed out to the repository
and installed on linerva.

I'll look into the current nmh when we get the bugs with what's out there squared away, since
we already know how to fix them and that'll be quicker than adopting a new version.

[andersk]

I’ve built nmh packages with DEB_OPT_FLAG = -O0 for testing, in /mit/debathena/packages/athena/nmh.

[mitchb]

Okay, I blew away most of the nmh stuff on zsr (just to be sure), and
installed Anders's new Ubuntu 7.10 package, and copied in all the conffiles.
I can confirm that this package appears to remedy both the lack-of-sendmail
problem and the mhl-eating-headers problem.

Also, a new discovery... Anders pointed out that Debathena is *already*
installing a custom static mhn.defaults file different from Athena's, and
is using attachandrun to display various mime types with programs out of
the mimeutils locker. The scripts in that locker load a utility script
that displays prompts and such by piping simple markup through the
'richtext' program. richtext exists and works fine on Debathena. However,
the mimeutils scripts alter the path to ensure that richtext from the
mimeutils locker is used, and that version links against libtermcap.so.2.
This library is missing on currentish Ubuntu and Debian, because termcap
is deprecated and things really should just use ncurses these days.
libtermcap.so does exist, but is in fact a symlink to libncurses.so.
Much as predicted (and suggested in some Google hits), symlinking
libtermcap.so.2 to libtermcap.so solves the problem.

Discussion with Anders indicates that a package to allow such symlinks
had been considered and rejected in favor of getting lockers fixed, and
it appears that I have bits on the mimeutils locker via release-team.
I'm going to check with wdc if it's okay for me to make changes in it,
and if so, will probably create an i386_deb40 arch subdir with a symlink
tree, and then install a Debian or Ubuntu richtext in it. This ought
to fix the problem, and perhaps there's nothing wrong with mhn.defaults
at all.

Also, I checked out comp, and it "worked," but of course exim on zsr
still isn't configured to default address domains to @mit.edu and to
allow sending to remote domains. That won't affect linerva, but it does
sort of need to be fixed so that arbitrary Debathena machines can send
mail.

I'm not sure what you guys would prefer, but it seems like the two known
remaining issues involve a change to a locker and a change to a different
package, so this one may be ready to be pushed out to the repository
and linerva, but maybe you'd rather wait until those fixes are ready and
tested.

[tabbott]

It sounds to me like we should upload the new version.

The lack of a reasonable sendmail replacement for Debathena machines other than Linerva is #52, and fairly high on my list of Debathena priorities, so maybe we should work on that on Monday.

[mitchb]

It sounds to me like we should upload the new version.

Almost. After talking with Bob Basch, I added an i386_deb40 arch directory to the
mimeutils locker that has a symlink farm to everything in i386_linux22, except that
it explicitly does not have a richtext binary or symlink. This will cause the scripts
in the mimeutils locker to use the native richtext installed on Debathena machines. richtext
is part of the metamail package. So, please add a dependency on metamail. The resulting
package should be ready to go, and should fix all issues I'm aware of with debathena-nmh
(at least for linerva, until the general MTA issue is resolved).

[tabbott]

I believe we've now uploaded the nmh package.