Mailman 3 May 2005 - Mailman-coders

[ mailman-Patches-657951 ] Generate RSS summary in archives
by SourceForge.net Aug. 19, 2022

Aug. 19, 2022

Patches item #657951, was opened at 2002-12-23 14:17 Message generated for change (Comment added) made by bwarsaw 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: Barry A. Warsaw (bwarsaw) Date: 2003-04-18 18:43 Message: Logged In: YES user_id=12800 Andrew, to get the url for the archived message use mlist.GetBaseArchiveURL(), which knows about private vs. public archives, the host name and the list name. From there you should be able to tack on just the part of the path under "archives/private/listname". See Mailman/Handlers/Scrubber.py for an example. Only other minor comment: NUM_ARTICLES can probably go in Defaults.py.in ---------------------------------------------------------------------- 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…

2 1

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

May 31, 2005

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 May 31, 2005

May 31, 2005

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 May 31, 2005

May 31, 2005

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 May 31, 2005

May 31, 2005

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 May 31, 2005

May 31, 2005

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 May 28, 2005

May 28, 2005

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 May 28, 2005

May 28, 2005

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 May 25, 2005

May 25, 2005

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 May 25, 2005

May 25, 2005

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