Mailman 3 March 2003 - Mailman-coders

[ mailman-Bugs-711564 ] make install fails, something with bin/update
by SourceForge.net 28 Mar '03

28 Mar '03

Bugs item #711564, was opened at 2003-03-28 13:56 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=711564&group_i… Category: configuring/installing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: ryan pratt (rhpratt) Assigned to: Nobody/Anonymous (nobody) Summary: make install fails, something with bin/update Initial Comment: I am running mailman 2.1.1, python 2.2.2, gcc 2.95.3 on Solaris 9. I've also tried it on Solaris 8. python seems to be working. import random returns fine. ... ... Compiling /opt/mailman/Mailman/Utils.py ... Compiling /opt/mailman/Mailman/Version.py ... Compiling /opt/mailman/Mailman/__init__.py ... Compiling /opt/mailman/Mailman/htmlformat.py ... Compiling /opt/mailman/Mailman/i18n.py ... Compiling /opt/mailman/Mailman/versions.py ... bin/update: downgrade is detected), nothing will be done.^J^J -h/--help^J Print this text and exit.^J^JUse this script to help you update to the latest release of Mailman from^Jsome previous version. It knows about versions back to 1.0b4 (?).^J""": not found bin/update: Perform all necessary upgrades.^J^JUsage: %(PROGRAM)s [options]^J^JOptions:^J -f/--force^J Force running the upgrade procedures. Normally, if the version number^J of the installed Mailman matches the current version number (or a^J : not found bin/update: import: not found bin/update: import: not found bin/update: import: not found bin/update: import: not found bin/update: import: not found bin/update: import: not found bin/update: import: not found bin/update: import: not found bin/update: import: not found bin/update: from: not found bin/update: from: not found bin/update: from: not found bin/update: from: not found bin/update: from: not found bin/update: from: not found bin/update: from: not found bin/update: from: not found bin/update: FRESH: not found bin/update: NOTFRESH: not found bin/update: syntax error at line 58: `(' unexpected *** Error code 2 make: Fatal error: Command failed for target `update' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=711564&group_i…

1 0

[ mailman-Feature Requests-402455 ] Generate .htaccess files containing username/passwd for list
by SourceForge.net 28 Mar '03

28 Mar '03

Feature Requests item #402455, was opened at 2000-11-20 10:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=402455&group_i… Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Generate .htaccess files containing username/passwd for list Initial Comment: ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-03-28 11:59 Message: Logged In: NO Try http://sourceforge.net/tracker/index.php? func=detail&aid=670142&group_id=103&atid=300103 ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-11 06:06 Message: Logged In: YES user_id=34209 This patch is out of date, but it shouldn't be hard to write something similar for Mailman 2.1. Moving to feature requests for now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=402455&group_i…

1 0

[ mailman-Patches-657951 ] Generate RSS summary in archives
by SourceForge.net 27 Mar '03

27 Mar '03

Patches item #657951, was opened at 2002-12-23 14:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=657951&group_i… Category: Pipermail Group: Mailman 2.2 / 3.0 Status: Open Resolution: None >Priority: 7 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Generate RSS summary in archives Initial Comment: Here's a first-draft patch. Things that need fixing: * The generated RSS feed needs to be validated. (It passed the W3C's RDF validator, but RSS validators still need to be checked.) * The date should be given in YYYY-MM-DD format, which requires parsing the .fromdate attribute. * How do I get the URL for an archived message? The generated RSS currently just uses the filename, which is wrong. How do I get at the PUBLIC_ARCHIVE_URL setting? * Getting the most recent N postings is inefficient; the code loops through all of the archived messages and takes the last N of them. We could add .last() and .prev() methods to the Database class, but that's more ambitious for 2.1beta than I like. (Would be nice to get this into 2.1final...) * The list index page should have a LINK element pointing to the RSS file. Please make any comments you have, and I'll rework the patch accordingly. ---------------------------------------------------------------------- Comment By: Justin Mason (jmason) Date: 2003-03-26 16:49 Message: Logged In: YES user_id=935 big thumbs up from me too. Much better solution than http://taint.org/mmrss/ ;) ---------------------------------------------------------------------- Comment By: Uche Ogbuji (uche) Date: 2003-03-17 20:09 Message: Logged In: YES user_id=38966 I'd like to add my vote to this item. This is a fantastic idea, Andrew. Thanks. --Uche ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-23 15:42 Message: Logged In: YES user_id=11375 Updated patch: * Dates are now rendered as ISO-8601 (date only, not the time of the message) * By hard-wiring 2002-December, I got the RSS to validate using Mark Pilgrim's validator. ---------------------------------------------------------------------- Comment By: captain larry (captainlarry) Date: 2002-12-23 14:36 Message: Logged In: YES user_id=147905 Just voting for support here. This is *great* thanks for the patch and I hope the maintainers include it as soon as it's appropriate :) Adam. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-23 14:27 Message: Logged In: YES user_id=12800 Deferring until post-2.1 ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-23 14:21 Message: Logged In: YES user_id=11375 Argh; SF choked on the file upload. Attaching the patch again... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=657951&group_i…

1 0

[ mailman-Bugs-710678 ] find_member fails using -w option
by SourceForge.net 27 Mar '03

27 Mar '03

Bugs item #710678, was opened at 2003-03-27 12:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=710678&group_i… Category: command line scripts Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: find_member fails using -w option Initial Comment: When run with the -w option $prefix/bin/find_member Traceback (most recent call last): File "../../bin/find_member", line 185, in ? main() File "../../bin/find_member", line 168, in main matches = scanlists(options) File "../../bin/find_member", line 115, in scanlists entries = matches.get(addr, {}) UnboundLocalError: local variable 'addr' referenced before assignment The findm-2.1.1-0.1.patch corrects the problem. It should be applied with the follwoing command from with the MM build directory as the current working directory: patch -p1 < path-to-patch-file ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=710678&group_i…

1 0

[ mailman-Patches-657951 ] Generate RSS summary in archives
by SourceForge.net 26 Mar '03

26 Mar '03

Patches item #657951, was opened at 2002-12-23 19:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=657951&group_i… Category: Pipermail Group: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 5 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Generate RSS summary in archives Initial Comment: Here's a first-draft patch. Things that need fixing: * The generated RSS feed needs to be validated. (It passed the W3C's RDF validator, but RSS validators still need to be checked.) * The date should be given in YYYY-MM-DD format, which requires parsing the .fromdate attribute. * How do I get the URL for an archived message? The generated RSS currently just uses the filename, which is wrong. How do I get at the PUBLIC_ARCHIVE_URL setting? * Getting the most recent N postings is inefficient; the code loops through all of the archived messages and takes the last N of them. We could add .last() and .prev() methods to the Database class, but that's more ambitious for 2.1beta than I like. (Would be nice to get this into 2.1final...) * The list index page should have a LINK element pointing to the RSS file. Please make any comments you have, and I'll rework the patch accordingly. ---------------------------------------------------------------------- Comment By: Justin Mason (jmason) Date: 2003-03-26 21:49 Message: Logged In: YES user_id=935 big thumbs up from me too. Much better solution than http://taint.org/mmrss/ ;) ---------------------------------------------------------------------- Comment By: Uche Ogbuji (uche) Date: 2003-03-18 01:09 Message: Logged In: YES user_id=38966 I'd like to add my vote to this item. This is a fantastic idea, Andrew. Thanks. --Uche ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-23 20:42 Message: Logged In: YES user_id=11375 Updated patch: * Dates are now rendered as ISO-8601 (date only, not the time of the message) * By hard-wiring 2002-December, I got the RSS to validate using Mark Pilgrim's validator. ---------------------------------------------------------------------- Comment By: captain larry (captainlarry) Date: 2002-12-23 19:36 Message: Logged In: YES user_id=147905 Just voting for support here. This is *great* thanks for the patch and I hope the maintainers include it as soon as it's appropriate :) Adam. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-23 19:27 Message: Logged In: YES user_id=12800 Deferring until post-2.1 ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-23 19:21 Message: Logged In: YES user_id=11375 Argh; SF choked on the file upload. Attaching the patch again... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=657951&group_i…

1 0

[ mailman-Patches-707624 ] SMTPDirect doesn't use persistent SMTP connections
by SourceForge.net 24 Mar '03

24 Mar '03

Patches item #707624, was opened at 2003-03-21 18:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=707624&group_i… Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Jesús Cea Avión (jcea) Assigned to: Nobody/Anonymous (nobody) Summary: SMTPDirect doesn't use persistent SMTP connections Initial Comment: Mailman 2.1.1 here. "/Mailman/Handlers/SMTPDirect.py" is suppose to reuse SMTP connections up to "mm_cfg.SMTP_MAX_SESSIONS_PER_CONNECTION" different messages. Nevertheless, it's NOT the case: "SMTPDirect" drop the connection when send each message. This is an important CPU hog when mailman has a long queue spool. Here is the patch (sorry, I can't send it as an attach, shame on me). It's fairly trivial : >>>>> Index: SMTPDirect.py =================================================================== RCS file: /opt/src/cvsroot/mailman/Mailman/Handlers/SMTPDirect.py,v retrieving revision 1.1.1.5 retrieving revision 1.1.1.5.2.1 diff -u -u -r1.1.1.5 -r1.1.1.5.2.1 --- SMTPDirect.py 2003/03/20 10:14:58 1.1.1.5 +++ SMTPDirect.py 2003/03/21 16:48:31 1.1.1.5.2.1 @@ -48,7 +48,7 @@ # Manage a connection to the SMTP server -class Connection: +class ConnectionClass: def __init__(self): self.__connect() @@ -79,7 +79,15 @@ def quit(self): self.__conn.quit() + def rset(self) : + self.__conn.rset() + def __del__(self) : + self.quit() + + +Connection=ConnectionClass() + def process(mlist, msg, msgdata): recips = msgdata.get('recips') @@ -130,7 +138,7 @@ # This means at worst, the last chunk for which delivery was attempted # could get duplicates but not every one, and no recips should miss the # message. - conn = Connection() + conn = Connection try: msgdata['undelivered'] = chunks while chunks: @@ -147,7 +155,8 @@ raise del msgdata['undelivered'] finally: - conn.quit() + conn.rset() + # conn.quit() msgdata['recips'] = origrecips # Log the successful post t1 = time.time() <<<<< ---------------------------------------------------------------------- >Comment By: Jesús Cea Avión (jcea) Date: 2003-03-24 08:33 Message: Logged In: YES user_id=97460 The proposed patch causes exceptions if space between messages is greater than SMTP timeout. Corrected patch (I still can't attach a file): >>>>> Index: SMTPDirect.py =================================================================== RCS file: /opt/src/cvsroot/mailman/Mailman/Handlers/SMTPDirect.py,v retrieving revision 1.1.1.5 retrieving revision 1.1.1.5.2.3 diff -u -r1.1.1.5 -r1.1.1.5.2.3 --- SMTPDirect.py 2003/03/20 10:14:58 1.1.1.5 +++ SMTPDirect.py 2003/03/24 07:11:32 1.1.1.5.2.3 @@ -48,7 +48,7 @@ # Manage a connection to the SMTP server -class Connection: +class ConnectionClass: def __init__(self): self.__connect() @@ -58,6 +58,15 @@ self.__numsessions = mm_cfg.SMTP_MAX_SESSIONS_PER_CONNECTION def sendmail(self, envsender, recips, msgtext): + try : + self.__conn.rset() + except : + try : + self.__conn.quit() + except : + pass + self.__connect() + try: results = self.__conn.sendmail(envsender, recips, msgtext) except smtplib.SMTPException: @@ -79,6 +88,11 @@ def quit(self): self.__conn.quit() + def __del__(self) : + self.quit() + + +Connection=ConnectionClass() def process(mlist, msg, msgdata): @@ -130,7 +144,7 @@ # This means at worst, the last chunk for which delivery was attempted # could get duplicates but not every one, and no recips should miss the # message. - conn = Connection() + conn = Connection try: msgdata['undelivered'] = chunks while chunks: @@ -147,7 +161,7 @@ raise del msgdata['undelivered'] finally: - conn.quit() + # conn.quit() msgdata['recips'] = origrecips # Log the successful post t1 = time.time() <<<<< ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=707624&group_i…

1 0

[ mailman-Bugs-707604 ] remove_members doesn't use default setting
by SourceForge.net 22 Mar '03

22 Mar '03

Bugs item #707604, was opened at 2003-03-21 11:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=707604&group_i… Category: command line scripts Group: 2.1 (stable) >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ricardo Kustner (rixhq) Assigned to: Nobody/Anonymous (nobody) Summary: remove_members doesn't use default setting Initial Comment: bin/remove_members turns on "userack" by default... even though it's supposed to use the list config setting whether or not it should send a message to the unsubscribers (line 111 in remove_members says "userack = 1"). is this a bug or has this been done intentionally? the danger is that even if you have "nouserack" set in your system, using "remove_members -a" will always mail all unsubscribers unless you specifically tell it not to through the command line... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=707604&group_i…

1 0

[ mailman-Bugs-700140 ] obsolete version number in TODO
by SourceForge.net 22 Mar '03

22 Mar '03

Bugs item #700140, was opened at 2003-03-08 18:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=700140&group_i… Category: documentation Group: 2.1 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Ross Boylan (rboylan) Assigned to: Nobody/Anonymous (nobody) Summary: obsolete version number in TODO Initial Comment: Got email-2.4.3.tar.gz from the latest cvs. It includes a TODO file, with the following notation: - We should support RFC 2231. Oleg Broytmann has patches to add this support, so we'll look into it for email-1.3. Since this is email-2.4, I presume either its been done or the version number needs to change. This is a low-priority item. I figured I mention it, since I saw it. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-22 01:08 Message: Logged In: YES user_id=12800 I'll bet you're looking at the maintenance branch. I still have to backport the trunk changes to the maint branch. Python bugs should go in the Python project trackers. mimelib bugs should probably go there too, or in the standalone mimelib project. If you submit email package bug reports in the Python project, be sure to assign them to me. ---------------------------------------------------------------------- Comment By: Ross Boylan (rboylan) Date: 2003-03-22 00:59 Message: Logged In: YES user_id=300987 I just did a cvs update and looked at email-2.5b1 in there. The TODO still refers to email-1.3. (21-Mar-2003). Out of curiosity, where do python and mimelilb bugs go? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-13 00:21 Message: Logged In: YES user_id=12800 Bugs and patches on the email package probably belong better on the Python or mimelib projects. But in any event, I've updated the TODO list. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=700140&group_i…

1 0

[ mailman-Bugs-700140 ] obsolete version number in TODO
by SourceForge.net 22 Mar '03

22 Mar '03

Bugs item #700140, was opened at 2003-03-08 15:34 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=700140&group_i… Category: documentation Group: 2.1 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Ross Boylan (rboylan) Assigned to: Nobody/Anonymous (nobody) Summary: obsolete version number in TODO Initial Comment: Got email-2.4.3.tar.gz from the latest cvs. It includes a TODO file, with the following notation: - We should support RFC 2231. Oleg Broytmann has patches to add this support, so we'll look into it for email-1.3. Since this is email-2.4, I presume either its been done or the version number needs to change. This is a low-priority item. I figured I mention it, since I saw it. ---------------------------------------------------------------------- >Comment By: Ross Boylan (rboylan) Date: 2003-03-21 21:59 Message: Logged In: YES user_id=300987 I just did a cvs update and looked at email-2.5b1 in there. The TODO still refers to email-1.3. (21-Mar-2003). Out of curiosity, where do python and mimelilb bugs go? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-03-12 21:21 Message: Logged In: YES user_id=12800 Bugs and patches on the email package probably belong better on the Python or mimelib projects. But in any event, I've updated the TODO list. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=700140&group_i…

1 0

[ mailman-Bugs-670535 ] qrunner stops for no apparent reason
by SourceForge.net 21 Mar '03

21 Mar '03

Bugs item #670535, was opened at 2003-01-19 04:04 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=670535&group_i… Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 8 Submitted By: David Gibbs (midrangeman) Assigned to: Nobody/Anonymous (nobody) Summary: qrunner stops for no apparent reason Initial Comment: About once every day or so, qrunner will stop for no apparent reason. The qrunner log file has the following ... Jan 18 14:29:09 2003 (3443) IncomingRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3443) IncomingRunner qrunner exiting. Jan 18 14:29:09 2003 (3441) BounceRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3441) BounceRunner qrunner exiting. Jan 18 14:29:09 2003 (3445) OutgoingRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3445) OutgoingRunner qrunner exiting. Jan 18 14:29:09 2003 (3442) CommandRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3442) CommandRunner qrunner exiting. Jan 18 14:29:09 2003 (3446) VirginRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3446) VirginRunner qrunner exiting. Jan 18 14:29:09 2003 (3440) ArchRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:09 2003 (3440) ArchRunner qrunner exiting. Jan 18 14:29:10 2003 (3444) NewsRunner qrunner caught SIGTERM. Stopping. Jan 18 14:29:12 2003 (3444) NewsRunner qrunner exiting. No other log has any indication of what might be happening. Is there a way to increase the logging somewhere so the cause can be identified? ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2003-03-22 01:54 Message: Logged In: YES user_id=34209 No, having multiple versions of Python should not be causing this. Nor should the SIGALRM handler being triggered cause it, unless something is seriously broken in your setup -- but we've already been there. The only way to see if a SIGTERM is actually being delivered is running the processes under strace or gdb, but this seriously disrupts regular operation. There is no way that i know of to find out where a signal is coming from, once you find out that it really is a signal. If it *isn't* a real signal, I would start looking at libc bugs and other platform bugs. You can try upgrading Python to 2.2.2 (the latest bugfix release) but I would be very suprised if it fixed your problem. RedHat does not have a great reputation for stability, so be sure to check for any RedHat updates. ---------------------------------------------------------------------- Comment By: David Gibbs (midrangeman) Date: 2003-03-17 18:44 Message: Logged In: YES user_id=86339 Additional environment details: Redhat Linux 8.0, uname = "Linux xxx.midrange.com 2.4.18- 26.8.0 #1 Mon Feb 24 10:21:42 EST 2003 i686 i686 i386 GNU/Linux" Python: 2.2.1 CPU: P4 2.4ghz, 512mb RAM Dunno if this makes a difference, but I have the following directories ... /usr/lib/python1.5 /usr/lib/python2.1 /usr/lib/python2.2 Any chance there is a conflict? ---------------------------------------------------------------------- Comment By: David Gibbs (midrangeman) Date: 2003-01-24 19:31 Message: Logged In: YES user_id=86339 I added some debug code to mailmanctl and found out that the sigalarm handler is firing just before the qrunners are terminating. ---------------------------------------------------------------------- Comment By: David Gibbs (midrangeman) Date: 2003-01-22 22:31 Message: Logged In: YES user_id=86339 After some further research, QRUNNER seems to stop after exactly 24 hours of operation. That is, 24 hours after qrunner starts, it ends as if someone killed it with SIGTERM. I know for a fact that nobody is actually doing this ... and no process on my system should be aware of the fact that qrunner is actually running. I will not discount the possiblity that this is an environmental factor, but it seems to me that a daemon process should not be affected by environmental factors. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-01-19 23:46 Message: Logged In: YES user_id=12800 I'm not sure what kind of logging would help. Some process somewhere is SIGTERMing the mailmanctl controller process. There's no way to know where a signal is coming from, so I'm not sure what more you could do in mailmanctl. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=670535&group_i…

1 0