Mailman-coders May 2005

mailman-coders@python.org

1 participants
40 discussions

[ mailman-Bugs-949117 ] 2.1.5rc2 upgrade dies on corrupt qfiles
by SourceForge.net 31 May '05

31 May '05

Bugs item #949117, was opened at 2004-05-06 08:16 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=949117&group_i… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: configuring/installing Group: 2.1 (stable) >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brion Vibber (vibber) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1.5rc2 upgrade dies on corrupt qfiles Initial Comment: Upgrading from 2.1.2 to 2.1.5rc2; a couple of the .pck files in qfiles/shunt were zero-length for reasons unknown. This caused the upgrade (make install) to fail with this message: updating old qfiles Traceback (most recent call last): File "bin/update", line 780, in ? errors = main() File "bin/update", line 709, in main update_qfiles() File "bin/update", line 441, in update_qfiles msg, data = dequeue(filebase) File "bin/update", line 497, in dequeue msg = cPickle.load(msgfp) EOFError make: *** [update] Error 1 Removing the zero-length files cleared that up. I did have one other problem; while investigating the first bit I dumped some info to a text file in qfiles, and the next make install failed with this error: updating old qfiles Traceback (most recent call last): File "bin/update", line 780, in ? errors = main() File "bin/update", line 709, in main update_qfiles() File "bin/update", line 434, in update_qfiles for filename in os.listdir(dirpath): OSError: [Errno 20] Not a directory: '/home/mailman/qfiles/blork' make: *** [update] Error 1 At least that had the filename in it. ;) Removed the file, and it installed/upgraded cleanly. So far so good... ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-05-31 18:34 Message: Logged In: YES user_id=12800 Fixed for MM2.1.7 ---------------------------------------------------------------------- Comment By: John Mora (jmoraragweed) Date: 2004-05-25 10:34 Message: Logged In: YES user_id=605434 I have the same problem when trying to update to 2.1.5 release from Mailman version 2.1.4. I have no zero-length files in qfiles/shunt. My error is similar, but I'm not certain the two are related. I'm posting it for lack of knowing better: Updating Usenet watermarks - nothing to update here Nothing to do. updating old qfiles Traceback (most recent call last): File "bin/update", line 780, in ? errors = main() File "bin/update", line 709, in main update_qfiles() File "bin/update", line 441, in update_qfiles msg, data = dequeue(filebase) File "bin/update", line 497, in dequeue msg = cPickle.load(msgfp) EOFError make: *** [update] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=949117&group_i…

1 0

[ mailman-Bugs-907272 ] URL given in UPGRADING no longer valid
by SourceForge.net 31 May '05

31 May '05

Bugs item #907272, was opened at 2004-02-29 23:10 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=907272&group_i… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: documentation Group: Out of Date >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nathan Stratton Treadway (nathanst) Assigned to: Nobody/Anonymous (nobody) Summary: URL given in UPGRADING no longer valid Initial Comment: I was just looking at the INSTALL document out of the CSV (both the HEAD version and v2.11.2.1 that was included in Mailman 2.1.4). This document mentions the URL http://mail.python.org/pipermail/mailman-users/2000-September/006826.html which is supposed to be a message about upgrading the list template files -- but the proper message is no longer found at that URL. I believe the intended message is now found at http://mail.python.org/pipermail/mailman-users/2000-September/006822.html If that's the right message, it problably makes sense to give a little info to help people find the correct message if it moves again (i.e. message dated Thu Sep 21 21:59:16 EDT 2000 and having a subject line of "quick note for those ugrading mailman". (Or, just quote the message directly in the INSTALL document; it's not too long...) Thanks. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-05-31 18:15 Message: Logged In: YES user_id=12800 The INSTALL file was substantially rewritten for Mailman 2.1.6. ---------------------------------------------------------------------- Comment By: Nathan Stratton Treadway (nathanst) Date: 2004-02-29 23:47 Message: Logged In: YES user_id=987478 Sorry, the file I was looking at was "UPGRADING", not "INSTALL". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=907272&group_i…

1 0

[ mailman-Patches-839386 ] MySQL MemberAdaptor for Mailman 2.1
by SourceForge.net 31 May '05

31 May '05

Patches item #839386, was opened at 2003-11-10 18:04 Message generated for change (Comment added) made by kyrian You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=839386&group_i… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: configure/install Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Kev Green (kyrian) Assigned to: Nobody/Anonymous (nobody) Summary: MySQL MemberAdaptor for Mailman 2.1 Initial Comment: A MemberAdaptor "plugin" which should allow Mailman list members to be loaded from a MySQL database, rather than just a Mailman "pickle" file. Provided as-is, and without warranty, this "plugin" may destroy your server, soul, scalp, house, and life. Please use it with caution. Kev Green, oRe Net. http://www.orenet.co.uk/ ---------------------------------------------------------------------- >Comment By: Kev Green (kyrian) Date: 2005-05-31 19:57 Message: Logged In: YES user_id=99923 Folks, Well, I've finally gotten around to releasing an update to this thing, after a phone conversation with the client who are using it, and I've incorporated a couple of cosmetic fixes, fairly substantial changes to make the bounce processing work properly (the ability to set people to NOMAIL now exists, and real world testing is commencing soon), and incorporated the flat vs. wide table archivecture types with various bugfixes. Main notes: * It would be a good idea to change all your delivery_status fields from VARCHAR(255) to INT(10) or similar, so that they will work properly, and not bomb out on this new version (they should be okay I think, but I'd advise the change). * The missing-'AND' typo has been rectified. Any suggestions and bugs should be sent to my sourceforge account address, which ends up in the right place. K. ---------------------------------------------------------------------- Comment By: Gergely EGERVARY (egervary) Date: 2005-04-09 11:14 Message: Logged In: YES user_id=1255996 Thank you for your good work. FYI: there's a missing "AND" in MysqlMemberships.py in line 494. ---------------------------------------------------------------------- Comment By: simboforge (simboforge) Date: 2005-03-11 23:22 Message: Logged In: YES user_id=1226150 excellent. can you please give me a list of the files modified from the original distro? grep sees six that grep have msyql in them. thx ---------------------------------------------------------------------- Comment By: Kev Green (kyrian) Date: 2005-03-11 22:56 Message: Logged In: YES user_id=99923 The flat file databases are unused when you put the MySQL adaptor in place, and they are untouched (and indeed not deleted) by it, the MySQL adaptor only queries the MySQL tables for membership information, without trying to force you into using it fulltime by deleting anything, etc. Once you unconfigure the MySQL adaptor, Mailman should revert back to your existing flat file databases. Of course, I could have missed something, etc. so do back up your flat file databases before installing the MySQL adaptor, and then you can just migrate back to them by restoring the backups. Either way, you have come up with a good question for an FAQ on the SQL adaptor :-) K. ---------------------------------------------------------------------- Comment By: simboforge (simboforge) Date: 2005-03-11 22:42 Message: Logged In: YES user_id=1226150 neat. just what i was looking for. i have a couple of live lists running on version version 2.1.5. i am a bit leary about unzipping this distrobution over the top of my working mailman as i am not sure how to backup the existing flat file databases. i would prefer to experiment with dropping the adapter into my existing installation. any pointers as to where to start? thx ---------------------------------------------------------------------- Comment By: Kev Green (kyrian) Date: 2004-12-13 18:34 Message: Logged In: YES user_id=99923 Oh, btw. v1.57 hasn't been tested yet, so it might kill your server, eat your dog, and stick your wife in the oven. Be careful using it! ---------------------------------------------------------------------- Comment By: Kev Green (kyrian) Date: 2004-12-13 18:33 Message: Logged In: YES user_id=99923 Version 1.57: 2004/12/13 * Merge in Daniel Shriver patch/code for a flat table architecture. [ Suggested by Kevin McCann <kmccann(at)bellanet.org>, but I hadn't found time to do it myself... ] * Add bugfix information from Jinhyok Heo <novembre(a)NOSPAM.ournature.org> * Add in mksqlmailman script from TheSin <thesin(a)SPAMNOTHANKS.southofheaven.org> * Follow Barry Warsaw's suggestion on delivery status timestamp. ---------------------------------------------------------------------- Comment By: Kev Green (kyrian) Date: 2004-01-08 11:38 Message: Logged In: YES user_id=99923 Latest version incorporates automated generation of the necessary tables, cleaner error reporting, and updated documentation. ---------------------------------------------------------------------- Comment By: Kev Green (kyrian) Date: 2003-11-11 11:14 Message: Logged In: YES user_id=99923 Bit of an oops in version 1.49, 1.50 now uploaded, which should fix it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=839386&group_i…

1 0

[ mailman-Bugs-1212066 ] 2.1.6rc4 mailing list creation mail has no Date: header
by SourceForge.net 31 May '05

31 May '05

Bugs item #1212066, was opened at 2005-05-31 15:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1212066&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: configuring/installing Group: 2.1 beta Status: Open Resolution: None Priority: 5 Submitted By: Anton R. Ivanov (arivanov) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1.6rc4 mailing list creation mail has no Date: header Initial Comment: This is cosmetic (mostly) The mail with a subject: Mailing list creation request for list LISTNAME is sent without a Date: header which makes Mozilla and other mail clients display it as sent on 1/01/1970 A. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1212066&group_…

1 0

[ mailman-Bugs-1211922 ] Incorrect config load 2.1.5 up to 2.1.6rc4
by SourceForge.net 31 May '05

31 May '05

Bugs item #1211922, was opened at 2005-05-31 11:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1211922&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: configuring/installing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Anton R. Ivanov (arivanov) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect config load 2.1.5 up to 2.1.6rc4 Initial Comment: This is observed in debian 2.1.5 package and in 2.1.6rc4 installed from source: Custom header rules under Privacy Options/Spam filters are lost if the URL http://server/cgi-bin/mailman/admin/listname/privacy/spam is accessed directly without being authenticated in advance. How to reproduce: 1. Enter some rules 2. Logout/Login view them to see if they are still there 3. Logout 3. Try to access http://server/cgi-bin/mailman/admin/listname/privacy/spam directly. Mailman asks for a password and after that the rules are blank. 2.1.5 also loses them on a few more occasions when navigating around the web interface. In either case the custom antispam rules feature is unusable. For more information see debian bug 309870 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=309870 A. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1211922&group_…

1 0

[ mailman-Patches-1210507 ] Option to not respond to successful confirm command
by SourceForge.net 28 May '05

28 May '05

Patches item #1210507, was opened at 2005-05-28 12:05 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1210507&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mark Sapiro (msapiro) Assigned to: Nobody/Anonymous (nobody) Summary: Option to not respond to successful confirm command Initial Comment: Some people feel that the e-mail response to a successful e-mail confirm command is unnecessary and confusing. This patch to the 2.1.6rc4 base adds a mm_cfg.py option to control the sending of the e-mail reply to a successful confirm. The patch adds RESPOND_TO_SUCCESSFUL_CONFIRM = Yes to Defaults.py.in, and code to cmd_confirm.py to test this and not send the response in the case when it is a successful confirm and RESPOND_TO_SUCCESSFUL_CONFIRM has been set to No in mm_cfg.py. Note that if you apply the patch to an already configured existing installation, you need to patch Defaults.py instead of Defaults.py.in, but presumably you would only apply the patch if you were going to put RESPOND_TO_SUCCESSFUL_CONFIRM = No in mm_cfg.py anyway, so patching Defaults.py would not be mandatory in this case. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2005-05-28 15:04 Message: Logged In: YES user_id=1123998 Updated patch - structurally different but functionally the same ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1210507&group_…

1 0

[ mailman-Patches-1210507 ] Option to not respond to successful confirm command
by SourceForge.net 28 May '05

28 May '05

Patches item #1210507, was opened at 2005-05-28 12:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1210507&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Mark Sapiro (msapiro) Assigned to: Nobody/Anonymous (nobody) Summary: Option to not respond to successful confirm command Initial Comment: Some people feel that the e-mail response to a successful e-mail confirm command is unnecessary and confusing. This patch to the 2.1.6rc4 base adds a mm_cfg.py option to control the sending of the e-mail reply to a successful confirm. The patch adds RESPOND_TO_SUCCESSFUL_CONFIRM = Yes to Defaults.py.in, and code to cmd_confirm.py to test this and not send the response in the case when it is a successful confirm and RESPOND_TO_SUCCESSFUL_CONFIRM has been set to No in mm_cfg.py. Note that if you apply the patch to an already configured existing installation, you need to patch Defaults.py instead of Defaults.py.in, but presumably you would only apply the patch if you were going to put RESPOND_TO_SUCCESSFUL_CONFIRM = No in mm_cfg.py anyway, so patching Defaults.py would not be mandatory in this case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1210507&group_…

1 0

[ mailman-Bugs-1208828 ] Message from InterScan Messaging Security Suite
by SourceForge.net 25 May '05

25 May '05

Bugs item #1208828, was opened at 2005-05-26 02:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1208828&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: bounce detection Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sub Zero (subzero5) Assigned to: Nobody/Anonymous (nobody) Summary: Message from InterScan Messaging Security Suite Initial Comment: I get a bounce from InterScan Messaging Security Suite and the body of the returned message is like this (between the quotes) "****** Message from InterScan Messaging Security Suite ****** Sent <<< RCPT TO:<nonexistinguser(a)domain.dom> Received >>> 550 5.1.1 <nonexistinguser(a)domain.dom>... user unknown Unable to deliver message to <vitel(a)vitel.com.tr>. ************************ End of message **********************" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1208828&group_…

1 0

[ mailman-Patches-1208685 ] mailmanctl report status
by SourceForge.net 25 May '05

25 May '05

Patches item #1208685, was opened at 2005-05-25 15:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1208685&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: command line scripts Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: John Dennis (jdennis-redhat) Assigned to: Nobody/Anonymous (nobody) Summary: mailmanctl report status Initial Comment: Mark's point about the presence of the pid and lock files not being a definitive metric of mailman health should not be ignored. You really have to ascertain the status of the process. If mailman is abnormally aborting, which is what started this thread, then there is a high degree of probably the lock files will be left behind and testing them will give false positives. In the Red Hat mailman RPM's we've modified mailmanctl so that it can be asked the status of the mailman process as an unprivledged user and return the result as status to the shell as well as printing a message. Since mailmanctl knows how to locate the process and communicate with the process via signals it makes mailmanctl the optimal reporter of status. It was probably an oversight mailmanctl never had this facility. We have also integrated this with the mailman init.d script so that one can perform the standard "service mailman status" command. The init.d script depends on the exit status of "mailmanctl status". These two changes probably represent a more robust and standard way to determine status. Two files are patched in this patch, mailmanctl and mailman init.d script. Technically the init.d script does not need to be modified to take advantage of the mailmanctl status feature, but the two are really meant to play together. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1208685&group_…

1 0

[ mailman-Bugs-1099138 ] Scrubber.py traceback
by SourceForge.net 22 May '05

22 May '05

Bugs item #1099138, was opened at 2005-01-09 17:36 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1099138&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Owen Taylor (otaylor) Assigned to: Nobody/Anonymous (nobody) Summary: Scrubber.py traceback Initial Comment: Outgoing mail on one of our lists on mail.gnome.org was being held up because of a error that was occuring sending out digests. Jan 09 16:07:24 2005 (22410) Uncaught runner exception: len() of unsized object Jan 09 16:07:24 2005 (22410) Traceback (most recent call last): File "/var/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File "/var/mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/var/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File "/var/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/var/mailman/Mailman/Handlers/ToDigest.py", line 91, in process send_digests(mlist, mboxfp) File "/var/mailman/Mailman/Handlers/ToDigest.py", line 132, in send_digests send_i18n_digests(mlist, mboxfp) File "/var/mailman/Mailman/Handlers/ToDigest.py", line 306, in send_i18n_digests msg = scrubber(mlist, msg) File "/var/mailman/Mailman/Handlers/Scrubber.py", line 262, in process size = len(payload) TypeError: len() of unsized object Unfortunately, I don't know what mail was triggering this... was trying to get the mailing list going and didn't want to spend a lot of time investigating. It's also not immediately clear to me how payload could end up as None there... from reading the code in email.Message maybe part._payload was None due to an earlier problem. I'll attach a workaround patch... the if: also covers the call to save_attachment() since that also tracebacked when I just fixed the call to len(). Anyways, filing in case it makes sense to someone more familiar with the guts of email.Message. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-05-22 16:19 Message: Logged In: YES user_id=12800 I figured this one out and the patch should be in 2.1.6 final. Under email 2.5, it is possible to get a message with a None payload. len(None) will produce the above error. I believe it is safe to ignore such parts and that is the fix I've checked into CVS. Note that under email 3 (which Mailman can't use until Python 2.3 is a minimum requirement), you won't get those None payloads. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-01-11 23:11 Message: Logged In: YES user_id=67709 I believe I fixed this bug. it will appear in public CVS soon. ---------------------------------------------------------------------- Comment By: Owen Taylor (otaylor) Date: 2005-01-11 21:59 Message: Logged In: YES user_id=63124 Sorry about that ... that's what happens when you work on multiple computers and call patches things like 'diff'. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-01-11 21:34 Message: Logged In: YES user_id=67709 Well, the patch looks like for different project?? ---------------------------------------------------------------------- Comment By: Owen Taylor (otaylor) Date: 2005-01-09 18:15 Message: Logged In: YES user_id=63124 Oh, forgot to add say, this is python-2.2.3 and mailman-2.1.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1099138&group_…

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Mailman-coders May 2005