From klm@python.org Tue Mar 17 15:26:17 1998 From: klm@python.org (Ken Manheimer) Date: Tue, 17 Mar 1998 10:26:17 -0500 (EST) Subject: [Mailman-developers] Re: [Matrix-SIG] Testing transition to mailman list processor In-Reply-To: <13582.36052.669936.337566@localhost> Message-ID: On Tue, 17 Mar 1998, Charles G Waldman wrote: > Ken Manheimer writes: > > The Matrix-SIG mailing list has just been migrated to mailman, a > > python-based maillist management system. > > Hi Ken - this is off-topic for the Matrix-SIG - more of a "mailman" > question. I've been meaning to mention this to someone, I'm not sure > who the maintainer is of the Mailman package - is it you? Anyway, > your message provides me with the excuse to write you.... :-) At the moment i'm carrying the ball, basically in order to get mailman in full gear at python.org. As you may know, we're using a version that's the most recent one recovered after loss of the server where john viega was developing and running mailman, and basically several months of work were lost. John is around and interested in continuing to work w/mailman, but deep in a grad school thesis, so it'll a little while before he gets to concentrate on it again. However, his intention is to come back to it, especially now that several people have also expressed interest. Towards the end of collaborating on mailman, we've set up a mailman-developers@python.org maillist - see http://www.python.org/mailman/listinfo/mailman-developers . I recommend joining that list, right off - it's not yet particularly active (i, for one, am too busy scrambling just to get the system shipshape and in production at this moment to do planning), but i expect we will be using it in earnest as time goes by. In addition, barry warsaw and i are setting up a mechanism (which barry devised) which should enable cvs sharing of the mailman sources across the internet, so we can do widely distributed coordinated development - at least have a convenient way to share modifications. We'll be pursuing this eventually, as time allows. > I recently set up "mailman" at my company, for our internal use. I > grabbed the distribution from python.org as well as the klm patches. > It basically works fine, but I noticed one oddness. > > If there is a line in a mail message that starts with "From ", > preceded by a blank line, the message is truncated in the message > archives. For instance: > > >From where I'm sitting, it looks like a very simple bug to fix. > > (This part of the message won't be archived) > > Has anybody fixed this yet? I don't want to waste time on this if > it has already been fixed. My work on the version here has diverged from the adapted version of pipermail that john was shipping with mailman - andrew kuchling is working here (handily enough!), so we're using a newer version of pipermail. We should be packaging up the whole shebang, pipermail and mailman, for use by others within the next few/several weeks, but in the meanwhile you're sorta on your own re the internal pipermail. That said, i do have an idea about what is needed. I am pretty sure that the line starting with "From " is being treated as the start of a new message, which probably is unarchivable and dropped on the floor, or perhaps getting put at some random place in the archive. The easy thing to do would be to preprocess the messages before they're put in the archive file so lines in the body starting with "From ", and following a blank line, have ">" prepended. I think the place to do this is in mailman/modules/mm_archive.py, Archiver.ArchiveMail(), but you'd have to scope it out a bit. Phew! This may be a bit more than you bargained for. I hope you don't mind that i'm cc'ing this to mailman developers - the info may well be useful for someone else. Ken Manheimer klm@python.org From w.t.hewitt@mcc.ac.uk Tue Mar 24 12:44:20 1998 From: w.t.hewitt@mcc.ac.uk (W T Hewitt) Date: Tue, 24 Mar 1998 12:44:20 +0000 Subject: [Mailman-developers] Help please. Message-ID: <3517AAA3.8F737108@mcc.ac.uk> --------------88426F57815991BF7BDCDA7F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I got the latest versions of mailman from ftp.python.org: klm.p1 mailman-1.0b1.tar.gz unpacked. When I tried to apply the patches I gave a significant number of rejects!! Would somebody please email me the latest version, or email where it is, or perhaps, let me know the trick to doing the patches.... -- Best wishes Terry W T Hewitt Telephone: +44 161 275 6095 Manchester Visualization Centre Fax: +44 161 275 6800 Manchester Computing Electronic mail: w.t.hewitt@mcc.ac.uk University of Manchester http://www.man.ac.uk/MVC Manchester M13 9PL United Kingdom (formerly the Computer Graphics Unit) --------------88426F57815991BF7BDCDA7F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I got the latest versions of mailman from ftp.python.org:

klm.p1
mailman-1.0b1.tar.gz

unpacked. When I tried to apply the patches I gave a significant number of rejects!!

Would somebody please email me the latest version, or email where it is, or perhaps,
let me know the trick to doing the patches....
 
  

-- 
Best wishes

Terry

W T Hewitt                         Telephone: +44 161 275 6095
Manchester Visualization Centre    Fax: +44 161 275 6800
Manchester Computing               Electronic mail: w.t.hewitt@mcc.ac.uk
University of Manchester           http://www.man.ac.uk/MVC
Manchester M13 9PL
United Kingdom

(formerly the Computer Graphics Unit)
  --------------88426F57815991BF7BDCDA7F-- From klm@python.org Tue Mar 24 16:45:47 1998 From: klm@python.org (Ken Manheimer) Date: Tue, 24 Mar 1998 11:45:47 -0500 (EST) Subject: [Mailman-developers] Help please. In-Reply-To: <3517AAA3.8F737108@mcc.ac.uk> Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --------------88426F57815991BF7BDCDA7F Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: On Tue, 24 Mar 1998, W T Hewitt wrote: > I got the latest versions of mailman from ftp.python.org: > > klm.p1 > mailman-1.0b1.tar.gz > > unpacked. When I tried to apply the patches I gave a significant number > of rejects!! The patches should apply with no problems if you run the patch from the same directory where you untarred the mailman package - ie, in the directory where the single 'mailman' dir was created. > Would somebody please email me the latest version, or email where it is, > or perhaps, > let me know the trick to doing the patches.... I've got lots of developments to package, but it'll be a week or two before i make them available. (One reason is that i want to create at least more elaborate 'help' style descriptions for each of the admin options, to make up a bit for the lack of documentation, and also i've departed from the old internal version of pipermail, in favor of a coordination with a newer version pipermail that andrew has developed, so we need to make both packages available...) Ken --------------88426F57815991BF7BDCDA7F Content-Type: TEXT/HTML; CHARSET=us-ascii Content-ID: Content-Description: I got the latest versions of mailman from ftp.python.org:

klm.p1
mailman-1.0b1.tar.gz

unpacked. When I tried to apply the patches I gave a significant number of rejects!!

Would somebody please email me the latest version, or email where it is, or perhaps,
let me know the trick to doing the patches....
 
  

-- 
Best wishes

Terry

W T Hewitt                         Telephone: +44 161 275 6095
Manchester Visualization Centre    Fax: +44 161 275 6800
Manchester Computing               Electronic mail: w.t.hewitt@mcc.ac.uk
University of Manchester           http://www.man.ac.uk/MVC
Manchester M13 9PL
United Kingdom

(formerly the Computer Graphics Unit)
  --------------88426F57815991BF7BDCDA7F-- From janne@avocado.pc.helsinki.fi Tue Mar 24 17:05:13 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 24 Mar 1998 19:05:13 +0200 Subject: [Mailman-developers] Help please. In-Reply-To: Ken Manheimer's message of "Tue, 24 Mar 1998 11:45:47 -0500 (EST)" References: Message-ID: Ken Manheimer writes: > The patches should apply with no problems if you run the patch from the > same directory where you untarred the mailman package - ie, in the > directory where the single 'mailman' dir was created. The patches installed cleanly and I was even able to create a list. mm_cfg.py or some such however lacked a lot of DEFAULTs and I was never able to subscribe to a test list. I tracked it down to the cgi module returning an empty FieldStorage to cgi/subscribe and the gave up. There was no signs of problems in server (apache) logs, and I did change the UIDs and GIDs in wrapper code. Also, the scripts in cgi/ have their suid bit set, although I guess that's not necessary, at least not in Linux where suid scripts do not suid at all. Just FYI. -- Janne Sinkkonen From w.t.hewitt@mcc.ac.uk Sat Mar 28 00:42:48 1998 From: w.t.hewitt@mcc.ac.uk (W T Hewitt) Date: Sat, 28 Mar 1998 00:42:48 +0000 Subject: [Mailman-developers] Next Release Message-ID: <351C4788.C9605F1@mcc.ac.uk> On Tuesday, March 24, 1998 4:46 PM, Ken Manheimer [SMTP:klm@cnri.reston.va.us] wrote: > On Tue, 24 Mar 1998, W T Hewitt wrote: > > > I got the latest versions of mailman from ftp.python.org: > > > > klm.p1 > > mailman-1.0b1.tar.gz > > > > unpacked. When I tried to apply the patches I gave a significant number > > of rejects!! > > The patches should apply with no problems if you run the patch from the > same directory where you untarred the mailman package - ie, in the > directory where the single 'mailman' dir was created. 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 s in it! 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: 1) in mailman/src/*.c put UID and GID in a .h file so I Only need to edit one file 2) Make /home/mailman a configuration variable 3) Make the logging files /tmp* world writeable (when debugging I had problems running as nobody and mailman) and make the names consistent 4) Use HTMLgen for creating HTML 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. 6) Add archive more frequently (e.g., daily, hourly, now) to mm_archive volume_frequency I have a fix for this 7) crontab on SGI complains about blank lines in crontab.in 8) Put all the files associated with a list in one subdirectory, that is independent of mailman code. Best wishes Terry W T Hewitt Manchester Visualization Centre Telephone: +44 161 275 6095 Manchester Computing Fax: +44 161 275 6800 University of Manchester Email: w.t.hewtt@mcc.ac.uk Manchester M13 9PL URL: http://info.mcc.ac.uk/MVC United Kingdom (Formerly Computer Graphics Unit) From klm@python.org Sat Mar 28 06:00:13 1998 From: klm@python.org (Ken Manheimer) Date: Sat, 28 Mar 1998 01:00:13 -0500 (EST) Subject: [Mailman-developers] Next Release In-Reply-To: <351C4788.C9605F1@mcc.ac.uk> Message-ID: 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 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 From friedrich@pythonpros.com Sat Mar 28 14:53:00 1998 From: friedrich@pythonpros.com (Robin Friedrich) Date: Sat, 28 Mar 1998 08:53:00 -0600 Subject: [Mailman-developers] Next Release References: Message-ID: <351D0ECA.7F84DB6D@pythonpros.com> Ken Manheimer wrote: > > On Sat, 28 Mar 1998, W T Hewitt wrote: > > > 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... > I agree. There is room for improvement in how HTML is generated in MM, and I've added things to the next version of HTMLgen in anticipation of it's use in MM. (i.e. A TemplateDocument class and a cool anti spider feature to the MailTo object.) But I worry about importing a module the size of HTMLgen for every cgi call. That would just slow MM down that much further until MM is upgraded to use a persistant process (v2.0?). idunno, it might add a second. I'll be happy to rework the HTML side of MM at that time. PS. The new Mailto class will now generate random encodings of the address charcters. This works in the browsers fine, but screw up the email spiders. I think this would solve the listinfo page mail privacy issue (at least for now). For example my address might come out like: Robin.Friedrich@pdq.net From klm@python.org Tue Mar 17 15:26:17 1998 From: klm@python.org (Ken Manheimer) Date: Tue, 17 Mar 1998 10:26:17 -0500 (EST) Subject: [Mailman-developers] Re: [Matrix-SIG] Testing transition to mailman list processor In-Reply-To: <13582.36052.669936.337566@localhost> Message-ID: On Tue, 17 Mar 1998, Charles G Waldman wrote: > Ken Manheimer writes: > > The Matrix-SIG mailing list has just been migrated to mailman, a > > python-based maillist management system. > > Hi Ken - this is off-topic for the Matrix-SIG - more of a "mailman" > question. I've been meaning to mention this to someone, I'm not sure > who the maintainer is of the Mailman package - is it you? Anyway, > your message provides me with the excuse to write you.... :-) At the moment i'm carrying the ball, basically in order to get mailman in full gear at python.org. As you may know, we're using a version that's the most recent one recovered after loss of the server where john viega was developing and running mailman, and basically several months of work were lost. John is around and interested in continuing to work w/mailman, but deep in a grad school thesis, so it'll a little while before he gets to concentrate on it again. However, his intention is to come back to it, especially now that several people have also expressed interest. Towards the end of collaborating on mailman, we've set up a mailman-developers@python.org maillist - see http://www.python.org/mailman/listinfo/mailman-developers . I recommend joining that list, right off - it's not yet particularly active (i, for one, am too busy scrambling just to get the system shipshape and in production at this moment to do planning), but i expect we will be using it in earnest as time goes by. In addition, barry warsaw and i are setting up a mechanism (which barry devised) which should enable cvs sharing of the mailman sources across the internet, so we can do widely distributed coordinated development - at least have a convenient way to share modifications. We'll be pursuing this eventually, as time allows. > I recently set up "mailman" at my company, for our internal use. I > grabbed the distribution from python.org as well as the klm patches. > It basically works fine, but I noticed one oddness. > > If there is a line in a mail message that starts with "From ", > preceded by a blank line, the message is truncated in the message > archives. For instance: > > >From where I'm sitting, it looks like a very simple bug to fix. > > (This part of the message won't be archived) > > Has anybody fixed this yet? I don't want to waste time on this if > it has already been fixed. My work on the version here has diverged from the adapted version of pipermail that john was shipping with mailman - andrew kuchling is working here (handily enough!), so we're using a newer version of pipermail. We should be packaging up the whole shebang, pipermail and mailman, for use by others within the next few/several weeks, but in the meanwhile you're sorta on your own re the internal pipermail. That said, i do have an idea about what is needed. I am pretty sure that the line starting with "From " is being treated as the start of a new message, which probably is unarchivable and dropped on the floor, or perhaps getting put at some random place in the archive. The easy thing to do would be to preprocess the messages before they're put in the archive file so lines in the body starting with "From ", and following a blank line, have ">" prepended. I think the place to do this is in mailman/modules/mm_archive.py, Archiver.ArchiveMail(), but you'd have to scope it out a bit. Phew! This may be a bit more than you bargained for. I hope you don't mind that i'm cc'ing this to mailman developers - the info may well be useful for someone else. Ken Manheimer klm@python.org From w.t.hewitt@mcc.ac.uk Tue Mar 24 12:44:20 1998 From: w.t.hewitt@mcc.ac.uk (W T Hewitt) Date: Tue, 24 Mar 1998 12:44:20 +0000 Subject: [Mailman-developers] Help please. Message-ID: <3517AAA3.8F737108@mcc.ac.uk> --------------88426F57815991BF7BDCDA7F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I got the latest versions of mailman from ftp.python.org: klm.p1 mailman-1.0b1.tar.gz unpacked. When I tried to apply the patches I gave a significant number of rejects!! Would somebody please email me the latest version, or email where it is, or perhaps, let me know the trick to doing the patches.... -- Best wishes Terry W T Hewitt Telephone: +44 161 275 6095 Manchester Visualization Centre Fax: +44 161 275 6800 Manchester Computing Electronic mail: w.t.hewitt@mcc.ac.uk University of Manchester http://www.man.ac.uk/MVC Manchester M13 9PL United Kingdom (formerly the Computer Graphics Unit) --------------88426F57815991BF7BDCDA7F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I got the latest versions of mailman from ftp.python.org:

klm.p1
mailman-1.0b1.tar.gz

unpacked. When I tried to apply the patches I gave a significant number of rejects!!

Would somebody please email me the latest version, or email where it is, or perhaps,
let me know the trick to doing the patches....
 
  

-- 
Best wishes

Terry

W T Hewitt                         Telephone: +44 161 275 6095
Manchester Visualization Centre    Fax: +44 161 275 6800
Manchester Computing               Electronic mail: w.t.hewitt@mcc.ac.uk
University of Manchester           http://www.man.ac.uk/MVC
Manchester M13 9PL
United Kingdom

(formerly the Computer Graphics Unit)
  --------------88426F57815991BF7BDCDA7F-- From klm@python.org Tue Mar 24 16:45:47 1998 From: klm@python.org (Ken Manheimer) Date: Tue, 24 Mar 1998 11:45:47 -0500 (EST) Subject: [Mailman-developers] Help please. In-Reply-To: <3517AAA3.8F737108@mcc.ac.uk> Message-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --------------88426F57815991BF7BDCDA7F Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: On Tue, 24 Mar 1998, W T Hewitt wrote: > I got the latest versions of mailman from ftp.python.org: > > klm.p1 > mailman-1.0b1.tar.gz > > unpacked. When I tried to apply the patches I gave a significant number > of rejects!! The patches should apply with no problems if you run the patch from the same directory where you untarred the mailman package - ie, in the directory where the single 'mailman' dir was created. > Would somebody please email me the latest version, or email where it is, > or perhaps, > let me know the trick to doing the patches.... I've got lots of developments to package, but it'll be a week or two before i make them available. (One reason is that i want to create at least more elaborate 'help' style descriptions for each of the admin options, to make up a bit for the lack of documentation, and also i've departed from the old internal version of pipermail, in favor of a coordination with a newer version pipermail that andrew has developed, so we need to make both packages available...) Ken --------------88426F57815991BF7BDCDA7F Content-Type: TEXT/HTML; CHARSET=us-ascii Content-ID: Content-Description: I got the latest versions of mailman from ftp.python.org:

klm.p1
mailman-1.0b1.tar.gz

unpacked. When I tried to apply the patches I gave a significant number of rejects!!

Would somebody please email me the latest version, or email where it is, or perhaps,
let me know the trick to doing the patches....
 
  

-- 
Best wishes

Terry

W T Hewitt                         Telephone: +44 161 275 6095
Manchester Visualization Centre    Fax: +44 161 275 6800
Manchester Computing               Electronic mail: w.t.hewitt@mcc.ac.uk
University of Manchester           http://www.man.ac.uk/MVC
Manchester M13 9PL
United Kingdom

(formerly the Computer Graphics Unit)
  --------------88426F57815991BF7BDCDA7F-- From janne@avocado.pc.helsinki.fi Tue Mar 24 17:05:13 1998 From: janne@avocado.pc.helsinki.fi (Janne Sinkkonen) Date: 24 Mar 1998 19:05:13 +0200 Subject: [Mailman-developers] Help please. In-Reply-To: Ken Manheimer's message of "Tue, 24 Mar 1998 11:45:47 -0500 (EST)" References: Message-ID: Ken Manheimer writes: > The patches should apply with no problems if you run the patch from the > same directory where you untarred the mailman package - ie, in the > directory where the single 'mailman' dir was created. The patches installed cleanly and I was even able to create a list. mm_cfg.py or some such however lacked a lot of DEFAULTs and I was never able to subscribe to a test list. I tracked it down to the cgi module returning an empty FieldStorage to cgi/subscribe and the gave up. There was no signs of problems in server (apache) logs, and I did change the UIDs and GIDs in wrapper code. Also, the scripts in cgi/ have their suid bit set, although I guess that's not necessary, at least not in Linux where suid scripts do not suid at all. Just FYI. -- Janne Sinkkonen From w.t.hewitt@mcc.ac.uk Sat Mar 28 00:42:48 1998 From: w.t.hewitt@mcc.ac.uk (W T Hewitt) Date: Sat, 28 Mar 1998 00:42:48 +0000 Subject: [Mailman-developers] Next Release Message-ID: <351C4788.C9605F1@mcc.ac.uk> On Tuesday, March 24, 1998 4:46 PM, Ken Manheimer [SMTP:klm@cnri.reston.va.us] wrote: > On Tue, 24 Mar 1998, W T Hewitt wrote: > > > I got the latest versions of mailman from ftp.python.org: > > > > klm.p1 > > mailman-1.0b1.tar.gz > > > > unpacked. When I tried to apply the patches I gave a significant number > > of rejects!! > > The patches should apply with no problems if you run the patch from the > same directory where you untarred the mailman package - ie, in the > directory where the single 'mailman' dir was created. 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 s in it! 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: 1) in mailman/src/*.c put UID and GID in a .h file so I Only need to edit one file 2) Make /home/mailman a configuration variable 3) Make the logging files /tmp* world writeable (when debugging I had problems running as nobody and mailman) and make the names consistent 4) Use HTMLgen for creating HTML 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. 6) Add archive more frequently (e.g., daily, hourly, now) to mm_archive volume_frequency I have a fix for this 7) crontab on SGI complains about blank lines in crontab.in 8) Put all the files associated with a list in one subdirectory, that is independent of mailman code. Best wishes Terry W T Hewitt Manchester Visualization Centre Telephone: +44 161 275 6095 Manchester Computing Fax: +44 161 275 6800 University of Manchester Email: w.t.hewtt@mcc.ac.uk Manchester M13 9PL URL: http://info.mcc.ac.uk/MVC United Kingdom (Formerly Computer Graphics Unit) From klm@python.org Sat Mar 28 06:00:13 1998 From: klm@python.org (Ken Manheimer) Date: Sat, 28 Mar 1998 01:00:13 -0500 (EST) Subject: [Mailman-developers] Next Release In-Reply-To: <351C4788.C9605F1@mcc.ac.uk> Message-ID: 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 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 From friedrich@pythonpros.com Sat Mar 28 14:53:00 1998 From: friedrich@pythonpros.com (Robin Friedrich) Date: Sat, 28 Mar 1998 08:53:00 -0600 Subject: [Mailman-developers] Next Release References: Message-ID: <351D0ECA.7F84DB6D@pythonpros.com> Ken Manheimer wrote: > > On Sat, 28 Mar 1998, W T Hewitt wrote: > > > 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... > I agree. There is room for improvement in how HTML is generated in MM, and I've added things to the next version of HTMLgen in anticipation of it's use in MM. (i.e. A TemplateDocument class and a cool anti spider feature to the MailTo object.) But I worry about importing a module the size of HTMLgen for every cgi call. That would just slow MM down that much further until MM is upgraded to use a persistant process (v2.0?). idunno, it might add a second. I'll be happy to rework the HTML side of MM at that time. PS. The new Mailto class will now generate random encodings of the address charcters. This works in the browsers fine, but screw up the email spiders. I think this would solve the listinfo page mail privacy issue (at least for now). For example my address might come out like: Robin.Friedrich@pdq.net