Folks,
I'm pleased to announce the release of Mailman 2.0 beta 6. In this release most of the bugs and patches submitted to SourceForge have been resolved. See below for a list of changes since 2.0 beta 5. I've tested this release with Python 1.5.2, 1.6, and 2.0beta1+CVS.
This will be the last beta before 2.0 final. I think Mailman 2.0 is now stable enough to be unleashed on the unsuspecting public :). Besides, it's way overdue and there are lots of important new features that are backed up waiting for this to get out.
I plan to release 2.0 final about a week after Python 2.0 final is released. That currently puts Mailman 2.0 final out on lucky Friday October 13th. If the Python release is pushed back, Mailman may be pushed back too.
Much thanks to everyone who has helped Mailman to where it is, either through bug reports, patch submissions, important feedback, and extensive testing. I'd like to single out Jeremy Hylton on this release for coming to the rescue at the last minute and working on Pipermail to fix bugs, add support for non-ASCII charsets, and improve its performance.
[Side note: I was in New York City last night doing a gig at the Lion's Den with my band, and I met the guitarist's Linuxhead network administrator friend. We were talking geek shop after the show and I mentioned I worked on "a mailing list manager". He said, "Oh, like Mailman?" :) ]
As usual, you can get the tarball from SourceForge
http://download.sourceforge.net/mailman/mailman-2.0beta6.tgzor list.org
http://www.list.org/mailman.tar.gzor (soon) ftp.gnu.org
ftp://ftp.gnu.org/gnu/mailman/mailman-2.0beta6.tgzEnjoy, -Barry
2.0 beta 6 (22-Sep-2000)
- Building
o Tested with Python 1.5.2, Python 1.6, and Python 2.0 beta 1.
Conducted on RH Linux 6.1 only, but should work
cross-platform.
o Configure now accepts --with-username, --with-groupname,
--with-var-prefix flags. See `configure --help' or the
INSTALL file for details.
o Setting the CFLAGS environment variable before invoking
configure now works.
o The icons are now copied into $prefix/icons at install time.
Patch by David Champion.
- Standards
o Compliance with RFC 2369 (List-*: headers). Patch by
Darrell Fuhriman. List-ID: header is kept for historical
reasons.
o Fixes by Jeremy Hylton to Pipermail in support of non-ASCII
charsets, based on the Content-Type: and encoded-words in
the original message. Mail headers are now decoded as per
RFC 2047.
o Many more bounce formats are detected: Microsoft's SMTPSVC,
Compuserve, GroupWise, SMTP32, and the more generic
SimpleMatch (which catches lots of similar but slightly
different formats).
- Defaults
o Email addresses can now be obscured in Pipermail archives by
setting mm_cfg.ARCHIVER_OBSCURES_EMAILADDRS to 1 (obscuring
is turned off by default). Patch provided by Chris Snell.
o The default NNTP host can now be set by editing
mm_cfg.DEFAULT_NNTP_HOST. Patch by David Champion.
o The default archiving mode (public/private) can now be set
by editing mm_cfg.DEFAULT_ARCHIVE. Patch by Ted Cabeen.
- Web UI
o The variable details pages in the administrators interface
is now `live', i.e. there's a submit button on the details
page.
o A link to the administrative interface is placed in the
footer of the general user pages (authentication still
required, of course!)
o The user options change results page has a link back to the
user's main page.
o In the admindb page (for dealing with held postings), the
default forward address is now listname-owner instead of
listname-admin. This avoids bounce detection on the
forwarded message.
- Miscellaneous
o Fixed config.db corruption problem when disk-full errors are
encountered.
o Command line scripts accept list names case-insensitively.
o bin/remove_members takes a -a flag to remove all members of
a list in one fell swoop.
o List admin passwords must be non-empty.
o Mailman generated passwords are slightly more mnemonic, and
shouldn't have confusing character selections (i.e. `i'
only, but no `1' or `l').
o Crossposting to two gated mailing lists should be fixed.
o Many other bug fixes and minor web UI improvements.
Hi Mailman developers.
I have installed mailman of various versions on a couple different servers, and have had to upgrade the mailman installation to a later version about three times (I think they were 1.0, 1.1, and most recently I tried to install 2.0b6 and failed.)
My observation is this: when I extract the tarfile and get ready to do a "make install," shouldn't it stop me (or at least warn me) if I try to do this install as "root"? My previous experience is that if I do a "make install" as root, instead of as mailman, it seems to screw up all the permissions, and I can never get it all set right again... this has happened twice (at 1.0 and 1.1) and now it seems to be happening again with 2.0b6. It turns out it's usually easier to restore from backup than to run bin/check_perms and try to fix all the broken permissions. (Earlier versions didn't catch everything like lock files and archives, so there would still be errors after bin/check_perms was done. I haven't had a chance to test this in 2.0b6...
My suggestion: how about a makefile entry that checks to see if you're root, and bails, saying something like "You must run make install as mailman, not as root" (according to what user they chose during configure). (Of course bin/check_perms might be smart enough to handle this now.. I don't know because bin/check_perms kept dying and dumping core and I finally had to restore to mailman 1.1 to get it working again.
Thanks for a great product. gregc
Greg Connor <gconnor@nekodojo.org> PGP: 6649 347A 025D 0AFD 3EBC F0E3 D884 D9AE B9B6 173B
At 11:10 PM -0700 9/24/00, Greg Connor wrote:
My previous experience is that if I do a "make install" as root, instead of as mailman, it seems to screw up all the permissions, and I can never get it all set right again...
What I do, and I admit I probably shouldn't,is do my work as root. Mailman work fine if you do:
in source dir:
- make install
in ~mailman:
- chown -R mailman:mailman .
- bin/check_perms -f (usually twice, or until it stops complaining)
Should it warn me not to do this? probably. Or perhaps check_perm should be run at the end of the make-install, and check_perm can be upgraded to do the chawn/chgrp/chmod as necessary... the latter causes the system to handle the situation, rather than simply saying "don't do that".
On the other hand, it's probably a good idea to discourage people from doing much work as root. I've been doing unix without a net for 20 years now, and I'm comfortable with it (and careful!) -- but most folks shouldn't do it that way. In fact, I shouldn't either...
-- Chuq Von Rospach - Plaidworks Consulting (mailto:chuqui@plaidworks.com) Apple Mail List Gnome (mailto:chuq@apple.com)
And they sit at the bar and put bread in my jar and say 'Man, what are you doing here?'"
"CVR" == Chuq Von Rospach <chuqui@plaidworks.com> writes:
CVR> 2) chown -R mailman:mailman .
CVR> 3) bin/check_perms -f (usually
CVR> twice, or until it stops complaining)check_perms will do the chgrp part of this. It does't care who the user-owner is, just the group-owner.
-Barry
participants (3)
-
bwarsaw＠beopen.com -
Chuq Von Rospach -
Greg Connor