On Sat, 28 Mar 1998, W T Hewitt wrote:

I finally figured out the problem. I'd ftp'ed the file to a PC then to an SGI O2, and the klm.p1 had extraneous <CR>s in it!

Yikes!

I've been using mailman on an SGI, and my problems/suggestions/fixes for the next release.

I'm willing to do some of them if somebody will tell me which ones to do:

I'm glad to hear your suggestions, and that you're interested in hacking on the system.

1. in mailman/src/*.c put UID and GID in a .h file so I Only need to edit one file

I would appreciate this being done, but be careful to distinguish them (and perhaps include more explanation about which is which). I will probably not do this myself.

2. Make /home/mailman a configuration variable

This would be good, but i'm not clear how it would be done in a general way - specifically because all the files need to add the modules dir path to their sys path, and they can't import anything or do anything implicit until they have that info. I'm inclined to think something involving a relative path will be the answer, but that can get complicated.

3. Make the logging files /tmp* world writeable (when debugging I had problems running as nobody and mailman) and make the names consistent

I have implemented a generic file logging mechanism, one which does not disrupt operation if log files are unreachable, and deployed the mechanism everywhere that files were deployed, plus some places where they weren't. (It will be easy to plug in syslog as an optional alternative to the file-based output, eventually.)

4. Use HTMLgen for creating HTML

Robin has looked at this a bit. I'll be interested in his response - but what in particular is to be gained by using HTMLgen instead of the home brewed stuff? It may be basic, but i'd think it'd be best to keep the html layout simple, at least until we have the rest of the system nicely polished, and can spend the attention on fancier layouts...

5. On SGI you can't add aliases to programs in /etc/aliases You do it through a .forward file for /home/mailman All names in /etc/aliases are therefore aliased to mailman, and I have a mailwrapper script that does what aliases used to do.

Hmm, this is a tricky one. If i recall correctly, on many unix systems (ie, with recent versions of sendmail) you need an entry:

/SENDMAIL/ANY/SHELL/

in /etc/shells to enable program aliases. Did you try that? If that's the problem, then the fix is to include an instruction about that in the installation doc. If it's not, then we'll want to include your additional wrapper layer (but it'll be getting deep!-)

6. Add archive more frequently (e.g., daily, hourly, now) to mm_archive volume_frequency I have a fix for this

I should warn you that in my new version i do away with the internal pipermail and instead use a new version of andrew kuchling's pipermail (which andrew is tinkering with here). Therefore the archive frequency depends on how often the pipermail archiver is pointed at the archives. (Something high on my priorities is to provide private archives, in addition to the public ones, which key on the maillist members passwords. We hope to have that together this or next week, and then we'll be able to release a new version of mailman, with lots of stuff like the above, together with the new pipermail.)

7. crontab on SGI complains about blank lines in crontab.in

On solaris 2.6 also - it's repaired.

8. Put all the files associated with a list in one subdirectory, that is independent of mailman code.

Hmm - on one hand, i like the idea of consolidating the templates and list data, on the other hand i want to be able to direct the list traffic to arbitrary places, to organize them sensibly for, eg, external archivers (:-). I think this should be configurable, perhaps with defaults that collect them together.

Speaking of defaults, another big change i've made is to collect together all the default values from all the files into a single new file, mm_defaults.py. All the other files get their defaults from mm_cfg, which gets the distributed defaults from mm_defaults (via 'from mm_defaults import *'). This way, we distribute generic defaults in mm_defaults.py, and sites put their local configurations in mm_cfg.py. New distrbutions overwrite mm_defaults.py, not mm_cfg.py, so the local settings are preserved...

There is a substantial number of other changes (eg, robin's nice listinfo layouts, which you might have noticed in the python.org maillists), but i've been too busy trying to get everything shipshape to get around to tallying and packaging it all.

Ken