From mtearle@tearle.com Sun Sep 2 10:19:42 2001 From: mtearle@tearle.com (Mark Tearle) Date: Sun, 2 Sep 2001 17:19:42 +0800 (WST) Subject: [Mailman-Developers] [PATCH] Duplicate mail avoiding in Mailman In-Reply-To: <87lmk42tlq.fsf@nausicaa.interq.or.jp> Message-ID: On Tue, 28 Aug 2001, Ben Gertzfield wrote: > Subject: [Mailman-Developers] [PATCH] Duplicate mail avoiding in Mailman > > Finally! Here's the patch to avoid sending out list duplicates to > users who don't want it. This is a solution to the never-ending > feuding on various Debian mailing lists about whether or not people > should Cc: folks already on the list; hopefully, this > user-configurable behavior will make everyone's lives easier. > I've just upload to sourceforge Patch tracker some code against CVS which solves a related or similar problem. https://sourceforge.net/tracker/index.php?func=detail&aid=457706&group_id=103&atid=300103 Provides functionality/behaviour similar to how sendmail treats its aliases file. eg alias1: alias2, alias3, alias4 alias2: a, b alias3: b, c alias4: c, d would only deliver one message to the union of alias2, alias3 and alias4 which is a, b, c, d We use it at the University Computer Club at UWA for a couple of our lists. For example, we have a technical discussion list which all members can join but our systems administrators are automatically included. This is an example of the MemberAdaptor API in 2.1. I haven't documented it at all so it's really only for those comfortable with Mailman's internals/python. Yours Mark -- Mark Tearle - mark@tearle.com "Happiness, it seems to me, consists of two things: first, in being where you belong, and second - and best - in comfortably going through everyday life, that is, having had a good nights sleep and not being hurt by new shoes" - Fontane From che@debian.org Sun Sep 2 13:41:40 2001 From: che@debian.org (Ben Gertzfield) Date: Sun, 02 Sep 2001 21:41:40 +0900 Subject: [Mailman-Developers] [PATCH] Duplicate mail avoiding in Mailman In-Reply-To: (Mark Tearle's message of "Sun, 2 Sep 2001 17:19:42 +0800 (WST)") References: Message-ID: <87r8tp933v.fsf@nausicaa.interq.or.jp> >>>>> "Mark" == Mark Tearle writes: Mark> Provides functionality/behaviour similar to how sendmail Mark> treats its aliases file. Very cool! This is actually the reason I wrote the patch in the first place -- we're replacing an 800K sendmail aliases file (no joke!) with mailman, to make user administration actually possible. Thanks! Ben -- Brought to you by the letters N and E and the number 19. "A calpac is a large cap." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From mtearle@tearle.com Sun Sep 2 15:50:14 2001 From: mtearle@tearle.com (Mark Tearle) Date: Sun, 2 Sep 2001 22:50:14 +0800 (WST) Subject: [Mailman-Developers] [PATCH] Duplicate mail avoiding in Mailman In-Reply-To: <87r8tp933v.fsf@nausicaa.interq.or.jp> Message-ID: On Sun, 2 Sep 2001, Ben Gertzfield wrote: > >>>>> "Mark" == Mark Tearle writes: > > Mark> Provides functionality/behaviour similar to how sendmail > Mark> treats its aliases file. > > Very cool! This is actually the reason I wrote the patch in the first > place -- we're replacing an 800K sendmail aliases file (no joke!) with > mailman, to make user administration actually possible. > > Thanks! > > Ben > Just drop UnionMemberAdaptor in MAILMANDIR/Mailman, extend.py in MAILMANDIR/lists/LISTNAME and edit appropriately. However, it does reveal a couple of omissions in the MemberAdaptor api - no easy way to indicate that a list is read-only, or a particular member is not editable. Also a clean way of getting parameters exposed to the web interface would be great. Yours Mark -- Mark Tearle - mark@tearle.com "Happiness, it seems to me, consists of two things: first, in being where you belong, and second - and best - in comfortably going through everyday life, that is, having had a good nights sleep and not being hurt by new shoes" - Fontane From mikhail.sobolev@transas.com Mon Sep 3 16:58:34 2001 From: mikhail.sobolev@transas.com (Mikhail Sobolev) Date: Mon, 3 Sep 2001 16:58:34 +0100 Subject: [Mailman-Developers] A small patch. Manual.py Message-ID: <20010903165834.A2605@transas.co.uk> --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Today I tried to install the CVS version on my computer. Here is the patch that helped me. Regards, -- Misha --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="mm.patch" Index: Manual.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/MTA/Manual.py,v retrieving revision 2.1 diff -u -b -r2.1 Manual.py --- Manual.py 2001/08/04 02:04:47 2.1 +++ Manual.py 2001/09/03 15:41:57 @@ -24,6 +24,7 @@ from Mailman.Queue.sbcache import get_switchboard from Mailman.i18n import _ from Mailman.MTA.Utils import makealiases +from Mailman.Utils import get_site_email @@ -60,7 +61,7 @@ if not cgi: print >> outfp return - siteowner = Utils.get_site_email() + siteowner = get_site_email() msg = Message.UserNotification( siteowner, siteowner, _('Mailing list creation request for list %(listname)s'), @@ -103,7 +104,7 @@ if not cgi: print >> outfp return - siteowner = Utils.get_site_email() + siteowner = get_site_email() msg = Message.UserNotification( siteowner, siteowner, _('Mailing list removal request for list %(listname)s'), --17pEHd4RhPHOinZp-- From tom@spamcon.org Mon Sep 3 22:29:28 2001 From: tom@spamcon.org (Tom Geller) Date: Mon, 03 Sep 2001 14:29:28 -0700 Subject: [Mailman-Developers] Proposed new subscribeack.txt Message-ID: Hey, gang. I'm not a regular on this list; please let me know if I should follow some other procedure for proposing a new text. Anyhoo... my users on spamcon.org lists seemed confused by the subscribeack.txt text, so I rewrote it. I think the one shown below is clearer in the following ways: 1) Warns the reader that the message is important up front (most just toss it otherwise) 2) Gives password earlier (in the first screen) 3) Gives unsubscribe instructions early 4) More straightforward overall. One thing that would improve it is to also give the %(address)s string (or whichever one is appropriate) on lines like: TO UNSUBSCRIBE: unsubscribe %(password)s I couldn't figure out how to do that. (I couldn't find a list of %()s variables. If one exists, I'd appreciate direction.) Submitted for possible inclusion in future revs. Best, --Tom Geller Executive Director, SpamCon Foundation ---begin proposed subscribeack.txt--- Welcome to the %(real_name)s@%(host_name)s mailing list! *** SAVE THIS MESSAGE *** TO UNSUBSCRIBE OR CHANGE YOUR OPTIONS VIA THE WEB: %(optionsurl)s %(umbrella)s Your password is %(password)s. TO UNSUBSCRIBE OR CHANGE YOUR OPTIONS VIA EMAIL: Send a message to %(real_name)s-request@%(host_name)s from your subscription address, with the appropriate text in the subject or body of the message: TO UNSUBSCRIBE: unsubscribe %(password)s TO RECEIVE A DAILY DIGEST: set digest on %(password)s TO GET A FULL LIST OF COMMANDS: help --- %(welcome)s If this is a discussion list, you can post to it by sending your email to: %(emailaddr)s General information about the mailing list is at: %(listinfo_url)s If you forget your password, don't worry, you will receive a monthly reminder telling you what all your %(host_name)s mailing list passwords are, and how to unsubscribe or change your options. There is also a button on your options page that will email your current password to you. Enjoy your time on the list! ---end--- -- Tom Geller * tom@spamcon.org * +1-415-552-2557 Executive Director, SpamCon Foundation A California non-profit organization Protecting email as a medium of communications and commerce Donations: From mikhail.sobolev@transas.com Tue Sep 4 10:48:01 2001 From: mikhail.sobolev@transas.com (Mikhail Sobolev) Date: Tue, 4 Sep 2001 10:48:01 +0100 Subject: [Mailman-Developers] A bug? Message-ID: <20010904104801.A12851@transas.co.uk> While trying to subscribe to a newly created list running under CVS version of Mailman, I found that the subject line for a confirmation request looks strange: confirm %(cookie)s I attach two (since I do not know what way is kocher :) patches that seem to fix this problem. Regards, -- Misha From mikhail.sobolev@transas.com Tue Sep 4 10:57:25 2001 From: mikhail.sobolev@transas.com (Mikhail Sobolev) Date: Tue, 4 Sep 2001 10:57:25 +0100 Subject: [Mailman-Developers] A bug? In-Reply-To: <20010904104801.A12851@transas.co.uk> References: <20010904104801.A12851@transas.co.uk> Message-ID: <20010904105725.A12898@transas.co.uk> --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Oops. Now they are really attached. -- Misha On Tue, Sep 04, 2001 at 10:48:01AM +0100, Mikhail Sobolev wrote: > While trying to subscribe to a newly created list running under CVS > version of Mailman, I found that the subject line for a confirmation > request looks strange: > > confirm %(cookie)s > > I attach two (since I do not know what way is kocher :) patches that > seem to fix this problem. > > Regards, > > -- > Misha > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ml.1.patch" Index: MailList.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/MailList.py,v retrieving revision 2.37 diff -u -b -r2.37 MailList.py --- MailList.py 2001/08/30 04:15:30 2.37 +++ MailList.py 2001/09/04 09:41:43 @@ -627,7 +627,7 @@ }, lang=lang, mlist=self) msg = Message.UserNotification( recipient, self.GetRequestEmail(), - 'confirm %(cookie)s', + 'confirm %(cookie)s' % { 'cookie' : cookie }, text) msg['Reply-To'] = self.GetRequestEmail() msg.send(self) @@ -804,7 +804,7 @@ }, lang=self.getMemberLanguage(oldaddr), mlist=self) msg = Message.UserNotification( newaddr, self.GetRequestEmail(), - 'confirm %(cookie)s', + 'confirm %(cookie)s' % { 'cookie' : cookie }, text) msg['Reply-To'] = self.GetRequestEmail() msg.send(self) @@ -897,7 +897,7 @@ }, lang=lang, mlist=self) msg = Message.UserNotification( addr, self.GetRequestEmail(), - 'confirm %(cookie)s', + 'confirm %(cookie)s' % { 'cookie' : cookie }, text) msg['Reply-To'] = self.GetRequestEmail() msg.send(self) --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ml.2.patch" Index: MailList.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/MailList.py,v retrieving revision 2.37 diff -u -b -r2.37 MailList.py --- MailList.py 2001/08/30 04:15:30 2.37 +++ MailList.py 2001/09/04 09:42:27 @@ -627,7 +627,7 @@ }, lang=lang, mlist=self) msg = Message.UserNotification( recipient, self.GetRequestEmail(), - 'confirm %(cookie)s', + 'confirm %s' % cookie, text) msg['Reply-To'] = self.GetRequestEmail() msg.send(self) @@ -804,7 +804,7 @@ }, lang=self.getMemberLanguage(oldaddr), mlist=self) msg = Message.UserNotification( newaddr, self.GetRequestEmail(), - 'confirm %(cookie)s', + 'confirm %s' % cookie, text) msg['Reply-To'] = self.GetRequestEmail() msg.send(self) @@ -897,7 +897,7 @@ }, lang=lang, mlist=self) msg = Message.UserNotification( addr, self.GetRequestEmail(), - 'confirm %(cookie)s', + 'confirm %s' % cookie, text) msg['Reply-To'] = self.GetRequestEmail() msg.send(self) --EeQfGwPcQSOJBaQU-- From thomas@xs4all.net Tue Sep 4 16:10:05 2001 From: thomas@xs4all.net (Thomas Wouters) Date: Tue, 4 Sep 2001 17:10:05 +0200 Subject: [Mailman-Developers] A small patch. Manual.py In-Reply-To: <20010903165834.A2605@transas.co.uk> References: <20010903165834.A2605@transas.co.uk> Message-ID: <20010904171004.A2068@xs4all.nl> On Mon, Sep 03, 2001 at 04:58:34PM +0100, Mikhail Sobolev wrote: > Today I tried to install the CVS version on my computer. Here is the > patch that helped me. > +from Mailman.Utils import get_site_email > - siteowner = Utils.get_site_email() > + siteowner = get_site_email() Thanx! Fixed, though in a slightly different way. (Just importing Mailman.Utils is less work :-) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! From barry@zope.com Wed Sep 5 00:12:38 2001 From: barry@zope.com (Barry A. Warsaw) Date: Tue, 4 Sep 2001 19:12:38 -0400 Subject: [Mailman-Developers] A bug? References: <20010904104801.A12851@transas.co.uk> Message-ID: <15253.24550.649714.322365@anthem.wooz.org> >>>>> "MS" == Mikhail Sobolev writes: MS> While trying to subscribe to a newly created list running MS> under CVS version of Mailman, I found that the subject line MS> for a confirmation request looks strange: MS> confirm %(cookie)s MS> I attach two (since I do not know what way is kocher :) MS> patches that seem to fix this problem. Yep, that is a consequence of un-i18n-ing that string. Thanks for the patches; I'll probably use the second one since it's a bit simpler. -Barry From che@debian.org Wed Sep 5 04:21:38 2001 From: che@debian.org (Ben Gertzfield) Date: Wed, 05 Sep 2001 12:21:38 +0900 Subject: [Mailman-Developers] [PATCH v2] Smaller, cleaner --with-python patch Message-ID: <87zo8ajpa5.fsf@nausicaa.interq.or.jp> Howdy again, Mailman folks. The last patch I provided to make it possible to build Python using --with-python=/usr/bin/python2 (or a python named anything) was pretty big and unwieldy, I agree. This is a much smaller, better solution. With the old patch, we renamed (for example) bin/newlist to bin/newlist.in, and changed #! /usr/bin/env python to #! /usr/bin/env @PYTHON@ . Then, we added bin/newlist to the AC_OUTPUT macro in configure.in, which made a ./configure do the proper expansion. But it made the patch huge, and would not only ruin the CVS logs for those files, but would force programmers to guess whether they should edit bin/foo.in or bin/foo. This new patch makes a temporary build/ top-level subdirectory when ./configure is run, and uses a bit of autoconf magic to macro-expand bin/newlist to build/bin/newlist. This works beautifully; the Makefile.in files in various directories just had to be modified to use ../build/bin (etc.) as a prefix to the filename to be installed on a make install. I also added a little macro in the configure.in to convert a long string like: bin/update \ bin/newlist \ bin/check_perms to: build/bin/update:bin/update \ build/bin/newlist:bin/newlist \ build/bin/check_perms:bin/check_perms This way, we just keep a variable called MM_SCRIPTS in the first format in configure.in, which lists everything that's considered a script and should be macro-expanded. I hope this patch will be more acceptable. It's very small (700 lines) but fixes the problem. It's really critical that this be accepted before Mailman 2.1 comes out, or it'll be unusable on systems that have python 2.0 installed as /usr/bin/python2 or /usr/local/bin/python2. Ben Patch follows. diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/Makefile.in mailman/Makefile.in --- mailman.cvs.orig/Makefile.in Thu Jul 19 06:49:19 2001 +++ mailman/Makefile.in Wed Sep 5 11:38:42 2001 @@ -137,3 +137,5 @@ (cd $$d; $(MAKE) distclean); \ done -rm -f config.cache config.log config.status Makefile + -rm -rf build + diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/Makefile.in mailman/bin/Makefile.in --- mailman.cvs.orig/bin/Makefile.in Tue Aug 21 05:08:41 2001 +++ mailman/bin/Makefile.in Wed Sep 5 11:14:49 2001 @@ -47,6 +47,8 @@ version config_list list_lists dumpdb fix_url.py \ list_admins genaliases change_pw mailmanctl qrunner +BUILDDIR= ../build/bin + # Modes for directories and executables created by the install # process. Default to group-writable directories but # user-only-writable for executables. @@ -63,7 +65,7 @@ install: for f in $(SCRIPTS); \ do \ - $(INSTALL) -m $(EXEMODE) $$f $(SCRIPTSDIR); \ + $(INSTALL) -m $(EXEMODE) $(BUILDDIR)/$$f $(SCRIPTSDIR); \ done finish: diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/add_members mailman/bin/add_members --- mailman.cvs.orig/bin/add_members Sat Aug 4 11:05:41 2001 +++ mailman/bin/add_members Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/arch mailman/bin/arch --- mailman.cvs.orig/bin/arch Thu Jul 26 14:30:28 2001 +++ mailman/bin/arch Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/change_pw mailman/bin/change_pw --- mailman.cvs.orig/bin/change_pw Sat Aug 4 11:05:41 2001 +++ mailman/bin/change_pw Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/check_db mailman/bin/check_db --- mailman.cvs.orig/bin/check_db Fri Dec 8 04:33:52 2000 +++ mailman/bin/check_db Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/check_perms mailman/bin/check_perms --- mailman.cvs.orig/bin/check_perms Mon Jul 2 22:55:23 2001 +++ mailman/bin/check_perms Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/clone_member mailman/bin/clone_member --- mailman.cvs.orig/bin/clone_member Mon Jul 30 06:26:49 2001 +++ mailman/bin/clone_member Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/config_list mailman/bin/config_list --- mailman.cvs.orig/bin/config_list Sat May 26 00:18:34 2001 +++ mailman/bin/config_list Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/digest_arch mailman/bin/digest_arch --- mailman.cvs.orig/bin/digest_arch Mon Mar 26 09:03:46 2001 +++ mailman/bin/digest_arch Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/dumpdb mailman/bin/dumpdb --- mailman.cvs.orig/bin/dumpdb Thu Jul 12 05:11:24 2001 +++ mailman/bin/dumpdb Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/find_member mailman/bin/find_member --- mailman.cvs.orig/bin/find_member Thu Jul 19 12:28:20 2001 +++ mailman/bin/find_member Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/genaliases mailman/bin/genaliases --- mailman.cvs.orig/bin/genaliases Wed Sep 5 12:04:45 2001 +++ mailman/bin/genaliases Wed Sep 5 11:36:49 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/list_admins mailman/bin/list_admins --- mailman.cvs.orig/bin/list_admins Thu Mar 22 12:42:00 2001 +++ mailman/bin/list_admins Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/list_lists mailman/bin/list_lists --- mailman.cvs.orig/bin/list_lists Fri Dec 8 04:33:52 2000 +++ mailman/bin/list_lists Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/list_members mailman/bin/list_members --- mailman.cvs.orig/bin/list_members Thu Jul 19 12:28:20 2001 +++ mailman/bin/list_members Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/mailmanctl mailman/bin/mailmanctl --- mailman.cvs.orig/bin/mailmanctl Thu Aug 16 04:38:00 2001 +++ mailman/bin/mailmanctl Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # Copyright (C) 2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/mmsitepass mailman/bin/mmsitepass --- mailman.cvs.orig/bin/mmsitepass Fri Jun 1 01:15:05 2001 +++ mailman/bin/mmsitepass Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/newlist mailman/bin/newlist --- mailman.cvs.orig/bin/newlist Tue Aug 21 00:15:56 2001 +++ mailman/bin/newlist Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/pygettext.py mailman/bin/pygettext.py --- mailman.cvs.orig/bin/pygettext.py Sat Jul 28 02:22:55 2001 +++ mailman/bin/pygettext.py Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # Originally written by Barry Warsaw # # Minimally patched to make it even more xgettext compatible diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/qrunner mailman/bin/qrunner --- mailman.cvs.orig/bin/qrunner Fri Jul 6 06:58:21 2001 +++ mailman/bin/qrunner Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # Copyright (C) 2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/remove_members mailman/bin/remove_members --- mailman.cvs.orig/bin/remove_members Fri Jul 20 05:01:48 2001 +++ mailman/bin/remove_members Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/rmlist mailman/bin/rmlist --- mailman.cvs.orig/bin/rmlist Thu May 10 00:04:15 2001 +++ mailman/bin/rmlist Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/sync_members mailman/bin/sync_members --- mailman.cvs.orig/bin/sync_members Thu Jul 19 12:28:20 2001 +++ mailman/bin/sync_members Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/update mailman/bin/update --- mailman.cvs.orig/bin/update Thu Aug 16 06:30:26 2001 +++ mailman/bin/update Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/version mailman/bin/version --- mailman.cvs.orig/bin/version Fri Dec 8 04:33:52 2000 +++ mailman/bin/version Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/bin/withlist mailman/bin/withlist --- mailman.cvs.orig/bin/withlist Wed Aug 1 15:30:33 2001 +++ mailman/bin/withlist Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/configure mailman/configure --- mailman.cvs.orig/configure Sat Aug 18 08:20:12 2001 +++ mailman/configure Wed Sep 5 11:30:56 2001 @@ -1,6 +1,6 @@ #! /bin/sh -# From configure.in Revision: 2.11 +# From configure.in Revision: 2.12 # Guess values for system-dependent variables and create Makefiles. # Generated automatically using autoconf version 2.13 @@ -1980,6 +1980,59 @@ done + + + + + +SCRIPTS="build/contrib/rotatelogs.py:contrib/rotatelogs.py \ +build/contrib/qmail-to-mailman.py:contrib/qmail-to-mailman.py \ +build/contrib/securelinux_fix.py:contrib/securelinux_fix.py \ +build/filters/bowa-strip:filters/bowa-strip \ +build/cron/senddigests:cron/senddigests \ +build/cron/bumpdigests:cron/bumpdigests \ +build/cron/nightly_gzip:cron/nightly_gzip \ +build/cron/mailpasswds:cron/mailpasswds \ +build/cron/gate_news:cron/gate_news \ +build/cron/checkdbs:cron/checkdbs \ +build/bin/update:bin/update \ +build/bin/newlist:bin/newlist \ +build/bin/check_perms:bin/check_perms \ +build/bin/find_member:bin/find_member \ +build/bin/withlist:bin/withlist \ +build/bin/mailmanctl:bin/mailmanctl \ +build/bin/change_pw:bin/change_pw \ +build/bin/list_admins:bin/list_admins \ +build/bin/check_db:bin/check_db \ +build/bin/list_lists:bin/list_lists \ +build/bin/pygettext.py:bin/pygettext.py \ +build/bin/qrunner:bin/qrunner \ +build/bin/clone_member:bin/clone_member \ +build/bin/genaliases:bin/genaliases \ +build/bin/digest_arch:bin/digest_arch \ +build/bin/arch:bin/arch \ +build/bin/rmlist:bin/rmlist \ +build/bin/mmsitepass:bin/mmsitepass \ +build/bin/version:bin/version \ +build/bin/remove_members:bin/remove_members \ +build/bin/config_list:bin/config_list \ +build/bin/list_members:bin/list_members \ +build/bin/sync_members:bin/sync_members \ +build/bin/add_members:bin/add_members \ +build/bin/dumpdb:bin/dumpdb \ +build/scripts/mailowner:scripts/mailowner \ +build/scripts/mailcmd:scripts/mailcmd \ +build/scripts/post:scripts/post \ +build/scripts/leave:scripts/leave \ +build/scripts/join:scripts/join \ +build/scripts/auto:scripts/auto " + + + +# These directories are temporary directories to store macro-expanded +# scripts. They're removed on a make distclean, so we make them here. +mkdir -p build/bin build/scripts build/contrib build/filters build/cron + trap '' 1 2 15 cat > confcache <<\EOF # This file is a shell script that caches the results of configure @@ -2101,7 +2154,8 @@ Mailman/Queue/Makefile Mailman/MTA/Makefile Mailman/Gui/Makefile templates/Makefile cron/Makefile filters/Makefile scripts/Makefile messages/Makefile - cron/crontab.in misc/mailman Makefile" | sed "s/:[^ ]*//g"` conftest*; exit 1' 1 2 15 + cron/crontab.in misc/mailman Makefile + $SCRIPTS" | sed "s/:[^ ]*//g"` conftest*; exit 1' 1 2 15 EOF cat >> $CONFIG_STATUS <> $CONFIG_STATUS <<\EOF for ac_file in .. $CONFIG_FILES; do if test "x$ac_file" != x..; then @@ -2271,3 +2327,6 @@ rm -fr confdefs* $ac_clean_files test "$no_create" = yes || ${CONFIG_SHELL-/bin/sh} $CONFIG_STATUS || exit 1 + +# Make sure all the build scripts are executable. +chmod -R +x build diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/configure.in mailman/configure.in --- mailman.cvs.orig/configure.in Sat Aug 18 08:20:12 2001 +++ mailman/configure.in Wed Sep 5 11:30:51 2001 @@ -470,6 +470,70 @@ # Checks for library functions. AC_CHECK_FUNCS(vsnprintf) +dnl Expand PYTHON path in the scripts, output into build/scriptname + +AC_DEFUN(MM_SCRIPTS, [dnl +contrib/rotatelogs.py \ +contrib/qmail-to-mailman.py \ +contrib/securelinux_fix.py \ +filters/bowa-strip \ +cron/senddigests \ +cron/bumpdigests \ +cron/nightly_gzip \ +cron/mailpasswds \ +cron/gate_news \ +cron/checkdbs \ +bin/update \ +bin/newlist \ +bin/check_perms \ +bin/find_member \ +bin/withlist \ +bin/mailmanctl \ +bin/change_pw \ +bin/list_admins \ +bin/check_db \ +bin/list_lists \ +bin/pygettext.py \ +bin/qrunner \ +bin/clone_member \ +bin/genaliases \ +bin/digest_arch \ +bin/arch \ +bin/rmlist \ +bin/mmsitepass \ +bin/version \ +bin/remove_members \ +bin/config_list \ +bin/list_members \ +bin/sync_members \ +bin/add_members \ +bin/dumpdb \ +scripts/mailowner \ +scripts/mailcmd \ +scripts/post \ +scripts/leave \ +scripts/join \ +scripts/auto ]) + +dnl Please make sure to leave a space at the end of the last entry. +dnl (This is so we don't have to use [a-z/] style character classes +dnl in the regexp below and mess with m4 quoting, which is not fun.) + +dnl This regexp munges each line in MM_SCRIPTS, replacing: +dnl path/script \ +dnl with: +dnl build/path/script:path/script \ +dnl so that we can macro-expand variables in scripts without using +dnl script.in filenames, outputting the new files in build/ . + +SCRIPTS="patsubst(MM_SCRIPTS, \(.+\) \(\\?\), build/\1:\1 \2)" + +AC_SUBST(SCRIPTS) + +# These directories are temporary directories to store macro-expanded +# scripts. They're removed on a make distclean, so we make them here. +mkdir -p build/bin build/scripts build/contrib build/filters build/cron + dnl Output everything AC_OUTPUT([misc/paths.py Mailman/Defaults.py Mailman/mm_cfg.py.dist src/Makefile misc/Makefile bin/Makefile @@ -479,4 +543,8 @@ Mailman/Queue/Makefile Mailman/MTA/Makefile Mailman/Gui/Makefile templates/Makefile cron/Makefile filters/Makefile scripts/Makefile messages/Makefile - cron/crontab.in misc/mailman Makefile]) + cron/crontab.in misc/mailman Makefile + $SCRIPTS]) + +# Make sure all the build scripts are executable. +chmod -R +x build diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/contrib/qmail-to-mailman.py mailman/contrib/qmail-to-mailman.py --- mailman.cvs.orig/contrib/qmail-to-mailman.py Fri Dec 8 01:53:21 2000 +++ mailman/contrib/qmail-to-mailman.py Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # Configuration variables - Change these for your site if necessary. MailmanHome = "/home/mailman"; # Mailman home directory. diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/contrib/rotatelogs.py mailman/contrib/rotatelogs.py --- mailman.cvs.orig/contrib/rotatelogs.py Sat Aug 4 11:06:06 2001 +++ mailman/contrib/rotatelogs.py Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#!/usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 2000 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/contrib/securelinux_fix.py mailman/contrib/securelinux_fix.py --- mailman.cvs.orig/contrib/securelinux_fix.py Mon Mar 19 01:52:48 2001 +++ mailman/contrib/securelinux_fix.py Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/cron/Makefile.in mailman/cron/Makefile.in --- mailman.cvs.orig/cron/Makefile.in Sat Aug 4 11:06:50 2001 +++ mailman/cron/Makefile.in Wed Sep 5 11:14:38 2001 @@ -44,6 +44,8 @@ nightly_gzip bumpdigests FILES= crontab.in +BUILDDIR= ../build/cron + # Modes for directories and executables created by the install # process. Default to group-writable directories but # user-only-writable for executables. @@ -62,7 +64,7 @@ done for f in $(PROGRAMS); \ do \ - $(INSTALL) -m $(EXEMODE) $$f $(CRONDIR); \ + $(INSTALL) -m $(EXEMODE) $(BUILDDIR)/$$f $(CRONDIR); \ done finish: diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/cron/bumpdigests mailman/cron/bumpdigests --- mailman.cvs.orig/cron/bumpdigests Sat Jul 28 01:35:45 2001 +++ mailman/cron/bumpdigests Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/cron/checkdbs mailman/cron/checkdbs --- mailman.cvs.orig/cron/checkdbs Sat Jul 28 01:35:45 2001 +++ mailman/cron/checkdbs Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/cron/gate_news mailman/cron/gate_news --- mailman.cvs.orig/cron/gate_news Sat Jul 28 01:35:45 2001 +++ mailman/cron/gate_news Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/cron/mailpasswds mailman/cron/mailpasswds --- mailman.cvs.orig/cron/mailpasswds Sat Aug 4 14:23:56 2001 +++ mailman/cron/mailpasswds Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/cron/nightly_gzip mailman/cron/nightly_gzip --- mailman.cvs.orig/cron/nightly_gzip Sat Jul 28 01:35:45 2001 +++ mailman/cron/nightly_gzip Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/cron/senddigests mailman/cron/senddigests --- mailman.cvs.orig/cron/senddigests Sat Jul 28 01:35:45 2001 +++ mailman/cron/senddigests Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/filters/Makefile.in mailman/filters/Makefile.in --- mailman.cvs.orig/filters/Makefile.in Fri Dec 8 01:53:22 2000 +++ mailman/filters/Makefile.in Wed Sep 5 11:15:23 2001 @@ -43,6 +43,8 @@ FILTERS= bowa-strip +BUILDDIR= ../build/filters + # Modes for directories and executables created by the install # process. Default to group-writable directories but # user-only-writable for executables. @@ -59,7 +61,7 @@ install: for f in $(FILTERS); \ do \ - $(INSTALL) -m $(FILEMODE) $$f $(FILTERSDIR); \ + $(INSTALL) -m $(FILEMODE) $(BUILDDIR)/$$f $(FILTERSDIR); \ done finish: diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/filters/bowa-strip mailman/filters/bowa-strip --- mailman.cvs.orig/filters/bowa-strip Fri Dec 8 01:53:22 2000 +++ mailman/filters/bowa-strip Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/messages/Makefile.in mailman/messages/Makefile.in --- mailman.cvs.orig/messages/Makefile.in Sat Aug 18 06:24:01 2001 +++ mailman/messages/Makefile.in Wed Sep 5 11:43:50 2001 @@ -62,7 +62,7 @@ EXEMODE= 755 FILEMODE= 644 INSTALL_PROGRAM=$(INSTALL) -m $(EXEMODE) -PROG= bin/pygettext.py +PROG= build/bin/pygettext.py .SUFFIXES: .po .mo .po.mo: @@ -117,7 +117,7 @@ docstring.files: @echo "Calculating script input files for pygettext" - (cd ..; grep -d skip -l '^#! /usr/bin/env python' `find bin cron scripts -name ".#*" -prune -o -print` >| messages/$@) + (cd ..; grep -d skip -l '^#! /usr/bin/env @PYTHON@' `find bin cron scripts -name ".#*" -prune -o -print` >| messages/$@) mailman.pot: marked.files docstring.files @echo "Running pygettext on $@; this make take a while." diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/misc/Cookie.py mailman/misc/Cookie.py --- mailman.cvs.orig/misc/Cookie.py Sun Aug 19 03:22:11 2001 +++ mailman/misc/Cookie.py Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#!/usr/bin/env python +#! /usr/bin/env @PYTHON@ """ #### diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/misc/Makefile.in mailman/misc/Makefile.in --- mailman.cvs.orig/misc/Makefile.in Wed Sep 5 12:04:47 2001 +++ mailman/misc/Makefile.in Wed Sep 5 11:16:23 2001 @@ -56,12 +56,14 @@ PATHSDIRS= bin cron scripts ICONS= *.jpg *.png +BUILDDIR= ../build/misc + # Rules all: install: - $(INSTALL) -m $(FILEMODE) Cookie.py $(PACKAGEDIR) + $(INSTALL) -m $(FILEMODE) $(BUILDDIR)/Cookie.py $(PACKAGEDIR) $(INSTALL) -m $(FILEMODE) $(ICONS) $(ICONDIR) for d in $(PATHSDIRS); \ do \ diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/scripts/Makefile.in mailman/scripts/Makefile.in --- mailman.cvs.orig/scripts/Makefile.in Sat Aug 4 11:26:54 2001 +++ mailman/scripts/Makefile.in Wed Sep 5 11:29:46 2001 @@ -42,6 +42,8 @@ SCRIPTS= mailcmd mailowner post driver join leave +BUILDDIR= ../build/scripts + # Modes for directories and executables created by the install # process. Default to group-writable directories but # user-only-writable for executables. @@ -58,7 +60,7 @@ install: for f in $(SCRIPTS); \ do \ - $(INSTALL) -m $(FILEMODE) $$f $(SCRIPTSDIR); \ + $(INSTALL) -m $(FILEMODE) $(BUILDDIR)/$$f $(SCRIPTSDIR); \ done finish: diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/scripts/auto mailman/scripts/auto --- mailman.cvs.orig/scripts/auto Thu Jun 28 08:00:47 2001 +++ mailman/scripts/auto Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/scripts/join mailman/scripts/join --- mailman.cvs.orig/scripts/join Thu Jun 28 08:01:22 2001 +++ mailman/scripts/join Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/scripts/leave mailman/scripts/leave --- mailman.cvs.orig/scripts/leave Thu Jun 28 08:01:42 2001 +++ mailman/scripts/leave Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/scripts/mailcmd mailman/scripts/mailcmd --- mailman.cvs.orig/scripts/mailcmd Thu Jun 28 08:02:03 2001 +++ mailman/scripts/mailcmd Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/scripts/mailowner mailman/scripts/mailowner --- mailman.cvs.orig/scripts/mailowner Thu Jun 28 08:02:29 2001 +++ mailman/scripts/mailowner Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x *.pot -x *.po -x *.mo -x CVS -ruN mailman.cvs.orig/scripts/post mailman/scripts/post --- mailman.cvs.orig/scripts/post Thu Jun 28 08:02:46 2001 +++ mailman/scripts/post Mon Sep 3 13:57:23 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # From barry@zope.com Wed Sep 5 05:17:42 2001 From: barry@zope.com (Barry A. Warsaw) Date: Wed, 5 Sep 2001 00:17:42 -0400 Subject: [Mailman-Developers] [PATCH v2] Smaller, cleaner --with-python patch References: <87zo8ajpa5.fsf@nausicaa.interq.or.jp> Message-ID: <15253.42854.792853.616751@anthem.wooz.org> >>>>> "BG" == Ben Gertzfield writes: BG> This new patch makes a temporary build/ top-level subdirectory BG> when ./configure is run, and uses a bit of autoconf magic to BG> macro-expand bin/newlist to build/bin/newlist. This works BG> beautifully; the Makefile.in files in various directories just BG> had to be modified to use ../build/bin (etc.) as a prefix to BG> the filename to be installed on a make install. Hi Ben, thanks this seems much more acceptable, although I'll reserve final judgement until I actually apply the patch and give it a drive . If it pans out, I'll include it in the next alpha -- hopefully this weekend -- and if not, I'll definitely give you feedback about it. Thanks, -Barry From che@debian.org Wed Sep 5 06:42:58 2001 From: che@debian.org (Ben Gertzfield) Date: Wed, 05 Sep 2001 14:42:58 +0900 Subject: [Mailman-Developers] [PATCH v2] Smaller, cleaner --with-python patch In-Reply-To: <15253.42854.792853.616751@anthem.wooz.org> (barry@zope.com's message of "Wed, 5 Sep 2001 00:17:42 -0400") References: <87zo8ajpa5.fsf@nausicaa.interq.or.jp> <15253.42854.792853.616751@anthem.wooz.org> Message-ID: <87lmjukxb1.fsf@nausicaa.interq.or.jp> >>>>> "BAW" == Barry A Warsaw writes: BAW> Hi Ben, thanks this seems much more acceptable, although I'll BAW> reserve final judgement until I actually apply the patch and BAW> give it a drive . If it pans out, I'll include it in BAW> the next alpha -- hopefully this weekend -- and if not, I'll BAW> definitely give you feedback about it. Understood -- and thanks a lot! I like working on Mailman quite a lot, and I hope I can be more help in the future. Please let me know if there are any issues with the patch. Ben -- Brought to you by the letters V and F and the number 13. "I choose YOU! Pikachu!" Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From guillermo antonio acosta jr" InternalAntennas.com


GET A FREE ANTENNA BOOSTER FOR YOUR CELL PHONE!



AS SEEN IN LAPTOP MAGAZINE!

Go to InternalAntennas.com to order your



We sell over 10,000 Version II antennas a month for
a good reason, OUR PRODUCT WORKS! we have
technical support FOR CUSTOMERS & 10 years
of wireless experience in tower construction for cellular
& PCS sites. We dont just sell you the product we
stand behind it.... We have thousands of satisfied
customers read our testimonials and you will see why
we are the main supplier of internal antennas to
local dept stores , dollar stores and wireless retail
centers ALL OVER NORTH AMERICA

Enjoy our expertise...
Brand New ! Version II eclusive to 2001 Technology
Services do not accept imitations

The Internal Booster Antenna is a passive
device designed to capture the stray radiation inside
the body of the phone and re-direct the signal to
improve the phone's performance. Now you can
use your cell phone in vaults, elevators, cars, boats,
mountains, ski resorts, tunnels, buildings and more.....
It's like having a FIVE foot antenna on your phone.

Great for Bad Areas, Boats, Mountains, Elevators, Car, Building Etc

Works on any cellular phone.

Very easy to install!!

Clears up static and make everything clear.
Enjoy the reduced static and enhanced
signal on your cellular phone!!

Retails ON TV for $19.95 to $29.95







All our mailings are sent complying to the proposed United States Federal requirements for
commercial e-mail: Section 301 Paragraph (a)(2)(C) of S. 618.
Please see the bottom of this message for further information and removal instructions.

Contact: POWER@elp.rr.com and you will be removed immediately!
TITLE YOUR EMAIL: REMOVE ME From benwa@ocentrix.com Wed Sep 5 23:49:47 2001 From: benwa@ocentrix.com (Ben Burnett) Date: Wed, 05 Sep 2001 15:49:47 -0700 Subject: [Mailman-Developers] Re: [Mailman-Users] Wrapper gid problem (Includes Patch against 2.0.6) In-Reply-To: <5.1.0.14.2.20010905161759.046740a0@pop.cs.uchicago.edu> References: <5.0.0.25.2.20010904215720.03bb60a0@pop3.vo.cnchost.com> <931658905.20010905013806@globalmargin.com> Message-ID: <5.1.0.14.0.20010905143204.00a7db90@mail.ocentrix.com> (my advanced apologies for hitting both the -users and -developers lists. I thought it would be applicable to both) I agree that this error message is pretty ambiguous. I participated in a thread about this started by Harold Paulson whom I thought had a pretty good idea of how to fix this. http://mail.python.org/pipermail/mailman-users/2001-April/010955.html Since then I've seen this question asked, answered, and ignored many times on the list. I realize that the error message says "Please read the INSTALL instructions again, paying close attention to the --with-cgi-gid configure option", however I don't really see any reason that this shouldn't be more explicit. I'm all for terseness, and I would rather see this list become more terse and the error message grow. As I mentioned in the April thread, I think that the message should read: "Mailman CGI error! Mailman was compiled to use GID 48, but the web server is running as GID 99. You must run ./configure again --with-cgi-gid=99, or reconfigure your web server." Instead of just whining about it like I did last time I figured I'd put together the following patch against 2.0.6 to common.c to make it do just that. I've tested this on my machine and it works just fine. ----------begin patch------------ *** ./src/common.c.bak Wed Sep 5 14:51:51 2001 --- ./src/common.c Wed Sep 5 14:57:43 2001 *************** *** 124,129 **** if (parentgid != mygid) { fatal(ident, GID_MISMATCH, ! "Failure to exec script. WANTED gid %ld, GOT gid %ld. " ! "(Reconfigure to take %ld?)", parentgid, mygid, mygid); } --- 124,131 ---- if (parentgid != mygid) { fatal(ident, GID_MISMATCH, ! "Mailman CGI error! Mailman was compiled to use\n " ! "GID %ld, but the web server is running as GID %ld.\n " ! "You must run ./configure again with the option\n " ! "--with-cgi-gid=%ld, or reconfigure your web server.", parentgid, mygid, mygid); } ----------end patch------------ I hope this is useful, - Ben P.S. Notice that the line separator I'm using is just the UNIX separator. I imagine if someone wants to port this to Windows this will need to be fixed, but I don't know enough about python to find a platform portable line separator. Is there such a thing? ( in Perl it's $/ ) From che@debian.org Thu Sep 6 04:20:03 2001 From: che@debian.org (Ben Gertzfield) Date: Thu, 06 Sep 2001 12:20:03 +0900 Subject: [Mailman-Developers] [PATCH] A small bug fixed in --with-python patch Message-ID: <87wv3dvwd8.fsf@nausicaa.interq.or.jp> There were a few scripts nestled among all the ones I converted to use #! /usr/bin/env @PYTHON@ that were not being installed, because they did not have a #! line at all. Here's a version of the patch that fixes this error by removing these scripts from the SCRIPTS variable in the various Makefile.in files and moving them to a NONSCRIPTS variable, which tells a make install to look for scripts/foo instead of build/scripts/foo . (Since these files are not executable and are not meant to be executable, they're not really scripts, but I'm not sure what they are. :) This patch is against current Mailman CVS. Ben diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/Makefile.in mailman/Makefile.in --- mailman.cvs.orig/Makefile.in Thu Sep 6 11:51:15 2001 +++ mailman/Makefile.in Thu Sep 6 11:57:24 2001 @@ -140,6 +140,7 @@ (cd $$d; $(MAKE) distclean); \ done -rm -f config.cache config.log config.status Makefile + -rm -rf build langpack: tar zcvf langpack-$(DATE).tgz $(EXCLUDES) $(LANGPACK) diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/Makefile.in mailman/bin/Makefile.in --- mailman.cvs.orig/bin/Makefile.in Tue Aug 21 05:08:41 2001 +++ mailman/bin/Makefile.in Thu Sep 6 12:05:33 2001 @@ -44,9 +44,13 @@ SCRIPTS= digest_arch mmsitepass newlist rmlist add_members \ list_members remove_members clone_member update arch \ sync_members check_db withlist check_perms find_member \ - version config_list list_lists dumpdb fix_url.py \ + version config_list list_lists dumpdb \ list_admins genaliases change_pw mailmanctl qrunner +NONSCRIPTS= fix_url.py + +BUILDDIR= ../build/bin + # Modes for directories and executables created by the install # process. Default to group-writable directories but # user-only-writable for executables. @@ -63,7 +67,12 @@ install: for f in $(SCRIPTS); \ do \ - $(INSTALL) -m $(EXEMODE) $$f $(SCRIPTSDIR); \ + $(INSTALL) -m $(EXEMODE) $(BUILDDIR)/$$f $(SCRIPTSDIR); \ + done + + for f in $(NONSCRIPTS); \ + do \ + $(INSTALL) -m $(FILEMODE) $$f $(SCRIPTSDIR); \ done finish: diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/add_members mailman/bin/add_members --- mailman.cvs.orig/bin/add_members Sat Aug 4 11:05:41 2001 +++ mailman/bin/add_members Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/arch mailman/bin/arch --- mailman.cvs.orig/bin/arch Thu Jul 26 14:30:28 2001 +++ mailman/bin/arch Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/change_pw mailman/bin/change_pw --- mailman.cvs.orig/bin/change_pw Sat Aug 4 11:05:41 2001 +++ mailman/bin/change_pw Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/check_db mailman/bin/check_db --- mailman.cvs.orig/bin/check_db Fri Dec 8 04:33:52 2000 +++ mailman/bin/check_db Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/check_perms mailman/bin/check_perms --- mailman.cvs.orig/bin/check_perms Mon Jul 2 22:55:23 2001 +++ mailman/bin/check_perms Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/clone_member mailman/bin/clone_member --- mailman.cvs.orig/bin/clone_member Mon Jul 30 06:26:49 2001 +++ mailman/bin/clone_member Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/config_list mailman/bin/config_list --- mailman.cvs.orig/bin/config_list Sat May 26 00:18:34 2001 +++ mailman/bin/config_list Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/digest_arch mailman/bin/digest_arch --- mailman.cvs.orig/bin/digest_arch Mon Mar 26 09:03:46 2001 +++ mailman/bin/digest_arch Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/dumpdb mailman/bin/dumpdb --- mailman.cvs.orig/bin/dumpdb Thu Jul 12 05:11:24 2001 +++ mailman/bin/dumpdb Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/find_member mailman/bin/find_member --- mailman.cvs.orig/bin/find_member Thu Jul 19 12:28:20 2001 +++ mailman/bin/find_member Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/genaliases mailman/bin/genaliases --- mailman.cvs.orig/bin/genaliases Wed Sep 5 12:04:45 2001 +++ mailman/bin/genaliases Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/list_admins mailman/bin/list_admins --- mailman.cvs.orig/bin/list_admins Thu Mar 22 12:42:00 2001 +++ mailman/bin/list_admins Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/list_lists mailman/bin/list_lists --- mailman.cvs.orig/bin/list_lists Fri Dec 8 04:33:52 2000 +++ mailman/bin/list_lists Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/list_members mailman/bin/list_members --- mailman.cvs.orig/bin/list_members Thu Jul 19 12:28:20 2001 +++ mailman/bin/list_members Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/mailmanctl mailman/bin/mailmanctl --- mailman.cvs.orig/bin/mailmanctl Thu Aug 16 04:38:00 2001 +++ mailman/bin/mailmanctl Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # Copyright (C) 2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/mmsitepass mailman/bin/mmsitepass --- mailman.cvs.orig/bin/mmsitepass Fri Jun 1 01:15:05 2001 +++ mailman/bin/mmsitepass Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/newlist mailman/bin/newlist --- mailman.cvs.orig/bin/newlist Tue Aug 21 00:15:56 2001 +++ mailman/bin/newlist Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/pygettext.py mailman/bin/pygettext.py --- mailman.cvs.orig/bin/pygettext.py Sat Jul 28 02:22:55 2001 +++ mailman/bin/pygettext.py Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # Originally written by Barry Warsaw # # Minimally patched to make it even more xgettext compatible diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/qrunner mailman/bin/qrunner --- mailman.cvs.orig/bin/qrunner Fri Jul 6 06:58:21 2001 +++ mailman/bin/qrunner Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # Copyright (C) 2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/remove_members mailman/bin/remove_members --- mailman.cvs.orig/bin/remove_members Fri Jul 20 05:01:48 2001 +++ mailman/bin/remove_members Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/rmlist mailman/bin/rmlist --- mailman.cvs.orig/bin/rmlist Thu May 10 00:04:15 2001 +++ mailman/bin/rmlist Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/sync_members mailman/bin/sync_members --- mailman.cvs.orig/bin/sync_members Thu Jul 19 12:28:20 2001 +++ mailman/bin/sync_members Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/update mailman/bin/update --- mailman.cvs.orig/bin/update Thu Aug 16 06:30:26 2001 +++ mailman/bin/update Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/version mailman/bin/version --- mailman.cvs.orig/bin/version Fri Dec 8 04:33:52 2000 +++ mailman/bin/version Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/bin/withlist mailman/bin/withlist --- mailman.cvs.orig/bin/withlist Wed Aug 1 15:30:33 2001 +++ mailman/bin/withlist Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/configure mailman/configure --- mailman.cvs.orig/configure Sat Aug 18 08:20:12 2001 +++ mailman/configure Thu Sep 6 12:09:01 2001 @@ -1,6 +1,6 @@ #! /bin/sh -# From configure.in Revision: 2.11 +# From configure.in Revision: 2.12 # Guess values for system-dependent variables and create Makefiles. # Generated automatically using autoconf version 2.13 @@ -1980,6 +1980,59 @@ done + + + + + +SCRIPTS="build/contrib/rotatelogs.py:contrib/rotatelogs.py \ +build/contrib/qmail-to-mailman.py:contrib/qmail-to-mailman.py \ +build/contrib/securelinux_fix.py:contrib/securelinux_fix.py \ +build/filters/bowa-strip:filters/bowa-strip \ +build/cron/senddigests:cron/senddigests \ +build/cron/bumpdigests:cron/bumpdigests \ +build/cron/nightly_gzip:cron/nightly_gzip \ +build/cron/mailpasswds:cron/mailpasswds \ +build/cron/gate_news:cron/gate_news \ +build/cron/checkdbs:cron/checkdbs \ +build/bin/update:bin/update \ +build/bin/newlist:bin/newlist \ +build/bin/check_perms:bin/check_perms \ +build/bin/find_member:bin/find_member \ +build/bin/withlist:bin/withlist \ +build/bin/mailmanctl:bin/mailmanctl \ +build/bin/change_pw:bin/change_pw \ +build/bin/list_admins:bin/list_admins \ +build/bin/check_db:bin/check_db \ +build/bin/list_lists:bin/list_lists \ +build/bin/pygettext.py:bin/pygettext.py \ +build/bin/qrunner:bin/qrunner \ +build/bin/clone_member:bin/clone_member \ +build/bin/genaliases:bin/genaliases \ +build/bin/digest_arch:bin/digest_arch \ +build/bin/arch:bin/arch \ +build/bin/rmlist:bin/rmlist \ +build/bin/mmsitepass:bin/mmsitepass \ +build/bin/version:bin/version \ +build/bin/remove_members:bin/remove_members \ +build/bin/config_list:bin/config_list \ +build/bin/list_members:bin/list_members \ +build/bin/sync_members:bin/sync_members \ +build/bin/add_members:bin/add_members \ +build/bin/dumpdb:bin/dumpdb \ +build/scripts/mailowner:scripts/mailowner \ +build/scripts/mailcmd:scripts/mailcmd \ +build/scripts/post:scripts/post \ +build/scripts/leave:scripts/leave \ +build/scripts/join:scripts/join \ +build/scripts/auto:scripts/auto " + + + +# These directories are temporary directories to store macro-expanded +# scripts. They're removed on a make distclean, so we make them here. +mkdir -p build/bin build/scripts build/contrib build/filters build/cron + trap '' 1 2 15 cat > confcache <<\EOF # This file is a shell script that caches the results of configure @@ -2101,7 +2154,8 @@ Mailman/Queue/Makefile Mailman/MTA/Makefile Mailman/Gui/Makefile templates/Makefile cron/Makefile filters/Makefile scripts/Makefile messages/Makefile - cron/crontab.in misc/mailman Makefile" | sed "s/:[^ ]*//g"` conftest*; exit 1' 1 2 15 + cron/crontab.in misc/mailman Makefile + $SCRIPTS" | sed "s/:[^ ]*//g"` conftest*; exit 1' 1 2 15 EOF cat >> $CONFIG_STATUS <> $CONFIG_STATUS <<\EOF for ac_file in .. $CONFIG_FILES; do if test "x$ac_file" != x..; then @@ -2271,3 +2327,6 @@ rm -fr confdefs* $ac_clean_files test "$no_create" = yes || ${CONFIG_SHELL-/bin/sh} $CONFIG_STATUS || exit 1 + +# Make sure all the build scripts are executable. +chmod -R +x build diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/configure.in mailman/configure.in --- mailman.cvs.orig/configure.in Sat Aug 18 08:20:12 2001 +++ mailman/configure.in Thu Sep 6 12:08:58 2001 @@ -470,6 +470,70 @@ # Checks for library functions. AC_CHECK_FUNCS(vsnprintf) +dnl Expand PYTHON path in the scripts, output into build/scriptname + +AC_DEFUN(MM_SCRIPTS, [dnl +contrib/rotatelogs.py \ +contrib/qmail-to-mailman.py \ +contrib/securelinux_fix.py \ +filters/bowa-strip \ +cron/senddigests \ +cron/bumpdigests \ +cron/nightly_gzip \ +cron/mailpasswds \ +cron/gate_news \ +cron/checkdbs \ +bin/update \ +bin/newlist \ +bin/check_perms \ +bin/find_member \ +bin/withlist \ +bin/mailmanctl \ +bin/change_pw \ +bin/list_admins \ +bin/check_db \ +bin/list_lists \ +bin/pygettext.py \ +bin/qrunner \ +bin/clone_member \ +bin/genaliases \ +bin/digest_arch \ +bin/arch \ +bin/rmlist \ +bin/mmsitepass \ +bin/version \ +bin/remove_members \ +bin/config_list \ +bin/list_members \ +bin/sync_members \ +bin/add_members \ +bin/dumpdb \ +scripts/mailowner \ +scripts/mailcmd \ +scripts/post \ +scripts/leave \ +scripts/join \ +scripts/auto ]) + +dnl Please make sure to leave a space at the end of the last entry. +dnl (This is so we don't have to use [a-z/] style character classes +dnl in the regexp below and mess with m4 quoting, which is not fun.) + +dnl This regexp munges each line in MM_SCRIPTS, replacing: +dnl path/script \ +dnl with: +dnl build/path/script:path/script \ +dnl so that we can macro-expand variables in scripts without using +dnl script.in filenames, outputting the new files in build/ . + +SCRIPTS="patsubst(MM_SCRIPTS, \(.+\) \(\\?\), build/\1:\1 \2)" + +AC_SUBST(SCRIPTS) + +# These directories are temporary directories to store macro-expanded +# scripts. They're removed on a make distclean, so we make them here. +mkdir -p build/bin build/scripts build/contrib build/filters build/cron + dnl Output everything AC_OUTPUT([misc/paths.py Mailman/Defaults.py Mailman/mm_cfg.py.dist src/Makefile misc/Makefile bin/Makefile @@ -479,4 +543,8 @@ Mailman/Queue/Makefile Mailman/MTA/Makefile Mailman/Gui/Makefile templates/Makefile cron/Makefile filters/Makefile scripts/Makefile messages/Makefile - cron/crontab.in misc/mailman Makefile]) + cron/crontab.in misc/mailman Makefile + $SCRIPTS]) + +# Make sure all the build scripts are executable. +chmod -R +x build diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/contrib/qmail-to-mailman.py mailman/contrib/qmail-to-mailman.py --- mailman.cvs.orig/contrib/qmail-to-mailman.py Fri Dec 8 01:53:21 2000 +++ mailman/contrib/qmail-to-mailman.py Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # Configuration variables - Change these for your site if necessary. MailmanHome = "/home/mailman"; # Mailman home directory. diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/contrib/rotatelogs.py mailman/contrib/rotatelogs.py --- mailman.cvs.orig/contrib/rotatelogs.py Sat Aug 4 11:06:06 2001 +++ mailman/contrib/rotatelogs.py Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#!/usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 2000 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/contrib/securelinux_fix.py mailman/contrib/securelinux_fix.py --- mailman.cvs.orig/contrib/securelinux_fix.py Mon Mar 19 01:52:48 2001 +++ mailman/contrib/securelinux_fix.py Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/cron/Makefile.in mailman/cron/Makefile.in --- mailman.cvs.orig/cron/Makefile.in Sat Aug 4 11:06:50 2001 +++ mailman/cron/Makefile.in Thu Sep 6 11:57:03 2001 @@ -44,6 +44,8 @@ nightly_gzip bumpdigests FILES= crontab.in +BUILDDIR= ../build/cron + # Modes for directories and executables created by the install # process. Default to group-writable directories but # user-only-writable for executables. @@ -62,7 +64,7 @@ done for f in $(PROGRAMS); \ do \ - $(INSTALL) -m $(EXEMODE) $$f $(CRONDIR); \ + $(INSTALL) -m $(EXEMODE) $(BUILDDIR)/$$f $(CRONDIR); \ done finish: diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/cron/bumpdigests mailman/cron/bumpdigests --- mailman.cvs.orig/cron/bumpdigests Sat Jul 28 01:35:45 2001 +++ mailman/cron/bumpdigests Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/cron/checkdbs mailman/cron/checkdbs --- mailman.cvs.orig/cron/checkdbs Sat Jul 28 01:35:45 2001 +++ mailman/cron/checkdbs Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/cron/gate_news mailman/cron/gate_news --- mailman.cvs.orig/cron/gate_news Sat Jul 28 01:35:45 2001 +++ mailman/cron/gate_news Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/cron/mailpasswds mailman/cron/mailpasswds --- mailman.cvs.orig/cron/mailpasswds Sat Aug 4 14:23:56 2001 +++ mailman/cron/mailpasswds Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/cron/nightly_gzip mailman/cron/nightly_gzip --- mailman.cvs.orig/cron/nightly_gzip Sat Jul 28 01:35:45 2001 +++ mailman/cron/nightly_gzip Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/cron/senddigests mailman/cron/senddigests --- mailman.cvs.orig/cron/senddigests Sat Jul 28 01:35:45 2001 +++ mailman/cron/senddigests Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/filters/Makefile.in mailman/filters/Makefile.in --- mailman.cvs.orig/filters/Makefile.in Fri Dec 8 01:53:22 2000 +++ mailman/filters/Makefile.in Thu Sep 6 11:57:03 2001 @@ -43,6 +43,8 @@ FILTERS= bowa-strip +BUILDDIR= ../build/filters + # Modes for directories and executables created by the install # process. Default to group-writable directories but # user-only-writable for executables. @@ -59,7 +61,7 @@ install: for f in $(FILTERS); \ do \ - $(INSTALL) -m $(FILEMODE) $$f $(FILTERSDIR); \ + $(INSTALL) -m $(FILEMODE) $(BUILDDIR)/$$f $(FILTERSDIR); \ done finish: diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/filters/bowa-strip mailman/filters/bowa-strip --- mailman.cvs.orig/filters/bowa-strip Fri Dec 8 01:53:22 2000 +++ mailman/filters/bowa-strip Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/messages/Makefile.in mailman/messages/Makefile.in --- mailman.cvs.orig/messages/Makefile.in Sat Aug 18 06:24:01 2001 +++ mailman/messages/Makefile.in Thu Sep 6 11:57:03 2001 @@ -62,7 +62,7 @@ EXEMODE= 755 FILEMODE= 644 INSTALL_PROGRAM=$(INSTALL) -m $(EXEMODE) -PROG= bin/pygettext.py +PROG= build/bin/pygettext.py .SUFFIXES: .po .mo .po.mo: @@ -117,7 +117,7 @@ docstring.files: @echo "Calculating script input files for pygettext" - (cd ..; grep -d skip -l '^#! /usr/bin/env python' `find bin cron scripts -name ".#*" -prune -o -print` >| messages/$@) + (cd ..; grep -d skip -l '^#! /usr/bin/env @PYTHON@' `find bin cron scripts -name ".#*" -prune -o -print` >| messages/$@) mailman.pot: marked.files docstring.files @echo "Running pygettext on $@; this make take a while." diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/scripts/Makefile.in mailman/scripts/Makefile.in --- mailman.cvs.orig/scripts/Makefile.in Sat Aug 4 11:26:54 2001 +++ mailman/scripts/Makefile.in Thu Sep 6 12:04:10 2001 @@ -40,7 +40,10 @@ SHELL= /bin/sh -SCRIPTS= mailcmd mailowner post driver join leave +SCRIPTS= mailcmd mailowner post join leave +NONSCRIPTS= driver + +BUILDDIR= ../build/scripts # Modes for directories and executables created by the install # process. Default to group-writable directories but @@ -57,6 +60,11 @@ install: for f in $(SCRIPTS); \ + do \ + $(INSTALL) -m $(FILEMODE) $(BUILDDIR)/$$f $(SCRIPTSDIR); \ + done + + for f in $(NONSCRIPTS); \ do \ $(INSTALL) -m $(FILEMODE) $$f $(SCRIPTSDIR); \ done diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/scripts/auto mailman/scripts/auto --- mailman.cvs.orig/scripts/auto Thu Jun 28 08:00:47 2001 +++ mailman/scripts/auto Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/scripts/join mailman/scripts/join --- mailman.cvs.orig/scripts/join Thu Jun 28 08:01:22 2001 +++ mailman/scripts/join Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/scripts/leave mailman/scripts/leave --- mailman.cvs.orig/scripts/leave Thu Jun 28 08:01:42 2001 +++ mailman/scripts/leave Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/scripts/mailcmd mailman/scripts/mailcmd --- mailman.cvs.orig/scripts/mailcmd Thu Jun 28 08:02:03 2001 +++ mailman/scripts/mailcmd Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/scripts/mailowner mailman/scripts/mailowner --- mailman.cvs.orig/scripts/mailowner Thu Jun 28 08:02:29 2001 +++ mailman/scripts/mailowner Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # diff -x CVS -x *.mo -x *.po -x *.pot -ruN mailman.cvs.orig/scripts/post mailman/scripts/post --- mailman.cvs.orig/scripts/post Thu Jun 28 08:02:46 2001 +++ mailman/scripts/post Thu Sep 6 11:57:03 2001 @@ -1,4 +1,4 @@ -#! /usr/bin/env python +#! /usr/bin/env @PYTHON@ # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # From barry@zope.com Thu Sep 6 06:29:38 2001 From: barry@zope.com (Barry A. Warsaw) Date: Thu, 6 Sep 2001 01:29:38 -0400 Subject: [Mailman-Developers] [PATCH] A small bug fixed in --with-python patch References: <87wv3dvwd8.fsf@nausicaa.interq.or.jp> Message-ID: <15255.2498.202009.106447@anthem.wooz.org> >>>>> "BG" == Ben Gertzfield writes: BG> There were a few scripts nestled among all the ones I BG> converted to use #! /usr/bin/env @PYTHON@ that were not being BG> installed, because they did not have a #! line at all. A couple of nits... First, since your patch changes things so that the scripts no longer search for `python' on your $PATH, we don't need the /usr/bin/env trick anymore. So I think those lines can safely be changed to #! @PYTHON@ No need to generate another patch Ben, I've made this change myself. Second, we can forget about the filter directory; it's old, obsolete, and soon to be removed . Third, we don't need #! lines in the scripts/* files, since these will always be executed by the wrappers, which already have @PYTHON@ hard-coded into them. I've changed these lines to #! -*- python -*- to keep the Emacs major mode dance working. Other than that, I think your patch looks fine. It certainly meets my requirements, seems to work, and solves your problem. Unless I hear any objections, I'll go ahead and accept these changes. Thanks Ben! -Barry From che@debian.org Thu Sep 6 09:17:05 2001 From: che@debian.org (Ben Gertzfield) Date: Thu, 06 Sep 2001 17:17:05 +0900 Subject: [Mailman-Developers] [PATCH] Avoid duplicates v2 / global new list user options Message-ID: <87ae08wx6m.fsf@nausicaa.interq.or.jp> I fixed a small issue with the avoid duplicates patch I sent to the list last week; now admins can set the nodupes flag just like any other in the subscriber options page. This patch also includes a new feature which I would have submitted as a separate patch, but the two are a little bit co-dependant. (I can re-submit it as a separate patch, but it'll take a bit of work to re-tool it for plain Mailman CVS.) With this new feature, admins can specify a value for the user options bitfield per-list, and all new users created will have their options field (hide, ack, nodupes, etc) set from that field. They can still change their values per-user, of course. This is really useful if you want to make all new lists have nodupes enabled; I could have coded in yet another "make X option default" option, but I opted to make a general solution that may help other folks who want global hide, ack, nodupes, or whatever set for all new users per-list. The value is set via a checkbox field in General Options. I tried a scrollable multi-value field box, but it was a pain in the butt to CTRL-click all the values I wanted, so a checkbox field seemed more appropriate. Note that I left out nomail and digest, due to the fact that there's no way to put in a
between the checkboxes returned from mm_cfg.Checkbox-style options, and using over 5 options would make the field very long. In addition, mm_cfg.DEFAULT_LIST_OPTIONS contains a value for the user options bitfield that will be used as the default options for all new lists created. I had to bump the DATA_FILE_VERSION to make this new default_options list value stick. By default, on upgrade, it's set to whatever mm_cfg.DEFAULT_LIST_OPTIONS is (which is 0 to keep current behavior). Patch follows, and is against current Mailman CVS. Ben diff -x CVS -x *.mo -x *.go -x *.pot -ruN mailman-wp/Mailman/Cgi/admin.py mailman/Mailman/Cgi/admin.py --- mailman-wp/Mailman/Cgi/admin.py Wed Sep 5 12:04:45 2001 +++ mailman/Mailman/Cgi/admin.py Thu Sep 6 16:32:38 2001 @@ -800,7 +800,7 @@ usertable.AddRow([Center(Italic(_('%(allcnt)s members total')))]) usertable.AddCellInfo(usertable.GetCurrentRowIndex(), usertable.GetCurrentCellIndex(), - colspan=9, + colspan=10, bgcolor=mm_cfg.WEB_ADMINITEM_COLOR) # Add the alphabetical links if bucket: @@ -818,16 +818,16 @@ usertable.AddRow([Center(joiner.join(cells))]) usertable.AddCellInfo(usertable.GetCurrentRowIndex(), usertable.GetCurrentCellIndex(), - colspan=9, + colspan=10, bgcolor=mm_cfg.WEB_ADMINITEM_COLOR) usertable.AddRow([Center(h) for h in (_('unsub'), _('member address
member name'), _('hide'), _('nomail'), _('ack'), _('not metoo'), - _('digest'), _('plain'), - _('language'))]) + _('nodupes'), _('digest'), + _('plain'), _('language'))]) rowindex = usertable.GetCurrentRowIndex() - for i in range(9): + for i in range(10): usertable.AddCellInfo(rowindex, i, bgcolor=mm_cfg.WEB_ADMINITEM_COLOR) # Find the longest name in the list longest = 0 @@ -848,7 +848,7 @@ name + Hidden('user', urllib.quote(addr)).Format(), ] - for opt in ('hide', 'nomail', 'ack', 'notmetoo'): + for opt in ('hide', 'nomail', 'ack', 'notmetoo', 'nodupes'): if mlist.getMemberOption(addr, MailCommandHandler.option_info[opt]): value = 'on' @@ -898,6 +898,9 @@ _('''not metoo -- Does the member avoid copies of their own posts?''')) legend.AddItem( + _('''nodupes -- Does the member avoid duplicates of the same + message?''')) + legend.AddItem( _('''digest -- Does the member get messages in digests? (otherwise, individual messages)''')) legend.AddItem( @@ -1186,6 +1189,16 @@ mlist.bump_digest_volume() elif property == '_send_digest_now' and value: mlist.send_digest_now() + elif property == 'default_options': + checked_defaults = cgidata.getvalue("default_options") + i = 0 + new_defaults = 0 + for opt in ("hide", "ack", "notmetoo", "plain", "nodupes"): + opt_code = MailCommandHandler.option_info[opt] + if `i` in checked_defaults: + new_defaults = new_defaults | opt_code + i = i + 1 + mlist.default_options = new_defaults elif getattr(mlist, property) <> value: # TBD: Ensure that mlist.real_name differs only in letter # case. Otherwise a security hole can potentially be opened @@ -1329,7 +1342,8 @@ if newlang and newlang <> oldlang: mlist.setMemberLanguage(user, newlang) - for opt in ("hide", "nomail", "ack", "notmetoo", "plain"): + for opt in ("hide", "nomail", "ack", "notmetoo", "plain", + "nodupes"): opt_code = MailCommandHandler.option_info[opt] if cgidata.has_key('%s_%s' % (user, opt)): mlist.setMemberOption(user, opt_code, 1) diff -x CVS -x *.mo -x *.go -x *.pot -ruN mailman-wp/Mailman/Cgi/options.py mailman/Mailman/Cgi/options.py --- mailman-wp/Mailman/Cgi/options.py Thu Aug 2 13:14:43 2001 +++ mailman/Mailman/Cgi/options.py Thu Sep 6 13:01:10 2001 @@ -375,6 +375,7 @@ ('conceal', mm_cfg.ConcealSubscription), ('remind', mm_cfg.SuppressPasswordReminder), ('rcvtopic', mm_cfg.ReceiveNonmatchingTopics), + ('nodupes', mm_cfg.DontReceiveDuplicates), ): try: newval = int(cgidata.getvalue(item)) @@ -449,9 +450,18 @@ global_remind = newval break - if global_enable is not None or global_remind is not None: + global_nodupes = None + if cgidata.getvalue('nodupes-globally'): + for flag, newval in newvals: + if flag == mm_cfg.DontReceiveDuplicates: + global_nodupes = newval + break + + if (global_enable is not None or global_remind is not None + or global_nodupes is not None): for gmlist in lists_of_member(mlist.host_name, user): - global_options(gmlist, user, global_enable, global_remind) + global_options(gmlist, user, global_enable, global_remind, + global_nodupes) # Now print the results if cantdigest: @@ -526,6 +536,10 @@ mlist.FormatOptionButton(mm_cfg.ConcealSubscription, 0, user)) replacements[''] = mlist.FormatOptionButton( mm_cfg.ConcealSubscription, 1, user) + replacements[''] = ( + mlist.FormatOptionButton(mm_cfg.DontReceiveDuplicates, 1, user)) + replacements[''] = ( + mlist.FormatOptionButton(mm_cfg.DontReceiveDuplicates, 0, user)) replacements[''] = ( mlist.FormatButton('unsub', _('Unsubscribe')) + '
' + CheckBox('unsubconfirm', 1, checked=0).Format() + @@ -555,6 +569,8 @@ CheckBox('deliver-globally', 1, checked=0).Format()) replacements[''] = ( CheckBox('remind-globally', 1, checked=0).Format()) + replacements[''] = ( + CheckBox('nodupes-globally', 1, checked=0).Format()) days = int(mm_cfg.PENDING_REQUEST_LIFE / mm_cfg.days(1)) if days > 1: @@ -741,7 +757,7 @@ -def global_options(mlist, user, global_enable, global_remind): +def global_options(mlist, user, global_enable, global_remind, global_nodupes): def sigterm_handler(signum, frame, mlist=mlist): # Make sure the list gets unlocked... mlist.Unlock() @@ -762,6 +778,10 @@ if global_remind is not None: mlist.setMemberOption(user, mm_cfg.SuppressPasswordReminder, global_remind) + + if global_nodupes is not None: + mlist.setMemberOption(user, mm_cfg.DontReceiveDuplicates, + global_nodupes) mlist.Save() finally: diff -x CVS -x *.mo -x *.go -x *.pot -ruN mailman-wp/Mailman/Defaults.py.in mailman/Mailman/Defaults.py.in --- mailman-wp/Mailman/Defaults.py.in Wed Sep 5 12:04:45 2001 +++ mailman/Mailman/Defaults.py.in Thu Sep 6 13:01:10 2001 @@ -286,6 +286,7 @@ 'Hold', 'Tagger', 'CalcRecips', + 'AvoidDuplicates', 'Cleanse', 'CookHeaders', 'ToDigest', @@ -570,6 +571,10 @@ # Make it 1 when it works. DEFAULT_MEMBER_POSTING_ONLY = 0 +# See "Bitfield for user options" below; make this a sum of those +# options, to make all new members of lists start with those options +# flagged. +DEFAULT_LIST_OPTIONS = 0 ##### @@ -731,6 +736,7 @@ TEXTFIELDWIDTH = 40 # Bitfield for user options +# See DEFAULT_LIST_OPTIONS above to set defaults for all new lists Digests = 0 # handled by other mechanism, doesn't need a flag. DisableDelivery = 1 DontReceiveOwnPosts = 2 # Non-digesters only @@ -739,6 +745,7 @@ ConcealSubscription = 16 SuppressPasswordReminder = 32 ReceiveNonmatchingTopics = 64 +DontReceiveDuplicates = 128 # Authentication contexts. # diff -x CVS -x *.mo -x *.go -x *.pot -ruN mailman-wp/Mailman/Gui/General.py mailman/Mailman/Gui/General.py --- mailman-wp/Mailman/Gui/General.py Fri Aug 17 14:47:11 2001 +++ mailman/Mailman/Gui/General.py Thu Sep 6 15:29:49 2001 @@ -30,6 +30,21 @@ def GetConfigInfo(self, mlist): WIDTH = mm_cfg.TEXTFIELDWIDTH + # These are for the default_options checkboxes below. + # this should be set in a module somewhere.. + option_info = {'hide' : mm_cfg.ConcealSubscription, + 'ack' : mm_cfg.AcknowledgePosts, + 'notmetoo' : mm_cfg.DontReceiveOwnPosts, + 'plain' : mm_cfg.DisableMime, + 'nodupes' : mm_cfg.DontReceiveDuplicates + } + + options = ['hide', 'ack', 'notmetoo', 'plain', 'nodupes'] + option_values = [] + + for o in options: + option_values.append(mlist.default_options & option_info[o]) + return [ _('''Fundamental list characteristics, including descriptive info and basic behaviors.'''), @@ -252,6 +267,9 @@ ('send_reminders', mm_cfg.Radio, (_('No'), _('Yes')), 0, _('''Send monthly password reminders or no? Overrides the previous option.''')), + + ('default_options', mm_cfg.Checkbox, (options, option_values, 1), + 0, _('''Default options for all members that join this list.''')), ('send_welcome_msg', mm_cfg.Radio, (_('No'), _('Yes')), 0, _('Send welcome message when people subscribe?'), diff -x CVS -x *.mo -x *.go -x *.pot -ruN mailman-wp/Mailman/HTMLFormatter.py mailman/Mailman/HTMLFormatter.py --- mailman-wp/Mailman/HTMLFormatter.py Wed Sep 5 12:04:45 2001 +++ mailman/Mailman/HTMLFormatter.py Thu Sep 6 13:01:10 2001 @@ -114,6 +114,7 @@ mm_cfg.ConcealSubscription : 'conceal', mm_cfg.SuppressPasswordReminder : 'remind', mm_cfg.ReceiveNonmatchingTopics : 'rcvtopic', + mm_cfg.DontReceiveDuplicates : 'nodupes', }[type] return '' % ( name, value, checked) diff -x CVS -x *.mo -x *.go -x *.pot -ruN mailman-wp/Mailman/Handlers/AvoidDuplicates.py mailman/Mailman/Handlers/AvoidDuplicates.py --- mailman-wp/Mailman/Handlers/AvoidDuplicates.py Thu Jan 1 09:00:00 1970 +++ mailman/Mailman/Handlers/AvoidDuplicates.py Thu Sep 6 13:01:10 2001 @@ -0,0 +1,118 @@ +# Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License +# as published by the Free Software Foundation; either version 2 +# of the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + +"""If the user wishes it, do not send duplicates of the same message. + +This module keeps an in-memory dictionary of Message-ID and recipient +pairs. If a message with an identical Message-ID is about to be sent +to someone who has already received a copy, we either drop the message, +add a duplicate warning header, or pass it through, depending on the +user's preferences. +""" + +import string + +from Mailman import mm_cfg +from Mailman import Utils +from Mailman import Message +from Mailman import Errors +from Mailman.i18n import _ +from mimelib.address import getaddresses + + + +class DuplicateDetected(Errors.DiscardMessage): + """The message would have been sent multiple times to a user who + prefers not to receive duplicates.""" + +# A dictionary of dictionaries, used to store which recipients have received +# which message IDs. +recip_msgids = {} + + + +def process(mlist, msg, msgdata): + + recips = msgdata['recips'] + msgid = msg.get('message-id') + + if not recips or not msgid: + return + + # This dictionary will hold recips who want their mail to have + # the X-Mailman-Duplicate: yes header. + if not msgdata.has_key('add-dupe-header'): + msgdata['add-dupe-header'] = {} + + # Happily borrowed from mimelib.getaddresses() example + tos = msg.getall('to') + ccs = msg.getall('cc') + resent_tos = msg.getall('resent-to') + resent_ccs = msg.getall('resent-cc') + external_recips = getaddresses(tos + ccs + resent_tos + resent_ccs) + + # Anyone mentioned in the to/cc/resent-to/resent-cc headers should + # not get a duplicate of the message. + for (name, email) in external_recips: + + # If getaddresses fails, email could be null. Skip those. + if not email: + continue + + # Initialize the external recipient's msgid hash if this is the + # first email they've received with this message-id. + if not recip_msgids.has_key(email): + recip_msgids[email] = {} + + # We don't do anything except record that that address has + # gotten or will get a copy of this email externally. + recip_msgids[email][msgid] = 1 + + newrecips = [] + + for r in recips: + if not recip_msgids.has_key(r): + recip_msgids[r] = {} + + # If they have received a message with this message-id already, + # see if they don't want duplicates. + if recip_msgids[r].has_key(msgid): + send_duplicate = 1 + + # If the member wants to receive duplicates, or if the recipient + # is not a member at all, just flag the X-Mailman-Duplicate: yes + # header. + try: + if mlist.getMemberOption(r, mm_cfg.DontReceiveDuplicates): + send_duplicate = 0 + except Errors.NotAMemberError: + pass + + # We'll send a duplicate unless the user doesn't wish it. + # If personalization is enabled, the add-dupe-header flag will + # add a X-Mailman-Duplicate: yes header for this user's message. + if send_duplicate: + msgdata['add-dupe-header'][r] = 1 + newrecips.append(r) + + else: + # Otherwise, this is the first time they've been in the recips + # list. Add them to the newrecips list and flag them as having + # received this message. + recip_msgids[r][msgid] = 1 + newrecips.append(r) + + msgdata['recips'] = newrecips diff -x CVS -x *.mo -x *.go -x *.pot -ruN mailman-wp/Mailman/Handlers/Personalize.py mailman/Mailman/Handlers/Personalize.py --- mailman-wp/Mailman/Handlers/Personalize.py Sat Aug 18 06:20:58 2001 +++ mailman/Mailman/Handlers/Personalize.py Thu Sep 6 13:01:10 2001 @@ -46,11 +46,23 @@ msg['To'] = '%s (%s)' % (member, name) else: msg['To'] = member + + # We can flag the mail as a duplicate for each member, if + # they've already received that message. (See AvoidDuplicates.py) + if msgdata['add-dupe-header'].has_key(member): + msg['X-Mailman-Duplicate'] = 'yes' + elif msg.has_key('X-Mailman-Duplicate'): + del msg['X-Mailman-Duplicate'] + inq.enqueue(msg, metadatacopy, listname=mlist.internal_name()) # Restore the original To: line del msg['To'] msg['To'] = originalto + + # The original message is not a duplicate. + if msg.has_key('X-Mailman-Duplicate'): + del msg['X-Mailman-Duplicate'] # Don't let the normal ToOutgoing processing actually send the original # copy. diff -x CVS -x *.mo -x *.go -x *.pot -ruN mailman-wp/Mailman/MailCommandHandler.py mailman/Mailman/MailCommandHandler.py --- mailman-wp/Mailman/MailCommandHandler.py Fri Aug 17 14:37:15 2001 +++ mailman/Mailman/MailCommandHandler.py Thu Sep 6 13:01:10 2001 @@ -80,27 +80,36 @@ you get digests in MIME format, which are much better if you have a mail reader that supports MIME.""") -option_desc = {'hide' : HIDE, - 'nomail' : NOMAIL, - 'ack' : ACK, - 'notmetoo': NOTMETOO, - 'digest' : DIGEST, - 'plain' : PLAIN, +NODUPES = _("""When turned on, you do *not* receive duplicate mails if mail is +sent to multiple lists that you belong to. This option will let you avoid +duplicate mails; if you turn it on, you will never receive multiple copies +of the same message. Also, if you *and* the list are mentioned explicitly +in the To: or Cc: headers of a message, you will not receive duplicates if +this is turned on.""") + +option_desc = {'hide' : HIDE, + 'nomail' : NOMAIL, + 'ack' : ACK, + 'notmetoo' : NOTMETOO, + 'digest' : DIGEST, + 'plain' : PLAIN, + 'nodupes' : NODUPES, } # jcrey: and then the real one _ = Mailman.i18n._ -option_info = {'hide' : mm_cfg.ConcealSubscription, - 'nomail' : mm_cfg.DisableDelivery, - 'ack' : mm_cfg.AcknowledgePosts, - 'notmetoo': mm_cfg.DontReceiveOwnPosts, - 'digest' : 0, - 'plain' : mm_cfg.DisableMime, +option_info = {'hide' : mm_cfg.ConcealSubscription, + 'nomail' : mm_cfg.DisableDelivery, + 'ack' : mm_cfg.AcknowledgePosts, + 'notmetoo' : mm_cfg.DontReceiveOwnPosts, + 'digest' : 0, + 'plain' : mm_cfg.DisableMime, + 'nodupes' : mm_cfg.DontReceiveDuplicates } # ordered list -options = ('hide', 'nomail', 'ack', 'notmetoo', 'digest', 'plain') +options = ('hide', 'nomail', 'ack', 'notmetoo', 'digest', 'plain', 'nodupes') # strip just the outer layer of quotes quotecre = re.compile(r'["\'`](?P.*)["\'`]') diff -x CVS -x *.mo -x *.go -x *.pot -ruN mailman-wp/Mailman/MailList.py mailman/Mailman/MailList.py --- mailman-wp/Mailman/MailList.py Wed Sep 5 12:04:45 2001 +++ mailman/Mailman/MailList.py Thu Sep 6 12:51:31 2001 @@ -254,7 +254,8 @@ self.language = {} self.usernames = {} self.passwords = {} - + self.default_options = mm_cfg.DEFAULT_LIST_OPTIONS + # This stuff is configurable self.respond_to_post_requests = 1 self.advertised = mm_cfg.DEFAULT_LIST_ADVERTISED diff -x CVS -x *.mo -x *.go -x *.pot -ruN mailman-wp/Mailman/OldStyleMemberships.py mailman/Mailman/OldStyleMemberships.py --- mailman-wp/Mailman/OldStyleMemberships.py Wed Sep 5 12:04:45 2001 +++ mailman/Mailman/OldStyleMemberships.py Thu Sep 6 12:42:19 2001 @@ -176,6 +176,8 @@ self.setMemberLanguage(member, language) if realname: self.setMemberName(member, realname) + if self.__mlist.default_options: + self.__mlist.user_options[member] = self.__mlist.default_options def removeMember(self, member): assert self.__mlist.Locked() diff -x CVS -x *.mo -x *.go -x *.pot -ruN mailman-wp/Mailman/Version.py mailman/Mailman/Version.py --- mailman-wp/Mailman/Version.py Fri Aug 17 14:41:03 2001 +++ mailman/Mailman/Version.py Thu Sep 6 12:57:05 2001 @@ -36,7 +36,7 @@ (REL_LEVEL << 4) | (REL_SERIAL << 0)) # config.db schema version number -DATA_FILE_VERSION = 35 +DATA_FILE_VERSION = 36 # qfile/*.db schema version number QFILE_SCHEMA_VERSION = 3 diff -x CVS -x *.mo -x *.go -x *.pot -ruN mailman-wp/Mailman/htmlformat.py mailman/Mailman/htmlformat.py diff -x CVS -x *.mo -x *.go -x *.pot -ruN mailman-wp/Mailman/versions.py mailman/Mailman/versions.py --- mailman-wp/Mailman/versions.py Fri Aug 17 14:40:28 2001 +++ mailman/Mailman/versions.py Thu Sep 6 12:55:00 2001 @@ -211,7 +211,7 @@ add_only_if_missing('one_last_digest', {}) add_only_if_missing('usernames', {}) add_only_if_missing('personalize', 0) - + add_only_if_missing('default_options', mm_cfg.DEFAULT_LIST_OPTIONS) def UpdateOldUsers(l): diff -x CVS -x *.mo -x *.go -x *.pot -ruN mailman-wp/templates/en/help.txt mailman/templates/en/help.txt --- mailman-wp/templates/en/help.txt Sat May 19 06:28:54 2001 +++ mailman/templates/en/help.txt Thu Sep 6 13:01:10 2001 @@ -79,6 +79,10 @@ Conceals your address when people look at who is on this list. + nodupes: + Turn this on if you do not want to receive duplicate mail + from the list, in case you are explicitly in the To: or Cc: + fields already or are included in multiple lists in one message. options Show the current values of your list options. diff -x CVS -x *.mo -x *.go -x *.pot -ruN mailman-wp/templates/en/options.html mailman/templates/en/options.html --- mailman-wp/templates/en/options.html Thu Jul 19 06:54:40 2001 +++ mailman/templates/en/options.html Thu Sep 6 13:01:10 2001 @@ -280,6 +280,26 @@ Yes + + Avoid duplicate copies of messages?

+ + When you are listed explicitly in the To: or Cc: headers + of a list message, or a message is sent to multiple lists + that you are a member of, you can opt to not receive another + copy from the mailing list. Select Yes to avoid + receiving duplicate copies from the mailing list; select + No to receive duplicate copies. + +

If the list has per-message personalization + enabled, every duplicate mail will have a + X-Mailman-Duplicate: yes header added to it. + + + No
+ Yes

+ Set globally + +

From che@debian.org Thu Sep 6 09:23:17 2001 From: che@debian.org (Ben Gertzfield) Date: Thu, 06 Sep 2001 17:23:17 +0900 Subject: [Mailman-Developers] [PATCH] A small bug fixed in --with-python patch In-Reply-To: <15255.2498.202009.106447@anthem.wooz.org> (barry@zope.com's message of "Thu, 6 Sep 2001 01:29:38 -0400") References: <87wv3dvwd8.fsf@nausicaa.interq.or.jp> <15255.2498.202009.106447@anthem.wooz.org> Message-ID: <871ylkwwwa.fsf@nausicaa.interq.or.jp> >>>>> "BAW" == Barry A Warsaw writes: BAW> A couple of nits... BAW> First, since your patch changes things so that the scripts no BAW> longer search for `python' on your $PATH, we don't need the BAW> /usr/bin/env trick anymore. So I think those lines can BAW> safely be changed to BAW> #! @PYTHON@ BAW> No need to generate another patch Ben, I've made this change BAW> myself. Great! That makes a lot of sense, I should have realized that. :) BAW> Second, we can forget about the filter directory; it's old, BAW> obsolete, and soon to be removed . Third, we don't BAW> need #! lines in the scripts/* files, since these will always BAW> be executed by the wrappers, which already have @PYTHON@ BAW> hard-coded into them. I've changed these lines to Ah, okay. It's sometimes a little hard to be aware of the big picture, but that'll work great. BAW> #! -*- python -*- BAW> to keep the Emacs major mode dance working. For future reference, you could also set it at the end of the file: # Local-variables: # major-mode:python # End: or something like that. :) BAW> Other than that, I think your patch looks fine. It certainly BAW> meets my requirements, seems to work, and solves your BAW> problem. BAW> Unless I hear any objections, I'll go ahead and accept these BAW> changes. Excellent! I'm really enjoying working with Mailman. Python is just so clean and easy to follow, it makes my life easy. :) Thanks for helping solve the (future) Debian users' problems. Ben -- Brought to you by the letters A and B and the number 11. "Ohhhh, Mentos Boy!" Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From michael@cmo.uqam.ca Thu Sep 6 19:00:24 2001 From: michael@cmo.uqam.ca (Michael Totschnig) Date: Thu, 06 Sep 2001 14:00:24 -0400 Subject: [Mailman-Developers] Re: Avoid duplicates v2 / global new list user options In-Reply-To: <87ae08wx6m.fsf@nausicaa.interq.or.jp> (Ben Gertzfield's message of "Thu, 06 Sep 2001 17:17:05 +0900") Message-ID: Hello, I am using the CVS version of mailman as of yesterday. The reason is that I'd like to propose a french interface for some lists, I had some troubles installing version 2.1a2, so I decided to give the most recent version a try. I do not know if reporting problems when using CVS should go to the developers or the users list. My apology if this is answered on an obvious place. until now, all works fine. the only apparent problem is an error a daily cron script generates. It seems to concern the sending of digests, until now I have not tested digesting, thus I do not see any apparent effects. Is this a know bug, or could there be anything wrong with my setup? Thanks, Michael Traceback (most recent call last): File "/var/Mailman//cron/senddigests", line 52, in ? main() File "/var/Mailman//cron/senddigests", line 44, in main mlist.send_digest_now() File "/var/Mailman//Mailman/Digester.py", line 59, in send_digest_now ToDigest.send_digests(self, mboxfp) File "/var/Mailman//Mailman/Handlers/ToDigest.py", line 135, in send_digests send_i18n_digests(mlist, mboxfp) File "/var/Mailman//Mailman/Handlers/ToDigest.py", line 330, in send_i18n_digests drecips = mlist.getDigestMemberKeys() + mlist.one_last_digest.keys() File "/var/Mailman//Mailman/MailList.py", line 134, in __getattr__ raise AttributeError, name AttributeError: one_last_digest From dagilbert@west.raytheon.com Fri Sep 7 01:06:26 2001 From: dagilbert@west.raytheon.com (David A Gilbert) Date: Thu, 6 Sep 2001 17:06:26 -0700 Subject: [Mailman-Developers] Archives not showing threading Message-ID: Hello, Does anyone know why archives are not showing threading? I look at the archives on this list (at http://mail.python.org/pipermail/mailman-developers/2001-August/thread.html, for example) and when View by Thread, they are nicely tabbed with a different style bullet for each reply. Ours are showing up all left-justified, no bullets. Have seen this problem for months and nobody seems to have any suggestions, does anyone here have any ideas?? Thanks in advance. David Gilbert dagilbert@west.raytheon.com ----- Forwarded by David A Gilbert/RWS/Raytheon/US on 09/06/2001 05:00 PM ----- David A Gilbert To: mailman-users@python.org cc: 09/02/2001 Subject: Archives not showing threading 09:02 PM I am using mailman-2.0.6 on RedHat Linux 6.2 machine. None of mail archives show the indented threading when the view by thread sort is selected. All messages are left-justified. Is there any configuration of mailman, pipermail, etc, that needs to be done to enable this? Thanks, David Gilbert dagilbert@west.raytheon.com From claw@kanga.nu Fri Sep 7 02:55:35 2001 From: claw@kanga.nu (J C Lawrence) Date: Thu, 06 Sep 2001 18:55:35 -0700 Subject: [Mailman-Developers] Archives not showing threading In-Reply-To: Message from "David A Gilbert" of "Thu, 06 Sep 2001 17:06:26 PDT." References: Message-ID: <19678.999827735@kanga.nu> On Thu, 6 Sep 2001 17:06:26 -0700 David A Gilbert wrote: > Does anyone know why archives are not showing threading? Threading is accomplished via the References: and In-Reply-To headers in messages. Check that you have the appropriate headers and that they link properly. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From michael@cmo.uqam.ca Fri Sep 7 03:42:03 2001 From: michael@cmo.uqam.ca (Michael Totschnig) Date: Thu, 06 Sep 2001 22:42:03 -0400 Subject: [Mailman-Developers] cron/senddigests raises error In-Reply-To: (Michael Totschnig's message of "Thu, 06 Sep 2001 14:00:24 -0400") References: Message-ID: My apology for not using an appropriate subject line in my last message. Michael From che@debian.org Fri Sep 7 03:54:08 2001 From: che@debian.org (Ben Gertzfield) Date: Fri, 07 Sep 2001 11:54:08 +0900 Subject: [Mailman-Developers] Mailman CVS sends out Japanese template mails in EUC-JP Message-ID: <877kvbk8xb.fsf@nausicaa.interq.or.jp> Right now, Mailman 2.1 and Japanese are not working together terribly well. The web pages are fully internationalized, which works great. But there's a big problem with sending template mails out; they're stored in EUC-JP, when Japanese mail *MUST* be formatted in ISO-2022-JP (JIS). Kikuchi-san has developed some Handler modules to solve this problem, but I cannot get them to work with the latest Mailman CVS. His solution is to add a ja_To_EUC_JP module at the beginning of the handler pipeline, then use a ja_SMTPDirect module to convert to ISO-2022-JP at the end of the pipeline, instead of SMTPDirect. However, with the latest Mailman CVS, even following the instructions at http://mm.tkikuchi.net/mailman-2.1alpha.ja/README.ja (both English and Japanese are in there), and doing the following, welcome and administration mails in Japanese are sent verbatim in EUC-JP, which of course is not readable in any mail reader. 1) Install kconv.py from http://hito.eccosys.com/~mak/kconv/index_jp.html (python setup.py; cp -a kconv /usr/local/lib/python2.0/site-packages/) 2) Copy ja_SMTPDirect.py, ja_To_EUC_JP.py, and ja_To_ISO_2022_JP.py into Mailman/Handlers 3) Set DEFAULT_SERVER_LANGUAGE to 'ja', add ja_To_EUC_JP.py to the beginning of the pipeline, and set DELIVERY_MODULE to ja_SMTPDirect. (I tried both via mm_cfg.py and by making them the default in Defaults.py.in, then configuring and making fresh). I'm not getting any errors in the logs, but mail is not converted to ISO-2022-JP with this method -- in fact, the Content-Type: text/plain; encoding=iso-2022-jp header that ja_To_ISO-2022-JP.py is supposed to add is not even added. It seems like even this is a really roundabout way to get Japanese to work in Mailman. Without converting the emails to ISO-2022-JP, Mailman might as well not have any Japanese support at all; it's misleading to have the web pages support Japanese and have the welcome mails translated, but then sending them out in an 8-bit encoding that may wreck people's mail servers or crash their mail clients. Please let me know if there's anything I've missed. I would really like to get Japanese support working in mainstream Mailman 2.1. Ben -- Brought to you by the letters N and H and the number 17. "I'm with insurance." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From che@debian.org Fri Sep 7 07:43:25 2001 From: che@debian.org (Ben Gertzfield) Date: Fri, 07 Sep 2001 15:43:25 +0900 Subject: [Mailman-Developers] Mailman CVS sends out Japanese template mails in EUC-JP In-Reply-To: <877kvbk8xb.fsf@nausicaa.interq.or.jp> (Ben Gertzfield's message of "Fri, 07 Sep 2001 11:54:08 +0900") References: <877kvbk8xb.fsf@nausicaa.interq.or.jp> Message-ID: <87pu93ijqq.fsf@nausicaa.interq.or.jp> Looking at this problem some more, it seems that Mailman has changed how system notification mails are sent quite a lot between 2.0 and CVS. Now they're inserted into a "virgin queue", which seems to not go through the normal pipeline. But I'd think at least the Content-Type: header needs to be modified, as well as converting the contents of the European internationalized mails to quoted-printable, before sending out these kinds of messages. How should we approach modifying the virgin queue? I can hack in conversion to ISO-2022-JP and adding the headers, but that seems wrong somehow. Maybe have each language supply its own special "incoming mail charset conversion", "outgoing mail charset conversion", and "header additions" modules? I know Japanese needs to convert incoming mails to EUC before they're archived, and back to ISO-2022-JP when they go back out to the list. Ben -- Brought to you by the letters Y and D and the number 11. "More testicles means more iron." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From mikhail.sobolev@transas.com Fri Sep 7 10:42:10 2001 From: mikhail.sobolev@transas.com (Mikhail Sobolev) Date: Fri, 7 Sep 2001 10:42:10 +0100 Subject: [Mailman-Developers] Content-Type headers Message-ID: <20010907104210.A3142@transas.co.uk> --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline While checking the maillist server answers, I found that those messages do not have any Content-Type headers... Which seems to be rather wrong. For example, in Russian we use a number of character sets among which koi8-r and cp1251 are the most common. That means that most likely the translation for Russian will be in either of them. Therefor, the lack of Content-Type header leads to the problems on the receiving side, where the default character set is different from the one used for translation. Here is a small patch, which, hopefully, fixes the problem. -- Misha --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ml.patch" Index: MailList.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/MailList.py,v retrieving revision 2.38 diff -u -b -r2.38 MailList.py --- MailList.py 2001/09/05 02:39:28 2.38 +++ MailList.py 2001/09/07 09:41:05 @@ -630,6 +630,8 @@ 'confirm %s' % cookie, text) msg['Reply-To'] = self.GetRequestEmail() + msg.addheader('Content-Type', 'text/plain', charset=Utils.GetCharSet(lang)) + msg.send(self) if recipient <> email: who = "%s (%s)" % (email, recipient.split('@')[0]) @@ -714,6 +716,8 @@ msg = Message.UserNotification( self.owner, Utils.get_site_email(self.host_name, '-admin'), subject, text) + msg.addheader('Content-Type', 'text/plain', charset=Utils.GetCharSet(lang)) + msg.send(self) def ApprovedDeleteMember(self, name, whence=None, @@ -742,6 +746,8 @@ msg = Message.UserNotification( self.owner, Utils.get_site_email(self.host_name, '-admin'), subject, text) + msg.addheader('Content-Type', 'text/plain', charset=Utils.GetCharSet(self.preferred_language)) + msg.send(self) if whence: whence = "; %s" % whence @@ -807,6 +813,8 @@ 'confirm %s' % cookie, text) msg['Reply-To'] = self.GetRequestEmail() + msg.addheader('Content-Type', 'text/plain', charset=Utils.GetCharSet(lang)) + msg.send(self) def ApprovedChangeMemberAddress(self, oldaddr, newaddr, globally): @@ -900,6 +908,8 @@ 'confirm %s' % cookie, text) msg['Reply-To'] = self.GetRequestEmail() + msg.addheader('Content-Type', 'text/plain', charset=Utils.GetCharSet(lang)) + msg.send(self) --EeQfGwPcQSOJBaQU-- From barry@zope.com Sat Sep 8 00:14:36 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 7 Sep 2001 19:14:36 -0400 Subject: [Mailman-Developers] [PATCH] A small bug fixed in --with-python patch References: <87wv3dvwd8.fsf@nausicaa.interq.or.jp> <15255.2498.202009.106447@anthem.wooz.org> <871ylkwwwa.fsf@nausicaa.interq.or.jp> Message-ID: <15257.21724.661166.532809@anthem.wooz.org> >>>>> "BG" == Ben Gertzfield writes: BAW> #! -*- python -*- BAW> to keep the Emacs major mode dance working. BG> For future reference, you could also set it at the end of the BG> file: | # Local-variables: | # major-mode:python | # End: BG> or something like that. :) Yeah, but I usually avoid Local-variables: sections for major mode settings. Force of habit I guess. ;) BAW> Other than that, I think your patch looks fine. It certainly BAW> meets my requirements, seems to work, and solves your BAW> problem. BAW> Unless I hear any objections, I'll go ahead and accept these BAW> changes. BG> Excellent! I'm really enjoying working with Mailman. Python BG> is just so clean and easy to follow, it makes my life easy. :) BG> Thanks for helping solve the (future) Debian users' problems. No problem, thanks for the patch! Checking these in momentarily. -Barry From barry@zope.com Sat Sep 8 05:01:24 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 8 Sep 2001 00:01:24 -0400 Subject: [Mailman-Developers] cron/senddigests raises error References: Message-ID: <15257.38932.692243.516288@anthem.wooz.org> >>>>> "MT" == Michael Totschnig writes: MT> I am using the CVS version of mailman as of yesterday. The MT> reason is that I'd like to propose a french interface for some MT> lists, I had some troubles installing version 2.1a2, so I MT> decided to give the most recent version a try. I do not know MT> if reporting problems when using CVS should go to the MT> developers or the users list. My apology if this is answered MT> on an obvious place. Yes, please send all 2.1 bug reports to -developers! MT> until now, all works fine. the only apparent problem is an MT> error a daily cron script generates. It seems to concern the MT> sending of digests, until now I have not tested digesting, MT> thus I do not see any apparent effects. Is this a know bug, or MT> could there be anything wrong with my setup? Nope, it's a bug. Watch for checkins shortly. Thanks! -Barry From barry@zope.com Sat Sep 8 05:28:35 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sat, 8 Sep 2001 00:28:35 -0400 Subject: [Mailman-Developers] Mailman CVS sends out Japanese template mails in EUC-JP References: <877kvbk8xb.fsf@nausicaa.interq.or.jp> <87pu93ijqq.fsf@nausicaa.interq.or.jp> Message-ID: <15257.40563.81479.94746@anthem.wooz.org> >>>>> "BG" == Ben Gertzfield writes: BG> Looking at this problem some more, it seems that Mailman has BG> changed how system notification mails are sent quite a lot BG> between 2.0 and CVS. Indeed! :) BG> Now they're inserted into a "virgin queue", which seems to not BG> go through the normal pipeline. This is true, but VirginRunner will do a little processing on the message and then drop it in the outgoing queue. From there the OutgoingRunner will attempt to deliver it via the DELIVERY_MODULE. At least, that's how it's supposed to work! BG> But I'd think at least the Content-Type: header needs to be BG> modified, as well as converting the contents of the European BG> internationalized mails to quoted-printable, before sending BG> out these kinds of messages. BG> How should we approach modifying the virgin queue? I can hack BG> in conversion to ISO-2022-JP and adding the headers, but that BG> seems wrong somehow. Maybe have each language supply its own BG> special "incoming mail charset conversion", "outgoing mail BG> charset conversion", and "header additions" modules? I know BG> Japanese needs to convert incoming mails to EUC before they're BG> archived, and back to ISO-2022-JP when they go back out to the BG> list. We only have this problem for messages that Mailman generates, right? IOW, for messages sent to the list by members, we're adhering to least-munging principles, so if someone sends a message to the list all bolluxed up, tough luck. Under that assumption, here's a strawman design for doing this in an extensible way: We extend the VirginRunner pipeline so that just before ToOutgoing, Mailman will send the message through a language-specific handler module. We use the list's default language code to calculate the name of the handler module. E.g. for Japanese, we'd use something like Mailman.Handlers.LanguagePrep_ja.py. If "LanguagePrep_py" doesn't exist, we don't do anything. Otherwise, the module has the same signature as other handler modules and of course, can do any necessary message munging. For Japanese, this should subsume the ja_to_EUC_JP.py and ja_SMTPDirect.py modules, right? Now, for archiving, we'd do something similar. I could see a couple of options. Either we re-use LanguagePrep_.py and call a different function in the module, or we call the same function and provide a flag (or more likely a msgdata entry) that tells the module which direction to do the conversion. Or we use two separate modules, something like LangPrepOutgoing_.py and LangPrepArchiving_.py. I'm not sure what the best solution is because I don't know how much can be shared between EUC->ISO-2022-JP and ISO-2022-JP->EUC. Please let me know if you think this will help solve the problem. -Barry From liuk@publinet.it Sat Sep 8 13:12:50 2001 From: liuk@publinet.it (Luca Maranzano) Date: Sat, 8 Sep 2001 14:12:50 +0200 Subject: [Mailman-Developers] Wrong file perms (0666) for data/qrunner.pid ? Message-ID: <20010908141250.A18525@publinet.it> Hi, I've noticed that the file data/qrunner.pid is created with perms 666 and IMVHO this my not be a Good Thing, especially because parent directory is world readable in my setup (all stuff in /home/mailman). I think that the problem is in bin/mailmanctl, my be the os.umask(0) at line 230 of mailmanctl ? Regards, Luca From liuk@publinet.it Sat Sep 8 13:37:56 2001 From: liuk@publinet.it (Luca Maranzano) Date: Sat, 8 Sep 2001 14:37:56 +0200 Subject: 2 "Uncaught runner exception" [was: Re: [Mailman-Developers] MM 2.1a2: bug if dont_respond_to_post_requests=N -> lang is undefined] In-Reply-To: <15247.41712.623906.586729@anthem.wooz.org> References: <20010830193532.A436@publinet.it> <15247.8651.802863.798688@anthem.wooz.org> <20010831135504.A10140@publinet.it> <15247.41712.623906.586729@anthem.wooz.org> Message-ID: <20010908143756.B18525@publinet.it> On Fri, Aug 31, 2001 at 10:45:04AM -0400, Barry A. Warsaw wrote: > > LM> Now my question is: can I simply issue a "configure && make > LM> install" in the CVS tree or there are some other action that I > LM> must consider? :) > > Depends on whether you're upgrading an existing site or testing it out > in a separate installation (which I recommend for now). If the > latter, then yup that should do it. If you're upgrading over an > existing site, then read the instructions in the UPGRADING manual. > Part of "testing it out" is also testing that upgrading is as painless > (or as documented ) as possible. I've upgraded from 2.0.5 to 2.1a2 since I read on the Web site that this was the (literally from http://www.list.org/MM21/index.html) "current stable GNU release". Only after the upgrade I digged into the list archives of mailman and I discovered that version 2.1 is still in alpha stage :-/ Ok, no matter, I like to live on the bleeding edge :) (I hope my users of the lists like too ;-) so I've decided to go on with CVS and to help as far as I can in this testing phase. I'm running a site with about 10 lists, all low traffic except one with ~500 subscribers and a traffic of some messages a day. This morning I came back from one week on holyday and since the bug about dont_respond_to_post_requests has created some troubles, I've updated to 2.1a3 of the latest CVS tree (updated just this morning). BTW, the upgrade seemed painless :). But I've to report this traceback from logs/error, that showed up some time after I restarted mailmanctl: [This happened 1 time only] Sep 08 11:14:09 2001 (17075) Uncaught runner exception: EOF read where object expected Sep 08 11:14:09 2001 (17075) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 104, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 152, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 111, in _dispose status = self._dopipeline(mlist, msg, msgdata, pipeline) File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 134, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/home/mailman/Mailman/Handlers/Hold.py", line 159, in process hold_for_approval(mlist, msg, msgdata, NonMemberPost) File "/home/mailman/Mailman/Handlers/Hold.py", line 234, in hold_for_approval id = mlist.HoldMessage(msg, reason, msgdata) File "/home/mailman/Mailman/ListAdmin.py", line 176, in HoldMessage self.__opendb() File "/home/mailman/Mailman/ListAdmin.py", line 77, in __opendb self.__db = marshal.load(fp) EOFError: EOF read where object expected While this is repeated several times (~10): Sep 08 13:09:59 2001 (17080) Uncaught runner exception: 'None' object has no attribute 'startswith' Sep 08 13:09:59 2001 (17080) Traceback (most recent call last): File "/home/mailman/Mailman/Queue/Runner.py", line 104, in __oneloop self.__onefile(msg, msgdata) File "/home/mailman/Mailman/Queue/Runner.py", line 152, in __onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/home/mailman/Mailman/Queue/CommandRunner.py", line 99, in _dispose if mlist.bounce_processing and \ File "/home/mailman/Mailman/Bouncers/BouncerAPI.py", line 63, in ScanMessages addrs = sys.modules[modname].process(msg) File "/home/mailman/Mailman/Bouncers/SMTP32.py", line 48, in process if not mailer.startswith('From the logs I can say that mailmanctl has prcessed some pending requests, but I don't know how to trace down the problem. Let me know if you need other info. My be sooner or later I'll be able also to submit some patch ;-) for the moment I can only report problems as soon as they happen. Thanks for your attention. Regards, Luca From ricardo@rixhq.nu Sat Sep 8 16:21:04 2001 From: ricardo@rixhq.nu (Ricardo F. Kustner) Date: Sat, 8 Sep 2001 17:21:04 +0200 Subject: [Mailman-Developers] 2.1 = alpha In-Reply-To: <20010908143756.B18525@publinet.it> References: <20010830193532.A436@publinet.it> <15247.8651.802863.798688@anthem.wooz.org> <20010831135504.A10140@publinet.it> <15247.41712.623906.586729@anthem.wooz.org> <20010908143756.B18525@publinet.it> Message-ID: <20010908172104.01b740b7.ricardo@rixhq.nu> On Sat, 8 Sep 2001 14:37:56 +0200 Luca Maranzano wrote: > I've upgraded from 2.0.5 to 2.1a2 since I read on the Web site that > this was the (literally from http://www.list.org/MM21/index.html) > "current stable GNU release". I also noticed alot of new mailman users start with 2.1a instead of going for 2.0.6 ... maybe this isn't advertised strongely enough? I'd hate to see losing new users because they think it isn't stable enough. -- Regards, Ricardo From barry@zope.com Sun Sep 9 08:57:25 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 9 Sep 2001 03:57:25 -0400 Subject: [Mailman-Developers] 2.1 = alpha References: <20010830193532.A436@publinet.it> <15247.8651.802863.798688@anthem.wooz.org> <20010831135504.A10140@publinet.it> <15247.41712.623906.586729@anthem.wooz.org> <20010908143756.B18525@publinet.it> <20010908172104.01b740b7.ricardo@rixhq.nu> Message-ID: <15259.8421.60892.441509@anthem.wooz.org> >>>>> "RFK" == Ricardo F Kustner writes: >> I've upgraded from 2.0.5 to 2.1a2 since I read on the Web site >> that this was the (literally from >> http://www.list.org/MM21/index.html) "current stable GNU >> release". RFK> I also noticed alot of new mailman users start with 2.1a RFK> instead of going for 2.0.6 ... maybe this isn't advertised RFK> strongely enough? I'd hate to see losing new users because RFK> they think it isn't stable enough. Good point! I'll update the index.html for the 2.1 pages. Thanks, -Barry From liuk@publinet.it Sun Sep 9 11:46:54 2001 From: liuk@publinet.it (Luca Maranzano) Date: Sun, 9 Sep 2001 12:46:54 +0200 Subject: [Mailman-Developers] MM-2.1a3: Errors from cron/checkdbs Message-ID: <20010909124654.B25743@publinet.it> Hi, after upgrading from 2.1a2 to 2.1a3 (latest CVS) now I'm getting this message from cron. I've tryed a "check_db -a" to see if this could be a problem related to db corruption but all databases seem fine. Is there a way to see which mailing list is being processed when the error occurs? Regards, Luca ----- Forwarded message from Cron Daemon ----- Date: Sat, 8 Sep 2001 17:00:02 +0200 From: root (Cron Daemon) Subject: Cron /usr/bin/python2 -S /home/mailman/cron/checkdbs To: mailman@XXXXXXXXXXXXXXXXX Traceback (most recent call last): File "/home/mailman/cron/checkdbs", line 104, in ? main() File "/home/mailman/cron/checkdbs", line 52, in main count = mlist.NumRequestsPending() File "/home/mailman/Mailman/ListAdmin.py", line 123, in NumRequestsPending self.__opendb() File "/home/mailman/Mailman/ListAdmin.py", line 77, in __opendb self.__db = marshal.load(fp) EOFError: EOF read where object expected ----- End forwarded message ----- From barry@zope.com Mon Sep 10 03:40:00 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 9 Sep 2001 22:40:00 -0400 Subject: 2 "Uncaught runner exception" [was: Re: [Mailman-Developers] MM 2.1a2: bug if dont_respond_to_post_requests=N -> lang is undefined] References: <20010830193532.A436@publinet.it> <15247.8651.802863.798688@anthem.wooz.org> <20010831135504.A10140@publinet.it> <15247.41712.623906.586729@anthem.wooz.org> <20010908143756.B18525@publinet.it> Message-ID: <15260.10240.132935.69971@anthem.wooz.org> >>>>> "LM" == Luca Maranzano writes: LM> But I've to report this traceback from logs/error, that showed LM> up some time after I restarted mailmanctl: LM> [This happened 1 time only] Sep 08 11:14:09 2001 (17075) LM> Uncaught runner exception: EOF read where object expected Sep LM> 08 11:14:09 2001 (17075) Traceback (most recent call last): LM> File "/home/mailman/Mailman/Queue/Runner.py", line 104, in LM> __oneloop self.__onefile(msg, msgdata) File LM> "/home/mailman/Mailman/Queue/Runner.py", line 152, in LM> __onefile keepqueued = self._dispose(mlist, msg, msgdata) File LM> "/home/mailman/Mailman/Queue/IncomingRunner.py", line 111, in LM> _dispose status = self._dopipeline(mlist, msg, msgdata, LM> pipeline) File LM> "/home/mailman/Mailman/Queue/IncomingRunner.py", line 134, in LM> _dopipeline sys.modules[modname].process(mlist, msg, msgdata) LM> File "/home/mailman/Mailman/Handlers/Hold.py", line 159, in LM> process hold_for_approval(mlist, msg, msgdata, NonMemberPost) LM> File "/home/mailman/Mailman/Handlers/Hold.py", line 234, in LM> hold_for_approval id = mlist.HoldMessage(msg, reason, msgdata) LM> File "/home/mailman/Mailman/ListAdmin.py", line 176, in LM> HoldMessage self.__opendb() File LM> "/home/mailman/Mailman/ListAdmin.py", line 77, in __opendb LM> self.__db = marshal.load(fp) LM> EOFError: EOF read where object expected Can you send me your list's request.db file? -Barry From barry@zope.com Mon Sep 10 05:59:01 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 10 Sep 2001 00:59:01 -0400 Subject: [Mailman-Developers] Help needed from Qmail users! Message-ID: <15260.18581.69529.589811@anthem.wooz.org> Could someone who uses Qmail and understands README.QMAIL and contrib/qmail-to-mailman.py, please take a look at SF bug #456080 and let me know what the Right Thing To Do is? http://sourceforge.net/tracker/index.php?func=detail&aid=456080&group_id=103&atid=100103 Thanks, -Barry From ricardo@rixhq.nu Mon Sep 10 06:15:55 2001 From: ricardo@rixhq.nu (Ricardo F. Kustner) Date: Mon, 10 Sep 2001 07:15:55 +0200 Subject: [Mailman-Developers] Help needed from Qmail users! In-Reply-To: <15260.18581.69529.589811@anthem.wooz.org> References: <15260.18581.69529.589811@anthem.wooz.org> Message-ID: <20010910071555.6cf22f7f.ricardo@rixhq.nu> On Mon, 10 Sep 2001 00:59:01 -0400 barry@zope.com (Barry A. Warsaw) wrote: > Could someone who uses Qmail and understands README.QMAIL and > contrib/qmail-to-mailman.py, please take a look at SF bug #456080 and > let me know what the Right Thing To Do is? I posted a short comment... hope it helps! -- Regards, Ricardo From Tim Constable" 9/10/2001 EMAIL PROCESSING COMPANY LOOKING FOR EMAIL PROCESSORS IMMEDIATELY, TO SUSTAIN EXPLOSIVE GROWTH. EARN $2,000-$6,000 (PART-TIME) AND $5,000-$10,000 (FULL TIME) MONTHLY. FREE START-UP, NOT MLM, NO EXPERIENCE NECESSARY. SEND AN EMAIL TO da_man_21@lycos.com WITH SUBJECT: "SHOW ME".WE WANT SERIOUS INQUIRIES FROM PEOPLE WHO WANT TO MAKE SERIOUS MONEY! Tim C. - Web Direct From liuk@publinet.it Mon Sep 10 17:08:56 2001 From: liuk@publinet.it (Luca Maranzano) Date: Mon, 10 Sep 2001 18:08:56 +0200 Subject: [Mailman-Developers] Re: MM-2.1a3: Errors from cron/checkdbs: *** SOLVED *** In-Reply-To: <20010909124654.B25743@publinet.it> References: <20010909124654.B25743@publinet.it> Message-ID: <20010910180856.A4387@publinet.it> Hi, it seems that the problem was due to a request.db file of a list which was very huge and possibly corrupted. After removing this file the error disappeared :-). --Luca On Sun, Sep 09, 2001 at 12:46:54PM +0200, Luca Maranzano wrote: > Hi, > > after upgrading from 2.1a2 to 2.1a3 (latest CVS) now I'm getting this message > from cron. > > I've tryed a "check_db -a" to see if this could be a problem related > to db corruption but all databases seem fine. > > Is there a way to see which mailing list is being processed when the > error occurs? > > Regards, > Luca > > ----- Forwarded message from Cron Daemon ----- > > Date: Sat, 8 Sep 2001 17:00:02 +0200 > From: root (Cron Daemon) > Subject: Cron /usr/bin/python2 -S /home/mailman/cron/checkdbs > To: mailman@XXXXXXXXXXXXXXXXX > > Traceback (most recent call last): > File "/home/mailman/cron/checkdbs", line 104, in ? > main() > File "/home/mailman/cron/checkdbs", line 52, in main > count = mlist.NumRequestsPending() > File "/home/mailman/Mailman/ListAdmin.py", line 123, in NumRequestsPending > self.__opendb() > File "/home/mailman/Mailman/ListAdmin.py", line 77, in __opendb > self.__db = marshal.load(fp) > EOFError: EOF read where object expected > > ----- End forwarded message ----- > > _______________________________________________ > Mailman-Developers mailing list > Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers From liuk@publinet.it Mon Sep 10 17:22:45 2001 From: liuk@publinet.it (Luca Maranzano) Date: Mon, 10 Sep 2001 18:22:45 +0200 Subject: [Mailman-Developers] Typo in misc/mailman Message-ID: <20010910182245.A4537@publinet.it> Hi, there is a typo in the file misc/mailman of the latest CVS, in the "restart" section there is $MAIMLANCTL instead of $MAILMANCTL :). --Luca From alaric@babcom.com Mon Sep 10 17:40:57 2001 From: alaric@babcom.com (Phil Stracchino) Date: Mon, 10 Sep 2001 09:40:57 -0700 Subject: [Mailman-Developers] Typo in misc/mailman In-Reply-To: <20010910182245.A4537@publinet.it>; from liuk@publinet.it on Mon, Sep 10, 2001 at 06:22:45PM +0200 References: <20010910182245.A4537@publinet.it> Message-ID: <20010910094057.A23298@babylon5.babcom.com> On Mon, Sep 10, 2001 at 06:22:45PM +0200, Luca Maranzano wrote: > Hi, > > there is a typo in the file misc/mailman of the latest CVS, in the "restart" > section there is $MAIMLANCTL instead of $MAILMANCTL :). MAIMLANCTL ..... would that be the control that automatically installs Windows XP on all of your nameservers? :) -- Linux Now! .........Because friends don't let friends use Microsoft. phil stracchino :: alaric@babcom.com :: halmayne@sourceforge.net the renaissance man ::: mystic zen biker geek ::: unix ronin 2000 CBR929RR, 1991 VFR750F3 (foully murdered), 1986 VF500F (sold) From jason-dated-1000850032.3b54e5@mastaler.com Mon Sep 10 22:53:51 2001 From: jason-dated-1000850032.3b54e5@mastaler.com (Jason R. Mastaler) Date: Mon, 10 Sep 2001 15:53:51 -0600 Subject: [Mailman-Developers] Help needed from Qmail users! In-Reply-To: <20010910071555.6cf22f7f.ricardo@rixhq.nu> ("Ricardo F. Kustner"'s message of "Mon, 10 Sep 2001 07:15:55 +0200") References: <15260.18581.69529.589811@anthem.wooz.org> <20010910071555.6cf22f7f.ricardo@rixhq.nu> Message-ID: On Mon, 10 Sep 2001, Ricardo F. Kustner wrote: > I posted a short comment... hope it helps! FWIW, I agree with your short comment. In fact, I actually had problems after I started using "preline" before calling "wrapper" as the FAQ recommended. My Mailman list archives were being populated by lots of empty messages that looked like this: From: bogus@does.not.exist.com () Date: Mon Apr 30 11:55:01 2001 Subject: No subject Removing `preline' fixed the problem. -- (TMDA - http://tmda.sourceforge.net) (Python-based SPAM reduction system) From marc_news@valinux.com Tue Sep 11 01:48:12 2001 From: marc_news@valinux.com (Marc MERLIN) Date: Mon, 10 Sep 2001 17:48:12 -0700 Subject: [Mailman-Developers] Mailman 500 error when some users access web pages. Message-ID: <20010910174731.F5600@magic.merlins.org> So, Sourceforge has been plagued by reports of users saying that they were getting sporadic 500 errors when accessing mailman admin pages. I think I just found one reason if not _the_ reason: --------------------------------------------------------------------------- > My Sourceforge.net Cookie was > > .sourceforge.net TRUE / FALSE 1000695393 username > gQdb8WNeEUc%3D Aaaaahhhhh, I think I get it. sourceforge.net (the web site) gives you a .sourceforge.net cookie. When you hit lists.sourceforge.net, your browser sends the cookie and mailman freaks out because it can't decode the cookie (it's not a mailman cookie, it's a SF cookie) At least, that's my guess. --------------------------------------------------------------------------- Does that make sense? (apparently, for whatever weird reason, it mostly happens with mozilla) If so, is it easy to fix mailman to be more robust and ignore bad cookies? Thanks, Marc -- Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key From che@debian.org Tue Sep 11 03:37:42 2001 From: che@debian.org (Ben Gertzfield) Date: Tue, 11 Sep 2001 11:37:42 +0900 Subject: [Mailman-Developers] Mailman CVS sends out Japanese template mails in EUC-JP In-Reply-To: <15257.40563.81479.94746@anthem.wooz.org> (barry@zope.com's message of "Sat, 8 Sep 2001 00:28:35 -0400") References: <877kvbk8xb.fsf@nausicaa.interq.or.jp> <87pu93ijqq.fsf@nausicaa.interq.or.jp> <15257.40563.81479.94746@anthem.wooz.org> Message-ID: <87sndusb9l.fsf@nausicaa.interq.or.jp> >>>>> "BAW" == Barry A Warsaw writes: >>>>> "BG" == Ben Gertzfield writes: BG> How should we approach modifying the virgin queue? I can hack BG> in conversion to ISO-2022-JP and adding the headers, but that BG> seems wrong somehow. Maybe have each language supply its own BG> special "incoming mail charset conversion", "outgoing mail BG> charset conversion", and "header additions" modules? I know BG> Japanese needs to convert incoming mails to EUC before they're BG> archived, and back to ISO-2022-JP when they go back out to the BG> list. BAW> We only have this problem for messages that Mailman BAW> generates, right? IOW, for messages sent to the list by BAW> members, we're adhering to least-munging principles, so if BAW> someone sends a message to the list all bolluxed up, tough BAW> luck. Unfortunately, it's not that simple. All the Japanese web pages for Mailman are in the 8-bit EUC-JP encoding, which is right and proper. However, when mail comes in to a list, we need to convert it from the 7-bit ISO-2022-JP encoding format to EUC-JP before we archive it. Otherwise, the archive web pages will have the static bits in EUC-JP, and the email contents in ISO-2022-JP! This is a mess. Also, we need to deal with de-MIMEifying the headers before they get archived, or the Subject/To/From/etc. lines will be completely unreadable Base-64 in the archives. The kconv Python module, available at http://tomigaya.shibuya.tokyo.jp/~mak/kconv/index.html , will handle the ISO-2022-JP <-> EUC-JP conversion. There's a pure Python version, so I think we should bundle it. (It would suck to make ANOTHER module required to download separately.) Here are a few possible solutions. We need to apply these both to virgin-birth messages and to incoming/outgoing list messages. 1) Store all Japanese web pages and templates as ISO-2022-JP. This is somewhat less than optimal; while it totally removes the archiving problem from the picture, many web browsers have a hard time auto-detecting ISO-2022-JP. Also, 7-bit encoding may make the headers and web pages slightly bigger (not that big of a deal). Finally, there are some half-width characters that I believe are not legal in ISO-2022-JP, so there are some things we would not be able to store in the web pages and templates. This solution does not deal at all with the Content-Type issue (we need to add the charset=iso-2022-jp flag), nor does it deal with other languages, which have similar issues. 2) Add a set of Handlers/{lang}/ subdirectories, with Incoming.py and Outgoing.py modules in each of them. The Incoming module (if it existed for the lang) would do all the munging necessary to make a message suitable for archiving. This includes de-MIMEifying the headers if needed; they'll come in base-64 or printed-quotable for various languages. I believe mimelib will deal with this. The Outgoing module would convert the message back to the outgoing 7-bit charset, as well as base-64 encode the headers if needed. Also, it would need to add a Content-Type: text/plain; charset=foo header. Problems: We can't blindly convert the entire message from one charset to another and expect things like MIME attachments to stay sane. MIME will have to be handled carefully; what happens to a message that has multiple text/plain; sections with different charsets? *shudder* We also can't blindly add the Content-Type header, unless we're positive we know what charset the message came in with. Final problem: Unicode. M$ Outlook sends email in UTF-8 by default. The kconv module will deal with this, but we need to be aware that people *are* sending email encoded with this format. If we wanted to be extra studly, we could offer the option to automatically convert from UTF-8 to ISO-2022-JP, but this conversion is hardly a bijection, so if a user used multiple languages in one message, they're SOL. Also, this will fully screw up PGP signatures, but I doubt any Outlook users are using PGP. *grin* Solution: The proper thing to do is to break each message up into its constituent MIME sections and munge each one on its own, dealing with whatever charset each section says it is, if it's text/*. There isn't a framework for this yet via the Handlers method, as far as I know. So we'll have to come up with one. I like the 2) solution a lot more, but it's going to take a lot of work. But we really can't ship MM2.1 with half-assed language support; it's awesome that we localized the web pages, but people will go off their rockers when things like Base64'd Subject/From lines don't work, and the welcome mails go out in an unreadable format. I'm going to start working on 2) now. I'll send in a prototype patch soon. Ben -- Brought to you by the letters T and J and the number 18. "A yonker is a young man." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From barry@zope.com Tue Sep 11 03:54:04 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 10 Sep 2001 22:54:04 -0400 Subject: [Mailman-Developers] Mailman CVS sends out Japanese template mails in EUC-JP References: <877kvbk8xb.fsf@nausicaa.interq.or.jp> <87pu93ijqq.fsf@nausicaa.interq.or.jp> <15257.40563.81479.94746@anthem.wooz.org> <87sndusb9l.fsf@nausicaa.interq.or.jp> Message-ID: <15261.31948.721484.994371@anthem.wooz.org> >>>>> "BG" == Ben Gertzfield writes: BG> However, when mail comes in to a list, we need to convert it BG> from the 7-bit ISO-2022-JP encoding format to EUC-JP before we BG> archive it. Otherwise, the archive web pages will have the BG> static bits in EUC-JP, and the email contents in ISO-2022-JP! BG> This is a mess. I really want to keep the archiver separate from the list exploder, although I may be missing something which prevents this. The reason I say this is because sites can drop in their own archivers (and probably should/do for high volume sites, since Pipermail has its own share of problems). So any solution for Mailman has to take into account a custom archiver that Does The Right Thing and completely bypasses Pipermail. In fact, I can imagine a site implementing a custom ArchRunner, where our Handler/ToArchive.py drops the message into qfiles/arch and from there Mailman might never touch that copy of the message again. Here's the scenario: APerson sends a message to a Japanese list. It shows up as ISO-2022-JP. We do the normal IncomingRunner processing on it and drop a copy into qfiles/out. OutgoingRunner picks up that copy and sends it to the list membership. That message will also be in ISO-2022-JP, right? Or will it need to be converted to EUC-JP? I think/hope the answer is that it will go out to the list membership in ISO-2022-JP. What I meant by the "tough luck" comment earlier was that if someone posts a message to a Japanese list, say in Russian/koi8-r, well, we just send it on to the list membership in that same encoding. So for messages traveling the poster->Mailman->list membership route, we don't need to convert encodings, right? I may be missing something, but it seems that nothing you've said so far contradicts this. If I'm wrong, please correct me here before we talk about the archiver. I think I understand the issues involved there, but I want to make sure I understand this part first. For right now, let's keep the archiver out of the picture. Thanks! -Barry From che@debian.org Tue Sep 11 03:57:56 2001 From: che@debian.org (Ben Gertzfield) Date: Tue, 11 Sep 2001 11:57:56 +0900 Subject: [Mailman-Developers] Mailman CVS sends out Japanese template mails in EUC-JP In-Reply-To: <87sndusb9l.fsf@nausicaa.interq.or.jp> (Ben Gertzfield's message of "Tue, 11 Sep 2001 11:37:42 +0900") References: <877kvbk8xb.fsf@nausicaa.interq.or.jp> <87pu93ijqq.fsf@nausicaa.interq.or.jp> <15257.40563.81479.94746@anthem.wooz.org> <87sndusb9l.fsf@nausicaa.interq.or.jp> Message-ID: <87k7z6sabv.fsf@nausicaa.interq.or.jp> More thoughts on the i18n mail issues. Currently, this is the sequence of the default pipeline for the Handlers. GLOBAL_PIPELINE = [ 'SpamDetect', 'Approve', 'Replybot', 'Hold', 'Tagger', 'CalcRecips', 'Cleanse', 'CookHeaders', 'ToDigest', 'ToArchive', 'Personalize', 'Decorate', 'AfterDelivery', 'Acknowledge', 'ToUsenet', 'ToOutgoing', ] I'm not sure if we can add an "IncomingLang" at the beginning and an "OutgoingLang" at the end that just deal with conversion to an archivable format, then to a mailable format at the end, but that'd be the best thing to do. The problem is, for Japanese, we need to convert the mails to EUC-JP before they go to SpamDetect/Approve/Hold/etc., or else they won't even be readable in the admin's web interface! But if they're converted to EUC-JP before the ToDigest step, will there be any chance to convert them back to ISO-2022-JP when the digest is sent out? How do we deal with this on a per-message basis, if not all the mails are in EUC-JP? I tried to grok to code in ToDigest.py, which seems mostly internationalized, but it doesn't seem to do anything but add the payload of each message to the digest: for msg in messages: # MIME mimedigest.add_payload(msg) # rfc1153 if first: first = 0 else: print >> plainmsg, separator30 print >> plainmsg g = Generator(plainmsg) g.write(msg, unixfrom=0) # Now add the footer Will msg here always be a Message object? If so, it shouldn't be too hard to run it through the appropriate {lang}/Outgoing.py language converter manually before we add it to the mimedigest. Ben -- Brought to you by the letters M and O and the number 2. "A squib is a firecracker." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From che@debian.org Tue Sep 11 04:07:18 2001 From: che@debian.org (Ben Gertzfield) Date: Tue, 11 Sep 2001 12:07:18 +0900 Subject: [Mailman-Developers] Mailman CVS sends out Japanese template mails in EUC-JP In-Reply-To: <15261.31948.721484.994371@anthem.wooz.org> (barry@zope.com's message of "Mon, 10 Sep 2001 22:54:04 -0400") References: <877kvbk8xb.fsf@nausicaa.interq.or.jp> <87pu93ijqq.fsf@nausicaa.interq.or.jp> <15257.40563.81479.94746@anthem.wooz.org> <87sndusb9l.fsf@nausicaa.interq.or.jp> <15261.31948.721484.994371@anthem.wooz.org> Message-ID: <87bskis9w9.fsf@nausicaa.interq.or.jp> >>>>> "BAW" == Barry A Warsaw writes: >>>>> "BG" == Ben Gertzfield writes: BG> However, when mail comes in to a list, we need to convert it BG> from the 7-bit ISO-2022-JP encoding format to EUC-JP before we BG> archive it. Otherwise, the archive web pages will have the BG> static bits in EUC-JP, and the email contents in ISO-2022-JP! BG> This is a mess. BAW> I really want to keep the archiver separate from the list BAW> exploder, although I may be missing something which prevents BAW> this. BAW> So for messages traveling the poster->Mailman->list BAW> membership route, we don't need to convert encodings, right? It's not just the archiver that needs to have the message in EUC-JP, but also the admin pages; the messages will be unreadable to the admin who's trying to approve messages or filter spam if half the web page is in EUC-JP and the rest is ISO-2022-JP! It's unfortunate, but we're just going to have to do an incoming conversion to make the incoming emails match whatever encoding the web pages use. UTF-8 makes this even worse, of course, as more and more mail readers start to use it, approving messages/filtering spam will become impossible unless we convert it to whatever charset the admin web pages happen to be in. Ben -- Brought to you by the letters I and G and the number 17. "You forgot Uranus." "Goooooooooodnight everybody!" Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From chuqui@plaidworks.com Tue Sep 11 04:30:43 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Mon, 10 Sep 2001 20:30:43 -0700 Subject: [Mailman-Developers] Mailman 500 error when some users access web pages. In-Reply-To: <20010910174731.F5600@magic.merlins.org> Message-ID: On 9/10/01 5:48 PM, "Marc MERLIN" wrote: > So, Sourceforge has been plagued by reports of users saying that they were > getting sporadic 500 errors when accessing mailman admin pages. You know, I've been seeing something similar. I thought it was mod_layout interacting in some way, and haven't bothered to go looking for it yet.... -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. You know, I Remember When I Used To Speak In Capitals, Too. It's addictive. It also encourages people to poke sticks at you. Justifiably. (chuq, 1992) From che@debian.org Tue Sep 11 09:40:06 2001 From: che@debian.org (Ben Gertzfield) Date: Tue, 11 Sep 2001 17:40:06 +0900 Subject: [Mailman-Developers] Mailman CVS sends out Japanese template mails in EUC-JP In-Reply-To: <15261.31948.721484.994371@anthem.wooz.org> (barry@zope.com's message of "Mon, 10 Sep 2001 22:54:04 -0400") References: <877kvbk8xb.fsf@nausicaa.interq.or.jp> <87pu93ijqq.fsf@nausicaa.interq.or.jp> <15257.40563.81479.94746@anthem.wooz.org> <87sndusb9l.fsf@nausicaa.interq.or.jp> <15261.31948.721484.994371@anthem.wooz.org> Message-ID: <87sndup1cp.fsf@nausicaa.interq.or.jp> I've come to the same understanding as Barry as far as this language stuff goes. We can actually do this without changing the message's encoding right when a message comes in. The only times when a message is displayed via the web are when it needs approval for some reason or another, or from HyperArch. So, we need to change Cgi/admindb.py to properly Web-ify the headers and body; currently it displays the message verbatim, which is fine unless you use a charset that must be quoted-printable or base64 encoded in the headers -- or if your message charset doesn't match your web charset. Next, we need to change pipermail and/or HyperArch to check if the charset in the decoded subject/author headers is iso-2022-jp; if so, we need to use kconv to convert it to EUC-JP. Similarly, we need to check the body, even if it's multi-part, and convert to EUC-JP the parts that are iso-2022-jp. Looking around, I found the very useful EncWord.py module, which for some strange reason was in Mailman, not in mimelib. It was probably written before mimelib was, but the functionality should certainly be moved there, as it's part of the MIME standard and will be needed for anyone doing mail outside the English world. Barry, will you think about moving EncWord into mimelib? It'd be much more at home there. :) It could be moved whole-hog, and the only thing that would need a s/Mailman.EncWord/mimelib.EncWord/ would be Archivers/HyperArch.py, as far as I can see. Here's a patch to add a new function to mimelib.Message. It returns the charsets of each of the text/* parts in a message, and None for each part that is not text or does not have a charset. This will make converting the iso-2022-jp parts much easier. This patch is against mimelib CVS. Index: Message.py =================================================================== RCS file: /cvsroot/mimelib/mimelib/mimelib/Message.py,v retrieving revision 1.13 diff -u -r1.13 Message.py --- Message.py 2001/05/04 18:47:22 1.13 +++ Message.py 2001/09/11 08:37:28 @@ -272,3 +272,31 @@ if name.lower() == param: return address.unquote(val) return failobj + + def getcharsets(self, default=None): + """Return an array containing the charset[s] used in a message. + + Returns an array containing one element for each part of the + message; will return an array of one element if the message is not + a multipart message. + + Each element will either be a string (the charset in the + Content-Type of that part) or the value of the 'default' + parameter (defaults to None), if the part is not a text part + or the charset is not defined. + """ + result = [] + + if self.ismultipart(): + for p in self.get_payload(): + if p.getmaintype() == "text": + result.append(p.getparam("charset")) + else: + result.append(default) + else: + if self.getmaintype() == "text": + result.append(self.getparam("charset")) + else: + result.append(default) + + return result -- Brought to you by the letters S and T and the number 17. "A baloo is a bear." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From tkikuchi@is.kochi-u.ac.jp Tue Sep 11 13:05:19 2001 From: tkikuchi@is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue, 11 Sep 2001 21:05:19 +0900 Subject: [Mailman-Developers] Mailman CVS sends out Japanese templatemails in EUC-JP References: <877kvbk8xb.fsf@nausicaa.interq.or.jp> <87pu93ijqq.fsf@nausicaa.interq.or.jp> <15257.40563.81479.94746@anthem.wooz.org> <87sndusb9l.fsf@nausicaa.interq.or.jp> <15261.31948.721484.994371@anthem.wooz.org> <87sndup1cp.fsf@nausicaa.interq.or.jp> Message-ID: <3B9DFDFF.93A264C9@is.kochi-u.ac.jp> Barry, Ben, Sorry I am late in responding your discussion. (I am busy since 'they' are back to school. ;-) Japanese (and may be other language) encoding glitch arise in 1. Archiving and displaying messages in Web Pages. 2. Moderation interfacing and 3. Message body munging like adding header and footer. All in all, my experience with good old Majordomo and Mailman 2.0 tells me that it is safe to convert the mail message when it comes in and use only one code (EUC-JP) to process it. And, convert to the conventional code (ISO-2022-JP) when the message is going out. There may be many occasions when you want to add new feature in the internal processing but it is no good if you always have to think aout the code. EUC-JP is safe in using HTML when you must escape < and > because all the double-byte characters are 8th bit set. Perhaps we should collect more discussion from other language users for converting other languages. I think we can put i18n of the message handling off to the 2.2 or later. Until then, separate contributing patches from several language user may be sufficent. > Here's a patch to add a new function to mimelib.Message. It returns > the charsets of each of the text/* parts in a message, and None for > each part that is not text or does not have a charset. This will make > converting the iso-2022-jp parts much easier. Ben, my Japanese patch worked at least for my environment. Internal crafted messages are converted to ISO-2022-JP using the last-week CVS. We should look at it more carefully, I think. And, thanks for your suggestion to use mimelib for code-finding. I will look at it when I have time. -- Tokio From liuk@publinet.it Tue Sep 11 14:11:16 2001 From: liuk@publinet.it (Luca Maranzano) Date: Tue, 11 Sep 2001 15:11:16 +0200 Subject: [Mailman-Developers] 2 Bouncer exceptions Message-ID: <20010911151116.A14924@publinet.it> Hi, here again with an error report, from logs/error 2 distinct errors: ========= Sep 11 13:10:48 2001 (8707) Bouncer exception: 'None' object has no attribute 'lower' Sep 11 13:10:48 2001 (8707) Traceback (most recent call last): File "/home/mailman/Mailman/Bouncers/BouncerAPI.py", line 71, in ScanMessages mlist.RegisterBounce(addr, msg) File "/home/mailman/Mailman/Bouncer.py", line 93, in RegisterBounce this_dude = Utils.FindMatchingAddresses(email, self.bounce_info) File "/home/mailman/Mailman/Utils.py", line 298, in FindMatchingAddresses p_matches = GetPossibleMatchingAddrs(name) File "/home/mailman/Mailman/Utils.py", line 262, in GetPossibleMatchingAddrs name = name.lower() AttributeError: 'None' object has no attribute 'lower' ========= Grepp'ing in the mail.info log file for the exact time I found an entry saying that the command it was executing was: "|/home/mailman/mail/wrapper mailowner listname" I'm not sure this may be correlated with the error, but I've no other clue :) =================== Sep 11 13:26:07 2001 (8707) Bouncer exception: not enough arguments; expected 1, got 0 Sep 11 13:26:07 2001 (8707) Traceback (most recent call last): File "/home/mailman/Mailman/Bouncers/BouncerAPI.py", line 71, in ScanMessages mlist.RegisterBounce(addr, msg) File "/home/mailman/Mailman/Bouncer.py", line 123, in RegisterBounce self.HandleBouncingAddress(addr, msg) File "/home/mailman/Mailman/Bouncer.py", line 214, in HandleBouncingAddress text = text + '\n\n--' + boundary + \ TypeError: not enough arguments; expected 1, got 0 =================== Instead for this error I've found something in the logs/bounce (listname and email address has been modified): Sep 11 13:26:07 2001 (8707) LISTNAME: XXXXXXX@tiscalinet.it - 2 more allowed over 345719 secs Sep 11 13:26:07 2001 (8707) LISTNAME: YYYYYYY@tiscalinet.it - exceeded limits Sep 11 13:26:07 2001 (8707) LISTNAME: disabled YYYYYYY@tiscalinet.it I'm using latest CVS, as always let me know if you need more infos! Hoping to be useful :) --Luca From che@debian.org Tue Sep 11 14:34:54 2001 From: che@debian.org (Ben Gertzfield) Date: Tue, 11 Sep 2001 22:34:54 +0900 Subject: [Mailman-Developers] Mailman CVS sends out Japanese templatemails in EUC-JP In-Reply-To: <3B9DFDFF.93A264C9@is.kochi-u.ac.jp> (Tokio Kikuchi's message of "Tue, 11 Sep 2001 21:05:19 +0900") References: <877kvbk8xb.fsf@nausicaa.interq.or.jp> <87pu93ijqq.fsf@nausicaa.interq.or.jp> <15257.40563.81479.94746@anthem.wooz.org> <87sndusb9l.fsf@nausicaa.interq.or.jp> <15261.31948.721484.994371@anthem.wooz.org> <87sndup1cp.fsf@nausicaa.interq.or.jp> <3B9DFDFF.93A264C9@is.kochi-u.ac.jp> Message-ID: <87k7z5u9z5.fsf@nausicaa.interq.or.jp> >>>>> "Tokio" == Tokio Kikuchi writes: Tokio> Ben, my Japanese patch worked at least for my Tokio> environment. Internal crafted messages are converted to Tokio> ISO-2022-JP using the last-week CVS. We should look at it Tokio> more carefully, I think. And, thanks for your suggestion Tokio> to use mimelib for code-finding. I will look at it when I Tokio> have time. Unfortunately, the patch and install documents are very out of date for current CVS.. there is a VirginQueue runner now that does not use the normal pipeline at all, so your patch will need to be re-written. This is why I am working to fix current CVS to work with Japanese without a separate patch. Ben -- Brought to you by the letters C and Q and the number 11. "Frungy! Frungy! Frungy!!" Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From rodolfo@linux.org.uy Tue Sep 11 17:53:56 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: Tue, 11 Sep 2001 13:53:56 -0300 Subject: [Mailman-Developers] Problem to gate_news Message-ID: <20010911135356.77990cc6.rodolfo@linux.org.uy> Since some minutes ago I am receiving these reports form the cron daemon: Traceback (most recent call last): File "/usr/lib/mailman/cron/gate_news", line 232, in ? main() File "/usr/lib/mailman/cron/gate_news", line 213, in main process_lists(lock) File "/usr/lib/mailman/cron/gate_news", line 147, in process_lists mlist = MailList.MailList(listname, lock=0) File "/usr/lib/mailman/Mailman/MailList.py", line 83, in __init__ self.Load() File "/usr/lib/mailman/Mailman/MailList.py", line 999, in Load raise Errors.MMCorruptListDatabaseError, e Mailman.Errors.MMCorruptListDatabaseError: bad marshal data It is ease to understand that the server do not route any list. :( Can you give me some idea to fix this problem? -- ____________________________________________________ -=(( Rodolfo Pilas - rodolfo@linux.org.uy ))=- -==((( Are you ready for XtraLinuX - http://xtralinux.org )))==- -=((____________________________________________________))=- Guarde sus mail en Echelon: OLP, Greenpeace, ETA, Hamas, Hizbullah, FMI Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 -- ____________________________________________________ -=(( Rodolfo Pilas - rodolfo@linux.org.uy ))=- -==((( Are you ready for XtraLinuX - http://xtralinux.org )))==- -=((____________________________________________________))=- Guarde sus mail en Echelon: OLP, Greenpeace, ETA, Hamas, Hizbullah, FMI Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From tkikuchi@is.kochi-u.ac.jp Tue Sep 11 22:02:41 2001 From: tkikuchi@is.kochi-u.ac.jp (Tokio Kikuchi) Date: Wed, 12 Sep 2001 06:02:41 +0900 Subject: [Mailman-Developers] Mailman CVS sends out Japanesetemplatemails in EUC-JP References: <877kvbk8xb.fsf@nausicaa.interq.or.jp> <87pu93ijqq.fsf@nausicaa.interq.or.jp> <15257.40563.81479.94746@anthem.wooz.org> <87sndusb9l.fsf@nausicaa.interq.or.jp> <15261.31948.721484.994371@anthem.wooz.org> <87sndup1cp.fsf@nausicaa.interq.or.jp> <3B9DFDFF.93A264C9@is.kochi-u.ac.jp> <87k7z5u9z5.fsf@nausicaa.interq.or.jp> Message-ID: <3B9E7BF1.D729C9BC@is.kochi-u.ac.jp> Ben Gertzfield wrote: > > >>>>> "Tokio" == Tokio Kikuchi writes: > > Tokio> Ben, my Japanese patch worked at least for my > Tokio> environment. Internal crafted messages are converted to > Tokio> ISO-2022-JP using the last-week CVS. We should look at it > Tokio> more carefully, I think. And, thanks for your suggestion > Tokio> to use mimelib for code-finding. I will look at it when I > Tokio> have time. > > Unfortunately, the patch and install documents are very out of > date for current CVS.. there is a VirginQueue runner now that > does not use the normal pipeline at all, so your patch will need > to be re-written. Well, I think I fixed it .... ??? That's why I put 'ja_To_ISO_2022_JP' within ja_SMTPDirect.py. Here is what you must set to work properly, I believe. > DEFAULT_SERVER_LANGUAGE = 'ja' > GLOBAL_PIPELINE = [ 'ja_To_EUC_JP', ] + GLOBAL_PIPELINE > DELIVERY_MODULE = 'ja_SMTPDirect' -- Tokio From rodolfo@linux.org.uy Tue Sep 11 23:38:05 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: Tue, 11 Sep 2001 19:38:05 -0300 Subject: Fw: [Mailman-Developers] Problem to gate_news REPEAT Message-ID: <20010911193805.774a2c59.rodolfo@linux.org.uy> Sorry to return about the same problem of my recent message, but I am with my MM without routing messages. Please, give me a bit help to fix this problem. Thank you, thank you. thank you. (I am using MM 2.1a2) Since some minutes ago I am receiving these reports form the cron daemon: Traceback (most recent call last): File "/usr/lib/mailman/cron/gate_news", line 232, in ? main() File "/usr/lib/mailman/cron/gate_news", line 213, in main process_lists(lock) File "/usr/lib/mailman/cron/gate_news", line 147, in process_lists mlist = MailList.MailList(listname, lock=0) File "/usr/lib/mailman/Mailman/MailList.py", line 83, in __init__ self.Load() File "/usr/lib/mailman/Mailman/MailList.py", line 999, in Load raise Errors.MMCorruptListDatabaseError, e Mailman.Errors.MMCorruptListDatabaseError: bad marshal data It is ease to understand that the server do not route any list. :( Can you give me some idea to fix this problem? -- ____________________________________________________ -=(( Rodolfo Pilas - rodolfo@linux.org.uy ))=- -==((( Are you ready for XtraLinuX - http://xtralinux.org )))==- -=((____________________________________________________))=- Guarde sus mail en Echelon: OLP, Greenpeace, ETA, Hamas, Hizbullah, FMI Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 -- ____________________________________________________ -=(( Rodolfo Pilas - rodolfo@linux.org.uy ))=- -==((( Are you ready for XtraLinuX - http://xtralinux.org )))==- -=((____________________________________________________))=- Guarde sus mail en Echelon: OLP, Greenpeace, ETA, Hamas, Hizbullah, FMI Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers -- ____________________________________________________ -=(( Rodolfo Pilas - rodolfo@linux.org.uy ))=- -==((( Are you ready for XtraLinuX - http://xtralinux.org )))==- -=((____________________________________________________))=- Guarde sus mail en Echelon: OLP, Greenpeace, ETA, Hamas, Hizbullah, FMI Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From che@debian.org Wed Sep 12 01:56:53 2001 From: che@debian.org (Ben Gertzfield) Date: Wed, 12 Sep 2001 09:56:53 +0900 Subject: [Mailman-Developers] Mailman CVS sends out Japanesetemplatemails in EUC-JP In-Reply-To: <3B9E7BF1.D729C9BC@is.kochi-u.ac.jp> (Tokio Kikuchi's message of "Wed, 12 Sep 2001 06:02:41 +0900") References: <877kvbk8xb.fsf@nausicaa.interq.or.jp> <87pu93ijqq.fsf@nausicaa.interq.or.jp> <15257.40563.81479.94746@anthem.wooz.org> <87sndusb9l.fsf@nausicaa.interq.or.jp> <15261.31948.721484.994371@anthem.wooz.org> <87sndup1cp.fsf@nausicaa.interq.or.jp> <3B9DFDFF.93A264C9@is.kochi-u.ac.jp> <87k7z5u9z5.fsf@nausicaa.interq.or.jp> <3B9E7BF1.D729C9BC@is.kochi-u.ac.jp> Message-ID: <87bskh9qga.fsf@nausicaa.interq.or.jp> >>>>> "Tokio" == Tokio Kikuchi writes: Tokio> Well, I think I fixed it .... ??? That's why I put Tokio> 'ja_To_ISO_2022_JP' within ja_SMTPDirect.py. Tokio> Here is what you must set to work properly, I believe. Tokio> DEFAULT_SERVER_LANGUAGE = 'ja' GLOBAL_PIPELINE = [ Tokio> 'ja_To_EUC_JP', ] + GLOBAL_PIPELINE DELIVERY_MODULE = Tokio> 'ja_SMTPDirect' I did this, and welcome mails are still mojibake.. Ben -- Brought to you by the letters V and W and the number 18. "Frungy! Frungy! Frungy!!" Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From tkikuchi@is.kochi-u.ac.jp Wed Sep 12 05:07:31 2001 From: tkikuchi@is.kochi-u.ac.jp (Tokio Kikuchi) Date: Wed, 12 Sep 2001 13:07:31 +0900 Subject: [Mailman-Developers] Mailman CVS sends outJapanesetemplatemails in EUC-JP References: <877kvbk8xb.fsf@nausicaa.interq.or.jp> <87pu93ijqq.fsf@nausicaa.interq.or.jp> <15257.40563.81479.94746@anthem.wooz.org> <87sndusb9l.fsf@nausicaa.interq.or.jp> <15261.31948.721484.994371@anthem.wooz.org> <87sndup1cp.fsf@nausicaa.interq.or.jp> <3B9DFDFF.93A264C9@is.kochi-u.ac.jp> <87k7z5u9z5.fsf@nausicaa.interq.or.jp> <3B9E7BF1.D729C9BC@is.kochi-u.ac.jp> <87bskh9qga.fsf@nausicaa.interq.or.jp> Message-ID: <3B9EDF83.173EC0D9@is.kochi-u.ac.jp> Ben Gertzfield wrote: > > I did this, and welcome mails are still mojibake.. Have you restart the qrunner by bin/mailmanctl stop bin/mailmanctl start I have not tried whether restart works or not, yet. -- Tokio From che@debian.org Wed Sep 12 06:32:12 2001 From: che@debian.org (Ben Gertzfield) Date: Wed, 12 Sep 2001 14:32:12 +0900 Subject: [Mailman-Developers] Mailman CVS sends outJapanesetemplatemails in EUC-JP References: <877kvbk8xb.fsf@nausicaa.interq.or.jp> <87pu93ijqq.fsf@nausicaa.interq.or.jp> <15257.40563.81479.94746@anthem.wooz.org> <87sndusb9l.fsf@nausicaa.interq.or.jp> <15261.31948.721484.994371@anthem.wooz.org> <87sndup1cp.fsf@nausicaa.interq.or.jp> <3B9DFDFF.93A264C9@is.kochi-u.ac.jp> <87k7z5u9z5.fsf@nausicaa.interq.or.jp> <3B9E7BF1.D729C9BC@is.kochi-u.ac.jp> <87bskh9qga.fsf@nausicaa.interq.or.jp> <3B9EDF83.173EC0D9@is.kochi-u.ac.jp> Message-ID: <8766ap9dpf.fsf@nausicaa.interq.or.jp> >>>>> "Tokio" == Tokio Kikuchi writes: Ben> I did this, and welcome mails are still mojibake.. Tokio> Have you restart the qrunner by bin/mailmanctl stop Tokio> bin/mailmanctl start I have not tried whether restart works Tokio> or not, yet. Wow!! I feel very silly, I didn't even think to try that. Now, with the settings: DEFAULT_SERVER_LANGUAGE = 'ja' GLOBAL_PIPELINE = [ 'ja_To_EUC_JP', ] + GLOBAL_PIPELINE DELIVERY_MODULE = 'ja_SMTPDirect' in Mailman/mm_cfg.py, welcome mails are sent out properly encoded, subjects and all. Pipermail.py is still not filling out the %(encoding) parameter kof index_header_template: index_header_template=''' The %(listname)s %(archive)s Archive by %(archtype)s %(encoding)s [snip] You can see how it's coming out on my test archive page: http://nausicaa.interq.or.jp/pipermail/test2/2001-September/000000.html The mail is mostly converted to EUC-JP, and the rest of the page is EUC, but the %(encoding) parameter is left blank, so my web browser assumes it's iso-8859-1. The hankaku (half-width) katakana characters in the message in the above URL are not converted to EUC-JP correctly, and are mojibake. Although the kconv documentation at http://tomigaya.shibuya.tokyo.jp/~mak/kconv/readmeen.txt says that the default is to convert hankaku katakana to full-width zenkaku katakana: * hankanaconvert Specify whether kconv converts hankaku katakana to zenkaku katakana or not. If the output encoding is EUC and you do want not to convert hankaku katakna to zenkaku katakana, kconv outputs 2 byte hankaku katakana in EUC. kconv.ZENKAKU - Convert hankaku katakana to zenkaku katakana(DEFAULT) kconv.HANKAKU - Output hankaku katakana if input string includes hankaku katakana the above URL shows that the hankaku katakana are *NOT* being converted to zenkaku. In fact, I just tried changing ja_To_EUC_JP.py and ja_To_ISO_2022_JP.py to specify kconv.HANKAKU, sent a test message with hankaku katakana, and still got mojibake in the archives. Finally, I tried specifying kconv.ZENKAKU, to see if the hankaku would be converted, and they were not. You can see the results of all these tests at: http://nausicaa.interq.or.jp/pipermail/test2/2001-September/ I think kconv has some bugs with converting ISO-2022-JP to EUC when hankaku characters are involved. Have you seen this problem, Kikuchi-san? Ben -- Brought to you by the letters S and P and the number 19. "Frungy! Frungy! Frungy!!" Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From che@debian.org Wed Sep 12 08:11:35 2001 From: che@debian.org (Ben Gertzfield) Date: Wed, 12 Sep 2001 16:11:35 +0900 Subject: [Mailman-Developers] Mailman CVS sends outJapanesetemplatemails in EUC-JP In-Reply-To: <8766ap9dpf.fsf@nausicaa.interq.or.jp> (Ben Gertzfield's message of "Wed, 12 Sep 2001 14:32:12 +0900") References: <877kvbk8xb.fsf@nausicaa.interq.or.jp> <87pu93ijqq.fsf@nausicaa.interq.or.jp> <15257.40563.81479.94746@anthem.wooz.org> <87sndusb9l.fsf@nausicaa.interq.or.jp> <15261.31948.721484.994371@anthem.wooz.org> <87sndup1cp.fsf@nausicaa.interq.or.jp> <3B9DFDFF.93A264C9@is.kochi-u.ac.jp> <87k7z5u9z5.fsf@nausicaa.interq.or.jp> <3B9E7BF1.D729C9BC@is.kochi-u.ac.jp> <87bskh9qga.fsf@nausicaa.interq.or.jp> <3B9EDF83.173EC0D9@is.kochi-u.ac.jp> <8766ap9dpf.fsf@nausicaa.interq.or.jp> Message-ID: <87r8tc993s.fsf@nausicaa.interq.or.jp> >>>>> "Ben" == Ben Gertzfield writes: Ben> Finally, I tried specifying kconv.ZENKAKU, to see if the Ben> hankaku would be converted, and they were not. You can see Ben> the results of all these tests at: Ben> http://nausicaa.interq.or.jp/pipermail/test2/2001-September/ Crud. I accidentally deleted this archive, but will be posting more examples shortly of the hankaku character convertion errors. Apologies. Ben -- Brought to you by the letters Q and W and the number 5. "Porcoga daisuki!" Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From rodolfo@linux.org.uy Wed Sep 12 15:32:17 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: Wed, 12 Sep 2001 11:32:17 -0300 Subject: Fw: [Mailman-Developers] Problem to gate_news REPEAT In-Reply-To: <20010912104912.A14754@publinet.it> References: <20010911193805.774a2c59.rodolfo@linux.org.uy> <20010912104912.A14754@publinet.it> Message-ID: <20010912113217.2fc24cc0.rodolfo@linux.org.uy> El Wed, 12 Sep 2001 10:49:12 +0200 Luca Maranzano ha escrito: > Have you tryed 2.1a3 ? You must get it via CVS. Let me know if > you need help. Ok, I can try it... but do you know a way to fix this problem? > > File "/usr/lib/mailman/cron/gate_news", line 147, in process_lists > > mlist = MailList.MailList(listname, lock=0) > > File "/usr/lib/mailman/Mailman/MailList.py", line 83, in __init__ > > self.Load() > > File "/usr/lib/mailman/Mailman/MailList.py", line 999, in Load > > raise Errors.MMCorruptListDatabaseError, e > > Mailman.Errors.MMCorruptListDatabaseError: bad marshal data you can go to http://www.espaciolibre.net/cgi-bin/listinfo to see this problem. If I need to delete databases I can do it, but I need to know how to do it. -- ____________________________________________________ -=(( Rodolfo Pilas - rodolfo@linux.org.uy ))=- -==((( Are you ready for XtraLinuX - http://xtralinux.org )))==- -=((____________________________________________________))=- Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From rodolfo@linux.org.uy Wed Sep 12 20:58:55 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: Wed, 12 Sep 2001 16:58:55 -0300 Subject: Fw: [Mailman-Developers] Problem to gate_news REPEAT In-Reply-To: <20010912180141.A17892@publinet.it> References: <20010911193805.774a2c59.rodolfo@linux.org.uy> <20010912104912.A14754@publinet.it> <20010912113217.2fc24cc0.rodolfo@linux.org.uy> <20010912163916.A17069@publinet.it> <20010912122439.6f37abdf.rodolfo@linux.org.uy> <20010912173609.A17664@publinet.it> <20010912130250.45181fac.rodolfo@linux.org.uy> <20010912180141.A17892@publinet.it> Message-ID: <20010912165855.12b4a4bd.rodolfo@linux.org.uy> El Wed, 12 Sep 2001 18:01:41 +0200 Luca Maranzano ha escrito: > Try to restart mailmanctl and dig into the log files, expecially > the logs/error file. The problem is that qrunner is not running. Log files do not say anything. To restart the mailmanctl was the first choice, but see this interesting problem: guru:/usr/lib/mailman # bin/mailmanctl -n stop PID unreadable in: /var/spool/mailman/data/qrunner.pid [Errno 2] No such file or directory: '/var/spool/mailman/data/qrunner.pid' Is qrunner even running? guru:/usr/lib/mailman # bin/mailmanctl -n start guru:/usr/lib/mailman # Traceback (most recent call last): File "bin/mailmanctl", line 169, in ? main() File "bin/mailmanctl", line 162, in main Control.start(restart) File "/usr/lib/mailman/Mailman/Queue/Control.py", line 209, in start master(restart, lock) File "/usr/lib/mailman/Mailman/Queue/Control.py", line 127, in master pid = start_runner(qrclass, slice, count) File "/usr/lib/mailman/Mailman/Queue/Control.py", line 111, in start_runner qrunner.run() File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 58, in run filecnt = self.__oneloop() File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 85, in __oneloop msg, msgdata = self._switchboard.dequeue(filebase) File "/usr/lib/mailman/Mailman/Queue/Switchboard.py", line 149, in dequeue msg = cPickle.load(msgfp) cPickle.UnpicklingError: unpickling stack underflow -- ____________________________________________________ -=(( Rodolfo Pilas - rodolfo@linux.org.uy ))=- -==((( Are you ready for XtraLinuX - http://xtralinux.org )))==- -=((____________________________________________________))=- Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From rodolfo@linux.org.uy Wed Sep 12 21:11:21 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: Wed, 12 Sep 2001 17:11:21 -0300 Subject: [Mailman-Developers] Solved In-Reply-To: <20010912165855.12b4a4bd.rodolfo@linux.org.uy> References: <20010911193805.774a2c59.rodolfo@linux.org.uy> <20010912104912.A14754@publinet.it> <20010912113217.2fc24cc0.rodolfo@linux.org.uy> <20010912163916.A17069@publinet.it> <20010912122439.6f37abdf.rodolfo@linux.org.uy> <20010912173609.A17664@publinet.it> <20010912130250.45181fac.rodolfo@linux.org.uy> <20010912180141.A17892@publinet.it> <20010912165855.12b4a4bd.rodolfo@linux.org.uy> Message-ID: <20010912171121.49dc432b.rodolfo@linux.org.uy> El Wed, 12 Sep 2001 16:58:55 -0300 Rodolfo Pilas ha escrito: I solved the following problem whith rm /var/spool/mailman/qfiles/in/* simply. > El Wed, 12 Sep 2001 18:01:41 +0200 > Luca Maranzano ha escrito: > > > Try to restart mailmanctl and dig into the log files, expecially > > the logs/error file. > File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 85, in __oneloop > msg, msgdata = self._switchboard.dequeue(filebase) > File "/usr/lib/mailman/Mailman/Queue/Switchboard.py", line 149, in > dequeue > msg = cPickle.load(msgfp) > cPickle.UnpicklingError: unpickling stack underflow Apparently, a config.db of one of my lists was corrupted (I have the file if somebody want it), after rm -R /var/spool/mailman/lists/mylist the systems return to work but qrunner not. To solve this problem I clean the in/* files. I will start to try 2.1a3 ;) Thank you very much to Luca to support me! -- ____________________________________________________ -=(( Rodolfo Pilas - rodolfo@linux.org.uy ))=- -==((( Are you ready for XtraLinuX - http://xtralinux.org )))==- -=((____________________________________________________))=- Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From che@debian.org Thu Sep 13 07:18:55 2001 From: che@debian.org (Ben Gertzfield) Date: Thu, 13 Sep 2001 15:18:55 +0900 Subject: [Mailman-Developers] [PATCH] mimelib base64 and q-p message decoding Message-ID: <87r8tbd35c.fsf@nausicaa.interq.or.jp> This patch is against mimelib CVS. It adds a few new extremely useful functions to mimelib.Message, which let users recursively get all parts of a message, decoded into viewable text format -- even non-text attachments will be replaced with a user-configurable message! It's required for the next patch I'm about to send, which ports pipermail/HyperArch and a few various other scripts from pythonlib/rfc822.py to mimelib. This is a huge help, because it was very difficult to follow the code when two slightly different Message classes (mimelib's and rfc822's) were being used. In addition, it adds a feature to Mailman that's been requested for some time: Base64-encoded gobbeldygook will no longer show up in the archives! Instead, non-viewable attachments will be displayed (by default) as: [Non-text (image/gif) part of message not included, filename foo.gif] In addition, users who attach multiple text files to a message will have them all show up in Pipermail, without the message delimiter gobbeldygook.. Both quoted-printable and base64 are dealt with in this patch, so Pine users who attach text files encoded in base64 will have them show up properly in the archives. This also lets us remove the quoted-printable code from Pipermail completely, as all the MIME-related stuff should be dealt with in mimelib from now on. This patch also includes my previous mimelib patch, which adds the getcharsets function. Here's a list of the functions this patch adds. It doesn't modify anything else besides including a few more modules. getfilename(self, failobj=None): Returns the filename associated with the payload if present. decode_body(self): Returns a string of the non-multipart message's body, decoded. If the message is encoded with quoted-printable or base64, will decode and return its payload. Otherwise, returns the payload as-is. Returns None if the message is multipart. get_decoded_payload(self, non_text_msg): Returns an array containing all decoded text parts of a MIME message. Will recurse through all payloads even if the message is multi-part. When a text part is seen, decodes the text if it's Base64 or Quoted-Printable encoded, and appends the (possibly decoded) text part to the end of the resulting array. When a non-text part is seen, replaces it with non_text_msg, which defaults to: [Non-text (%(type)s) part of message not included, filename %(filename)s]\n and appends it to the end of the resulting array. The following keywords will be expanded in non_text_msg: type: Full MIME type of the non-text part maintype: Main MIME type of the non-text part subtype: Sub MIME type of the non-text part filename: Filename of the non-text part description: Description associated with the non-text part transfer-encoding: Transfer encoding of the non-text part get_text_payload(self, non_text_msg): Return the decoded body of the message in a text format. If the message is not text, will return non_text_msg, formatted as described in get_decoded_payload(). getcharsets(self, default): Return an array containing the charset[s] used in a message. Returns an array containing one element for each part of the message; will return an array of one element if the message is not a multipart message. Each element will either be a string (the charset in the Content-Type of that part) or the value of the 'default' parameter (defaults to None), if the part is not a text part or the charset is not defined. Patch follows. Index: mimelib/Message.py =================================================================== RCS file: /cvsroot/mimelib/mimelib/mimelib/Message.py,v retrieving revision 1.13 diff -u -r1.13 Message.py --- mimelib/Message.py 2001/05/04 18:47:22 1.13 +++ mimelib/Message.py 2001/09/13 06:15:07 @@ -5,6 +5,11 @@ import re import address +import base64 +import quopri +import string +from StringIO import StringIO +from rfc822 import unquote from types import ListType SEMISPACE = '; ' @@ -272,3 +277,132 @@ if name.lower() == param: return address.unquote(val) return failobj + + def getcharsets(self, default=None): + """Return an array containing the charset[s] used in a message. + + Returns an array containing one element for each part of the + message; will return an array of one element if the message is not + a multipart message. + + Each element will either be a string (the charset in the + Content-Type of that part) or the value of the 'default' + parameter (defaults to None), if the part is not a text part + or the charset is not defined. + """ + result = [] + + if self.ismultipart(): + for p in self.get_payload(): + if p.getmaintype() == "text": + result.append(p.getparam("charset")) + else: + result.append(default) + else: + if self.getmaintype() == "text": + result.append(self.getparam("charset")) + else: + result.append(default) + + return result + + def getfilename(self, failobj=None): + """Return the filename associated with the payload if present.""" + + disp = self.get("Content-Disposition") + + if disp is None: + return failobj + + # Match up to and not including the next semicolon, if any + filename = re.search(r'filename\s*=\s*([^;]*)', disp, re.IGNORECASE) + + if filename is None: + return failobj + + # Trim the whitespace if there was any at the end of the filename, + # then remove quotes from around it. + return unquote(string.rstrip(filename.group(1))) + + def get_decoded_payload(self, non_text_msg="[Non-text (%(type)s) part of message not included, filename %(filename)s]\n"): + """Return an array containing all decoded text parts of a MIME message. + + Will recurse through all payloads even if the message is + multi-part. When a text part is seen, decodes the text if + it's Base64 or Quoted-Printable encoded, and appends the + (possibly decoded) text part to the end of the resulting + array. + + When a non-text part is seen, replaces it with non_text_msg, + which defaults to: + + [Non-text (%(type)s) part of message not included, filename %(filename)s]\n + + and appends it to the end of the resulting array. + + The following keywords will be expanded in non_text_msg: + + type: Full MIME type of the non-text part + maintype: Main MIME type of the non-text part + subtype: Sub MIME type of the non-text part + filename: Filename of the non-text part + description: Description associated with the non-text part + transfer-encoding: Transfer encoding of the non-text part + """ + result = [] + if self.ismultipart(): + for p in self.get_payload(): + # Can we even get multipart messages w/ multiparts inside? + if p.ismultipart(): + result.append(p.get_decoded_payload(non_text_msg)) + else: + result.append(p.get_text_payload(non_text_msg)) + else: + result.append(self.get_text_payload(non_text_msg)) + + return result + + def get_text_payload(self, non_text_msg): + """Return the decoded body of the message in a text format. + + If the message is not text, will return non_text_msg, formatted + as described in get_decoded_payload(). + """ + if self.getmaintype('text') == 'text': + return self.decode_body() + else: + return non_text_msg % { + 'type': self.gettype(), + 'maintype': self.getmaintype(), + 'subtype': self.getsubtype(), + 'filename': self.getfilename(), + 'description': self.get('Content-Description'), + 'transfer-encoding': self.get('Content-Transfer-Encoding') + } + + def decode_body(self): + """Return a string of the non-multipart message's body, decoded. + + If the message is encoded with quoted-printable or base64, will + decode and return its payload. Otherwise, returns the payload + as-is. + + Returns None if the message is multipart. + """ + if self.ismultipart(): + return None + + cte = self.get('Content-Transfer-Encoding') + # Assume no encoding if header not specified + if cte is None: + return self.get_payload() + elif string.lower(cte) == 'quoted-printable': + input = StringIO(self.get_payload()) + output = StringIO() + quopri.decode(input, output) + return output.getvalue() + elif string.lower(cte) == 'base64': + return base64.decodestring(self.get_payload()) + # Otherwise, could be 7bit, 8bit, or binary.. don't mess with it + else: + return self.get_payload() From che@debian.org Thu Sep 13 07:45:29 2001 From: che@debian.org (Ben Gertzfield) Date: Thu, 13 Sep 2001 15:45:29 +0900 Subject: [Mailman-Developers] [PATCH] Port HyperArch/pipermail to mimelib Message-ID: <87g09rd1x2.fsf@nausicaa.interq.or.jp> Here's a port of HyperArch and pipermail to mimelib. This allows proper parsing of multipart messages, and will make i18n handling much easier. This is a big step forward, I think, because now we no longer have two very different Message classes in Mailman. This patch depends on the mimelib patch I just sent; it uses the get_decoded_payload() function I added to get a nice text representation of even a multi-part message. This will let us even display a message for non-text parts of a message, and eventually will let HyperArch display attachments inline. And of course, as I mentioned in my previous mail, this will prevent base64 gobbeldygook from showing up in the archives. This patch even deals with multiple text/* attachments to a message, and will include them all in the archive even if they're base64 or quoted-printable encoded. It currently does not deal with replacing high-ASCII characters with HTML entities in HyperArch; I'm going to deal with that next by taking the htmlentitydefs module's hash, inverting it, and using that as a big global search-and-replace, if the charset is undefined or iso-8859-1. You can see an example message with lots of mixed parts in my pipermail archive, at: http://nausicaa.interq.or.jp/pipermail/test2/2001-September/000025.html (The original message that produced this output is available at: http://nausicaa.interq.or.jp/~ben/mime-test.txt) . This also patches pythonlib/mailbox.py to use mimelib instead of rfc822. This is the last use of rfc822 in Mailman, so we can now remove pythonlib/rfc822.py completely from the archives -- now we use mimelib entirely! Patch follows, against current Mailman CVS. Index: Mailman/Archiver/HyperArch.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Archiver/HyperArch.py,v retrieving revision 2.7 diff -u -r2.7 HyperArch.py --- Mailman/Archiver/HyperArch.py 2001/07/26 05:26:48 2.7 +++ Mailman/Archiver/HyperArch.py 2001/09/13 06:19:47 # Note: I'm overriding most, if not all of the pipermail Article class # here -ddm # The Article class encapsulates a single posting. The attributes are: @@ -165,8 +164,8 @@ # Snag the content-* headers. RFC 1521 states that their values are # case insensitive. - ctype = message.getheader('Content-Type', 'text/plain') - cenc = message.getheader('Content-Transfer-Encoding', '') + ctype = message.gettype("text/plain") + cenc = message.get('Content-Transfer-Encoding', '') self.ctype = string.lower(ctype) self.cenc = string.lower(cenc) self.decoded = {} @@ -283,42 +282,14 @@ next = next_wsubj = "" return next, next_wsubj - _rx_quote = re.compile('=([A-F0-9][A-F0-9])') - _rx_softline = re.compile('=[ \t]*$') - def _get_body(self): """Return the message body ready for HTML, decoded if necessary""" try: body = self.html_body except AttributeError: body = self.body - if self.charset is None or self.cenc != "quoted-printable": - return null_to_space(string.join(body, "")) - # the charset is specified and the body is quoted-printable - # first get rid of soft line breaks, then decode literals - lines = [] - rx = self._rx_softline - for line in body: - mo = rx.search(line) - if mo: - i = string.rfind(line, "=") - line = line[:i] - lines.append(line) - buf = string.join(lines, "") - - chunks = [] - offset = 0 - rx = self._rx_quote - while 1: - mo = rx.search(buf, offset) - if not mo: - chunks.append(buf[offset:]) - break - i = mo.start() - chunks.append(buf[offset:i]) - offset = i + 3 - chunks.append(chr(string.atoi(mo.group(1), 16))) - return null_to_space(string.join(chunks, "")) + + return null_to_space(string.join(body, "")) def _add_decoded(self, d): """Add encoded-word keys to HTML output""" Index: Mailman/Archiver/pipermail.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/Archiver/pipermail.py,v retrieving revision 2.8 diff -u -r2.8 pipermail.py --- Mailman/Archiver/pipermail.py 2001/08/17 05:41:25 2.8 +++ Mailman/Archiver/pipermail.py 2001/09/13 06:19:47 @@ -7,6 +7,11 @@ import string import time +from Mailman.pythonlib.StringIO import StringIO + +from mimelib.date import parsedate_tz +from mimelib.address import parseaddr + try: import cPickle pickle = cPickle @@ -20,7 +25,6 @@ from Mailman.Mailbox import Mailbox from Mailman.i18n import _ - msgid_pat = re.compile(r'(<.*>)') def strip_separators(s): @@ -155,7 +159,7 @@ self.parentID = None self.threadKey = None # otherwise the current sequence number is used. - id = strip_separators(message.getheader('Message-Id')) + id = strip_separators(message['Message-Id']) if id == "": self.msgid = str(self.sequence) else: self.msgid = id @@ -169,8 +173,8 @@ self._set_date(message) # Figure out the e-mail address and poster's name - self.author, self.email = message.getaddr('From') - e = message.getheader('Reply-To') + self.author, self.email = parseaddr(message['From']) + e = message['Reply-To'] if e is not None: self.email = e self.email = strip_separators(self.email) @@ -184,11 +188,11 @@ # shouldn't be necessary, but changing this may break code. For # safety, I save the original headers on different attributes for use # in writing the plain text periodic flat files. - self._in_reply_to = message.getheader('in-reply-to') - self._references = message.getheader('references') - self._message_id = message.getheader('message-id') + self._in_reply_to = message['in-reply-to'] + self._references = message['references'] + self._message_id = message['message-id'] - i_r_t = message.getheader('In-Reply-To') + i_r_t = message['In-Reply-To'] if i_r_t is None: self.in_reply_to = '' else: @@ -196,7 +200,7 @@ if match is None: self.in_reply_to = '' else: self.in_reply_to = strip_separators(match.group(1)) - references = message.getheader('References') + references = message['References'] if references is None: self.references = [] else: @@ -209,14 +213,12 @@ if message.has_key(i): self.headers[i] = message[i] - # Read the message body - message.rewindbody() - self.body = message.fp.readlines() + self.body = message.get_decoded_payload() def _set_date(self, message): if message.has_key('Date'): self.datestr = str(message['Date']) - date = message.getdate_tz('Date') + date = parsedate_tz(self.datestr) else: self.datestr = '' date = None Index: Mailman/pythonlib/cgi.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/pythonlib/cgi.py,v retrieving revision 2.0 diff -u -r2.0 cgi.py --- Mailman/pythonlib/cgi.py 2000/12/07 16:53:20 2.0 +++ Mailman/pythonlib/cgi.py 2001/09/13 06:19:47 @@ -30,7 +30,8 @@ import os import urllib import mimetools -import rfc822 +from Mailman import Message +from mimelib import Parser import UserDict from StringIO import StringIO @@ -462,6 +463,7 @@ self.filename = None if pdict.has_key('filename'): self.filename = pdict['filename'] + self.parser = Parser.Parser(Message.Message) # Process content-type header # Index: Mailman/pythonlib/mailbox.py =================================================================== RCS file: /cvsroot/mailman/mailman/Mailman/pythonlib/mailbox.py,v retrieving revision 1.1 diff -u -r1.1 mailbox.py --- Mailman/pythonlib/mailbox.py 2001/02/15 06:09:38 1.1 +++ Mailman/pythonlib/mailbox.py 2001/09/13 06:19:47 @@ -3,13 +3,15 @@ """Classes to handle Unix style, MMDF style, and MH style mailboxes.""" -import rfc822 +from Mailman import Message +from mimelib import Parser import os __all__ = ["UnixMailbox","MmdfMailbox","MHMailbox","Maildir","BabylMailbox"] +parser = Parser.Parser(Message.Message) class _Mailbox: - def __init__(self, fp, factory=rfc822.Message): + def __init__(self, fp, factory=parser.parse): self.fp = fp self.seekp = 0 self.factory = factory @@ -184,7 +186,7 @@ class MHMailbox: - def __init__(self, dirname, factory=rfc822.Message): + def __init__(self, dirname, factory=parser.parse): import re pat = re.compile('^[1-9][0-9]*$') self.dirname = dirname @@ -211,7 +213,7 @@ class Maildir: # Qmail directory mailbox - def __init__(self, dirname, factory=rfc822.Message): + def __init__(self, dirname, factory=parser.parse): self.dirname = dirname self.factory = factory From che@debian.org Thu Sep 13 11:42:31 2001 From: che@debian.org (Ben Gertzfield) Date: Thu, 13 Sep 2001 19:42:31 +0900 Subject: [Mailman-Developers] (2.0.6) pipermail takes >1 minute to rebuild indexes on large lists Message-ID: <8766anbcdk.fsf@nausicaa.interq.or.jp> On a massive list (Mailman 2.0.6) I run that regularly gets a few hundred or more emails every day, things begin to slow down to molasses after a week or two each month, with the qrunner process taking literally HUNDREDS of megabytes of RAM, and 100% CPU, all the time. It's gotten so bad that the pipermail databases have gotten massive: -rw-rw-r-- 1 list list 40866061 Sep 13 19:24 2001-September-article -rw-rw-r-- 1 list list 686273 Sep 13 19:24 2001-September-author -rw-rw-r-- 1 list list 561479 Sep 13 19:24 2001-September-date -rw-rw-r-- 1 list list 796534 Sep 13 19:24 2001-September-subject -rw-rw-r-- 1 list list 569238 Sep 13 19:24 2001-September-thread And, of course, pipermail takes over a *MINUTE* to rebuild the indexes now. This is with a bunch of syslog() debugging in pipermail.py. Notice the timestamps -- this is how long it takes a *single* message to make it through the ToArchive step of the pipeline.. Sep 13 19:24:02 2001 (29357) in pipermail._update_simple_index() now Sep 13 19:24:02 2001 (29357) opening index as stdout Sep 13 19:24:02 2001 (29357) done opening index, writing index header Sep 13 19:24:02 2001 (29357) getting article 200109010000.JAA26551@admin.interq.or.jp from db Sep 13 19:24:03 2001 (29357) writing index entry 0 Sep 13 19:24:03 2001 (29357) going to next entry (snip LOTS of index entry writing -- note the timestamp and the count below) Sep 13 19:24:52 2001 (29357) getting article 3B95AB3EA.4F08HONDA@192.168.1.190 from db Sep 13 19:24:52 2001 (29357) writing index entry 4794 Sep 13 19:24:52 2001 (29357) going to next db Sep 13 19:24:52 2001 (29357) calling self.write_index_footer() Sep 13 19:24:52 2001 (29357) in pipermail._update_thread_index Sep 13 19:24:53 2001 (29357) in pipermail.write_TOC() Sep 13 19:24:53 2001 (29357) done writing TOC Sep 13 19:24:53 2001 (29357) picking archive state into /var/lib/mailman/archives/private/sysadmin/pipermail.pck While it does this, the size of the python process that's doing the qrunner grows by *megabytes* each second. I've seen it get to 200MB before it finishes, and it's always taking up 99% CPU. As you can guess, things rapidly get out of hand, and messages start arriving faster than pipermail can deal with them. And since it's first in the pipeline, nothing gets delivered until pipermail archives the mail.. and mail queues up and queues up, until it's taking 7-8 hours to send out each mail -- no joke. What can I do to help solve this? I know I can use an external archiver, but I don't know anything about that. I've commented out the ToArchive step from the pipeline for now, but I don't know what else I can do. There *MUST* be a way to not have to loop over every single article in the simple index every time a message arrives, right? Other people must have run into this, and I'd like to know what I can do to only have to write the changed articles in the simple index. Thanks, Ben -- Brought to you by the letters F and O and the number 12. "Johnny! Don't go! It's too dangerous!" "I don't care!" Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From midnight@the-oasis.net Thu Sep 13 12:22:28 2001 From: midnight@the-oasis.net (Phil Barnett) Date: Thu, 13 Sep 2001 07:22:28 -0400 Subject: [Mailman-Developers] [PATCH] mimelib base64 and q-p message decoding In-Reply-To: <87r8tbd35c.fsf@nausicaa.interq.or.jp> References: <87r8tbd35c.fsf@nausicaa.interq.or.jp> Message-ID: On Thursday 13 September 2001 02:18, Ben Gertzfield wrote: > This patch is against mimelib CVS. > > It adds a few new extremely useful functions to mimelib.Message, > which let users recursively get all parts of a message, decoded into > viewable text format -- even non-text attachments will be replaced > with a user-configurable message! Bravo to you for all the great new features... Most excellent! From turnbull@sk.tsukuba.ac.jp Thu Sep 13 13:09:02 2001 From: turnbull@sk.tsukuba.ac.jp (Stephen J. Turnbull) Date: Thu, 13 Sep 2001 21:09:02 +0900 Subject: [Mailman-Developers] (2.0.6) pipermail takes >1 minute to rebuild indexes on large lists In-Reply-To: References: Message-ID: <15264.41438.34480.725393@turnbull.sk.tsukuba.ac.jp> Sorry about the busted references, I'm on the digest. >>>>> "ben" == Ben Gertzfield writes ben> On a massive list (Mailman 2.0.6) I run that regularly gets a ben> few hundred or more emails every day, things begin to slow ben> down to molasses after a week or two each month, [...] ben> What can I do to help solve this? I know I can use an ben> external archiver, You could switch to weekly or daily archiving, I assume Pipermail supports that. ben> but I don't know anything about that. It's not that hard. I don't know much about this (jason, our Official Mail Guy, has taken an indefinite sanity leave so I'm learning more than I really wanna know), but what XEmacs does is to use the remnants of the former MLM like so: In /etc/aliases: main: "|/home/mailman/prog/wrapper post main",main-archive main-archive: "|/opt/majordomo/wrapper archive2-y2k.pl -a -M -f /opt/archive/majordomo/main "/opt/archive/majordomo/main" is the directory holding the archives. Of course you switch off Mailman's internal archiver. At least this gets the archiving hairball out of Mailman's pipeline. The HTML stuff is done by wilma (Web Interface to List Mail Archives), a front end to mhonarc and glimpse. I don't know anything about that, but could check out the configuration if you want. Provides fairly nice searching, and is admittedly tuned to majordomo archives. Requires one cron job for reindexing. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules." From che@debian.org Thu Sep 13 13:21:24 2001 From: che@debian.org (Ben Gertzfield) Date: Thu, 13 Sep 2001 21:21:24 +0900 Subject: [Mailman-Developers] (2.0.6) pipermail takes >1 minute to rebuild indexes on large lists In-Reply-To: <15264.41438.34480.725393@turnbull.sk.tsukuba.ac.jp> ("Stephen J. Turnbull"'s message of "Thu, 13 Sep 2001 21:09:02 +0900") References: <15264.41438.34480.725393@turnbull.sk.tsukuba.ac.jp> Message-ID: <87sndr9t8b.fsf@nausicaa.interq.or.jp> >>>>> "Stephen" == Stephen J Turnbull writes: >>>>> "ben" == Ben Gertzfield writes ben> On a massive list (Mailman 2.0.6) I run that regularly gets a ben> few hundred or more emails every day, things begin to slow ben> down to molasses after a week or two each month, ben> What can I do to help solve this? I know I can use an ben> external archiver, Stephen> You could switch to weekly or daily archiving, I assume Stephen> Pipermail supports that. Right, I guess there's just no archiver in the world that would support real-time archiving like this. In that case, I think it might be a better idea for pipermail to keep an eye on how long it's taking, and set a maximum for how long it spends on each message before it gives up and (possibly) tells the admin they need to switch to weekly/daily archiving. I'll try and code up a patch to this effect; it's better than people claiming Mailman sucks and can't support large lists! Ben -- Brought to you by the letters P and F and the number 10. "Tahiti is not in Europe." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From mrbill@mrbill.net Fri Sep 14 03:31:25 2001 From: mrbill@mrbill.net (Bill Bradford) Date: Thu, 13 Sep 2001 21:31:25 -0500 Subject: [Mailman-Developers] help! 2.0.6 just *stopped* Message-ID: <20010913213125.L24473@mrbill.net> Around 5pm this afternoon, my long-standing 2.0.6 installation, working great, just *stopped* working. here's all i can find, in ~mailman/logs/error: Sep 13 21:30:02 2001 qrunner(12488): Traceback (most recent call last): Sep 13 21:30:02 2001 qrunner(12488): File "/usr/local/mailman/cron/qrunner", line 282, in ? Sep 13 21:30:02 2001 qrunner(12488): kids = main(lock) Sep 13 21:30:02 2001 qrunner(12488): File "/usr/local/mailman/cron/qrunner", line 252, in main Sep 13 21:30:02 2001 qrunner(12488): keepqueued = dispose_message(mlist, msg, msgdata) Sep 13 21:30:02 2001 qrunner(12488): File "/usr/local/mailman/cron/qrunner", line 121, in dispose_message Sep 13 21:30:02 2001 qrunner(12488): if BouncerAPI.ScanMessages(mlist, mimemsg): Sep 13 21:30:02 2001 qrunner(12488): File "/usr/local/mailman/Mailman/Bouncers/BouncerAPI.py", line 59, in ScanMessages Sep 13 21:30:02 2001 qrunner(12488): addrs = func(msg) Sep 13 21:30:02 2001 qrunner(12488): File "/usr/local/mailman/Mailman/Bouncers/DSN.py", line 46, in process Sep 13 21:30:02 2001 qrunner(12488): if string.lower(msg.gettype()) <> 'multipart/report' or \ Sep 13 21:30:02 2001 qrunner(12488): File "/usr/local/lib/python2.1/string.py", line 51, in lower Sep 13 21:30:02 2001 qrunner(12488): return s.lower() Sep 13 21:30:02 2001 qrunner(12488): AttributeError : 'None' object has no attribute 'lower' Any suggestions? I literally havent changed a *thing*... and no mail is hitting the lists.... its not even showing up in logs/post. Bill -- Bill Bradford mrbill@mrbill.net Austin, TX From mrbill@mrbill.net Fri Sep 14 03:48:29 2001 From: mrbill@mrbill.net (Bill Bradford) Date: Thu, 13 Sep 2001 21:48:29 -0500 Subject: [Mailman-Developers] help! 2.0.6 just *stopped* In-Reply-To: <20010913213125.L24473@mrbill.net> References: <20010913213125.L24473@mrbill.net> Message-ID: <20010913214828.N24473@mrbill.net> On Thu, Sep 13, 2001 at 09:31:25PM -0500, Bill Bradford wrote: > Around 5pm this afternoon, my long-standing 2.0.6 installation, > working great, just *stopped* working. here's all i can find, > in ~mailman/logs/error: > Any suggestions? I literally havent changed a *thing*... > and no mail is hitting the lists.... its not even showing up in > logs/post. > Nuked all the .pyc files so they had to be re-compiled, cleaned out the qfiles directory, and now things are flowing... had 313 files in qfiles. Bill -- Bill Bradford mrbill@mrbill.net Austin, TX From barry@zope.com Fri Sep 14 22:52:45 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 14 Sep 2001 17:52:45 -0400 Subject: [Mailman-Developers] [PATCH] mimelib base64 and q-p message decoding References: <87r8tbd35c.fsf@nausicaa.interq.or.jp> Message-ID: <15266.31789.563488.960507@anthem.wooz.org> [mimelib-devel'ers, please see http://mail.python.org/pipermail/mailman-developers/2001-September/009588.html -BAW] >>>>> "BG" == Ben Gertzfield writes: BG> This patch is against mimelib CVS. Ben, I really like what you've added here, and intend to merge those into mimelib. First a couple of general comments and then some specific ones. mimelib will soon be merged into the Python 2.2 standard library, under the package name `email'. It will generally have the same class structure, modules, etc. although it is likely that some of the method names will be changed. I plan to release a mimelib 0.5 in which I will include your changes (see below), along with a few other patches and bug fixes I've collected. I plan on including the email package in Python 2.2a4 to be released next week. When I merge it into Python 2.2, I will essentially stop releasing mimelib separately, although I may piggyback off the SF project for a while so that I can do distutils-based releases of the email package; we'll see how easy that turns out to be. If difficult, then I'll add this stuff to Mailman/pythonlib for the next Mailman alpha. BG> It adds a few new extremely useful functions to BG> mimelib.Message, which let users recursively get all parts of BG> a message, decoded into viewable text format -- even non-text BG> attachments will be replaced with a user-configurable message! I wonder if we couldn't generalize some of this into a "subpart walker", a la os.path.walk()? I'm not going to do that now, but it's something to keep in mind for later. BG> It's required for the next patch I'm about to send, which BG> ports pipermail/HyperArch and a few various other scripts from BG> pythonlib/rfc822.py to mimelib. This is a huge help, because BG> it was very difficult to follow the code when two slightly BG> different Message classes (mimelib's and rfc822's) were being BG> used. Indeed! Boy, I'm glad someone has the nerve to dive into the archiver code. :) It'll be way cool to eliminate the need for rfc822, except internally for some of mimelib's implementation, which will eventually go away. BG> In addition, it adds a feature to Mailman that's been BG> requested for some time: Base64-encoded gobbeldygook will no BG> longer show up in the archives! Instead, non-viewable BG> attachments will be displayed (by default) as: BG> [Non-text (image/gif) part of message not included, filename BG> foo.gif] Awesome! I hope you don't mind that I changed this message just a little bit: [Non-text (%(type)s) part of message omitted, filename %(filename)s]\n Also, is the trailing newline necessary? BG> In addition, users who attach multiple text files to a message BG> will have them all show up in Pipermail, without the message BG> delimiter gobbeldygook.. Both quoted-printable and base64 are BG> dealt with in this patch, so Pine users who attach text files BG> encoded in base64 will have them show up properly in the BG> archives. BG> This also lets us remove the quoted-printable code from BG> Pipermail completely, as all the MIME-related stuff should be BG> dealt with in mimelib from now on. All this is truely fantastic, thanks! BG> This patch also includes my previous mimelib patch, which adds BG> the getcharsets function. Here's a list of the functions this BG> patch adds. It doesn't modify anything else besides including BG> a few more modules. I'm going to simplify some of the implementations when I check them in, and I may also change the method names, although perhaps I should keep yours for `backwards' compatibility? | getfilename(self, failobj=None): | Returns the filename associated with the payload if present. I'm also adding a getboundary() since I tend to use that a lot! | decode_body(self): | Returns a string of the non-multipart message's body, decoded. Here's where I've hit a conundrum. What's the difference between "body" and "payload"? To me, the body contains the entire flattened contents of the outer message, while the payload contains just first level down from the outer message. I.e. it is definitely possible to have nested multiparts, e.g. multipart/mixed which contains some stuff including a multipart/digest -- think Mailman's MIME digests! Thus the outer message's body would include all the multipart/digest's message/rfc822 subparts, but the outer message's payload would include just the multipart/mixed object. Along those lines, I'd call this method getdecodedpayload() since it doesn't recurse. | get_decoded_payload(self, non_text_msg): | Returns an array containing all decoded text parts of a MIME message. So this one can't be called get_decoded_payload() :). I propose getpayloadastext(). Also, I'm setting non_text_msg=None as a default value, and if non_text_msg is None, then I set it to the string before I interpolate the dictionary. I'm also shortening the 'transfer-encoding' key to just 'encoding', and giving all the other self.get*() methods failobjs like '[no MIME type]' so they don't try to interpolate "None" if it's missing. | get_text_payload(self, non_text_msg): | Return the decoded body of the message in a text format. So, because this one recurses, I propose to call it getbodyastext(). Side note: the naming scheme in mimelib.Message is getting both inconsistent and clumsy. I intend to rectify this when I merge it into Py2.2. Question: is backwards compatibility with mimelib 0.x important? I claim it isn't, even though this means a lot of busy work for me, fixing Mailman's code. Heck, that's what 0.x releases are for! I'm leaning toward a naming scheme such as: def getDecodedPayload() def getPayloadAsText() def getBodyAsText() modulo comments from Guido. | getcharsets(self, default): | Return an array containing the charset[s] used in a message. Cool. Comments? I will likely check something in tonight, although I'll need to add unittest cases and documentation. Thanks, -Barry From che@debian.org Sat Sep 15 02:11:27 2001 From: che@debian.org (Ben Gertzfield) Date: Sat, 15 Sep 2001 10:11:27 +0900 Subject: [Mailman-Developers] [PATCH] mimelib base64 and q-p message decoding In-Reply-To: <15266.31789.563488.960507@anthem.wooz.org> (barry@zope.com's message of "Fri, 14 Sep 2001 17:52:45 -0400") References: <87r8tbd35c.fsf@nausicaa.interq.or.jp> <15266.31789.563488.960507@anthem.wooz.org> Message-ID: <87u1y58dhc.fsf@nausicaa.interq.or.jp> >>>>> "BAW" == Barry A Warsaw writes: >>>>> "BG" == Ben Gertzfield writes: BAW> I really like what you've added here, and intend to merge BAW> those into mimelib. First a couple of general comments and BAW> then some specific ones. Great! I appreciate all the comments and the quick attention. I hope I'm not being a pain, sending off all these rapid-fire patches. *grin* BG> It adds a few new extremely useful functions to BG> mimelib.Message, which let users recursively get all parts of BG> a message, decoded into viewable text format -- even non-text BG> attachments will be replaced with a user-configurable message! BAW> I wonder if we couldn't generalize some of this into a BAW> "subpart walker", a la os.path.walk()? I'm not going to do BAW> that now, but it's something to keep in mind for later. Yes, eventually this should be generalized into something that will simply decode even non-text attachments (and even replace them with Image/etc objects? Hmm.) but I wanted to get something done now. BAW> Indeed! Boy, I'm glad someone has the nerve to dive into the BAW> archiver code. :) It'll be way cool to eliminate the need for BAW> rfc822, except internally for some of mimelib's BAW> implementation, which will eventually go away. Pipermail is not wholly bad, but it is extremely inefficient. Since so many people are never going to use anything but the built-in archiver, I'd like to make it pretty solid, including behaving well on huge lists. BAW> Awesome! I hope you don't mind that I changed this message BAW> just a little bit: BAW> [Non-text (%(type)s) part of message omitted, filename BAW> %(filename)s]\n BAW> Also, is the trailing newline necessary? Looks fine! I expected lots of things to change. The trailing newline is an issue I wanted to address; currently, multiple text parts just show up one after another (if there was a newline between them in the message, they have newlines between them). I'd be happier doing something like how Gnus shows multiple attachments in a message: (snip here) This is the first, text part of the message. [3. Interesting test --- text/plain; test]... This is the (second? third?) text part of the message after the first text attachment. [5. Interesting pic --- image/gif; gm-icon00.gif]... This is the (third? fourth?) text part of the message after the GIF image. (snip here) Now, we're already replacing non-text attachments with a message, but it'd be nice to announce text-attachments too, so things don't get confusing. Also, I forgot to test what happens with text/html parts. Will they get HTML escaped or will they mess up the document? BAW> I'm going to simplify some of the implementations when I BAW> check them in, and I may also change the method names, BAW> although perhaps I should keep yours for `backwards' BAW> compatibility? BAW> Side note: the naming scheme in mimelib.Message is getting BAW> both inconsistent and clumsy. I intend to rectify this when BAW> I merge it into Py2.2. Question: is backwards compatibility BAW> with mimelib 0.x important? Please, please, go ahead and change all the names! I actually agree that mimelib.Message is a big old mess, and the get_foo_bar vs. getfoobar functions kind of got on my nerves. :) I have no attachments whatsoever to the current names, but I think it would be the right thing to do to at least make the old names call the new ones (just segregate them in the documents as a list of compatibility interface names). BAW> I'm also adding a getboundary() since I tend to use that a BAW> lot! Very useful. BAW> | decode_body(self): | Returns a string of the BAW> non-multipart message's body, decoded. BAW> Here's where I've hit a conundrum. What's the difference BAW> between "body" and "payload"? To me, the body contains the BAW> entire flattened contents of the outer message, while the BAW> payload contains just first level down from the outer BAW> message. I.e. it is definitely possible to have nested BAW> multiparts, e.g. multipart/mixed which contains some stuff BAW> including a multipart/digest -- think Mailman's MIME digests! I guess my concept was the reverse; since a "payload" from mimelib.Message can be either a list of payloads OR a single message, my brain called the former a "payload" and the second a "body". But I still don't really know the right terminology.. We should probably come up with some clearer nomenclature, because the current one really confused me. :) Basically, we need a distinction between functions which take a (possibly) multipart message, and ones that only take a single part message. Rereading RFC 2045, I see that I subconsciously got my naming scheme from a past reading of it. Here's what RFC 2045 has to say: [begin quote] 2.3. Message The term "message", when not further qualified, means either a (complete or "top-level") RFC 822 message being transferred on a network, or a message encapsulated in a body of type "message/rfc822" or "message/partial". 2.4. Entity The term "entity", refers specifically to the MIME-defined header fields and contents of either a message or one of the parts in the body of a multipart entity. The specification of such entities is the essence of MIME. Since the contents of an entity are often called the "body", it makes sense to speak about the body of an entity. Any sort of field may be present in the header of an entity, but only those fields whose names begin with "content-" actually have any MIME-related meaning. Note that this does NOT imply thay they have no meaning at all -- an entity that is also a message has non-MIME header fields whose meanings are defined by RFC 822. 2.5. Body Part The term "body part" refers to an entity inside of a multipart entity. 2.6. Body The term "body", when not further qualified, means the body of an entity, that is, the body of either a message or of a body part. [end quote] So, where you say "payload", RFC 2045 says "body", and where you say "body", the RFC says "message". How confusing! :) I would suggest that we should go with the RFC's naming scheme, and just make up a new term, something like single_body or single_entity, to refer to MIME parts that themselves are not multipart. So, how about these names. I'm following the RFC here, using 'single entity' to mean a non-multipart payload, 'message' to refer to a full, standalone MIME message, and 'body' to refer to the body of a message. decode_body -> decodeSingleEntity get_decoded_payload -> getMessageAsText get_text_payload -> getBodyAsText Do they all have to start with 'get'? I guess that's a matter of taste. BAW> Comments? I will likely check something in tonight, although BAW> I'll need to add unittest cases and documentation. I hope this is helpful. :) Let me know what you think; I like 'single entity' to refer to a non-multipart part of a message, 'message' to refer to the whole thing, and 'body' to refer to the (possibly multipart) body of a message. Ben -- Brought to you by the letters K and B and the number 7. "Wuzzle means to mix." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From chuqui@plaidworks.com Sat Sep 15 04:54:11 2001 From: chuqui@plaidworks.com (Chuq Von Rospach) Date: Fri, 14 Sep 2001 20:54:11 -0700 Subject: [Mailman-Developers] Authentication errors in admin pages. Message-ID: Someone brought this up a couple of days ago, and I mentioned I'd been seeing something similar. Here's the traceback I'm seeing. I see it intermittently, usually if I'm going through a number of lists, one after another. It never happens on the first list, but on one of the later ones. And if I hit the "refresh" button on the browser, it goes away and brings up the password page just fine (that's why I never mentioned it; I was sort of assuming it was a weird interaction between python, cookies and mod_layout, and hadn't had time to debug it. It might STILL be that, for all I know...) Any thoughts on what this traceback is telling us, I'd be happy to hear and test... Especially since the refresh of the page makes it leave again... Sep 14 20:30:47 2001 admin(24621): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ admin(24621): [----- Mailman Version: 2.0.5 -----] admin(24621): [----- Traceback ------] admin(24621): Traceback (innermost last): admin(24621): File "/home/mailman/scripts/driver", line 96, in run_main admin(24621): main() admin(24621): File "/home/mailman/Mailman/Cgi/admindb.py", line 78, in main admin(24621): Auth.authenticate(mlist, cgidata) admin(24621): File "/home/mailman/Mailman/Cgi/Auth.py", line 65, in authenticate admin(24621): if cgidata.has_key('adminpw') and \ admin(24621): File "/home/mailman/Mailman/pythonlib/cgi.py", line 564, in has_key admin(24621): raise TypeError, "not indexable" admin(24621): TypeError: not indexable admin(24621): [----- Python Information -----] -- Chuq Von Rospach, Internet Gnome [ = = ] Yes, yes, I've finally finished my home page. Lucky you. 95% of being a net.god is sounding persuasive and convincing people you know what you're talking about, even when you're making it up as you go along. (chuq von rospach, 1992) From barry@zope.com Sun Sep 16 08:19:39 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 16 Sep 2001 03:19:39 -0400 Subject: [Mailman-Developers] [PATCH] mimelib base64 and q-p message decoding References: <87r8tbd35c.fsf@nausicaa.interq.or.jp> <15266.31789.563488.960507@anthem.wooz.org> <87u1y58dhc.fsf@nausicaa.interq.or.jp> Message-ID: <15268.21131.800311.458371@anthem.wooz.org> >>>>> "BAW" == Barry A Warsaw writes: >>>>> "BG" == Ben Gertzfield writes: BAW> I really like what you've added here, and intend to merge BAW> those into mimelib. First a couple of general comments and BAW> then some specific ones. BG> Great! I appreciate all the comments and the quick BG> attention. I hope I'm not being a pain, sending off all these BG> rapid-fire patches. *grin* Not at all! I've just got to stop trying to respond to this stuff at 3am and Get Some Sleep. ;) BAW> I wonder if we couldn't generalize some of this into a BAW> "subpart walker", a la os.path.walk()? I'm not going to do BAW> that now, but it's something to keep in mind for later. BG> Yes, eventually this should be generalized into something that BG> will simply decode even non-text attachments (and even replace BG> them with Image/etc objects? Hmm.) but I wanted to get BG> something done now. Agreed. BG> Pipermail is not wholly bad, but it is extremely inefficient. BG> Since so many people are never going to use anything but the BG> built-in archiver, I'd like to make it pretty solid, including BG> behaving well on huge lists. And I applaud you for that! BAW> Awesome! I hope you don't mind that I changed this message BAW> just a little bit: BAW> [Non-text (%(type)s) part of message omitted, filename BAW> %(filename)s]\n BAW> Also, is the trailing newline necessary? BG> Looks fine! I expected lots of things to change. :) BG> The trailing newline is an issue I wanted to address; BG> currently, multiple text parts just show up one after another BG> (if there was a newline between them in the message, they have BG> newlines between them). BG> I'd be happier doing something like how Gnus shows multiple BG> attachments in a message: BG> (snip here) BG> This is the first, text part of the message. BG> [3. Interesting test --- text/plain; test]... BG> This is the (second? third?) text part of the message after BG> the first text attachment. BG> [5. Interesting pic --- image/gif; gm-icon00.gif]... BG> This is the (third? fourth?) text part of the message after BG> the GIF image. BG> (snip here) BG> Now, we're already replacing non-text attachments with a BG> message, but it'd be nice to announce text-attachments too, so BG> things don't get confusing. I think I'm too tired right now to parse this, but I'm happy to leave the newline in for now. BG> Also, I forgot to test what happens with text/html parts. BG> Will they get HTML escaped or will they mess up the document? I'm not sure at the moment. BAW> I'm going to simplify some of the implementations when I BAW> check them in, and I may also change the method names, BAW> although perhaps I should keep yours for `backwards' BAW> compatibility? BAW> Side note: the naming scheme in mimelib.Message is getting BAW> both inconsistent and clumsy. I intend to rectify this when BAW> I merge it into Py2.2. Question: is backwards compatibility BAW> with mimelib 0.x important? BG> Please, please, go ahead and change all the names! I actually BG> agree that mimelib.Message is a big old mess, and the BG> get_foo_bar vs. getfoobar functions kind of got on my BG> nerves. :) I have no attachments whatsoever to the current BG> names, but I think it would be the right thing to do to at BG> least make the old names call the new ones (just segregate BG> them in the documents as a list of compatibility interface BG> names). I'm going to keep the inconsistency for now, but will clean it all up when I merge it into Python 2.2. mimelib 0.5 will also have a couple of methods that are in the wrong module, but again, that'll be cleaned up later. BG> I guess my concept was the reverse; since a "payload" from BG> mimelib.Message can be either a list of payloads OR a single BG> message, my brain called the former a "payload" and the second BG> a "body". But I still don't really know the right BG> terminology.. BG> We should probably come up with some clearer nomenclature, BG> because the current one really confused me. :) BG> Rereading RFC 2045, I see that I subconsciously got my naming BG> scheme from a past reading of it. Here's what RFC 2045 has to BG> say: I'm going to ruminate on this and I'll get the story straight for the merge into Python. But I think you have some good points. Thanks! -Barry From jarrell@vt.edu Mon Sep 17 02:03:54 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Sun, 16 Sep 2001 21:03:54 -0400 Subject: [Mailman-Developers] current snapshot Message-ID: <5.1.0.14.2.20010916210258.039610d0@lennier.cc.vt.edu> Still trying to install bowa-strip in filters, which I think just got deleted out of the repositor? I saw it go by earlier in the update, but wasn't really paying attention to the keys on the items, so dunno if it was a D or not... From barry@zope.com Mon Sep 17 03:05:07 2001 From: barry@zope.com (Barry A. Warsaw) Date: Sun, 16 Sep 2001 22:05:07 -0400 Subject: [Mailman-Developers] current snapshot References: <5.1.0.14.2.20010916210258.039610d0@lennier.cc.vt.edu> Message-ID: <15269.23123.42806.132979@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> Still trying to install bowa-strip in filters, which I think RJ> just got deleted out of the repositor? I saw it go by earlier RJ> in the update, but wasn't really paying attention to the keys RJ> on the items, so dunno if it was a D or not... I was D but I forgot to clean up the Makefile and remove the .cvsignore directory. Next time you do a "cvs up" include the -P flag and the whole filters subdir should go away. -Barry From jarrell@vt.edu Mon Sep 17 16:05:21 2001 From: jarrell@vt.edu (Ron Jarrell) Date: Mon, 17 Sep 2001 11:05:21 -0400 Subject: [Mailman-Developers] current snapshot In-Reply-To: <15269.23123.42806.132979@anthem.wooz.org> References: <5.1.0.14.2.20010916210258.039610d0@lennier.cc.vt.edu> Message-ID: <5.1.0.14.2.20010917110448.039509f0@lennier.cc.vt.edu> At 10:05 PM 9/16/01 -0400, Barry A. Warsaw wrote: >>>>>> "RJ" == Ron Jarrell writes: > > RJ> Still trying to install bowa-strip in filters, which I think > RJ> just got deleted out of the repositor? I saw it go by earlier > RJ> in the update, but wasn't really paying attention to the keys > RJ> on the items, so dunno if it was a D or not... > >I was D but I forgot to clean up the Makefile and remove the >.cvsignore directory. Next time you do a "cvs up" include the -P flag >and the whole filters subdir should go away. I always do a -P -d, but, no, the filters dir didn't go away. Since there's a generated makefile in there... But the make file looks better :-). From rodolfo@linux.org.uy Mon Sep 17 16:36:47 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: Mon, 17 Sep 2001 12:36:47 -0300 Subject: [Mailman-Developers] public.html Message-ID: <20010917123647.736ce2e8.rodolfo@linux.org.uy> Content-type: text/html Bug in Mailman version 2.1a2 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (most recent call last): File "/usr/lib/mailman/scripts/driver", line 96, in run_main main() File "/usr/lib/mailman/Mailman/Cgi/private.py", line 132, in main }, mlist=mlist) File "/usr/lib/mailman/Mailman/Utils.py", line 517, in maketext raise IOError(errno.ENOENT, 'No template file found', templatefile) IOError: [Errno 2] No template file found: 'private.html' Can you confirm if I need to create the private.html and where to put it? (I use the Spanish version) All of my list that I mark as private archive has this problem, you can see one here: http://www.espaciolibre.net/cgi-bin/private/uylug-demoday/ -- ____________________________________________________ -=(( Rodolfo Pilas - rodolfo@linux.org.uy ))=- -==((( Are you ready for XtraLinuX - http://xtralinux.org )))==- -=((____________________________________________________))=- Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From barry@zope.com Mon Sep 17 16:34:03 2001 From: barry@zope.com (Barry A. Warsaw) Date: Mon, 17 Sep 2001 11:34:03 -0400 Subject: [Mailman-Developers] current snapshot References: <5.1.0.14.2.20010916210258.039610d0@lennier.cc.vt.edu> <5.1.0.14.2.20010917110448.039509f0@lennier.cc.vt.edu> Message-ID: <15270.6123.670694.434840@anthem.wooz.org> >>>>> "RJ" == Ron Jarrell writes: RJ> I always do a -P -d, but, no, the filters dir didn't go away. RJ> Since there's a generated makefile in there... Oh right, just rm that Makefile. Also, I just removed the .cvsignore file which would also keep that directory around. RJ> But the make file looks better :-). Good. ;) From dredd@megacity.org Mon Sep 17 21:54:39 2001 From: dredd@megacity.org (Derek Balling) Date: Mon, 17 Sep 2001 13:54:39 -0700 Subject: [Mailman-Developers] Stripping Received headers on anonymous lists Message-ID: [originally posted to -users, but I figured -developers is probably a better forum for it] I mentioned this once before and the general response I got was "it uses them for loop detection, so it leaves them alone", but for anonymous lists (especially ones dealing with sensitive subjects) those received headers can easily give away the identity of the person sending the message, which is a Bad Thing. The X-Been-There flag SHOULD be catching looping, so I'm not worried if this "loop detection of last resort" is removed. This really (IMHO) should be there if we want to be able to consider anonymous lists anonymous. Right now, they're WORSE than anonymous because they give the ILLUSION of anonymity. :( Any thoughts on how this could be done? I'm not a python guy by trade, so I'm sorta lost trying to find where the anonymization takes place to begin with. :) D -- +---------------------+-----------------------------------------+ | dredd@megacity.org | "... And so it begins ... " | | Derek J. Balling | - Ambassador Kosh, Babylon 5 | +---------------------+-----------------------------------------+ From claw@kanga.nu Tue Sep 18 08:41:24 2001 From: claw@kanga.nu (J C Lawrence) Date: Tue, 18 Sep 2001 00:41:24 -0700 Subject: [Mailman-Developers] Stripping Received headers on anonymous lists In-Reply-To: Message from Derek Balling of "Mon, 17 Sep 2001 13:54:39 PDT." References: Message-ID: <30337.1000798884@kanga.nu> On Mon, 17 Sep 2001 13:54:39 -0700 Derek Balling wrote: > I mentioned this once before and the general response I got was > "it uses them for loop detection, so it leaves them alone", but > for anonymous lists (especially ones dealing with sensitive > subjects) those received headers can easily give away the identity > of the person sending the message, which is a Bad Thing. > The X-Been-There flag SHOULD be catching looping, so I'm not > worried if this "loop detection of last resort" is removed. > This really (IMHO) should be there if we want to be able to > consider anonymous lists anonymous. Right now, they're WORSE than > anonymous because they give the ILLUSION of anonymity. :( >From an anonymity perspective, to do it properly ALL headers other than TO/FROM/CC/SUBJECT need to be removed. Its also worth realising that the likely most common use of this feature isn't for anonymity, but is for group presence. Eg a MailMan run tech support list where all official reponses come from the same address. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From dredd@megacity.org Tue Sep 18 14:25:59 2001 From: dredd@megacity.org (Derek Balling) Date: Tue, 18 Sep 2001 06:25:59 -0700 Subject: [Mailman-Developers] Stripping Received headers on anonymous lists In-Reply-To: <30337.1000798884@kanga.nu> References: <30337.1000798884@kanga.nu> Message-ID: >From an anonymity perspective, to do it properly ALL headers other >than TO/FROM/CC/SUBJECT need to be removed. True. So what are the chances of doing this? :) >Its also worth realising that the likely most common use of this >feature isn't for anonymity, but is for group presence. Eg a >MailMan run tech support list where all official reponses come from >the same address. Wouldn't the questions get posted to the list with that same address then, as well? That seems a confusing use of the feature. :) D -- +---------------------+-----------------------------------------+ | dredd@megacity.org | "... And so it begins ... " | | Derek J. Balling | - Ambassador Kosh, Babylon 5 | +---------------------+-----------------------------------------+ From chip@pcc.com Tue Sep 18 14:43:31 2001 From: chip@pcc.com (Chip Hart) Date: Tue, 18 Sep 2001 09:43:31 -0400 Subject: [Mailman-Developers] Mailman, majordomo, mhonarc - Questions about conversion Message-ID: <20010918094331.G91332@pcc.com> Would someone mind confirming my suspicion that the ability to use an external archiver is SITE and not LIST specific? We have a few lists here that wish to use the mailman html/archive process and a few legacy lists that need to maintain the majordomo/mhonarc process. If anyone out there has gone from a majordomo/mhonarc configuration to use mailman - but still maintains the mhonarc utilities as an external archiver and majordomo's mbox archiving - would you mind dropping me a line so I can pester you with a few small questions? Thank you! -- Chip Hart * chip @ pcc.com Physician's Computer Company * http://www.pcc.com/~chip 1 Main Street * Work:800-722-7708 Winooski, VT 05404 * Fax: 802-846-8178 From claw@2wire.com Tue Sep 18 17:52:54 2001 From: claw@2wire.com (J C Lawrence) Date: Tue, 18 Sep 2001 09:52:54 -0700 Subject: [Mailman-Developers] Stripping Received headers on anonymous lists In-Reply-To: Message from Derek Balling of "Tue, 18 Sep 2001 06:25:59 PDT." References: <30337.1000798884@kanga.nu> Message-ID: <17359.1000831974@2wire.com> On Tue, 18 Sep 2001 06:25:59 -0700 Derek Balling wrote: >> From an anonymity perspective, to do it properly ALL headers >> other than TO/FROM/CC/SUBJECT need to be removed. > True. So what are the chances of doing this? :) Source wise its a fairly simple hack. >> Its also worth realising that the likely most common use of this >> feature isn't for anonymity, but is for group presence. Eg a >> MailMan run tech support list where all official reponses come >> from the same address. > Wouldn't the questions get posted to the list with that same > address then, as well? That seems a confusing use of the > feature. :) You're skipping the extesnsible and flexible wonder that is MS Outlook and the population's capacity to properly configure their own mail systems. The times I've seen this done they gang two lists -- one a public list, and the other an internal list that the HelpDesk is subscribed to, with the internal list set with privacy options and REply-To. They'd rather conflate everything into one than fix their mail systems. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From claw@2wire.com Tue Sep 18 17:55:04 2001 From: claw@2wire.com (J C Lawrence) Date: Tue, 18 Sep 2001 09:55:04 -0700 Subject: [Mailman-Developers] Mailman, majordomo, mhonarc - Questions about conversion In-Reply-To: Message from Chip Hart of "Tue, 18 Sep 2001 09:43:31 EDT." <20010918094331.G91332@pcc.com> References: <20010918094331.G91332@pcc.com> Message-ID: <17389.1000832104@2wire.com> On Tue, 18 Sep 2001 09:43:31 -0400 Chip Hart wrote: > Would someone mind confirming my suspicion that the ability to use > an external archiver is SITE and not LIST specific? Depends how you implement it. If you use the plug-it-into-mailman approach, then yes, its site specific. Nothing however prevents you from using an external archiver hung off a subscribed address. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. claw@kanga.nu He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. From rodolfo@linux.org.uy Tue Sep 18 18:53:35 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: Tue, 18 Sep 2001 14:53:35 -0300 Subject: [Mailman-Developers] public.html In-Reply-To: <20010918133941.D8408@freemail.hu> References: <20010917123647.736ce2e8.rodolfo@linux.org.uy> <20010918133941.D8408@freemail.hu> Message-ID: <20010918145335.364bbfce.rodolfo@linux.org.uy> El Tue, 18 Sep 2001 13:39:42 +0200 Szilard Vizi ha escrito: > > IOError: [Errno 2] No template file found: 'private.html' > > (I use the Spanish version) > > In your case the problem is that Juan Carlos (the Spanish > translation maintiner) does not renamed his private.txt translation > to private.html > cd /usr/local/mailman/templates/es/ > mv private.txt private.html OK! it works! But the private.html do not replace any macro like %(listname)s and when you access the server try with the following URL: http://www.server.com/mailman/private/mylist/%(basepath)s/ You can see my system at http://www.espaciolibre.net/cgi-bin/private/uylug-demoday/ Now I stop the bug report about template file not found, but I feel that the system has a more complex problem here and perhaps you need to fix it for the 2.1a3. -- ____________________________________________________ -=(( Rodolfo Pilas - rodolfo@linux.org.uy ))=- -==((( Are you ready for XtraLinuX - http://xtralinux.org )))==- -=((____________________________________________________))=- Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From dredd@megacity.org Tue Sep 18 18:59:07 2001 From: dredd@megacity.org (Derek Balling) Date: Tue, 18 Sep 2001 10:59:07 -0700 Subject: [Mailman-Developers] Stripping Received headers on anonymous lists In-Reply-To: <17359.1000831974@2wire.com> References: <30337.1000798884@kanga.nu> <17359.1000831974@2wire.com> Message-ID: At 9:52 AM -0700 9/18/01, J C Lawrence wrote: >On Tue, 18 Sep 2001 06:25:59 -0700 >Derek Balling wrote: > >>> From an anonymity perspective, to do it properly ALL headers >>> other than TO/FROM/CC/SUBJECT need to be removed. > >> True. So what are the chances of doing this? :) > >Source wise its a fairly simple hack. Not to sound lame, but for someone like myself who's more a follower of the camel than the snake, can you point me in the right direction? :) D -- +---------------------+-----------------------------------------+ | dredd@megacity.org | "... And so it begins ... " | | Derek J. Balling | - Ambassador Kosh, Babylon 5 | +---------------------+-----------------------------------------+ From rodolfo@linux.org.uy Wed Sep 19 00:07:35 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: Tue, 18 Sep 2001 20:07:35 -0300 Subject: [Mailman-Developers] Backup mailman Message-ID: <20010918200735.0bb7d8f6.rodolfo@linux.org.uy> This is a multi-part message in MIME format. --Multipart_Tue__18_Sep_2001_20:07:35_-0300_08227f00 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit First of all I wish to confirm that I do not understand MM 100% and also I do not know python. I has lost a complete list (user & confs) because a corrupt config.db. For this reason I has just made a small script that create a backup.tar.gz of each list config and subscriber-list. (a patched list_lists (list_names) and a bash script) I think this backup script to be run one time a day. Ok, I understand that may be easy to do something like this in python... you have here my idea of a backup, if you have something better, please, notice me! -- ____________________________________________________ -=(( Rodolfo Pilas - rodolfo@linux.org.uy ))=- -==((( Are you ready for XtraLinuX - http://xtralinux.org )))==- -=((____________________________________________________))=- Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 --Multipart_Tue__18_Sep_2001_20:07:35_-0300_08227f00 Content-Type: application/octet-stream; name="backup_mailman" Content-Disposition: attachment; filename="backup_mailman" Content-Transfer-Encoding: base64 IyEvYmluL2Jhc2gKCk1NSE9NRT0nL3Vzci9saWIvbWFpbG1hbicKTU1CSU49JE1NSE9NRScvYmlu JwoKQ09ORkxJU1Q9J2NvbmYnClVTRVJMSVNUPSd1c2VyJwoKQkFDS0RJUj1gZGF0ZSArJVklbSVk YAoKbWtkaXIgJEJBQ0tESVIKCiRNTUJJTi9saXN0X25hbWVzID4gJEJBQ0tESVIvbGlzdF9uYW1l cwoKRklMRVM9YGNhdCAkQkFDS0RJUicvbGlzdF9uYW1lcydgCgpmb3IgZmlsZSBpbiAkRklMRVMK ZG8KICAgICAgICAkTU1CSU4vY29uZmlnX2xpc3QgIC1vICRCQUNLRElSLyRmaWxlLiRDT05GTElT VCAkZmlsZQogICAgICAgICRNTUJJTi9saXN0X21lbWJlcnMgLW8gJEJBQ0tESVIvJGZpbGUuJFVT RVJMSVNUICRmaWxlCmRvbmUKCi9iaW4vdGFyIGN6ZiBiYWNrdXAtTU0kQkFDS0RJUi50Z3ogICRC QUNLRElSLyoKcm0gLVIgJEJBQ0tESVIK --Multipart_Tue__18_Sep_2001_20:07:35_-0300_08227f00 Content-Type: application/octet-stream; name="list_names" Content-Disposition: attachment; filename="list_names" Content-Transfer-Encoding: base64 IyEgL3Vzci9iaW4vZW52IHB5dGhvbgojCiMgQ29weXJpZ2h0IChDKSAxOTk4LDE5OTksMjAwMCBi eSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCiMKIyBUaGlzIHByb2dyYW0gaXMg ZnJlZSBzb2Z0d2FyZTsgeW91IGNhbiByZWRpc3RyaWJ1dGUgaXQgYW5kL29yCiMgbW9kaWZ5IGl0 IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKIyBhcyBw dWJsaXNoZWQgYnkgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbjsgZWl0aGVyIHZlcnNpb24g MgojIG9mIHRoZSBMaWNlbnNlLCBvciAoYXQgeW91ciBvcHRpb24pIGFueSBsYXRlciB2ZXJzaW9u LgojIAojIFRoaXMgcHJvZ3JhbSBpcyBkaXN0cmlidXRlZCBpbiB0aGUgaG9wZSB0aGF0IGl0IHdp bGwgYmUgdXNlZnVsLAojIGJ1dCBXSVRIT1VUIEFOWSBXQVJSQU5UWTsgd2l0aG91dCBldmVuIHRo ZSBpbXBsaWVkIHdhcnJhbnR5IG9mCiMgTUVSQ0hBTlRBQklMSVRZIG9yIEZJVE5FU1MgRk9SIEEg UEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZQojIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNl IGZvciBtb3JlIGRldGFpbHMuCiMgCiMgWW91IHNob3VsZCBoYXZlIHJlY2VpdmVkIGEgY29weSBv ZiB0aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UKIyBhbG9uZyB3aXRoIHRoaXMgcHJvZ3Jh bTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZSAKIyBGb3VuZGF0aW9uLCBJbmMu LCA1OSBUZW1wbGUgUGxhY2UgLSBTdWl0ZSAzMzAsIEJvc3RvbiwgTUEgMDIxMTEtMTMwNywgVVNB LgoKIiIiTGlzdCBhbGwgbWFpbGluZyBsaXN0cy4KClVzYWdlOiAlKHByb2dyYW0pcyBbb3B0aW9u c10KCldoZXJlOgoKICAgIC0tYWR2ZXJ0aXNlZAogICAgLWEKICAgICAgICBMaXN0IG9ubHkgdGhv c2UgbWFpbGluZyBsaXN0cyB0aGF0IGFyZSBwdWJsaWNhbGx5IGFkdmVydGlzZWQKCiAgICAtLXZp cnR1YWwtaG9zdC1vdmVydmlldz1kb21haW4KICAgIC1WIGRvbWFpbgogICAgICAgIExpc3Qgb25s eSB0aG9zZSBtYWlsaW5nIGxpc3RzIHRoYXQgYXJlIGhvbWVkIHRvIHRoZSBnaXZlbiB2aXJ0dWFs CiAgICAgICAgZG9tYWluLiAgVGhpcyBvbmx5IHdvcmtzIGlmIHRoZSBWSVJUVUFMX0hPU1RfT1ZF UlZJRVcgdmFyaWFibGUgaXMKICAgICAgICBzZXQuCgogICAgLS1oZWxwCiAgICAtaAogICAgICAg IFByaW50IHRoaXMgdGV4dCBhbmQgZXhpdC4KCiIiIgoKaW1wb3J0IHN5cwppbXBvcnQgZ2V0b3B0 CmltcG9ydCBwYXRocwoKZnJvbSBNYWlsbWFuIGltcG9ydCBtbV9jZmcKZnJvbSBNYWlsbWFuIGlt cG9ydCBNYWlsTGlzdApmcm9tIE1haWxtYW4gaW1wb3J0IFV0aWxzCmZyb20gTWFpbG1hbiBpbXBv cnQgRXJyb3JzCmZyb20gTWFpbG1hbi5pMThuIGltcG9ydCBfCgpwcm9ncmFtID0gc3lzLmFyZ3Zb MF0KCmRlZiB1c2FnZShjb2RlLCBtc2c9JycpOgogICAgcHJpbnQgPj4gc3lzLnN0ZGVyciwgXyhf X2RvY19fKQogICAgaWYgbXNnOgogICAgICAgIHByaW50ID4+IHN5cy5zdGRlcnIsIG1zZwogICAg c3lzLmV4aXQoY29kZSkKCgoMCmRlZiBtYWluKCk6CiAgICB0cnk6CiAgICAgICAgb3B0cywgYXJn cyA9IGdldG9wdC5nZXRvcHQoc3lzLmFyZ3ZbMTpdLCAnYVY6aCcsCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgWydhZHZlcnRpc2VkJywgJ3ZpcnR1YWwtaG9zdC1vdmVydmlldz0n LAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAnaGVscCddKQogICAgZXhjZXB0 IGdldG9wdC5lcnJvciwgbXNnOgogICAgICAgIHVzYWdlKDEsIG1zZykKCiAgICBhZHZlcnRpc2Vk ID0gMAogICAgdmhvc3QgPSBOb25lCgogICAgZm9yIG9wdCwgYXJnIGluIG9wdHM6CiAgICAgICAg aWYgb3B0IGluICgnLWgnLCAnLS1oZWxwJyk6CiAgICAgICAgICAgIHVzYWdlKDApCiAgICAgICAg ZWxpZiBvcHQgaW4gKCctYScsICctLWFkdmVydGlzZWQnKToKICAgICAgICAgICAgYWR2ZXJ0aXNl ZCA9IDEKICAgICAgICBlbGlmIG9wdCBpbiAoJy1WJywgJy0tdmlydHVhbC1ob3N0LW92ZXJ2aWV3 Jyk6CiAgICAgICAgICAgIHZob3N0ID0gYXJnCgogICAgbmFtZXMgPSBVdGlscy5saXN0X25hbWVz KCkKICAgIG5hbWVzLnNvcnQoKQoKICAgIG1saXN0cyA9IFtdCiAgICBsb25nZXN0ID0gMAogICAg Zm9yIG4gaW4gbmFtZXM6CiAgICAgICAgbWxpc3QgPSBNYWlsTGlzdC5NYWlsTGlzdChuLCBsb2Nr PTApCiAgICAgICAgaWYgYWR2ZXJ0aXNlZCBhbmQgbm90IG1saXN0LmFkdmVydGlzZWQ6CiAgICAg ICAgICAgIGNvbnRpbnVlCiAgICAgICAgaWYgdmhvc3QgYW5kIG1tX2NmZy5WSVJUVUFMX0hPU1Rf T1ZFUlZJRVcgYW5kIFwKICAgICAgICAgICAgICAgdmhvc3QuZmluZChtbGlzdC53ZWJfcGFnZV91 cmwpID09IC0xIGFuZCBcCiAgICAgICAgICAgICAgIG1saXN0LndlYl9wYWdlX3VybC5maW5kKHZo b3N0KSA9PSAtMToKICAgICAgICAgICAgY29udGludWUKICAgICAgICBtbGlzdHMuYXBwZW5kKG1s aXN0KQogICAgICAgIGxvbmdlc3QgPSBtYXgobGVuKG1saXN0LnJlYWxfbmFtZSksIGxvbmdlc3Qp CgogICAgaWYgbm90IG1saXN0czoKICAgICAgICBwcmludCBfKCdObyBtYXRjaGluZyBtYWlsaW5n IGxpc3RzIGZvdW5kJykKICAgICAgICByZXR1cm4KCiMgICAgcHJpbnQgbGVuKG1saXN0cyksIF8o J21hdGNoaW5nIG1haWxpbmcgbGlzdHMgZm91bmQ6JykKIyAgICBmb3JtYXQgPSAnJSUlZHMgLSAl JS4lZHMnICUgKGxvbmdlc3QsIDc3IC0gbG9uZ2VzdCkKICAgIGZvciBtbGlzdCBpbiBtbGlzdHM6 CiMgICAgICAgIGRlc2NyaXB0aW9uID0gbWxpc3QuZGVzY3JpcHRpb24gb3IgXygnW25vIGRlc2Ny aXB0aW9uIGF2YWlsYWJsZV0nKQojICAgICAgICBwcmludCAnICAgJywgZm9ybWF0ICUgKG1saXN0 LnJlYWxfbmFtZSwgZGVzY3JpcHRpb24pCglwcmludCBtbGlzdC5yZWFsX25hbWUgCiAgICAgICAg ICAgIAoKaWYgX19uYW1lX18gPT0gJ19fbWFpbl9fJzoKICAgIG1haW4oKQo= --Multipart_Tue__18_Sep_2001_20:07:35_-0300_08227f00-- From mrbill@mrbill.net Fri Sep 21 01:53:41 2001 From: mrbill@mrbill.net (Bill Bradford) Date: Thu, 20 Sep 2001 19:53:41 -0500 Subject: [Mailman-Developers] HELP! Message-ID: <20010920195341.O14220@mrbill.net> Now, my list(s) have gotten to the point that where if I dont clear out the qfiles directory every four to six hours, I start getting stuff like this in ~mailman/logs/error: Sep 20 15:40:04 2001 qrunner(19365): Traceback (most recent call last): Sep 20 15:40:04 2001 qrunner(19365): File "/usr/local/mailman/cron/qrunner", l ine 282, in ? Sep 20 15:40:04 2001 qrunner(19365): kids = main(lock) Sep 20 15:40:04 2001 qrunner(19365): File "/usr/local/mailman/cron/qrunner", l ine 252, in main Sep 20 15:40:04 2001 qrunner(19365): keepqueued = dispose_message(mlist, ms g, msgdata) Sep 20 15:40:04 2001 qrunner(19365): File "/usr/local/mailman/cron/qrunner", l ine 121, in dispose_message Sep 20 15:40:04 2001 qrunner(19365): if BouncerAPI.ScanMessages(mlist, mime msg): Sep 20 15:40:04 2001 qrunner(19365): File "/usr/local/mailman/Mailman/Bouncers /BouncerAPI.py", line 59, in ScanMessages Sep 20 15:40:04 2001 qrunner(19365): addrs = func(msg) Sep 20 15:40:04 2001 qrunner(19365): File "/usr/local/mailman/Mailman/Bouncers /DSN.py", line 46, in process Sep 20 15:40:04 2001 qrunner(19365): if string.lower(msg.gettype()) <> 'mul tipart/report' or \ Sep 20 15:40:04 2001 qrunner(19365): File "/usr/local/lib/python2.1/string.py" , line 51, in lower Sep 20 15:40:04 2001 qrunner(19365): return s.lower() Sep 20 15:40:04 2001 qrunner(19365): AttributeError : 'None' object has no attr ibute 'lower' This is 2.0.6, and it works fine otherwise. Suggestions? Python 2.1... Has worked fine for months... bill -- Bill Bradford mrbill@mrbill.net Austin, TX From mrbill@mrbill.net Fri Sep 21 22:31:07 2001 From: mrbill@mrbill.net (Bill Bradford) Date: Fri, 21 Sep 2001 16:31:07 -0500 Subject: [Mailman-Developers] HELP! In-Reply-To: <20010920195341.O14220@mrbill.net> References: <20010920195341.O14220@mrbill.net> Message-ID: <20010921163107.Y14220@mrbill.net> On Thu, Sep 20, 2001 at 07:53:41PM -0500, Bill Bradford wrote: > Now, my list(s) have gotten to the point that where if I dont clear > out the qfiles directory every four to six hours, I start getting > stuff like this in ~mailman/logs/error: I'm seeing an interesting possible-bug in 2.0.6. Whenever it gets close to ~290 files in ~mailman/qfiles, it starts bombing out with the error I posted before. When qfiles is cleaned out, or doesnet have that many messages backed up, it works fine. Possible overflow somewhere? I have yet to look at 2.1, so I dont know if its susceptible to this or not. Bill -- Bill Bradford mrbill@mrbill.net Austin, TX From Dan Mick Sat Sep 22 01:52:57 2001 From: Dan Mick (Dan Mick) Date: Fri, 21 Sep 2001 17:52:57 -0700 (PDT) Subject: [Mailman-Developers] Maybe this is old news: mimelib 0.6 no good for Mailman 2.1a3 Message-ID: <200109220052.RAA21553@utopia.West.Sun.COM> Mailman current CVS and mimelib 0.6 are incompatible; Generator.write() has changed. Don't try to combine them. (I've sent details to Barry.) From barry@zope.com Sat Sep 22 04:07:41 2001 From: barry@zope.com (Barry A. Warsaw) Date: Fri, 21 Sep 2001 23:07:41 -0400 Subject: [Mailman-Developers] Maybe this is old news: mimelib 0.6 no good for Mailman 2.1a3 References: <200109220052.RAA21553@utopia.West.Sun.COM> Message-ID: <15276.125.449505.466106@anthem.wooz.org> >>>>> "DM" == Dan Mick writes: DM> Mailman current CVS and mimelib 0.6 are incompatible; DM> Generator.write() has changed. Don't try to combine them. DM> (I've sent details to Barry.) Sorry folks, I've been really busy. This is a known incompatibility. I will fix this and then release the next MM alpha. -Barry From info@emfpollutioncontrol.com Sat Sep 22 09:28:42 2001 From: info@emfpollutioncontrol.com (info@emfpollutioncontrol.com) Date: Sat, 22 Sep 2001 04:28:42 -0400 Subject: [Mailman-Developers] Sick of the 21st Century ? Message-ID: --=200109221825= Content-Type: text/plain;charset=US-ASCII We all struggle mentally to keep pace with a changing world. In the same way our bodies struggle to adapt to the waste of the technology that we use. The most pervasive of these wastes comes from every piece of electric equipment in our homes and offices. We have a natural bio-rhythm, but because this artificial, very powerful and all-pervading Electro-Magnetic Field is so strong, our natural bio-rhythm is forced to respond to the frequency of our computers or mobile phones rather than that of the natural environment. Some of the more commonly reported symptoms of EMF 'poisoning' are: <> A headache after working at the computer, or being under lights - especially fluorescents. <> A migraine that lasts for days. <> Allergies. <> Being "off color" or a feeling of internal disharmony. So far, we don't know if there is a "snowball" effect from daily Electro-Magnetic Radiation exposure. The trouble is, when we find the true answers to these questions, it's often too late. You may have heard of "sick building syndrome" or "chronic fatigue syndrome". These are often related to EMF pollution. To find out more and to perform your self diagnosis, click here > --=200109221825=-- From donfede@casagrau.org Sat Sep 22 21:23:41 2001 From: donfede@casagrau.org (Federico Grau) Date: Sat, 22 Sep 2001 16:23:41 -0400 Subject: [Mailman-Developers] privacy problems with web interface Message-ID: <20010922162341.A31731@casagrau.org> Hello: We're running a 16K member mailing list on version 1.1 and running into a significant privacy issue regarding membership management. As distributed, Mailman makes it trivial to discover if a given address is in fact a subscriber. If you suspect dev@null.com has joined a list, go to the user page and enter his address to subscribe; you'll get back a revealing reply 'You already belong, dummy'.. We initially yanked large chunks of html from the general list information page, but that removes all web-based user options. Our ideal outcome is a General List Info Page with two actions: No password section: Current users get passwords (if any) mailed; with the web page not saying if any address is subscribed or not. If not a subscriber, Mailman would send a "subscription confirmation" notice to the potential member. (This also alerts the 'victim' of potential abuse.) Password presented sections: Users w/ password see no feedback until after entering a valid ID and pw; i.e. both non-existent users and existing ones w/bad pw's are both met with "Sorry, wrong password" as in a *nix login. We looked at modifying the html on the user pages but the python module "handle_opts" seems hard-coded into giving revealing responses. We also glanced at Mailman 2.0.6 but it seemed to offer the same behavior. Has anyone else already looked into this issue, and proposed code to solve it? We are considering writing a patch for "handle_opts" and and submitting it but 1) don't want to fork the code, and 2) don't want to duplicate/waste the effort. thanks, David and Federico From che@debian.org Tue Sep 25 12:33:03 2001 From: che@debian.org (Ben Gertzfield) Date: Tue, 25 Sep 2001 20:33:03 +0900 Subject: [Mailman-Developers] Proper solution to Mailman CVS's Japanese problems Message-ID: <87sndbec9c.fsf@nausicaa.interq.or.jp> I had a flash of inspiration and realized the correct way to solve Mailman's Japanese problems once and for all. Kikuchi-san's solution, which converted all incoming emails to EUC-JP for archiving/admin purposes, then re-converted them to ISO-2022-JP, is fine for users who do not use an external archiver, or depend on PGP-signed mails to come through properly. However, this is not the best solution. Currently, the Japanese localized messages for Mailman are stored in EUC-JP (an 8-bit encoding). This presents a problem, as Japanese emails are inherently ISO-2022-JP, a very different (7-bit) encoding, and displaying an EUC-JP web page with an ISO-2022-JP encoded email on it just leads to garbage. The "proper" solution is to make all of Mailman's Japanese web pages be stored internally in ISO-2022-JP; this way, we can include emails almost verbatim (see below) and never convert their charsets, which makes external archiving with Japanese a reality, as well as no longer possibly messing up PGP signed messages when converting the encoding back and forth. In addition, with this solution, we won't need to add an extra dependancy on the kconv Python module, which Kikuchi-san's method requires for conversion back and forth between ISO-2022-JP <-> EUC-JP. The one catch is that, as ISO-2022-JP is a 7-bit medium, it can contain the characters <, >, and & -- even within the non-ASCII parts of the text. These characters are familiar to all of us as the three special HTML entities that must be represented in HTML documents as < > and & respectively. Unfortunately, you can't just take ISO-2022-JP text and globally search-and-replace these three characters, as they must remain verbatim in the non-ASCII sections of the encoded text, or the Japanese will be rendered as garbage! I have coded up a solution to this problem. The following module I've named JisEscape (the name can be changed :) will take any JIS-encoded text (ISO-2022-JP, the Japanese email charset, is a subset of JIS) and escape <, >, and & within *ONLY* the ASCII and ASCII-like segments of the text, while leaving them as-is in the Japanese-encoded segments. We can use this to process any messages/multipart message segments that have charset=iso-2022-jp, and display them properly escaped in the Mailman admin pages, as well as the Pipermail archives. Since this solution does not convert the message's charset at all, it works perfectly even with external archiving solutions, like Hypermail. I'm Cc:ing Kikuchi-san on this mail, because I believe he's the one who did most of the work translating Mailman's messages and web pages into Japanese. Kikuchi-san, what do you think of this solution? Also, Barry, I hope this solution makes sense to you. We can keep the localized Japanese messages that Mailman outputs at the shell in EUC-JP, or change them to ISO-2022-JP; I'm not sure where in the Mailman source we specify the encoding for the 'ja' messages, but it should be possible to specify that somewhere. In my experience, most Japanese-aware terminals can understand both EUC-JP and ISO-2022-JP, but I'm not certain of that. (At least, krxvt supports them both. :) Module follows. I'm willing to also do the work of integrating this with Mailman. It won't take much; instead of blindly HTML-escaping every message, we'll only do so if the message [or message part] is not ISO-2022-JP, and if it is ISO-2022-JP, we'll run it through this module. I can also convert the HTML pages and internal messages to ISO-2022-JP. I'm not sure whether this module should be made part of Python proper or not, although it would be extremely useful for anyone who is dealing with Japanese email and the web as a general solution. Barry, if you think it's proper, should I submit it upstream to get it integrated into Python proper? Right now, the cgi.escape() function does something similar to this, but is not JIS-aware. Ben #!/usr/bin/env python # JisEscape.py # # Written 2001-09-25 by Ben Gertzfield # # Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License # as published by the Free Software Foundation; either version 2 # of the License, or (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. import sys class JisEscape: """Safely HTML escape JIS (Japanese) encoded text. JIS (of which ISO-2022-JP, the encoding method used for Japanese email, is a subset) is a 7-bit encoding that encompasses several Japanese character sets, as well as ASCII. To properly display JIS on the World Wide Web, the usual HTML substitutions (< for <, > for >, and & for &) must be treated with care; inside JIS-encoded text, if <, >, or & appear inside a part of the document in a Japanese character set, they MUST be left verbatim. However, as JIS text switches states between ASCII-like character sets and Japanese character based on a set of escape codes, we must be sure to properly escape <, >, and & inside the ASCII-like segments, while leaving the Japanese segments verbatim. This module will safely prepare text containing (for example) a Japanese email for display on the Web. """ ESC = "\x1b" SO = "\x0e" SI = "\x0f" # Possible states for JIS-encoded text. NON_JIS = 0 # Encoding not specified JIS_ROMAN = 1 # modified ASCII: \ = yen, ~ = overbar ASCII = 2 # ASCII HANKAKU = 3 # half-width katakana (JIS X 0201-1997) JIS_C_6226_1978 = 4 # old JIS (JIS C 6226-1978) JIS_X_0208_1983 = 5 # updated JIS (JIS X 0208-1983) JIS_X_0208_1997 = 6 # modern JIS (JIS X 0208:1997) JIS_X_0212_1990 = 7 # JIS supplement (JIS X 0212-1990) NEC_KANJI = 8 # NEC kanji HANKAKU_START = 9 # shift to half-width katakana (keep old state) HANKAKU_END = 10 # return to old state escapes = { ESC + "(J" : JIS_ROMAN, ESC + "(H" : JIS_ROMAN, ESC + "(B" : ASCII, ESC + "(I" : HANKAKU, ESC + "$@" : JIS_C_6226_1978, ESC + "$B" : JIS_X_0208_1983, ESC + "&@" + ESC + "$B" : JIS_X_0208_1997, ESC + "$(D" : JIS_X_0212_1990, ESC + "K" : NEC_KANJI, SO : HANKAKU_START, SI : HANKAKU_END, } def __init__(self, text): """Create the JIS object, initialized to the value of text. As JIS text does not necessarily start in any specific character set, the object's state is initialized to the non-JIS state. This can be updated by checkJisEscape(). """ self.text = text self.state = self.NON_JIS self.last_state = self.NON_JIS def HTMLEscape(self): """Return the JIS encoded text with special HTML entities escaped. This function returns a string with the special HTML entities (<, >, and &) safely escaped as < > and & respectively. It is aware of JIS encoding rules, and as such will not escape these characters when they are inside Japanese-encoded segments of the text. However, as JIS encoded text can contain ASCII (and ASCII-like) segments, it will escape these three characters within the non-Japanese segments of the string. """ out = "" count = 0 while (count < len(self.text)): # Check if the current character is a control character. if self.isControl(self.text[count]): # If so, does it start a JIS escape? length = self.checkJisEscape(self.text[count:]) if length: # Yes: copy the escape to the output string and skip # forward that many characters. out = out + self.text[count:count + length] count = count + length else: # No: just copy and move forward one character. out = out + self.text[count] count = count + 1 else: # If it's not a control character, are we in a part # of the string that's ASCII-like (i.e. HTML escapable?) if self.htmlEscapableState(): if self.text[count] == '<': out = out + '<' elif self.text[count] == '>': out = out + '>' elif self.text[count] == '&': out = out + '&' else: out = out + self.text[count] else: out = out + self.text[count] count = count + 1 return out def isControl(self, char): """Return true if char is a control character.""" if 0x00 <= ord(char) <= 0x1f: return 1 # Check for DEL as well. elif char == chr(0x7f): return 1 else: return 0 def checkJisEscape(self, substring): """Update the state of the JIS text if substring is a JIS escape. Checks if substring starts with a JIS escape, and if so, updates the object's state (and last_state, if needed) attributes to reflect the current character set specified. Returns the length of the escape that the substring starts with, or None if the substring does not start with a JIS escape. """ # Check each of the possible JIS escapes. for e in self.escapes.keys(): # If substring begins with one of them.. if substring[0:len(e)] == e: # First, check if we're ending a half-width katakana # segment -- we better have started one first! if self.escapes[e] == self.HANKAKU_END: if self.state == self.HANKAKU_START: self.state = self.last_state self.last_state = self.NON_JIS else: continue else: # Are we starting a half-width katakana state? # Save the old state in last_state if so. if (self.escapes[e] == self.HANKAKU_START): self.last_state = self.state # In any case, update the object's JIS state. self.state = self.escapes[e] return len(e) # if we've gotten here, substring does not begin with an escape. return None def htmlEscapableState(self): """Return true if the object is currently in an HTML-escapable state. JIS text includes text in both Japanese and ASCII-like character sets; this function returns true when the object is in one of the ASCII-like charsets, signifying that the special HTML characters <, >, and & should be escaped. """ if (self.state == self.JIS_ROMAN or self.state == self.ASCII or self.state == self.NON_JIS): return 1 else: return 0 # If called as a standalone script, just HTML escape JIS-encoded stdin. if __name__ == '__main__': text = sys.stdin.read() jis = JisEscape(text) print jis.HTMLEscape() From tkikuchi@is.kochi-u.ac.jp Tue Sep 25 14:28:30 2001 From: tkikuchi@is.kochi-u.ac.jp (Tokio Kikuchi) Date: Tue, 25 Sep 2001 22:28:30 +0900 Subject: [Mailman-Developers] Proper solution to Mailman CVS's Japanese problems References: <87sndbec9c.fsf@nausicaa.interq.or.jp> Message-ID: <3BB0867E.9A28DDE7@is.kochi-u.ac.jp> Ben Gertzfield wrote: > > I had a flash of inspiration and realized the correct way to solve > Mailman's Japanese problems once and for all. Well, (snip) > The one catch is that, as ISO-2022-JP is a 7-bit medium, it can > contain the characters <, >, and & -- even within the non-ASCII parts > of the text. There are '\'s in ISO-2022-JP (and in Shift_JIS, also) and that will make headake when you want to match or search within text. Things are not easy and I am rather decided to teach Japanese users to use 'standard' coding. * Use ISO-2022-JP in mail messages * Not Shift_JIS, nor EUC-JP * No HTML or attachments * Hankaku is worst of all, because it cannot be automatically distinguished -- Tokio From rodolfo@linux.org.uy Tue Sep 25 19:11:25 2001 From: rodolfo@linux.org.uy (Rodolfo Pilas) Date: Tue, 25 Sep 2001 15:11:25 -0300 Subject: [Mailman-Developers] CPU Usage Message-ID: <20010925151125.77e01be4.rodolfo@linux.org.uy> Two mails about CPU usage: ----------------------------------------- Date: Tue, 25 Sep 2001 00:50:33 -0300 From: Rodolfo Pilas To: mailman-users@python.org Subject: [Mailman-Users] CPU Usage in 2.1a2 Hello, Perhaps somebody can explain me why I have a task (mailman) to eat all of my CPU: 60 processes: 56 sleeping, 4 running, 0 zombie, 0 stopped CPU states: 5.1% user, 94.8% system, 0.0% nice, 0.0% idle Mem: 259688K av, 154984K used, 104704K free, 0K shrd, 90484K buff Swap: 385552K av, 12004K used, 373548K free 25160K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 25893 root 14 0 3688 3688 2468 R 99.0 1.4 2:42 python bin/mailmanctl start 25899 root 2 0 924 924 732 R 0.7 0.3 0:01 top Sometimes I have two python task eating 50% of my CPU each one. It is normal? How many time these task are overload the CPU? ---------------------- Date: Mon, 24 Sep 2001 23:57:03 -0400 From: David Ball To: Rodolfo Pilas Subject: Re: [Mailman-Users] CPU Usage in 2.1a2 I have experienced the same problem recently (v2.0.6), and ended up having to disable the Mailman web interface as Python2.1 procs were taking down my machine (a mere P75 w/16MB or ram, which may account for the problem). Unless I killed the processes immediately, all daemons would eventually shut down (sshd, apache, even login), requiring me to reboot the machine when I got home. ------------------------------ -- Rodolfo Pilas Quien los puso a estos tipos donde estan, rodolfo@linux.org.uy Quien los deja seguir en su lugar, http://rodolfo.pilas.net Quien los baja ahora de su altar, ICQ #17461636 Quien les paga para que hagan lo que haran http://xtralinux.org -=# Apocalipsis Now % Cuarteto de Nos #=- Public GnuPG key: http://www.keyserver.net 1024D/57153363 2001-06-02 key fingerprint = DAAE 3246 3F7D A420 B7A0 48A5 D120 C773 5715 3363 From che@debian.org Wed Sep 26 00:50:30 2001 From: che@debian.org (Ben Gertzfield) Date: Wed, 26 Sep 2001 08:50:30 +0900 Subject: [Mailman-Developers] CPU Usage In-Reply-To: <20010925151125.77e01be4.rodolfo@linux.org.uy> (Rodolfo Pilas's message of "Tue, 25 Sep 2001 15:11:25 -0300") References: <20010925151125.77e01be4.rodolfo@linux.org.uy> Message-ID: <87hetqomnt.fsf@nausicaa.interq.or.jp> >>>>> "Rodolfo" == Rodolfo Pilas writes: Rodolfo> Perhaps somebody can explain me why I have a task Rodolfo> (mailman) to eat all of my CPU: Is this on a huge list? Try turning off archiving or switching to an external archiver like hypermail. The internal archiver, pipermail, is a monstrous hack and is not up to the job of real-time archiving of large (> 600 messages a day) lists.. Ben -- Brought to you by the letters I and J and the number 5. "A yonker is a young man." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From michael@cmo.uqam.ca Wed Sep 26 02:53:23 2001 From: michael@cmo.uqam.ca (Michael Totschnig) Date: Tue, 25 Sep 2001 21:53:23 -0400 Subject: [Mailman-Developers] bug raised by roster when accessing subscription list Message-ID: <86u1xqg1kc.fsf@cmo.uqam.ca> The following is the error output when I try to access the list of subscribers from the listinfo page on a 2.1a3 system. Regards, Michael Bug in Mailman version 2.1a3 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (most recent call last): File "/var/Mailman/scripts/driver", line 96, in run_main main() File "/var/Mailman/Mailman/Cgi/roster.py", line 106, in main replacements = mlist.GetAllReplacements(lang) File "/var/Mailman/Mailman/HTMLFormatter.py", line 377, in GetAllReplacements d.update({"": self.FormatUsers(0, lang), File "/var/Mailman/Mailman/HTMLFormatter.py", line 79, in FormatUsers concealed = _( File "/var/Mailman/Mailman/i18n.py", line 83, in _ return _x(s, sys._getframe(1)) File "/var/Mailman/Mailman/i18n.py", line 71, in _x return _translation.gettext(s) % dict TypeError: an integer is required Python information: VariableValue sys.version 2.1.1 (#1, Aug 28 2001, 19:51:39) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] sys.executable /usr/bin/python2.1 sys.prefix /usr sys.exec_prefix /usr sys.path /usr sys.platform linux2 Environment variables: VariableValue DOCUMENT_ROOT /var/www/html SERVER_ADDR 132.208.95.195 HTTP_ACCEPT_ENCODING x-gzip; q=1.0, gzip; q=1.0, identity CONTENT_LENGTH 51 CONTENT_TYPE application/x-www-form-urlencoded PATH_TRANSLATED /var/www/html/forum-uull REMOTE_ADDR 132.208.95.195 SERVER_SOFTWARE Apache/1.3.19 (Unix) (Red-Hat/Linux) mod_ssl/2.8.1 OpenSSL/0.9.6 DAV/1.0.2 PHP/4.0.4pl1 mod_perl/1.24_01 GATEWAY_INTERFACE CGI/1.1 HTTP_COOKIE $Version="1"; forum-uull:admin="2802000000691030b13b732800000063623963623866653536623737373031373836613636393464356538323366306334303564313064"; $Path="/mailman/", $Version="1"; forum-uull:user:michael@cmo.uqam.ca="280200000069312fb13b732800000062363361613734663463373266633936653834333161343638643461373461373162383030616663"; $Path="/mailman/" HTTP_ACCEPT_LANGUAGE de, fr_CA, en REMOTE_PORT 33758 SERVER_PORT 80 HTTP_CONNECTION Keep-Alive HTTP_USER_AGENT Mozilla/5.0 (compatible; Konqueror/2.1.2; X11) HTTP_ACCEPT_CHARSET iso-8859-1;q=1.0, *;q=0.9, utf-8;q=0.8 HTTP_ACCEPT text/*;q=1.0, image/png;q=1.0, image/jpeg;q=1.0, image/gif;q=1.0, image/*;q=0.8, */*;q=0.5 REQUEST_URI /mailman/roster/forum-uull HTTP_CACHE_CONTROL no-cache QUERY_STRING SERVER_PROTOCOL HTTP/1.1 PATH_INFO /forum-uull HTTP_HOST cmo.uqam.ca REQUEST_METHOD POST SERVER_SIGNATURE Apache/1.3.19 Server at cmo.uqam.ca Port 80 SCRIPT_NAME /mailman/roster SERVER_ADMIN benoit@brosseau.org SCRIPT_FILENAME /var/Mailman/cgi-bin/roster PYTHONPATH /var/Mailman HTTP_REFERER http://cmo.uqam.ca/mailman/listinfo/forum-uull HTTP_PRAGMA no-cache SERVER_NAME cmo.uqam.ca From che@debian.org Wed Sep 26 03:00:42 2001 From: che@debian.org (Ben Gertzfield) Date: Wed, 26 Sep 2001 11:00:42 +0900 Subject: [Mailman-Developers] Proper solution to Mailman CVS's Japanese problems In-Reply-To: <3BB0867E.9A28DDE7@is.kochi-u.ac.jp> (Tokio Kikuchi's message of "Tue, 25 Sep 2001 22:28:30 +0900") References: <87sndbec9c.fsf@nausicaa.interq.or.jp> <3BB0867E.9A28DDE7@is.kochi-u.ac.jp> Message-ID: <87g09a1zjp.fsf@nausicaa.interq.or.jp> >>>>> "Tokio" == Tokio Kikuchi writes: Tokio> There are '\'s in ISO-2022-JP (and in Shift_JIS, also) and Tokio> that will make headake when you want to match or search Tokio> within text. I think it won't be a problem for mailman, though, because all we want to do is: 1) display the mails for admins, when they are filtered as SPAM or for size 2) be able to archive the mails properly, even with an external archiver 3) not add another dependancy on kconv I think 2) is very important, and currently all archivers I've found that support Japanese require ISO-2022-JP. Tokio> Things are not easy and I am rather decided to teach Tokio> Japanese users to use 'standard' coding. Yes, absolutely! This solution does not deal with UTF-8 encoded Japanese mail, which comes from Outlook users once in a while.. we will have to look at that in the future. Ben -- Brought to you by the letters P and G and the number 12. "It should be illegal to yell 'Y2K' in a crowded economy." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From che@debian.org Wed Sep 26 08:30:53 2001 From: che@debian.org (Ben Gertzfield) Date: Wed, 26 Sep 2001 16:30:53 +0900 Subject: [Mailman-Developers] Proper solution to Mailman CVS's Japanese problems In-Reply-To: <87g09a1zjp.fsf@nausicaa.interq.or.jp> (Ben Gertzfield's message of "Wed, 26 Sep 2001 11:00:42 +0900") References: <87sndbec9c.fsf@nausicaa.interq.or.jp> <3BB0867E.9A28DDE7@is.kochi-u.ac.jp> <87g09a1zjp.fsf@nausicaa.interq.or.jp> Message-ID: <87u1xqz9w2.fsf@nausicaa.interq.or.jp> Unfortunately, my grand plans may be for nothing. GNU gettext does not support storing messages in ISO-2022-JP. At all. >From gettext's info file: Because the PO files must be portable to operating systems with less advanced internationalization facilities, the character encodings that can be used are limited to those supported by both GNU `libc' and GNU `libiconv'. These are: `ASCII', `ISO-8859-1', `ISO-8859-2', `ISO-8859-3', `ISO-8859-4', `ISO-8859-5', `ISO-8859-6', `ISO-8859-7', `ISO-8859-8', `ISO-8859-9', `ISO-8859-13', `ISO-8859-15', `KOI8-R', `KOI8-U', `CP850', `CP866', `CP874', `CP932', `CP949', `CP950', `CP1250', `CP1251', `CP1252', `CP1253', `CP1254', `CP1255', `CP1256', `CP1257', `GB2312', `EUC-JP', `EUC-KR', `EUC-TW', `BIG5', `BIG5-HKSCS', `GBK', `GB18030', `SHIFT_JIS', `JOHAB', `TIS-620', `VISCII', `UTF-8'. This is most frustrating. They support Shift-JIS, Microsoft's evil charset, but not the standard ISO-2022-JP. I tried forcing ISO-2022-JP encoded strings into the po file, but msgfmt barfs: [ben@nausicaa:~/src/mailman/mailman/messages/ja/LC_MESSAGES]% msgfmt mailman.po mailman.po: warning: Charset "iso-2022-jp" is not a portable encoding name. Message conversion to user's charset might not work. mailman.po:35: invalid control sequence mailman.po:55: keyword "$7" unknown mailman.po:56: end-of-line within string Escaping the literal ESC characters as \033 works, but not the many $ characters common to ISO-2022-JP text. I don't know how to work around that, and besides, it's ridiculous to ask translators to have to change all ESC characters to \033 and all $ characters to something else. It seems that our only solution, then, is truly to convert ISO-2022-JP encoded messages to EUC when they're displayed on the web -- but not when they're being archived. This is possible either through the kconv module, from http://tomigaya.shibuya.tokyo.jp/~mak/kconv/ , or the Japanese codec for Python 1.6 or later, at http://pseudo.grad.sccs.chukyo-u.ac.jp/~kajiyama/python/ . In either case, one of these will have to be bundled with the next Mailman release, or Japanese support should be removed, as it currently will happily send out mails encoded in 8-bit EUC-JP. Very very bad. We could just translate the template mails into ISO-2022-JP and force a Content-Type: text/plain; charset=iso-2022-jp on any Japanese-language mails sent out, but that would leave the admin interface being useless for Japanese mails. Barry? I hope you're still out there, because this is your call on which Japanese module to include. Both have pure Python and hybrid Python-C versions, with compilation and speed tradeoffs for each. kconv is GPL'd, and the Japanese codec is a BSD-like license. Ben -- Brought to you by the letters U and D and the number 16. "A squib is a firecracker." Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ From mrbill@mrbill.net Wed Sep 26 17:04:23 2001 From: mrbill@mrbill.net (Bill Bradford) Date: Wed, 26 Sep 2001 11:04:23 -0500 Subject: [Mailman-Developers] adding old list archives to web archive? Message-ID: <20010926110423.H2460@mrbill.net> I've got a mailing list that I took over in December of last year, but now have received copies (in mbox format) of list archives going back to 1997 or so. Is there a way to add these posts to the web-based archive *without* disturbing the stuff thats already there (I dont have mbox-format of the current archives)? Or, anybody know where I can find a stand-alone version of pipermail to convert the mbox file to a web-based archive? Bill -- Bill Bradford mrbill@mrbill.net Austin, TX From josi@globalmargin.com Thu Sep 27 08:39:12 2001 From: josi@globalmargin.com (=?ISO-8859-1?B?Sm9z6SBJZ25hY2lvIEZyYW5xdWVpcm8=?=) Date: Thu, 27 Sep 2001 04:39:12 -0300 Subject: [Mailman-Developers] Automated responses Message-ID: <23482297.20010927043912@globalmargin.com> Hi. I´m running Mailman v2.0.6. I´m creating a moderated list, but I´d like to avoid the automated response to posters advicing that "your email is being held until the list moderator can review it for approval". In the Auto-responder section of the Administration site I set to "No" the question "Should Mailman send an auto-response to mailing list posters?", but this didn´t work. Question: Where should I have to look to change this? Do I need to change/rewrite any of Mailman script´s? Sorry, maybe it´s something trivial, but I´m really new with this tool. Thank you in advance. José Ignacio From jj-list@mail.dk Thu Sep 27 09:10:16 2001 From: jj-list@mail.dk (Jesper Jensen) Date: Thu, 27 Sep 2001 10:10:16 +0200 Subject: [Mailman-Developers] Automated responses In-Reply-To: <23482297.20010927043912@globalmargin.com> Message-ID: <5.1.0.14.0.20010927100439.034b2350@pop3.mail.dk> >I=B4m creating a moderated list, but I=B4d like to avoid the automated >response to posters advicing that "your email is being held until the >list moderator can review it for approval". > >In the Auto-responder section of the Administration site I set to "No" >the question "Should Mailman send an auto-response to mailing list >posters?", but this didn=B4t work. > >Question: Where should I have to look to change this? Do I need to >change/rewrite any of Mailman script=B4s? It should work, Hold.py line 237: if not fromusenet and not mlist.dont_respond_to_post_requests: subject =3D 'Your message to %s awaits moderator approval' %= listname text =3D Utils.maketext('postheld.txt', d) msg =3D Message.UserNotification(sender, adminaddr, subject, text) HandlerAPI.DeliverToUser(mlist, msg) Maybe mlist.dont_respond_to_post_requests isn't set properly by the web=20 interface? I'm not very familar with that part of Mailman. Anyway, if you want to make the change yourself, you just need to comment=20 out the section above. Jesper. From tjenkins@devis.com Thu Sep 27 14:26:57 2001 From: tjenkins@devis.com (Tom Jenkins) Date: Thu, 27 Sep 2001 09:26:57 -0400 Subject: [Mailman-Developers] Unsubscribe without password Message-ID: <3BB32921.2080901@devis.com> Hello folks, We have a mailing list that we run for a client. He's freaking out that the users have to remember a password to unsubscribe from the mailing list. So I was wondering: a) can we currently turn off the password requirements for unsubscribing b) if not, anybody have any pointers for me in patching Mailman to allow list managers to toggle this on/off c) if/when I make this change, what will he now bitch about....err, ummm, sorry that one just slipped out -- Tom Jenkins devIS - Development Infostructure http://www.devis.com From dsp@waterspout.com Thu Sep 27 18:29:22 2001 From: dsp@waterspout.com (Doug Porter) Date: Thu, 27 Sep 2001 12:29:22 -0500 Subject: [Mailman-Developers] Re: Unsubscribe without password In-Reply-To: Your message of "Thu, 27 Sep 2001 09:26:57 -0400." <3BB32921.2080901@devis.com> References: <3BB32921.2080901@devis.com> Message-ID: <20010927173233.87AF29B08@squall.waterspout.com> Tom Jenkins wrote: > > a) can we currently turn off the password requirements for > unsubscribing Are you running an older version of Mailman? I think that was fixed somewhere around 2.0.4. -- Doug Porter From pioppo@ferrara.linux.it Thu Sep 27 20:41:03 2001 From: pioppo@ferrara.linux.it (Simone Piunno) Date: Thu, 27 Sep 2001 21:41:03 +0200 Subject: [Mailman-Developers] bug? Message-ID: <20010927214103.A2378@abulafia.casa> executing make install on my strange configuration: Compiling /home/soci/homepages/pioppo/mailman/Mailman/versions.py ... Traceback (most recent call last): File "bin/update", line 46, in ? from Mailman import Utils File "/home/soci/homepages/pioppo/mailman/Mailman/Utils.py", line 36, in ? from mimelib.MsgReader import MsgReader ImportError: No module named mimelib.MsgReader make: *** [update] Error 1 Using: - latest Mailman CVS - Python 2.1.1 - ./configure --prefix=/home/soci/homepages/pioppo/mailman --with-username=pioppo --with-groupname=users --with-cgi-gid=apache --with-python=/home/soci/pioppo/python/bin/python - doing configure, make and make install as user pioppo What's wrong? -- /~\ The ASCII \ / Ribbon Campaign X Against HTML unzip && touch && finger && mount / \ Email! && gasp && yes && umount && sleep From jj-list@mail.dk Thu Sep 27 21:57:58 2001 From: jj-list@mail.dk (Jesper Jensen) Date: Thu, 27 Sep 2001 22:57:58 +0200 Subject: [Mailman-Developers] OT: The impact of Internet standards/RFC's Message-ID: <5.1.0.14.0.20010927223445.01c073b8@wheresmymailserver.com> Sorry for this OT question. I am about to start writing my final paper soon and have been looking around for interesting topics. With e-mail being so large a part of almost everybody's daily working routine, one (me) would think that the actual e-mail format/protocol/standard would have a rather big influence on the way people communicate/work together/socialise. The impact/influence might be so big that you could actually see a change in the way people work with the release of a new Outlook version. Or maybe looking at a 5-10 year period you could see communication patterns change as a result of a new RFC document, e.g. will the newly inserted listinfo headers in Mailman change the way people communicate (this might be a silly example, but you get the idea). I would love to hear if anyone has heard of similar (or even vaguely similar) research. Also pointers to anything even remotely similar are very much appreciated. And finally I would be interested in hearing your own opinion. Many thanks in advance, Jesper. From pioppo@ferrara.linux.it Thu Sep 27 22:14:45 2001 From: pioppo@ferrara.linux.it (Simone Piunno) Date: Thu, 27 Sep 2001 23:14:45 +0200 Subject: [Mailman-Developers] bug? In-Reply-To: <20010927214103.A2378@abulafia.casa>; from pioppo@ferrara.linux.it on Thu, Sep 27, 2001 at 09:41:03PM +0200 References: <20010927214103.A2378@abulafia.casa> Message-ID: <20010927231445.A2515@abulafia.casa> giovedì, 27 settembre 2001 alle 21:41:03, Simone Piunno ha scritto: > What's wrong? sorry... now I can answer myself: o mimelib 0.4 is now required. Get it from http://mimelib.sf.net. If you've installed an earlier version of mimelib, you must upgrade. -- /~\ The ASCII \ / Ribbon Campaign X Against HTML unzip && touch && finger && mount / \ Email! && gasp && yes && umount && sleep From Dan Mick Thu Sep 27 22:59:32 2001 From: Dan Mick (Dan Mick) Date: Thu, 27 Sep 2001 14:59:32 -0700 (PDT) Subject: [Mailman-Developers] Automated responses Message-ID: <200109272158.OAA09921@utopia.West.Sun.COM> > >I=B4m creating a moderated list, but I=B4d like to avoid the automate= d > >response to posters advicing that "your email is being held until the > >list moderator can review it for approval". > > > >In the Auto-responder section of the Administration site I set to "No" > >the question "Should Mailman send an auto-response to mailing list > >posters?", but this didn=B4t work. > > > >Question: Where should I have to look to change this? Do I need to > >change/rewrite any of Mailman script=B4s? >=20 > It should work, Hold.py line 237: >=20 > if not fromusenet and not mlist.dont_respond_to_post_requests: > subject =3D 'Your message to %s awaits moderator approval' % lis= tname > text =3D Utils.maketext('postheld.txt', d) > msg =3D Message.UserNotification(sender, adminaddr, subject, tex= t) > HandlerAPI.DeliverToUser(mlist, msg) >=20 > Maybe mlist.dont_respond_to_post_requests isn't set properly by the web= =20 > interface? > I'm not very familar with that part of Mailman. >=20 > Anyway, if you want to make the change yourself, you just need to comment= =20 > out the section above. ...or use withlist to set that variable on your mailing list (see the comments at the front of withlist for how to use it)