X-Git-Url: http://git.marmaro.de/?a=blobdiff_plain;f=ChangeLog;h=580cf4c3ac860de943185665657345dc5f0520df;hb=cd5e92564c2b2c1d4c247b97ca27b016afb22976;hp=2ba743ee1008091d979989509f9609e2dd1a5176;hpb=a5ff28a9c0927f27efd1378ebc97ad72ffeb56d1;p=mmh

diff --git a/ChangeLog b/ChangeLog
index 2ba743e..580cf4c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,48 @@
+Fri Sep 8 00:36:48 2000 Shantonu Sen <ssen@mit.edu>
+
+	* Moved zotnet/mts to mts/generic. This code reorganization
+	makes the entire zotnet tree deprecated -- bboards is unneeded,
+	mf was was moved to sbr, tws was rewritten and moved to sbr, and
+	now finally mts.
+
+	* Created a new static library called libmts.a used during
+	compilation which includes the generic mts code and the
+	smtp/sendmail code. This supercedes the functionality of the
+	old libsmtp.a and the remains of libzot.a.
+
+	* Updated header includes to reference the new location of mts.h
+	in mts/generic/mts.h. Also, update the configure and top-level
+	Makefile not to descend into zotnet. Also, they don't descend
+	into mts/mmdf and mts/sendmail (the sendmail code has been
+	merged into the smtp code).
+
+	* Added #include <h/nmh.h> to h/md5.h, since my compile was
+	complaining about implicitly-declared memcpy and memset, which
+	appear to be in strings.h. In any event, nmh.h should take care
+	of it for us.
+
+	* When doing a "make nmhdist", notice that the generated
+	snapshot does not include zotnet of the mts directories as noted
+	above. Since they are no longer compiled, and I don't see any
+	obvious code path to get to them, end-users should probably
+	not need them. If you think otherwise, turn Makefile generation
+	back on in configure.in and turn on recursion into those dirs
+	in the appropriate Makefile.in
+
+Wed Sep 6 22:40:03 2000 Shantonu Sen <ssen@mit.edu>
+
+	* Tracked down the problem in the new dtimep where time
+	zones were being radically misreported. It was because the
+	parser knew about military time zones (such as M or E) but in
+	some cases did not know about the textual representation of
+	some zones (like MET). When it encountered one of these, the
+	date parser misread MET as the military time zone T (well, first
+	zone M, then E, and finally T). I took military zones out, and
+	things seem much better. Also, the default behavior of parsing
+	time zones appears to default to GMT in the absence of better
+	info, which is less bogus than assuming the mail came from the
+	current time zone, which was the behavior in 1.04.
+
 Thu Aug 10 13:22:13 2000 Dan Harkless <dan-nmh@dilvish.speed.net>
 
 	* Decided that limiting the message number columns to 3 on my