From noreply at sourceforge.net Fri Oct 1 19:15:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 1 19:15:16 2004 Subject: [ mailman-Patches-1029275 ] Maximum number of members per list. Message-ID: Patches item #1029275, was opened at 2004-09-16 12:31 Message generated for change (Comment added) made by iamstratus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1029275&group_id=103 Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: iamstratus (iamstratus) Assigned to: Nobody/Anonymous (nobody) Summary: Maximum number of members per list. Initial Comment: With this patch site administrators can control the maximum number of members per list. I really need this feature but it's my first attempt changing mailman code so i don't known if it's the best way to handle this situation and if a list administrator can override 'max_members'.Comments, anyone? I've patched mailman 2.1.5 and the mailman 2.1.5 official debian source package (through dpatch) and it seems to be working fine on my test server. The lists that doesn't have 'max_members'[*] or where it's 0 are unlimited and i've created (based on change_pw) the change_maxmembers script where you can change and print the 'max_members' attribute from a list (or many). [*] = How the new attributes situation is handled? On upgrade you add what's missing with the upgrade script or what? Hope that helps, Gustavo Franco -- RITS - http://www.rits.org.br/ p.s: It's being accepted i guess that we can ack some of the suggestions at the RFE #403310. ---------------------------------------------------------------------- >Comment By: iamstratus (iamstratus) Date: 2004-10-01 14:15 Message: Logged In: YES user_id=1121054 Hi, I'm sending this update to the previous patch.With this one you can create a list through web interface ('create' script) limiting the number of members. 8) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1029275&group_id=103 From noreply at sourceforge.net Sat Oct 2 09:31:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 09:31:12 2004 Subject: [ mailman-Patches-946554 ] configure does not check for gettext/msgmerge Message-ID: Patches item #946554, was opened at 2004-05-02 19:20 Message generated for change (Settings changed) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=946554&group_id=103 Category: configure/install Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: O.S. (olaf) >Assigned to: Tokio Kikuchi (tkikuchi) Summary: configure does not check for gettext/msgmerge Initial Comment: configure does not check for gettext/msgmerge, but when building with make it beaks. Mailman version 2.1.4 system: Debian stable/testing 3.0r2/3.1 python version: 2.3.3 architecture: intel-i386 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=946554&group_id=103 From noreply at sourceforge.net Sat Oct 2 09:46:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 09:46:48 2004 Subject: [ mailman-Patches-946554 ] configure does not check for gettext/msgmerge Message-ID: Patches item #946554, was opened at 2004-05-02 19:20 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=946554&group_id=103 Category: configure/install Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: O.S. (olaf) Assigned to: Tokio Kikuchi (tkikuchi) Summary: configure does not check for gettext/msgmerge Initial Comment: configure does not check for gettext/msgmerge, but when building with make it beaks. Mailman version 2.1.4 system: Debian stable/testing 3.0r2/3.1 python version: 2.3.3 architecture: intel-i386 ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-02 07:46 Message: Logged In: YES user_id=67709 closing. fixed in revision: 2.31.2.14 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=946554&group_id=103 From noreply at sourceforge.net Sat Oct 2 09:47:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 09:47:30 2004 Subject: [ mailman-Patches-946554 ] configure does not check for gettext/msgmerge Message-ID: Patches item #946554, was opened at 2004-05-02 19:20 Message generated for change (Settings changed) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=946554&group_id=103 Category: configure/install Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: O.S. (olaf) Assigned to: Tokio Kikuchi (tkikuchi) Summary: configure does not check for gettext/msgmerge Initial Comment: configure does not check for gettext/msgmerge, but when building with make it beaks. Mailman version 2.1.4 system: Debian stable/testing 3.0r2/3.1 python version: 2.3.3 architecture: intel-i386 ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-02 07:46 Message: Logged In: YES user_id=67709 closing. fixed in revision: 2.31.2.14 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=946554&group_id=103 From noreply at sourceforge.net Sat Oct 2 09:50:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 09:50:24 2004 Subject: [ mailman-Patches-799166 ] install-sh doesn't support multiple sources Message-ID: Patches item #799166, was opened at 2003-09-02 14:49 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=799166&group_id=103 Category: configure/install Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: Joerg Friedrich (jeff42) Assigned to: Nobody/Anonymous (nobody) Summary: install-sh doesn't support multiple sources Initial Comment: Hi, When not having installed a 'install'-programm configure falls back to the provided install-sh. But this Program does'nt support multiple source files. I encountered not installed files in messages (the mo-files) and the icons. Since I had no time to take a look at install-sh I send two patches to the Makefiles. Yours, Joerg ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-02 07:50 Message: Logged In: YES user_id=67709 closing. messages/Makefile.in revision: 2.31.2.14 misc/Makefile.in revision: 2.33.2.8 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=799166&group_id=103 From noreply at sourceforge.net Sat Oct 2 11:09:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 11:09:16 2004 Subject: [ mailman-Patches-796950 ] Mails get shunt for no apparent reason Message-ID: Patches item #796950, was opened at 2003-08-28 20:45 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=796950&group_id=103 Category: mail delivery Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: Nadim Shaikli (shaikli) Assigned to: Nobody/Anonymous (nobody) Summary: Mails get shunt for no apparent reason Initial Comment: Here's the patch that was noted on this thread, http://mail.python.org/pipermail/mailman-developers/2003-August/015547.html I hope it makes it ASAP as it has solved a major problem for us and could be of use to others (there is a bug report with symptoms very similar to what we saw, bug #707610 among others). --- Scrubber.py.orig 2003-08-13 23:19:19.000000000 -0700 +++ Scrubber.py 2003-08-14 00:23:47.000000000 -0700 @@ -305,6 +305,8 @@ t = unicode(t, 'ascii', 'replace').encode('ascii') try: # Should use HTML-Escape, or try generalizing to UTF-8 + if len(charset) == 0: + charset = 'us-ascii' t = t.encode(charset, 'replace') except (UnicodeError, LookupError): t = t.encode(lcset, 'replace') ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-02 09:09 Message: Logged In: YES user_id=67709 patch item #891491 was closed and merged into CVS. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-02-06 01:30 Message: Logged In: YES user_id=67709 this bug is fixed by patch item #891491 (I believe) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=796950&group_id=103 From noreply at sourceforge.net Sat Oct 2 23:45:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 2 23:45:40 2004 Subject: [ mailman-Bugs-968680 ] PDF file for list members won't print Message-ID: Bugs item #968680, was opened at 2004-06-08 03:13 Message generated for change (Comment added) made by spot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=968680&group_id=103 Category: documentation Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Ulrich Windl (windl) Assigned to: Nobody/Anonymous (nobody) Summary: PDF file for list members won't print Initial Comment: The file at http://mailman.sourceforge.net/mailman-member.pdf won't print with Adobe Acrobat 5: At page 3 it gets some error, saying the file can't be printed. My version has been created at 2003-10-07 18:17:00 with pdfTeX-0.14h. The file displays correctly on the screen however. If possible, provide a corrected PDF file, please ---------------------------------------------------------------------- Comment By: Terri Oda (spot) Date: 2004-10-02 17:45 Message: Logged In: YES user_id=110886 Can you try the latest version at http://terri.zone12.com/doc/mailman/mailman-member.pdf ? ---------------------------------------------------------------------- Comment By: Ulrich Windl (windl) Date: 2004-06-08 03:29 Message: Logged In: YES user_id=181779 After doing a "pdf2ps" and a "ps2pdf" (using Ghostscript 7), the file looked a lot uglier, but it could be printed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=968680&group_id=103 From noreply at sourceforge.net Sun Oct 3 01:27:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 3 01:27:28 2004 Subject: [ mailman-Bugs-948152 ] Out of date link on Docs webpage Message-ID: Bugs item #948152, was opened at 2004-05-04 21:57 Message generated for change (Comment added) made by spot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=948152&group_id=103 Category: documentation Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: quetza (user99) Assigned to: Nobody/Anonymous (nobody) Summary: Out of date link on Docs webpage Initial Comment: On http://www.list.org/docs.html there is a link to "HOWTO on using Exim and Mailman" (http://www.exim.org/howto/mailman.html) This refers to an old version of Exim (and mailman). The link should be: http://www.exim.org/howto/mailman21.html ---------------------------------------------------------------------- Comment By: Terri Oda (spot) Date: 2004-10-02 19:27 Message: Logged In: YES user_id=110886 I've changed this in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=948152&group_id=103 From noreply at sourceforge.net Sun Oct 3 08:04:40 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 3 08:04:47 2004 Subject: [ mailman-Patches-904850 ] Scrubber in regular delivery per list Message-ID: Patches item #904850, was opened at 2004-02-26 06:02 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=904850&group_id=103 Category: mail delivery Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: Scrubber in regular delivery per list Initial Comment: Mailman/Handlers/Scrubber.py is used to save attachments in separated area in the pipermail archive while processing the messages in archiving and digesting. We can also use this script in GLOBAL_PIPELINE to scrub all the messages for regular (non-digest) delivery. This patch makes this scrubbing configurable per list. This patch will work most of the environment (us-ascii only sites) but you are adviced to apply a separate scrubber patch #891491 to avoid i18n bugs. In mailman src dir, type patch -p1 < this_patch. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-03 06:04 Message: Logged In: YES user_id=67709 merged in CVS Scrubber.py revision: 2.18.2.8 NonDigest.py revision: 2.10.2.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=904850&group_id=103 From noreply at sourceforge.net Sun Oct 3 08:06:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 3 08:06:49 2004 Subject: [ mailman-Patches-1027882 ] filter attachments by filename extensions Message-ID: Patches item #1027882, was opened at 2004-09-14 12:55 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1027882&group_id=103 Category: mail delivery Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: filter attachments by filename extensions Initial Comment: Mailman's filter attachment feature is useful but many MUA's are sending same application files with different content-type: eg. application/pdf or application/octet-stream for PDF. Viruses also fake the content-type for executables as audio etc. So, we need to filter attachments by filename extensions by which windows assumes their associated applications. This patch enables list owners to define filename extensions to filter (block) or pass the attached file. After applying patch, configure and make install, you may have to 'bin/update -f' to force the list attribute upgrading. You may also have to check the config.pck schema version (DATA_FILE_VERSION) in Version.py and make sure the number is incremented. (90 -> 91) The old number may be different if you have applied other patches. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-03 06:06 Message: Logged In: YES user_id=67709 Merged in CVS MimeDel.py 2.5.2.1 ContentFilter.py revision: 2.6.2.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1027882&group_id=103 From noreply at sourceforge.net Mon Oct 4 09:14:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 4 09:14:23 2004 Subject: [ mailman-Bugs-968680 ] PDF file for list members won't print Message-ID: Bugs item #968680, was opened at 2004-06-08 09:13 Message generated for change (Comment added) made by windl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=968680&group_id=103 Category: documentation Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Ulrich Windl (windl) Assigned to: Nobody/Anonymous (nobody) Summary: PDF file for list members won't print Initial Comment: The file at http://mailman.sourceforge.net/mailman-member.pdf won't print with Adobe Acrobat 5: At page 3 it gets some error, saying the file can't be printed. My version has been created at 2003-10-07 18:17:00 with pdfTeX-0.14h. The file displays correctly on the screen however. If possible, provide a corrected PDF file, please ---------------------------------------------------------------------- >Comment By: Ulrich Windl (windl) Date: 2004-10-04 09:14 Message: Logged In: YES user_id=181779 Still no luck: Acrobat 5.0.5 on WIndows/XP when trying to print on a PostScript printer failed at page 3. However all pages displayed just fine. If you have some acrobat reader, maybe try to print to a PostScript file to try to reproduce. ---------------------------------------------------------------------- Comment By: Terri Oda (spot) Date: 2004-10-02 23:45 Message: Logged In: YES user_id=110886 Can you try the latest version at http://terri.zone12.com/doc/mailman/mailman-member.pdf ? ---------------------------------------------------------------------- Comment By: Ulrich Windl (windl) Date: 2004-06-08 09:29 Message: Logged In: YES user_id=181779 After doing a "pdf2ps" and a "ps2pdf" (using Ghostscript 7), the file looked a lot uglier, but it could be printed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=968680&group_id=103 From noreply at sourceforge.net Wed Oct 6 02:35:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 6 02:35:35 2004 Subject: [ mailman-Bugs-1041100 ] moderation approval should send email notification Message-ID: Bugs item #1041100, was opened at 2004-10-05 17:35 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=1041100&group_id=103 Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Kirsten Petersen (kiwimonster) Assigned to: Nobody/Anonymous (nobody) Summary: moderation approval should send email notification Initial Comment: When a non-member attempts to post to a moderated list, they receive an email informing them that their message is pending moderation. However, when the moderator has approved the message, they receive no follow-up to let them know this has happened. Since the non-member is not on the list, they have no way of knowing whether their post was successful. It would be nice to have a checkbox that allowed the moderator to notify the poster when their message has been approved. Or, to have notification sent by default. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1041100&group_id=103 From noreply at sourceforge.net Wed Oct 6 23:14:03 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 6 23:14:06 2004 Subject: [ mailman-Bugs-1041791 ] Bug in Mailman version 2.1.5 - help Message-ID: Bugs item #1041791, was opened at 2004-10-06 23:14 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=1041791&group_id=103 Category: None Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: FeniX (zmrozek) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in Mailman version 2.1.5 - help Initial Comment: Bug in Mailman version 2.1.5 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/lib/mailman/scripts/driver", line 96, in run_main main() File "/usr/lib/mailman/Mailman/Cgi/listinfo.py", line 42, in main listinfo_overview() File "/usr/lib/mailman/Mailman/Cgi/listinfo.py", line 88, in listinfo_overview if mlist.advertised: File "/usr/lib/mailman/Mailman/MailList.py", line 144, in __getattr__ raise AttributeError, name AttributeError: advertised Python information: Variable Value sys.version 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3. 3.4 (Debian 1:3.3.4-12)] sys.executable /usr/bin/python sys.prefix /usr sys.exec_prefix /usr sys.path /usr sys.platform linux2 Environment variables: Variable Value HTTP_COOKIE openwebmail-loginname=jurek; openwebmail-httpcompress=0 SERVER_SOFTWARE Apache/1.3.31 (Debian GNU/Linux) mod_gzip/1.3.26.1a SCRIPT_NAME /mailman/listinfo SERVER_SIGNATURE REQUEST_METHOD GET SERVER_PROTOCOL HTTP/1.1 QUERY_STRING HTTP_TE deflate, gzip, chunked, identity, trailers HTTP_ACCEPT_CHARSET iso-8859-2, utf-8, utf-16, iso- 8859-1;q=0.6, *;q=0.1 HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.54 [pl] HTTP_CONNECTION Keep-Alive, TE SERVER_NAME eko.org.pl REMOTE_ADDR 156.17.228.163 SERVER_PORT 80 SERVER_ADDR 195.116.86.81 DOCUMENT_ROOT /httpd/htdocs/www.eko.wroc.pl PYTHONPATH /var/lib/mailman SCRIPT_FILENAME /httpd/cgi-bin/mailman/listinfo SERVER_ADMIN webmaster@eko.wroc.pl HTTP_HOST eko.org.pl HTTP_COOKIE2 $Version=1 HTTP_CACHE_CONTROL no-cache REQUEST_URI /mailman/listinfo HTTP_ACCEPT text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 GATEWAY_INTERFACE CGI/1.1 REMOTE_PORT 2632 HTTP_ACCEPT_LANGUAGE pl;q=1.0,en;q=0.9 HTTP_ACCEPT_ENCODING deflate, gzip, x-gzip, identity, *;q=0 UNIQUE_ID QWRfL8N0VlEAACVGm7I ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1041791&group_id=103 From noreply at sourceforge.net Thu Oct 7 05:37:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 7 05:37:45 2004 Subject: [ mailman-Bugs-1041963 ] Members of sub-lists can't post to umbrella list Message-ID: Bugs item #1041963, was opened at 2004-10-06 23:37 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=1041963&group_id=103 Category: None Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Evan Prodromou (evanprodromou) Assigned to: Nobody/Anonymous (nobody) Summary: Members of sub-lists can't post to umbrella list Initial Comment: Consider list1 and list2 on the same Mailman server. The admin creates a third list, list3, to act as an umbrella list for both lists. If the admin configures list3 so that only list members can post, members of list1 or list2 can't post to the list. This is a FAQ'd problem with a workaround: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.005.htp The problem should be fixed so that the workaround isn't needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1041963&group_id=103 From noreply at sourceforge.net Thu Oct 7 05:40:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 7 05:40:24 2004 Subject: [ mailman-Bugs-1041965 ] Members of umbrella list receive double-posts Message-ID: Bugs item #1041965, was opened at 2004-10-06 23:40 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=1041965&group_id=103 Category: None Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Evan Prodromou (evanprodromou) Assigned to: Nobody/Anonymous (nobody) Summary: Members of umbrella list receive double-posts Initial Comment: Consider list1 and list2 both on the same Mailman server. An umbrella list, list3, has both lists subscribed. Users who are on both list1 and list2 will receive double copies of mail sent to list3. This is a FAQ'd problem with various workarounds; it should be fixed so that the workarounds aren't needed. http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.005.htp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1041965&group_id=103 From noreply at sourceforge.net Sat Oct 9 02:31:21 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 9 02:31:30 2004 Subject: [ mailman-Patches-790494 ] built-in automatic discard Message-ID: Patches item #790494, was opened at 2003-08-18 12:20 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=790494&group_id=103 Category: list administration Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 7 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: built-in automatic discard Initial Comment: This patch is a revision of #636412 (discard old pending post) script. While the script was to be run by cron, this patch gives full feature of 1. site wide default of MAX_DAYS_TO_HOLD in Defaults.py (mm_cfg.py). 2. list admin can set list specific max_days_to_hold through Web GUI 3. integreate in cron/checkdbs and reports the number of discarded messages. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-09 00:31 Message: Logged In: YES user_id=67709 This patch was merged in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=790494&group_id=103 From noreply at sourceforge.net Sat Oct 9 02:42:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 9 02:42:51 2004 Subject: [ mailman-Patches-789015 ] Archiver.py patch for pipermail URL generation Message-ID: Patches item #789015, was opened at 2003-08-15 00:52 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=789015&group_id=103 Category: Web UI Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: Archiver.py patch for pipermail URL generation Initial Comment: In Archiver.py, there is a function GetBaseArchiveURL() which is called whenever needed the archiver page url. While it is all right if (urlhost, mailhost) pair is one to one, if there are many to one urlhost->mailhost pairs, this function may return wrong host name. This patch trys to extract urlhost from private archive url and therefore does not suffer from multiple hostname for sigle email host. See more detailed discussion in the posting by Richard Barret in Mailman-Developers; http://mail.python.org/pipermail/mailman-developers/2003-August/015498.html ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-09 00:42 Message: Logged In: YES user_id=67709 merged in CVS: new revision: 2.28.2.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=789015&group_id=103 From noreply at sourceforge.net Sat Oct 9 04:03:48 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 9 04:04:23 2004 Subject: [ mailman-Patches-1025372 ] empty Cc: Message-ID: Patches item #1025372, was opened at 2004-09-09 20:02 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1025372&group_id=103 Category: mail delivery Group: Mailman 2.1 >Status: Closed Resolution: Later Priority: 7 Submitted By: Rob Ellis (robellis) Assigned to: Tokio Kikuchi (tkikuchi) Summary: empty Cc: Initial Comment: In lists migrated from 2.0.13, new messages without a Cc: header end up with an empty one when delivered by mailman (2.1.5). Freshly created lists don't seem to have the problem ? This is on a freebsd 4 stable machine running postfix 2.0.19,1 with mailman set up to use SMTPDirect. Python 2.3.3. The attached patch to AvoidDuplicates.py/CookHeaders.py seems to fix it... - rob ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-09 02:03 Message: Logged In: YES user_id=67709 fixed in CVS: AvoidDuplicates.py new revision: 2.1.2.2; ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-16 01:30 Message: Logged In: YES user_id=67709 Okey, I take this one for testing at my site and merge into CVS if no problem. Looks like the latter part (CookHeaders.py) is unnecessary because at least one cc is registered. ---------------------------------------------------------------------- Comment By: Morgan Fletcher (potstickr) Date: 2004-09-15 23:53 Message: Logged In: YES user_id=459672 Er, spoke too soon. Did a 'mailmanctl restart' and then sent a test message, and did not see an empty cc header. Thanks! ---------------------------------------------------------------------- Comment By: Morgan Fletcher (potstickr) Date: 2004-09-15 23:45 Message: Logged In: YES user_id=459672 I tried this patch on a netbsd machine recently upgraded from 2.0.8 to 2.1.5. After applying the patch and a 'make install' I still see the empty Cc header. This bug is causing some trouble for some our list members, so I was really hoping this fix would work. Let me know if you need debugging info or testing of possible patches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1025372&group_id=103 From noreply at sourceforge.net Sat Oct 9 06:17:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 9 06:17:39 2004 Subject: [ mailman-Bugs-1030228 ] Mass Subscribe address with control character - can't delete Message-ID: Bugs item #1030228, was opened at 2004-09-18 05:28 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1030228&group_id=103 Category: (un)subscribing Group: 2.1 (stable) >Status: Closed Resolution: None Priority: 5 Submitted By: Mark Sapiro (msapiro) Assigned to: Tokio Kikuchi (tkikuchi) Summary: Mass Subscribe address with control character - can't delete Initial Comment: Mailman 2.1.4 We mass subscribed an automatically generated list of addresses. One of these contained an ascii Vertical-Tab character. The (somewhat munged for privacy) address in the mass subscribe list was lauxxxxxher@comcast.netrixxxxxher where represents ascii Vertical Tab (hex 0B). The address was subscribed OK and then noticed to be bad. We followed the link from the member list to that member's option page an attempted to unsubscribe it and "encountered a bug". This happened twice in succession and then a third time about an hour later. The error log entry from the first try is attached (with the same address munging). Another list administrator tried the same thing the next morning and that time it worked. We don't know why what we think was the same unsubscribe procedure didn't work 3 times and then worked the next day. the following is in Utils.py # TBD: what other characters should be disallowed? _badchars = re.compile(r'[][()<>|;^,/\200-\377]') A fix might be to add the range \000-\037 to the _badchars re, but this may not be correct. It is not clear whether they should be allowed. RFC 2822 allows "non white space" control characters in domain-literals, but not in local-parts of addresses. However, RFC 2821 (SMTP) says: A domain (or domain name) consists of one or more dot-separated components. These components ("labels" in DNS terminology) are restricted for SMTP purposes to consist of a sequence of letters, digits, and hyphens drawn from the ASCII character set. Thus, it seems that for Mailman purposes it would be safe to not allow any of \000-\037 in addresses. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-09 04:17 Message: Logged In: YES user_id=67709 Closing for merged in CVS: Checking in SecurityManager.py; new revision: 2.20.2.4; previous revision: 2.20.2.3 Checking in Utils.py; new revision: 2.45.2.9; previous revision: 2.45.2.8 ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-21 00:55 Message: Logged In: YES user_id=67709 sorry, I am now updating the patch. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2004-09-20 20:47 Message: Logged In: YES user_id=1123998 I see the patch changes Utils.py as follows: -_badchars = re.compile(r'[][()<>|;^,/\200-\377]') +_badchars = re.compile(r'[][()<>|;^,\000-\037\200-\377]') Per discussion on mailman-developers list, I think \177 should also be disallowed: +_badchars = re.compile(r'[][()<>|;^,\000-\037\177-\377]') ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-20 05:20 Message: Logged In: YES user_id=67709 uploading a patch to fix this and other. ---------------------------------------------------------------------- Comment By: Terri Oda (spot) Date: 2004-09-18 05:54 Message: Logged In: YES user_id=110886 As a side note, if you have problems with illegal characters in subscribed addresses, here's the relevant FAQ entry: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.013.htp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1030228&group_id=103 From noreply at sourceforge.net Sat Oct 9 06:59:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 9 06:59:28 2004 Subject: [ mailman-Patches-1026977 ] check attachment header by SpamDetect.py Message-ID: Patches item #1026977, was opened at 2004-09-13 02:01 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1026977&group_id=103 Category: list administration Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: check attachment header by SpamDetect.py Initial Comment: SpamDetect.py and Privacy -> Spam interface can check incoming message haeder by regular expressions and discard/reject/hold the message. It can prevent viruses by blocking multipart messages but many users are now want to pass multipart. This patch extents the check into the attachment header so that viruses which have .exe/.pif file can be prevented by the same interface. Note that cheking is limited to the second level of multiparts because collecting all the header will cause infinite loop because owner notification message is also checked by this module. Usage: after applying this patch and restart mailman, go to the privacy/spam admin page and insert a rule content-.*name.*\.(exe|pif|com|vbs) to be discarded. Cheers, ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-09 04:59 Message: Logged In: YES user_id=67709 Merged in CVS, closing. Checking in Gui/Privacy.py; new revision: 2.15.2.5; previous revision: 2.15.2.4 Checking in Handlers/SpamDetect.py; new revision: 2.3.2.2; previous revision: 2.3.2.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1026977&group_id=103 From noreply at sourceforge.net Sat Oct 9 07:00:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 9 07:00:36 2004 Subject: [ mailman-Patches-1032434 ] make KNOWN_SPAMMERS work for headers appearing mult. times Message-ID: Patches item #1032434, was opened at 2004-09-22 08:39 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1032434&group_id=103 Category: mail delivery Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: Alexander Bergolth (bergolth) Assigned to: Tokio Kikuchi (tkikuchi) Summary: make KNOWN_SPAMMERS work for headers appearing mult. times Initial Comment: Hi! Currently the header check against the KNOWN_SPAMMERS config option in SpamDetect.py uses msg[header], i.e. __getitem__. This method only checks against the first matching header: Note that if the header appeared multiple times, exactly which occurrance gets returned is undefined. Use getall() to get all the values matching a header field name. I've changed the code to use msg.get_all() instead. --leo ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-09 05:00 Message: Logged In: YES user_id=67709 Merged in CVS; closing. Checking in Handlers/SpamDetect.py; new revision: 2.3.2.2; previous revision: 2.3.2.1 ---------------------------------------------------------------------- Comment By: Alexander Bergolth (bergolth) Date: 2004-09-24 08:11 Message: Logged In: YES user_id=24695 I'm using spamassassin and amavisd to tag spam and viruses. The header lines added by the virus-check look like the following: ---------- snipp! ---------- X-Amavis-Alert: INFECTED, message contains virus: Worm.SomeFool.Gen-1 X-Amavis-Alert: BANNED FILENAME, message contains part named: .exe ---------- snipp! ---------- I.e. there are multiple "X-Amavis-Alert" headers to be considered. --leo ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-24 02:20 Message: Logged In: YES user_id=67709 Looks like resonable to me. So, testing in my site. Do you have example to catch spam with this patch enabled. (received: ??) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1032434&group_id=103 From noreply at sourceforge.net Sat Oct 9 14:27:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 9 14:27:41 2004 Subject: [ mailman-Patches-804162 ] Bug: unsubscription confirmation from Web bypasses approval Message-ID: Patches item #804162, was opened at 2003-09-11 03:53 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=804162&group_id=103 Category: Web UI Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: Hatuka*nezumi (hatukanezumi) Assigned to: Nobody/Anonymous (nobody) Summary: Bug: unsubscription confirmation from Web bypasses approval Initial Comment: When a member submit unsubscription request from Web UI (options) without logging in then submit confirmation from Web UI (confirm), s/he can be unsubscribed without moderator approval. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-09 12:27 Message: Logged In: YES user_id=67709 looks like this was closed in a different way. see Mailman/Cgi/options.py rev=2.40.2.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=804162&group_id=103 From noreply at sourceforge.net Sat Oct 9 14:55:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 9 14:55:37 2004 Subject: [ mailman-Patches-601117 ] add sequencial number in subject prefix Message-ID: Patches item #601117, was opened at 2002-08-28 05:07 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=601117&group_id=103 Category: mail delivery Group: Mailman 2.2 / 3.0 >Status: Closed Resolution: None Priority: 7 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: add sequencial number in subject prefix Initial Comment: This patch for 'CookHeaders.py' add an ability to add a sequencial number in the subject prefix. You can define a subject prefix like: [listname %d] Then, the subject line of delivered mail becomes: Subject: [listname 123] Hoge hoge When someone replied this mail, mailman receives a messages with: Subject: Re: [listname 123] Hoge hoge Then, this patch removes [listname \d+] part and deliver it with: Subject: [listname 124] Re: Hoge hoge And next, another person replies with Subject: Re: [listname 124] Re: Hoge hoge Then, (magically!) you get: Subject: [listname 125] Re: Hoge hoge Not with Re: Re: Hoge hoge. Looks like complicated but this patch has been working well with Japanese-enhanced Mailman for more than a year. Without %d, this patch works like current version, I believe. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-09 12:55 Message: Logged In: YES user_id=67709 Merged in CVS. Checking in Gui/General.py; new revision: 2.22.2.3; previous revision: 2.22.2.2 Checking in Handlers/CookHeaders.py; new revision: 2.33.2.7; previous revision: 2.33.2.6 ---------------------------------------------------------------------- Comment By: yoda (shobhanc) Date: 2004-09-14 06:16 Message: Logged In: YES user_id=598275 Hi tkikuchi, There are some gibberish text within the patch, are they Japanesh chars..?? If possible can you look at this tracker and give your suggestions.https://sourceforge.net/tracker/index.php?func=detail&aid=1024289&group_id=103&atid=300103 This is basically I want to implement threading in Mailman. Yes Mailman implements threading I agree but when the mail replies are sent using Lotus Notes 5.0.8/5.0.9 the threading doesn't work because Lotus Notes doesn't set the "In-Reply-To" header. Thanks for your time ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-05-24 21:28 Message: Logged In: YES user_id=67709 You can download the patch for 2.1.5 from http://mm.tkikuchi.net/mailman-2.1.5+patch.20040516.gz TK ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-02-08 06:10 Message: Logged In: YES user_id=67709 This patch for 2.1.3 is also applicable to 2.1.4. Though one patch fails to apply, it can safely be neglected. You can also get a newer and more convenient patch at: http://mm.tkikuchi.net/mailman-2.1.4+patch.20040123.gz Cheers, TK ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-09-29 01:21 Message: Logged In: YES user_id=67709 Now the patch includes instruction in General admin page. (in detail part). In source dir you should type: patch -p0 < /path/to/seqnum.patch ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-05-18 02:01 Message: Logged In: YES user_id=67709 Here is update of my patch for 2.1.2 ---------------------------------------------------------------------- Comment By: Mitchell Marks (jojoba2) Date: 2003-05-17 17:42 Message: Logged In: YES user_id=718482 Is there a version vor MM 2.1.2? I'm trying the older one but doesn't seem to work. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-02-27 05:33 Message: Logged In: YES user_id=67709 sorry for daily update but there was an error in i18n handling of '(no subject)' ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-02-26 01:25 Message: Logged In: YES user_id=67709 update of patch for 2.1.1 if the subject is all ascii, then cat the prefix and subject before it is instantiated. Hope to solve prefix only subject 1st line. Note: with this patch without $d, Re: [prefix] is now mungled to [prefix] Re:. This is useful if someone post new issue as follow up to old subject like; New subject bah bah was Re: [prefix] foo ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2003-02-14 11:33 Message: Logged In: YES user_id=67709 Hi, I am pleased you like this patch. Here is my current version attached. ---------------------------------------------------------------------- Comment By: Fabio Rossetti (fabiorossetti) Date: 2003-02-14 10:02 Message: Logged In: YES user_id=693899 If you need a quick fix to make the patch work with 2.1.1 here's my take (it's the diff file adapted to work with 2.1.1 CookHeaders.py) 17a18 > (sequence version) 221c222,223 < prefix = mlist.subject_prefix --- > prefix = mlist.subject_prefix.strip(); > if not prefix: return 237,243c239,250 < if prefix and subject: < pattern = re.escape(prefix.strip()) < for decodedsubj, charset in headerbits: < if re.search(pattern, decodedsubj, re.IGNORECASE): < # The subject's already got the prefix, so don't change it < return < del msg['subject'] --- > headerstring = '' > fws = '' > cset = None > for (s, c) in headerbits: > headerstring += fws + s > if c == None or c == 'us-ascii': > fws = ' ' > cset = Utils.GetCharSet(mlist.preferred_language) > else: > fws = '' > cset = c > # Note: searching prefix in subject is REMOVED. (seq version) 245a253,275 > else: > subject = headerstring > # If the subject_prefix contains '%d', it is replaced with the > # mailing list sequential number. Also, if the prefix is closed with > # [],(), or {}, the prefix in the responding post subject will be cared. > # sequential number format allows '%05d' like pattern. > p = re.compile('%\d*d') > if p.search(prefix,1): > # prefix have number, so we should search prefix w/number > # in subject. > prefix_pattern = p.sub(r'\s*\d+\s*', prefix) > else: > prefix_pattern = prefix > prefix_pattern = re.sub('([\[\(\{])', '\\\g<1>', prefix_pattern) > subject = re.sub(prefix_pattern, '', subject) > subject = re.compile('(RE:\s*)+', re.I).sub('Re: ', subject, 1) > # and substitute %d in prefix with post_id > try: > prefix = prefix % mlist.post_id > except: > pass > # Note that trailing space was stripped in seq version (TK) > prefix += ' ' 248,262c278,288 < for s, c in headerbits: < # Once again, convert the string to unicode. < if c is None: < c = Charset('iso-8859-1') < if not isinstance(c, Charset): < c = Charset(c) < if not _isunicode(s): < codec = c.input_codec or 'ascii' < try: < s = unicode(s, codec, 'replace') < except LookupError: < # Unknown codec, is this default reasonable? < s = unicode(s, Utils.GetCharSet (mlist.preferred_language), < 'replace') < h.append(s, c) --- > # in seq version, subject header is already concatnated > if not _isunicode(subject): > try: > subject = unicode(subject, cset, 'replace') > except LookupError: > # unknown codec > cset = Utils.GetCharSet(mlist.preferred_language) > subject = unicode(subject, cset, 'replace') > subject = subject.encode(cset) > h.append(subject, cset) > del msg['subject'] ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2002-12-20 04:31 Message: Logged In: YES user_id=67709 update for 2.1b6+ ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2002-10-31 05:59 Message: Logged In: YES user_id=67709 I have uploaded the patch with the same name as the old one. Please download the upper one because it's newer. Sorry for the inconvenience. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2002-10-31 05:53 Message: Logged In: YES user_id=67709 Patch ID 625482 (i18n List-Id) and this was merged for 2.1b4+ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=601117&group_id=103 From noreply at sourceforge.net Sun Oct 10 19:15:49 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 10 19:15:52 2004 Subject: [ mailman-Feature Requests-1044103 ] Webmail interface for mailman Message-ID: Feature Requests item #1044103, was opened at 2004-10-10 19:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1044103&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: PingHansen (pinghansen) Assigned to: Nobody/Anonymous (nobody) Summary: Webmail interface for mailman Initial Comment: I would dearly love to see a webmail interface for mailman, where users could read and post mail online. The functionality I wish for, is similar to the mail functions known from yahoogroups. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1044103&group_id=103 From noreply at sourceforge.net Mon Oct 11 23:11:34 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 11 23:11:40 2004 Subject: [ mailman-Patches-457706 ] Union Mailing Lists membership adaptor Message-ID: Patches item #457706, was opened at 2001-09-02 09:03 Message generated for change (Comment added) made by pjsm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=457706&group_id=103 Category: mail delivery Group: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 3 Submitted By: Mark Tearle (mtearle) Assigned to: Nobody/Anonymous (nobody) Summary: Union Mailing Lists membership adaptor Initial Comment: Provides functionality/behaviour similar to how sendmail treats its aliases file. eg alias1: alias2, alias3 alias2: a, b alias3: b, c would only deliver one message to the union of alias2 and alias3 which is a, b, c Also, an example of the MemberAdaptor API ---------------------------------------------------------------------- Comment By: Paulo Matos (pjsm) Date: 2004-10-11 21:11 Message: Logged In: YES user_id=80175 Was this issue dropped/postponed again? TIA. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-11-19 01:10 Message: Logged In: YES user_id=12800 Postponing until after MM2.1 ---------------------------------------------------------------------- Comment By: Mark Tearle (mtearle) Date: 2002-01-14 07:04 Message: Logged In: YES user_id=2554 Updated UnionMemberAdaptor for 2.1a4 (basically just extra methods) ---------------------------------------------------------------------- Comment By: Mark Tearle (mtearle) Date: 2001-09-02 09:07 Message: Logged In: YES user_id=2554 Against Mailman 2.1a3 (May need to bump version number in Version.py) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=457706&group_id=103 From noreply at sourceforge.net Tue Oct 12 21:50:29 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 12 21:50:32 2004 Subject: [ mailman-Patches-1045656 ] Race in LockFile.py resulting in extraneous log entries. Message-ID: Patches item #1045656, was opened at 2004-10-12 14:50 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=1045656&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Brian Greenberg (grnbrg) Assigned to: Nobody/Anonymous (nobody) Summary: Race in LockFile.py resulting in extraneous log entries. Initial Comment: There is a race condition (that does not affect correct operation of Mailman) in .../Mailman/LockFile.py. This race results in entries to the "locks" log file (usually in pairs) that are unnecessary and confusing. If there is a process holding a lock for a file, and a process waiting for that lock to be freed, the following sequence can occur: 1) The waiting process executes os.link(). Since the running process still has the lock, this fails with EEXIST. 2) The running process releases the lock, and removes the lock file. 3) The waiting process proceeds with it's checks, and checks self.__linkcount() which returns -1 due to an ENOENT error. This throws an error into the "locks" log file. 4) The waiting process continues processing, checks it's timeout, and then checks to see if the lock lifetime has expired. The lifetime check is based on a call to self.__releasetime(), which returns -1, due to an ENOENT error. This results in the lockfile being declared stale, and self.__break() is called. This then throws a second error into the "locks" log file. The attached patch checks for these ENOENT errors, immediately restarting the loop when they are detected. It does not affect operation is the lock file exists and is held by another process. Brian Greenberg. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045656&group_id=103 From noreply at sourceforge.net Tue Oct 12 21:51:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 12 21:51:36 2004 Subject: [ mailman-Patches-1045656 ] Race in LockFile.py resulting in extraneous log entries. Message-ID: Patches item #1045656, was opened at 2004-10-12 14:50 Message generated for change (Settings changed) made by grnbrg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045656&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None >Priority: 3 Submitted By: Brian Greenberg (grnbrg) Assigned to: Nobody/Anonymous (nobody) Summary: Race in LockFile.py resulting in extraneous log entries. Initial Comment: There is a race condition (that does not affect correct operation of Mailman) in .../Mailman/LockFile.py. This race results in entries to the "locks" log file (usually in pairs) that are unnecessary and confusing. If there is a process holding a lock for a file, and a process waiting for that lock to be freed, the following sequence can occur: 1) The waiting process executes os.link(). Since the running process still has the lock, this fails with EEXIST. 2) The running process releases the lock, and removes the lock file. 3) The waiting process proceeds with it's checks, and checks self.__linkcount() which returns -1 due to an ENOENT error. This throws an error into the "locks" log file. 4) The waiting process continues processing, checks it's timeout, and then checks to see if the lock lifetime has expired. The lifetime check is based on a call to self.__releasetime(), which returns -1, due to an ENOENT error. This results in the lockfile being declared stale, and self.__break() is called. This then throws a second error into the "locks" log file. The attached patch checks for these ENOENT errors, immediately restarting the loop when they are detected. It does not affect operation is the lock file exists and is held by another process. Brian Greenberg. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045656&group_id=103 From noreply at sourceforge.net Wed Oct 13 07:43:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 13 07:43:18 2004 Subject: [ mailman-Patches-1045909 ] user cancel of pending subscription fails Message-ID: Patches item #1045909, was opened at 2004-10-13 14:43 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=1045909&group_id=103 Category: Web UI Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Jim Tittsler (jtittsler) Assigned to: Nobody/Anonymous (nobody) Summary: user cancel of pending subscription fails Initial Comment: If a user visits the "Confirm subscription request" page and presses the "Cancel my subscription request" link, an AssertionError is raised because the list is not locked. This list should be locked before attempting to discard the cookie. Also mentioned in Bug report 981188 https://sourceforge.net/tracker/index.php?func=detail&aid=981188&group_id=103&atid=100103 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045909&group_id=103 From noreply at sourceforge.net Wed Oct 13 14:41:12 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 13 14:41:16 2004 Subject: [ mailman-Patches-1045909 ] user cancel of pending subscription fails Message-ID: Patches item #1045909, was opened at 2004-10-13 05:43 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045909&group_id=103 Category: Web UI Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: Jim Tittsler (jtittsler) Assigned to: Nobody/Anonymous (nobody) Summary: user cancel of pending subscription fails Initial Comment: If a user visits the "Confirm subscription request" page and presses the "Cancel my subscription request" link, an AssertionError is raised because the list is not locked. This list should be locked before attempting to discard the cookie. Also mentioned in Bug report 981188 https://sourceforge.net/tracker/index.php?func=detail&aid=981188&group_id=103&atid=100103 ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-13 12:41 Message: Logged In: YES user_id=67709 Thank you Jim! The patch was merged in CVS. Checking in confirm.py; new revision: 2.31.2.5; previous revision: 2.31.2.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045909&group_id=103 From noreply at sourceforge.net Wed Oct 13 14:43:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 13 14:44:02 2004 Subject: [ mailman-Bugs-981188 ] Cannot cancel subscription on confirmation page Message-ID: Bugs item #981188, was opened at 2004-06-28 11:32 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=981188&group_id=103 Category: (un)subscribing Group: 2.1 (stable) >Status: Closed Resolution: None Priority: 5 Submitted By: mranner (mranner) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot cancel subscription on confirmation page Initial Comment: Bug in Mailman version 2.1.5 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/local/mailman/scripts/driver", line 87, in run_main main() File "/usr/local/mailman/Mailman/Cgi/confirm.py", line 114, in main subscription_cancel(mlist, doc, cookie) File "/usr/local/mailman/Mailman/Cgi/confirm.py", line 312, in subscription_cancel userdesc = mlist.pend_confirm(cookie)[1] File "/usr/local/mailman/Mailman/Pending.py", line 141, in pend_confirm assert self.Locked() AssertionError Python information: Variable Value sys.version 2.3.3 (#1, Jan 10 2004, 17:19:45) [GCC 2.95.4 20020320 [FreeBSD]] sys.executable /usr/local/bin/python sys.prefix /usr/local sys.exec_prefix /usr/local sys.path /usr/local sys.platform freebsd4 Environment variables: Variable Value HTTP_REFERER https://secure.inforum.at/mailman/confirm/vinegar-newsletter/c082c7391977d2edb7c174f3ac3318964119fc24 SERVER_SOFTWARE Apache/1.3.31 (Unix) mod_gzip/1.3.26.1a DAV/1.0.3 FrontPage/5.0.2.2623 mod_ssl/2.8.18 OpenSSL/0.9.7c PHP/4.3.5 SCRIPT_NAME /mailman/confirm SERVER_SIGNATURE Apache/1.3.31 Server at secure.inforum.at Port 443 REQUEST_METHOD POST PATH_INFO /vinegar-newsletter SERVER_PROTOCOL HTTP/1.1 QUERY_STRING CONTENT_LENGTH 121 HTTP_ACCEPT_CHARSET iso-8859-15, utf-8;q=0.5, *;q=0.5 HTTP_USER_AGENT Mozilla/5.0 (compatible; Konqueror/3.2; FreeBSD; X11; i386) (KHTML, like Gecko) HTTP_CONNECTION Keep-Alive SERVER_NAME secure.inforum.at REMOTE_ADDR 213.229.17.146 PATH_TRANSLATED /www/virtual/secure.inforum.at/data/vinegar-newsletter SERVER_PORT 443 SERVER_ADDR 195.58.178.86 DOCUMENT_ROOT /www/virtual/secure.inforum.at/data HTTP_PRAGMA no-cache PYTHONPATH /usr/local/mailman SCRIPT_FILENAME /usr/local/mailman/cgi-bin/confirm SERVER_ADMIN webmaster@inforum.at HTTP_HOST secure.inforum.at HTTPS on HTTP_CACHE_CONTROL no-cache REQUEST_URI /mailman/confirm/vinegar-newsletter HTTP_ACCEPT text/html, image/jpeg, image/png, text/*, image/*, */* GATEWAY_INTERFACE CGI/1.1 REMOTE_PORT 49579 HTTP_ACCEPT_LANGUAGE de, en CONTENT_TYPE application/x-www-form-urlencoded HTTP_ACCEPT_ENCODING x-gzip, x-deflate, gzip, deflate UNIQUE_ID QOAAWMM6slYAAD56QB4 ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-13 12:43 Message: Logged In: YES user_id=67709 Thank Jim Tittsler for patch. It was fixed in CVS. ---------------------------------------------------------------------- Comment By: mranner (mranner) Date: 2004-06-28 11:34 Message: Logged In: YES user_id=1072505 cannot cancel "pending" subscribtion on confirmation page ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=981188&group_id=103 From noreply at sourceforge.net Wed Oct 13 14:45:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 13 14:45:59 2004 Subject: [ mailman-Bugs-954806 ] AssertionError when Web-canceling subscribtion in 2.1.5 Message-ID: Bugs item #954806, was opened at 2004-05-16 12:28 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=954806&group_id=103 Category: Web/CGI Group: 2.1 (stable) >Status: Closed Resolution: None Priority: 5 Submitted By: Raimund Specht (rspecht) Assigned to: Nobody/Anonymous (nobody) Summary: AssertionError when Web-canceling subscribtion in 2.1.5 Initial Comment: I subscribe to a mailing list and get the confirmation mail. I go to the web confirmation page and choose NOT to confirm but to cancel the subscription, I get the following traceback. Confirming a subscription through web works fine though. [----- Mailman Version: 2.1.5 -----] [----- Traceback ------] Traceback (most recent call last): File "/home/pacs/rsp00/mailman/scripts/driver", line 87, in run_main main() File "/home/pacs/rsp00/mailman/Mailman/Cgi/confirm.py", line 114, in main subscription_cancel(mlist, doc, cookie) File "/home/pacs/rsp00/mailman/Mailman/Cgi/confirm.py", line 312, in subscription_cancel userdesc = mlist.pend_confirm(cookie)[1] File "/home/pacs/rsp00/mailman/Mailman/Pending.py", line 141, in pend_confirm assert self.Locked() AssertionError [----- Python Information -----] sys.version = 2.1.3 (#1, Sep 7 2002, 15:29:56) [GCC 2.95.4 20011002 (Debian prerelease)] sys.executable = /usr/bin/python sys.platform = linux2 ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-13 12:45 Message: Logged In: YES user_id=67709 Thank Jim Tittsler for patch. This was fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=954806&group_id=103 From noreply at sourceforge.net Wed Oct 13 15:06:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 13 15:07:47 2004 Subject: [ mailman-Bugs-1041791 ] Bug in Mailman version 2.1.5 - help Message-ID: Bugs item #1041791, was opened at 2004-10-06 21:14 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1041791&group_id=103 Category: None Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: FeniX (zmrozek) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in Mailman version 2.1.5 - help Initial Comment: Bug in Mailman version 2.1.5 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/lib/mailman/scripts/driver", line 96, in run_main main() File "/usr/lib/mailman/Mailman/Cgi/listinfo.py", line 42, in main listinfo_overview() File "/usr/lib/mailman/Mailman/Cgi/listinfo.py", line 88, in listinfo_overview if mlist.advertised: File "/usr/lib/mailman/Mailman/MailList.py", line 144, in __getattr__ raise AttributeError, name AttributeError: advertised Python information: Variable Value sys.version 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3. 3.4 (Debian 1:3.3.4-12)] sys.executable /usr/bin/python sys.prefix /usr sys.exec_prefix /usr sys.path /usr sys.platform linux2 Environment variables: Variable Value HTTP_COOKIE openwebmail-loginname=jurek; openwebmail-httpcompress=0 SERVER_SOFTWARE Apache/1.3.31 (Debian GNU/Linux) mod_gzip/1.3.26.1a SCRIPT_NAME /mailman/listinfo SERVER_SIGNATURE REQUEST_METHOD GET SERVER_PROTOCOL HTTP/1.1 QUERY_STRING HTTP_TE deflate, gzip, chunked, identity, trailers HTTP_ACCEPT_CHARSET iso-8859-2, utf-8, utf-16, iso- 8859-1;q=0.6, *;q=0.1 HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.54 [pl] HTTP_CONNECTION Keep-Alive, TE SERVER_NAME eko.org.pl REMOTE_ADDR 156.17.228.163 SERVER_PORT 80 SERVER_ADDR 195.116.86.81 DOCUMENT_ROOT /httpd/htdocs/www.eko.wroc.pl PYTHONPATH /var/lib/mailman SCRIPT_FILENAME /httpd/cgi-bin/mailman/listinfo SERVER_ADMIN webmaster@eko.wroc.pl HTTP_HOST eko.org.pl HTTP_COOKIE2 $Version=1 HTTP_CACHE_CONTROL no-cache REQUEST_URI /mailman/listinfo HTTP_ACCEPT text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 GATEWAY_INTERFACE CGI/1.1 REMOTE_PORT 2632 HTTP_ACCEPT_LANGUAGE pl;q=1.0,en;q=0.9 HTTP_ACCEPT_ENCODING deflate, gzip, x-gzip, identity, *;q=0 UNIQUE_ID QWRfL8N0VlEAACVGm7I ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-13 13:06 Message: Logged In: YES user_id=67709 Can you explain more detail of the environment ? Is this your fresh install of mailman, or upgrading from older version ? Install from source or package ? What do you you when you exec 'ls -l /lists/*' ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1041791&group_id=103 From noreply at sourceforge.net Wed Oct 13 15:08:39 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 13 15:08:44 2004 Subject: [ mailman-Feature Requests-1041965 ] Members of umbrella list receive double-posts Message-ID: Feature Requests item #1041965, was opened at 2004-10-07 03:40 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1041965&group_id=103 Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Evan Prodromou (evanprodromou) Assigned to: Nobody/Anonymous (nobody) Summary: Members of umbrella list receive double-posts Initial Comment: Consider list1 and list2 both on the same Mailman server. An umbrella list, list3, has both lists subscribed. Users who are on both list1 and list2 will receive double copies of mail sent to list3. This is a FAQ'd problem with various workarounds; it should be fixed so that the workarounds aren't needed. http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.005.htp ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-13 13:08 Message: Logged In: YES user_id=67709 This is more a feature request than a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1041965&group_id=103 From noreply at sourceforge.net Wed Oct 13 15:09:30 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 13 15:09:34 2004 Subject: [ mailman-Feature Requests-1041963 ] Members of sub-lists can't post to umbrella list Message-ID: Feature Requests item #1041963, was opened at 2004-10-07 03:37 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1041963&group_id=103 Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Evan Prodromou (evanprodromou) Assigned to: Nobody/Anonymous (nobody) Summary: Members of sub-lists can't post to umbrella list Initial Comment: Consider list1 and list2 on the same Mailman server. The admin creates a third list, list3, to act as an umbrella list for both lists. If the admin configures list3 so that only list members can post, members of list1 or list2 can't post to the list. This is a FAQ'd problem with a workaround: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.005.htp The problem should be fixed so that the workaround isn't needed. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-13 13:09 Message: Logged In: YES user_id=67709 This is more a feature request than a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1041963&group_id=103 From noreply at sourceforge.net Wed Oct 13 15:10:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 13 15:10:41 2004 Subject: [ mailman-Feature Requests-1041100 ] moderation approval should send email notification Message-ID: Feature Requests item #1041100, was opened at 2004-10-06 00:35 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1041100&group_id=103 >Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kirsten Petersen (kiwimonster) Assigned to: Nobody/Anonymous (nobody) Summary: moderation approval should send email notification Initial Comment: When a non-member attempts to post to a moderated list, they receive an email informing them that their message is pending moderation. However, when the moderator has approved the message, they receive no follow-up to let them know this has happened. Since the non-member is not on the list, they have no way of knowing whether their post was successful. It would be nice to have a checkbox that allowed the moderator to notify the poster when their message has been approved. Or, to have notification sent by default. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-13 13:10 Message: Logged In: YES user_id=67709 This is more a feature request than a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1041100&group_id=103 From noreply at sourceforge.net Thu Oct 14 08:24:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 14 08:24:22 2004 Subject: [ mailman-Feature Requests-1024289 ] Add threading support for Lotus Notes < 5.0.9 Message-ID: Feature Requests item #1024289, was opened at 2004-09-08 15:35 Message generated for change (Comment added) made by shobhanc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1024289&group_id=103 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: yoda (shobhanc) Assigned to: Nobody/Anonymous (nobody) Summary: Add threading support for Lotus Notes < 5.0.9 Initial Comment: Lotus Notes below 6.25 doesnt set the 'In-Reply-To' or 'References' header. but it sets 'Orig' and 'REF' headers. Mailman should be able to process 'Orig' and 'REF' headers if 'In-Reply-To' is not set for Lotus Notes. Does anyone have any idea how to do this..? Thanks ---------------------------------------------------------------------- >Comment By: yoda (shobhanc) Date: 2004-10-14 11:24 Message: Logged In: YES user_id=598275 Hi tkikuchi, I've attached a patch for CookHeaders.py to solve the threading issue with Lotus Notes < 6.00. How does this work: ---------------------- 1) For each incoming the Message-Id value of the mail is added to the 'Subject' line with the following format: Subject: Testing [<09238-343430@testing.com>] 2) If the subject line has a message-id value, the value is grabbed and will be added to a new "In-Reply-To' header with that value. Because we have a In-Reply-To header with the value of old message-id, we need not worry about threading. Thanks -Shobhan ---------------------------------------------------------------------- Comment By: yoda (shobhanc) Date: 2004-09-15 10:16 Message: Logged In: YES user_id=598275 ok, here are the headers generated by Lotus Notes 5.0.8. 1) The headers of the first mail sent from Lotus Notes: Return-path: Envelope-to: root@sfeng00.lotussoft.com Received: from lotus-testing.com ([11.1.30.111]) by sfeng00.lotussoft.com with esmtp (Exim 3.36 #1 (GForge)) id 1C7RyW-0004Zg-00; Wed, 15 Sep 2004 10:35:00 +0530 Subject: Test mail To: lotus-thread-mail@sfeng00.lotussoft.com Cc: root@sfeng00.lotussoft.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: postmaster@lotus-testing.com Date: Wed, 15 Sep 2004 10:33:51 +0530 X-MIMETrack: Serialize by Router on lotus-testing/LOTUSTesting(Release 5.0.8 |June 18, 2001) at 09/15/2004 10:33:51 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii This is the test mail 2) The reply headers for the original mail from Lotus Notes: Return-path: Envelope-to: root@sfeng00.lotussoft.com Received: from lotus-testing.com ([11.1.30.111]) by sfeng00.lotussoft.com with esmtp (Exim 3.36 #1 (GForge)) id 1C7S3q-0004an-00; Wed, 15 Sep 2004 10:40:30 +0530 Subject: Re: [Lotus-thread-mail] Test mail To: postmaster@lotus-testing.com Cc: lotus-thread-mail@sfeng00.lotussoft.com, lotus-thread-mail-admin@sfeng00.lotussoft.com, X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: postmaster@lotus-testing.com Date: Wed, 15 Sep 2004 10:39:21 +0530 X-MIMETrack: Serialize by Router on lotus-testing/LOTUSTesting(Release 5.0.8 |June 18, 2001) at 09/15/2004 10:39:21 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Reply to the test mail. Thanks ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-15 07:25 Message: Logged In: YES user_id=67709 Sorry but I have no Notes users around. So, this is low priority. I suggest you upload relevant message header example in case some one is interested. ---------------------------------------------------------------------- Comment By: yoda (shobhanc) Date: 2004-09-14 19:37 Message: Logged In: YES user_id=598275 Thanks tkikuchi, Any idea whats the alternative to thread the mails if $REF header is not set in the reply mail from Lotus Notes, like an autogenerated number be added to the subject line and check the number in the reply mail and generate a thread likewise..?? Thanks for your time. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-14 18:06 Message: Logged In: YES user_id=67709 No patch. Requesting a feature. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1024289&group_id=103 From noreply at sourceforge.net Fri Oct 15 02:11:52 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 15 02:11:59 2004 Subject: [ mailman-Patches-1045656 ] Race in LockFile.py resulting in extraneous log entries. Message-ID: Patches item #1045656, was opened at 2004-10-13 04:50 Message generated for change (Comment added) made by shigeno You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045656&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 3 Submitted By: Brian Greenberg (grnbrg) Assigned to: Nobody/Anonymous (nobody) Summary: Race in LockFile.py resulting in extraneous log entries. Initial Comment: There is a race condition (that does not affect correct operation of Mailman) in .../Mailman/LockFile.py. This race results in entries to the "locks" log file (usually in pairs) that are unnecessary and confusing. If there is a process holding a lock for a file, and a process waiting for that lock to be freed, the following sequence can occur: 1) The waiting process executes os.link(). Since the running process still has the lock, this fails with EEXIST. 2) The running process releases the lock, and removes the lock file. 3) The waiting process proceeds with it's checks, and checks self.__linkcount() which returns -1 due to an ENOENT error. This throws an error into the "locks" log file. 4) The waiting process continues processing, checks it's timeout, and then checks to see if the lock lifetime has expired. The lifetime check is based on a call to self.__releasetime(), which returns -1, due to an ENOENT error. This results in the lockfile being declared stale, and self.__break() is called. This then throws a second error into the "locks" log file. The attached patch checks for these ENOENT errors, immediately restarting the loop when they are detected. It does not affect operation is the lock file exists and is held by another process. Brian Greenberg. ---------------------------------------------------------------------- Comment By: SHIGENO Kazutaka (shigeno) Date: 2004-10-15 09:11 Message: Logged In: YES user_id=1138453 How about changing as follows about self.__releasetime()? @@ -448,7 +448,7 @@ return os.stat(self.__lockfile)[ST_MTIME] except OSError, e: if e.errno <> errno.ENOENT: raise - return -1 + return time.time() def __linkcount(self): try: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045656&group_id=103 From noreply at sourceforge.net Fri Oct 15 05:41:42 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 15 05:41:46 2004 Subject: [ mailman-Bugs-1047531 ] problem with "discard all ... Message-ID: Bugs item #1047531, was opened at 2004-10-14 23:41 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=1047531&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Relson (relson) Assigned to: Nobody/Anonymous (nobody) Summary: problem with "discard all ... Initial Comment: Greetings, I've noticed a minor problem with mailman 2.1.5. My main use of the admindb page is deleting spam. From admin page http://www.mydomain.com/mailman/admindb/mylist, checking "Discard all messages marked Defer" and clicking on SUBMIT works fine. Occasionally, I will use the "you can view all messages from address@example.com" link. If I click on "Discard all messages marked Defer", the message isn't discarded. What the heck's going on here??? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1047531&group_id=103 From noreply at sourceforge.net Fri Oct 15 05:44:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 15 05:44:27 2004 Subject: [ mailman-Bugs-1047532 ] problem with "discard all ..." Message-ID: Bugs item #1047532, was opened at 2004-10-14 23:44 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=1047532&group_id=103 Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: David Relson (relson) Assigned to: Nobody/Anonymous (nobody) Summary: problem with "discard all ..." Initial Comment: Mailman 2.1.5: >From admin page http://www.mydomain.com/mailman/admindb/mylist, checking "Discard all messages marked Defer" and clicking on SUBMIT works fine -- removes the message(s). If I click on the "you can view all messages from address@example.com" link, and then click on "Discard all messages marked Defer", the message(s) aren't discarded. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1047532&group_id=103 From noreply at sourceforge.net Fri Oct 15 05:44:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 15 05:45:00 2004 Subject: [ mailman-Bugs-1047531 ] problem with "discard all ... Message-ID: Bugs item #1047531, was opened at 2004-10-14 23:41 Message generated for change (Settings changed) made by relson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1047531&group_id=103 Category: None Group: None >Status: Deleted Resolution: None Priority: 5 Submitted By: David Relson (relson) Assigned to: Nobody/Anonymous (nobody) Summary: problem with "discard all ... Initial Comment: Greetings, I've noticed a minor problem with mailman 2.1.5. My main use of the admindb page is deleting spam. From admin page http://www.mydomain.com/mailman/admindb/mylist, checking "Discard all messages marked Defer" and clicking on SUBMIT works fine. Occasionally, I will use the "you can view all messages from address@example.com" link. If I click on "Discard all messages marked Defer", the message isn't discarded. What the heck's going on here??? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1047531&group_id=103 From noreply at sourceforge.net Fri Oct 15 06:58:38 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 15 06:58:43 2004 Subject: [ mailman-Bugs-998384 ] Tend to Pending Moderator Requests breaks on a few lists Message-ID: Bugs item #998384, was opened at 2004-07-27 00:15 Message generated for change (Comment added) made by zot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=998384&group_id=103 Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Len Hatfield (lenhatfield) Assigned to: Nobody/Anonymous (nobody) Summary: Tend to Pending Moderator Requests breaks on a few lists Initial Comment: After upgrading from MM 2.0.3 to 2.1.5, I find that on just a couple of my lists when I access the web-admin interface and try to follow the "Tend to Pending Moderator Requests" link, I get the following bug announcement: Bug in Mailman version 2.1.5 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 "/c/mm2/scripts/driver", line 87, in run_main main() File "/c/mm2/Mailman/Cgi/admindb.py", line 231, in main num = show_pending_subs(mlist, form) File "/c/mm2/Mailman/Cgi/admindb.py", line 274, in show_pending_subs pendingsubs = mlist.GetSubscriptionIds() File "/c/mm2/Mailman/ListAdmin.py", line 138, in GetSubscriptionIds return self.__getmsgids(SUBSCRIPTION) File "/c/mm2/Mailman/ListAdmin.py", line 130, in __getmsgids ids = [k for k, (op, data) in self.__db.items() if op == rtype] ValueError: unpack tuple of wrong size Python information: Variable Value sys.version 2.3.4 (#1, Jul 21 2004, 23:31:00) [GCC 2.95.3 20010315 (release)] sys.executable /usr/bin/python sys.prefix /usr/local sys.exec_prefix /usr/local sys.path /usr/local sys.platform linux2 Environment variables: Variable Value HTTP_REFERER http://wiz.cath.vt.edu/mailman/admin/hel-l SERVER_SOFTWARE Apache SCRIPT_NAME /mailman/admindb SERVER_SIGNATURE REQUEST_METHOD GET HTTP_KEEP_ALIVE 300 SERVER_PROTOCOL HTTP/1.1 QUERY_STRING HTTP_ACCEPT_CHARSET ISO-8859-1,utf-8;q=0.7,*;q=0.7 HTTP_USER_AGENT Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040628 Firefox/0.9.1 HTTP_CONNECTION keep-alive HTTP_COOKIE hel-l+admin=280200000069299d0541732800000034633337343331663037376464386366353661356532393638663262343937613764313365663234 SERVER_NAME wiz.cath.vt.edu REMOTE_ADDR 68.185.125.105 PATH_TRANSLATED /www/hel-l SERVER_PORT 80 SERVER_ADDR 128.173.51.243 DOCUMENT_ROOT /www PYTHONPATH /c/mm2 SCRIPT_FILENAME /c/mm2/cgi-bin/admindb SERVER_ADMIN lhat@wiz.cath.vt.edu HTTP_HOST wiz.cath.vt.edu REQUEST_URI /mailman/admindb/hel-l HTTP_ACCEPT text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 GATEWAY_INTERFACE CGI/1.1 REMOTE_PORT 61615 HTTP_ACCEPT_LANGUAGE en-us,en;q=0.5 HTTP_ACCEPT_ENCODING gzip,deflate UNIQUE_ID QQWdLICtM-MAAEji16U PATH_INFO /hel-l ---------------------------------------------------------------------- Comment By: Zot O'Connor (zot) Date: 2004-10-15 04:58 Message: Logged In: YES user_id=79680 I am seeing the same exact thing. Traceback (most recent call last): File "/var/mailman/scripts/driver", line 87, in run_main main() File "/var/mailman/Mailman/Cgi/admindb.py", line 231, in main num = show_pending_subs(mlist, form) File "/var/mailman/Mailman/Cgi/admindb.py", line 274, in show_pending_subs pendingsubs = mlist.GetSubscriptionIds() File "/var/mailman/Mailman/ListAdmin.py", line 138, in GetSubscriptionIds return self.__getmsgids(SUBSCRIPTION) File "/var/mailman/Mailman/ListAdmin.py", line 130, in __getmsgids ids = [k for k, (op, data) in self.__db.items() if op == rtype] ValueError: unpack tuple of wrong size sys.version 2.3.3 (#1, May 7 2004, 10:31:40) [GCC 3.3.3 20040412 (Red Hat Linux 3.3.3-7)] sys.executable /usr/bin/python sys.prefix /usr sys.exec_prefix /usr sys.path /usr sys.platform linux2 The environment vars were a bit off for PATH_TRANSLATED and DOCUMENT_ROOT But evertyhing else seems to be working. Is anyone looking at this bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=998384&group_id=103 From noreply at sourceforge.net Fri Oct 15 15:42:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 15 15:42:44 2004 Subject: [ mailman-Feature Requests-1047785 ] Obscure e-mail of administrator on the listinfo page Message-ID: Feature Requests item #1047785, was opened at 2004-10-15 08:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1047785&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: NancyS (nes49) Assigned to: Nobody/Anonymous (nobody) Summary: Obscure e-mail of administrator on the listinfo page Initial Comment: When an administrator's e-mail address is entered in the general options, that address appears in the footer of the listinfo page. For instance listname list run by someone at somehost but the mailto link under "someone at somehost" is still "mailto:listname-owner@listhost". Yes, I know that the entire page can be replaced with other HTML, but can there be an option to make the text for the link agree with the mailto, e.g. "listname- owner at listhost" instead of "advertising" what may be a real person's address as something associated with the list? -Nancy ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1047785&group_id=103 From noreply at sourceforge.net Fri Oct 15 16:22:43 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 15 16:22:49 2004 Subject: [ mailman-Patches-1045656 ] Race in LockFile.py resulting in extraneous log entries. Message-ID: Patches item #1045656, was opened at 2004-10-12 14:50 Message generated for change (Comment added) made by grnbrg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045656&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 3 Submitted By: Brian Greenberg (grnbrg) Assigned to: Nobody/Anonymous (nobody) Summary: Race in LockFile.py resulting in extraneous log entries. Initial Comment: There is a race condition (that does not affect correct operation of Mailman) in .../Mailman/LockFile.py. This race results in entries to the "locks" log file (usually in pairs) that are unnecessary and confusing. If there is a process holding a lock for a file, and a process waiting for that lock to be freed, the following sequence can occur: 1) The waiting process executes os.link(). Since the running process still has the lock, this fails with EEXIST. 2) The running process releases the lock, and removes the lock file. 3) The waiting process proceeds with it's checks, and checks self.__linkcount() which returns -1 due to an ENOENT error. This throws an error into the "locks" log file. 4) The waiting process continues processing, checks it's timeout, and then checks to see if the lock lifetime has expired. The lifetime check is based on a call to self.__releasetime(), which returns -1, due to an ENOENT error. This results in the lockfile being declared stale, and self.__break() is called. This then throws a second error into the "locks" log file. The attached patch checks for these ENOENT errors, immediately restarting the loop when they are detected. It does not affect operation is the lock file exists and is held by another process. Brian Greenberg. ---------------------------------------------------------------------- >Comment By: Brian Greenberg (grnbrg) Date: 2004-10-15 09:22 Message: Logged In: YES user_id=902583 This would fix this bug, as long as CLOCK_SLOP is large enough. But I don't think it's the Right Thing, as you are returning a result that says that the lockfile has a lifetime, when it in fact simply no longer exists. For a function whose purpose is to report the mtime of the master lockfile, -1 is the correct response if the file doesn't exist. The code that calls that function should check for and interpret that condition. ---------------------------------------------------------------------- Comment By: SHIGENO Kazutaka (shigeno) Date: 2004-10-14 19:11 Message: Logged In: YES user_id=1138453 How about changing as follows about self.__releasetime()? @@ -448,7 +448,7 @@ return os.stat(self.__lockfile)[ST_MTIME] except OSError, e: if e.errno <> errno.ENOENT: raise - return -1 + return time.time() def __linkcount(self): try: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045656&group_id=103 From noreply at sourceforge.net Sun Oct 17 06:23:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 17 06:23:26 2004 Subject: [ mailman-Patches-1029275 ] Maximum number of members per list. Message-ID: Patches item #1029275, was opened at 2004-09-16 15:31 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1029275&group_id=103 Category: list administration Group: Mailman 2.1 Status: Open Resolution: None >Priority: 4 Submitted By: iamstratus (iamstratus) Assigned to: Nobody/Anonymous (nobody) Summary: Maximum number of members per list. Initial Comment: With this patch site administrators can control the maximum number of members per list. I really need this feature but it's my first attempt changing mailman code so i don't known if it's the best way to handle this situation and if a list administrator can override 'max_members'.Comments, anyone? I've patched mailman 2.1.5 and the mailman 2.1.5 official debian source package (through dpatch) and it seems to be working fine on my test server. The lists that doesn't have 'max_members'[*] or where it's 0 are unlimited and i've created (based on change_pw) the change_maxmembers script where you can change and print the 'max_members' attribute from a list (or many). [*] = How the new attributes situation is handled? On upgrade you add what's missing with the upgrade script or what? Hope that helps, Gustavo Franco -- RITS - http://www.rits.org.br/ p.s: It's being accepted i guess that we can ack some of the suggestions at the RFE #403310. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-17 04:23 Message: Logged In: YES user_id=67709 Looks like this patch is useful if an ISP is providing limited service or charging extra fee for increased list size. Since mailman is not only for ISPs, priority is lowered. I hope you can keep maintaining this patch here in the tracker. For your info, if you add a new variable in mlist class, you can update exsisting lists' variables through versions.py, Version.py, and bin/update. ---------------------------------------------------------------------- Comment By: iamstratus (iamstratus) Date: 2004-10-01 17:15 Message: Logged In: YES user_id=1121054 Hi, I'm sending this update to the previous patch.With this one you can create a list through web interface ('create' script) limiting the number of members. 8) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1029275&group_id=103 From noreply at sourceforge.net Sun Oct 17 06:54:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 17 06:54:12 2004 Subject: [ mailman-Bugs-913397 ] Subscriber E-Mail-Address: GlobalChange causes removal Message-ID: Bugs item #913397, was opened at 2004-03-10 10:53 Message generated for change (Settings changed) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=913397&group_id=103 Category: None Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: chris-taylor (chris-taylor) >Assigned to: Tokio Kikuchi (tkikuchi) Summary: Subscriber E-Mail-Address: GlobalChange causes removal Initial Comment: A subscriber of some mailinglists on my site tried to change his email address globally. The change for one of the lists only affected a correction of upper- and lower-case letters in the local part of the address(e.g. will.smith@... -> Will.Smith@....). After confirming the change an error occured and the subscriber was completely unsubscribed from the list. Neither the old address nor the new address were registered in the subscribers list. ---------------------------------------------------------------------- Comment By: Eirik Dentz (edentz) Date: 2004-07-21 06:30 Message: Logged In: YES user_id=878352 Here is a patch against the 2.1.5 Mailman release: --- mailman-2.1.5/Mailman/MailList.py 2004-03-04 06:10:28.000000000 -0800 +++ mailman-2.1.5.patch/Mailman/MailList.py 2004-07-20 23:17: 09.000000000 -0700 @@ -1081,7 +1081,7 @@ # It's possible they were a member of this list, but choose to change # their membership globally. In that case, we simply remove the old # address. - if self.isMember(newaddr): + if self.getMemberCPAddress(oldaddr) == newaddr: self.removeMember(oldaddr) else: self.changeMemberAddress(oldaddr, newaddr) @@ -1101,7 +1101,7 @@ mlist.Lock() try: # Same logic as above, re newaddr is already a member - if mlist.isMember(newaddr): + if mlist.getMemberCPAddress(oldaddr) == newaddr: mlist.removeMember(oldaddr) else: mlist.changeMemberAddress(oldaddr, newaddr) ---------------------------------------------------------------------- Comment By: Eirik Dentz (edentz) Date: 2004-07-21 05:50 Message: Logged In: YES user_id=878352 I encountered this bug too. It doesn't look like it is fixed in 2.1.5 or CVS yet so I did a bit of searching through the Mailman source code and found the part(s) that causes the deletion of the member when attempting to change the case of the localpart of the email address. Lines 332 - 341 of Mailman/Cgi/options.py pass the global change address off and the actual deletion occurs in the ApprovedChangeMemberAddress() method in Mailman/MailList.py. If you change the first if statement in that method (should be line 1050 in Mailman version 2.1.4) from: if self.isMember(newaddr): to: if self.getMemberCPAddress(oldaddr) == newaddr: And then the last if statement (should be line 1070 in Mailman version 2.1.4) in the method from: if mlist.isMember(newaddr): to: if mlist.getMemberCPAddress(oldaddr) == newaddr: It should fix the bug. However I haven't tested this extensively and it may break other functionality. Eirik ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=913397&group_id=103 From noreply at sourceforge.net Sun Oct 17 06:54:44 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 17 06:54:47 2004 Subject: [ mailman-Patches-995029 ] Patch against Mailman 2.1.5 release fixes bug #913397 Message-ID: Patches item #995029, was opened at 2004-07-21 06:40 Message generated for change (Settings changed) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=995029&group_id=103 Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Eirik Dentz (edentz) >Assigned to: Tokio Kikuchi (tkikuchi) Summary: Patch against Mailman 2.1.5 release fixes bug #913397 Initial Comment: Patch against 2.1.5 release to fix bug #913397 This hasn't been tested extensively and it may break other functionality, but it seems to produce the desired result of allowing user to change the case of the localpart of his/her email address when checking the "change globally" option on the options page. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=995029&group_id=103 From noreply at sourceforge.net Sun Oct 17 06:55:37 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 17 06:55:42 2004 Subject: [ mailman-Patches-960551 ] Bug: Plain digest with mixed charsets Message-ID: Patches item #960551, was opened at 2004-05-26 04:18 Message generated for change (Settings changed) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=960551&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Hatuka*nezumi (hatukanezumi) >Assigned to: Tokio Kikuchi (tkikuchi) Summary: Bug: Plain digest with mixed charsets Initial Comment: Plain digest including bodies: - encoded with charset not preferred by the list - including unkown characters will be shunted. This patch fixes this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=960551&group_id=103 From noreply at sourceforge.net Mon Oct 18 14:16:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 18 14:17:01 2004 Subject: [ mailman-Patches-923428 ] VERP subscription confirmations Message-ID: Patches item #923428, was opened at 2004-03-25 20:16 Message generated for change (Settings changed) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=923428&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Gordon Rowell (gordonr) >Assigned to: Tokio Kikuchi (tkikuchi) Summary: VERP subscription confirmations Initial Comment: From: Gordon Rowell To: mailman-developers@python.org [...] On Thu, Feb 05, 2004 at 09:44:05PM -0500, Gordon Rowell wrote: > If I enable VERP_CONFIRMATIONS and "Invite" > someone from the admin page, I get a VERP > invite and a "nice" Subject line: > [...] > It appears that the VERP confirmations are only > partially implemented, but maybe I've missed > something. > [...] The attached patch seems to DTRT for me. Gordon ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=923428&group_id=103 From noreply at sourceforge.net Tue Oct 19 06:37:06 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 19 06:37:15 2004 Subject: [ mailman-Bugs-913397 ] Subscriber E-Mail-Address: GlobalChange causes removal Message-ID: Bugs item #913397, was opened at 2004-03-10 10:53 Message generated for change (Settings changed) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=913397&group_id=103 Category: None Group: 2.1 (stable) >Status: Closed Resolution: None Priority: 5 Submitted By: chris-taylor (chris-taylor) Assigned to: Tokio Kikuchi (tkikuchi) Summary: Subscriber E-Mail-Address: GlobalChange causes removal Initial Comment: A subscriber of some mailinglists on my site tried to change his email address globally. The change for one of the lists only affected a correction of upper- and lower-case letters in the local part of the address(e.g. will.smith@... -> Will.Smith@....). After confirming the change an error occured and the subscriber was completely unsubscribed from the list. Neither the old address nor the new address were registered in the subscribers list. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-19 04:37 Message: Logged In: YES user_id=67709 fixed in MailList.py revision: 2.100.2.23 ---------------------------------------------------------------------- Comment By: Eirik Dentz (edentz) Date: 2004-07-21 06:30 Message: Logged In: YES user_id=878352 Here is a patch against the 2.1.5 Mailman release: --- mailman-2.1.5/Mailman/MailList.py 2004-03-04 06:10:28.000000000 -0800 +++ mailman-2.1.5.patch/Mailman/MailList.py 2004-07-20 23:17: 09.000000000 -0700 @@ -1081,7 +1081,7 @@ # It's possible they were a member of this list, but choose to change # their membership globally. In that case, we simply remove the old # address. - if self.isMember(newaddr): + if self.getMemberCPAddress(oldaddr) == newaddr: self.removeMember(oldaddr) else: self.changeMemberAddress(oldaddr, newaddr) @@ -1101,7 +1101,7 @@ mlist.Lock() try: # Same logic as above, re newaddr is already a member - if mlist.isMember(newaddr): + if mlist.getMemberCPAddress(oldaddr) == newaddr: mlist.removeMember(oldaddr) else: mlist.changeMemberAddress(oldaddr, newaddr) ---------------------------------------------------------------------- Comment By: Eirik Dentz (edentz) Date: 2004-07-21 05:50 Message: Logged In: YES user_id=878352 I encountered this bug too. It doesn't look like it is fixed in 2.1.5 or CVS yet so I did a bit of searching through the Mailman source code and found the part(s) that causes the deletion of the member when attempting to change the case of the localpart of the email address. Lines 332 - 341 of Mailman/Cgi/options.py pass the global change address off and the actual deletion occurs in the ApprovedChangeMemberAddress() method in Mailman/MailList.py. If you change the first if statement in that method (should be line 1050 in Mailman version 2.1.4) from: if self.isMember(newaddr): to: if self.getMemberCPAddress(oldaddr) == newaddr: And then the last if statement (should be line 1070 in Mailman version 2.1.4) in the method from: if mlist.isMember(newaddr): to: if mlist.getMemberCPAddress(oldaddr) == newaddr: It should fix the bug. However I haven't tested this extensively and it may break other functionality. Eirik ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=913397&group_id=103 From noreply at sourceforge.net Tue Oct 19 06:38:05 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 19 06:38:10 2004 Subject: [ mailman-Patches-995029 ] Patch against Mailman 2.1.5 release fixes bug #913397 Message-ID: Patches item #995029, was opened at 2004-07-21 06:40 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=995029&group_id=103 Category: list administration Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: Eirik Dentz (edentz) Assigned to: Tokio Kikuchi (tkikuchi) Summary: Patch against Mailman 2.1.5 release fixes bug #913397 Initial Comment: Patch against 2.1.5 release to fix bug #913397 This hasn't been tested extensively and it may break other functionality, but it seems to produce the desired result of allowing user to change the case of the localpart of his/her email address when checking the "change globally" option on the options page. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-19 04:38 Message: Logged In: YES user_id=67709 merged in CVS MailList.py revision: 2.100.2.23 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=995029&group_id=103 From noreply at sourceforge.net Tue Oct 19 06:39:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 19 06:39:25 2004 Subject: [ mailman-Patches-960551 ] Bug: Plain digest with mixed charsets Message-ID: Patches item #960551, was opened at 2004-05-26 04:18 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=960551&group_id=103 Category: mail delivery Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: Hatuka*nezumi (hatukanezumi) Assigned to: Tokio Kikuchi (tkikuchi) Summary: Bug: Plain digest with mixed charsets Initial Comment: Plain digest including bodies: - encoded with charset not preferred by the list - including unkown characters will be shunted. This patch fixes this problem. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-19 04:39 Message: Logged In: YES user_id=67709 Fixed in CVS ToDigest.py revision: 2.22.2.8 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=960551&group_id=103 From noreply at sourceforge.net Tue Oct 19 06:42:51 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 19 06:43:33 2004 Subject: [ mailman-Patches-923428 ] VERP subscription confirmations Message-ID: Patches item #923428, was opened at 2004-03-25 20:16 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=923428&group_id=103 Category: mail delivery Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: Gordon Rowell (gordonr) Assigned to: Tokio Kikuchi (tkikuchi) Summary: VERP subscription confirmations Initial Comment: From: Gordon Rowell To: mailman-developers@python.org [...] On Thu, Feb 05, 2004 at 09:44:05PM -0500, Gordon Rowell wrote: > If I enable VERP_CONFIRMATIONS and "Invite" > someone from the admin page, I get a VERP > invite and a "nice" Subject line: > [...] > It appears that the VERP confirmations are only > partially implemented, but maybe I've missed > something. > [...] The attached patch seems to DTRT for me. Gordon ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-19 04:42 Message: Logged In: YES user_id=67709 merged in CVS MailList.py revision: 2.100.2.23 Note that default is not to use VERP_CONFIRMATIONS. Users may want to edit templates if VERP_CONFIRMATIONS is set Yes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=923428&group_id=103 From noreply at sourceforge.net Tue Oct 19 07:09:33 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 19 07:09:38 2004 Subject: [ mailman-Bugs-874764 ] -admin address is now equiv to -bounce Message-ID: Bugs item #874764, was opened at 2004-01-11 05:02 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=874764&group_id=103 Category: Web/CGI Group: 2.1 (stable) >Status: Closed Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: -admin address is now equiv to -bounce Initial Comment: If a new list is created, a notice is sent to the list owner including the questions address mailman-admin@the.site.dom. Since in 2.1.x, -admin adderss is an alias for bounce, if the new list owner sends questions to this address, the message is treated as uninterpretable bounce message. This address should be mailman-owner@the.site.dom. I attach a fix for Cgi/create.py but looks like bin/newlist has the same error. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-19 05:09 Message: Logged In: YES user_id=67709 fixed in CVS ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=874764&group_id=103 From noreply at sourceforge.net Wed Oct 20 18:49:26 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 20 18:49:29 2004 Subject: [ mailman-Bugs-1050878 ] "Cancel my subscription request" error Message-ID: Bugs item #1050878, was opened at 2004-10-20 12: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=1050878&group_id=103 Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: cmika (cmika) Assigned to: Nobody/Anonymous (nobody) Summary: "Cancel my subscription request" error Initial Comment: Bug in Mailman version 2.1.5 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/local/lib/mailman/scripts/driver", line 87, in run_main main() File "/usr/obj/ports/mailman-2.1.5/fake-i386/usr/local/lib/mailman/Mailman/Cgi/confirm.py", line 114, in main File "/usr/obj/ports/mailman-2.1.5/fake-i386/usr/local/lib/mailman/Mailman/Cgi/confirm.py", line 312, in subscription_cancel File "/usr/obj/ports/mailman-2.1.5/fake-i386/usr/local/lib/mailman/Mailman/Pending.py", line 141, in pend_confirm AssertionError Python information: Variable Value sys.version 2.2.3 (#1, Mar 23 2004, 19:11:01) [GCC 2.95.3 20010125 (prerelease, propolice)] sys.executable /usr/local/bin/python2.2 sys.prefix /usr/local sys.exec_prefix /usr/local sys.path /usr/local sys.platform openbsd3 Environment variables: Variable Value PATH_INFO /friends HTTP_ACCEPT text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 CONTENT_TYPE application/x-www-form-urlencoded HTTP_REFERER https://lists.seenothing.org/confirm/friends/26ebbe661ef86491452776e04efd2aafd9788a6f SERVER_SOFTWARE Apache/1.3.29 (Unix) PHP/4.3.8 mod_ssl/2.8.16 OpenSSL/0.9.7c PYTHONPATH /usr/local/lib/mailman SCRIPT_FILENAME /usr/local/lib/mailman/cgi-bin/confirm SERVER_ADMIN webmaster@lists.seenothing.org SCRIPT_NAME /confirm SERVER_SIGNATURE Apache/1.3.29 Server at lists.seenothing.org Port 443 REQUEST_METHOD POST HTTP_HOST lists.seenothing.org HTTP_KEEP_ALIVE 300 SERVER_PROTOCOL HTTP/1.1 QUERY_STRING REQUEST_URI /confirm/friends CONTENT_LENGTH 117 HTTP_ACCEPT_CHARSET ISO-8859-1,utf-8;q=0.7,*;q=0.7 HTTP_USER_AGENT Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040809 Galeon/1.3.17 HTTP_CONNECTION keep-alive HTTP_COOKIE friends+user+cmika--at--seenothing.org=2802000000696b957641732800000038323862613031396536373461656238326664646166363064643930623331666538626361613262 SERVER_NAME lists.seenothing.org REMOTE_ADDR 66.80.107.196 REMOTE_PORT 60843 HTTP_ACCEPT_LANGUAGE en PATH_TRANSLATED /usr/local/lib/mailman/cgi-bin/friends SERVER_PORT 443 GATEWAY_INTERFACE CGI/1.1 HTTP_ACCEPT_ENCODING gzip,deflate SERVER_ADDR 192.168.1.2 DOCUMENT_ROOT /var/www/htdocs When a user tries to cancel subscription request, mailman comes up with an error. Mailman's installed on an OpenBSD 3.5 machine, using packages. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1050878&group_id=103 From noreply at sourceforge.net Thu Oct 21 18:41:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 21 18:41:31 2004 Subject: [ mailman-Bugs-1051615 ] Tend to pending moderator requests error Message-ID: Bugs item #1051615, was opened at 2004-10-21 16:41 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=1051615&group_id=103 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: curly (cunoodle2) Assigned to: Nobody/Anonymous (nobody) Summary: Tend to pending moderator requests error Initial Comment: I was logged in to manage my list and clicked on the link that said "Tend to pending moderator requests " and I got an error. Here it is... Bug in Mailman version 2.1.5 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/local/cpanel/3rdparty/mailman/scripts/driver", line 87, in run_main main() File "/usr/local/cpanel/3rdparty/mailman/Mailman/Cgi/admi ndb.py", line 246, in main print doc.Format() File "/usr/local/cpanel/3rdparty/mailman/Mailman/htmlfor mat.py", line 331, in Format output.append(Container.Format(self, indent)) File "/usr/local/cpanel/3rdparty/mailman/Mailman/htmlfor mat.py", line 264, in Format output.append(HTMLFormatObject(item, indent)) File "/usr/local/cpanel/3rdparty/mailman/Mailman/htmlfor mat.py", line 50, in HTMLFormatObject return item.Format(indent) File "/usr/local/cpanel/3rdparty/mailman/Mailman/htmlfor mat.py", line 417, in Format output = output + Container.Format(self, indent+2) File "/usr/local/cpanel/3rdparty/mailman/Mailman/htmlfor mat.py", line 264, in Format output.append(HTMLFormatObject(item, indent)) File "/usr/local/cpanel/3rdparty/mailman/Mailman/htmlfor mat.py", line 50, in HTMLFormatObject return item.Format(indent) File "/usr/local/cpanel/3rdparty/mailman/Mailman/htmlfor mat.py", line 200, in Format output = output + self.FormatRow(i, indent + 2) MemoryError ------------------------------------------------------ -------------------------- Python information: Variable Value sys.version 2.2.2 (#1, Jan 30 2003, 21:26:22) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] sys.executable /usr/bin/python2 sys.prefix /usr sys.exec_prefix /usr sys.path /usr sys.platform linux2 ------------------------------------------------------ -------------------------- Environment variables: Variable Value HTTP_COOKIE cpin_christianparents.com+admin=2802000000699cdd774 17328000000373338303438623638373364366135356262 32663961613331353935623932346338343832323465 SERVER_SOFTWARE Apache/1.3.31 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.3.9 FrontPage/5.0.2.2634a mod_ssl/2.8.20 OpenSSL/0.9.6b PYTHONPATH /usr/local/cpanel/3rdparty/mailman SCRIPT_FILENAME /usr/local/cpanel/3rdparty/mailman/c gi-bin/admindb SERVER_ADMIN webmaster@christianparents.com SCRIPT_NAME /mailman/admindb REQUEST_METHOD GET HTTP_HOST christianparents.com PATH_INFO /cpin_christianparents.com SERVER_PROTOCOL HTTP/1.1 QUERY_STRING REQUEST_URI /mailman/admindb/cpin_christianparents.c om HTTP_ACCEPT image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-powerpoint, application/vnd.ms- excel, application/msword, */* HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; NetCaptor 7.5.2; (R1 1.5)) HTTP_CONNECTION Keep-Alive HTTP_REFERER http://christianparents.com/mailman/admin/cpin_christian parents.com/members SERVER_NAME www.christianparents.com REMOTE_ADDR 69.49.193.98 REMOTE_PORT 18495 HTTP_ACCEPT_LANGUAGE en-us PATH_TRANSLATED /home/chris/public_html/cpin_christi anparents.com SERVER_PORT 80 GATEWAY_INTERFACE CGI/1.1 HTTP_ACCEPT_ENCODING gzip, deflate SERVER_ADDR 205.243.144.12 DOCUMENT_ROOT /home/chris/public_html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1051615&group_id=103 From noreply at sourceforge.net Fri Oct 22 02:24:41 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 22 02:24:49 2004 Subject: [ mailman-Patches-1008983 ] qrunner w/ multiple slices crashing. Message-ID: Patches item #1008983, was opened at 2004-08-13 21:45 Message generated for change (Settings changed) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1008983&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 7 Submitted By: Brian Greenberg (grnbrg) >Assigned to: Tokio Kikuchi (tkikuchi) Summary: qrunner w/ multiple slices crashing. Initial Comment: When running qrunner with multiple instances of a particular class (ie: qrunner -r OutgoingRunner:0:4 -r OutgoingRunner:1:4 -r OutgoingRunner:2:4 -r OutgoingRunner:3:4 ) the qrunner processes for this class will periodically crash, leaving the following traces: logs/qrunner: Aug 13 15:27:51 2004 (29188) Master qrunner detected subprocess exit (pid: 23829, sig: None, sts: 1, class: OutgoingRunner, slice: 1/4) [restarting] logs/error: Aug 13 15:27:51 2004 qrunner(23829): Traceback (most recent call last): Aug 13 15:27:51 2004 qrunner(23829): File "/usr/local/mailman/bin/qrunner", line 270, in ? Aug 13 15:27:51 2004 qrunner(23829): main() Aug 13 15:27:51 2004 qrunner(23829): File "/usr/local/mailman/bin/qrunner", line 230, in main Aug 13 15:27:51 2004 qrunner(23829): qrunner.run() Aug 13 15:27:51 2004 qrunner(23829): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 70, in run Aug 13 15:27:51 2004 qrunner(23829): filecnt = self._oneloop() Aug 13 15:27:51 2004 qrunner(23829): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 99, in _oneloop Aug 13 15:27:51 2004 qrunner(23829): msg, msgdata = self._switchboard.dequeue(filebase) Aug 13 15:27:51 2004 qrunner(23829): File "/usr/local/mailman/Mailman/Queue/Switchboard.py", line 143, in dequeue Aug 13 15:27:51 2004 qrunner(23829): fp = open(filename) Aug 13 15:27:51 2004 qrunner(23829): IOError : [Errno 2] No such file or directory: '/var/priv/mail/mailman/qfiles/out/1092428866.8410051+70dcb0bb96e6460d8cd2a a8103cce318cfa3ed1f.pck' This is caused by a logic error in mailman/Mailman/Queues/Switchboard.py:files. Specifically, when there are not multiple slices running for a particular qrunner class, self.__upper and self.__lower are both set to None in Switchboard.py:__init__. Switchboard.py:files contains the statement: if not lower or (lower <= long(digest, 16) < upper): times[float](when)] = filebase ie: if there is only one slice (because "lower" is not "None") or if this filename is within the range of the slice that this qrunner is managing, then add it to the list. The problem is that the first slice of any multi-slice qrunner has a lower bound of "0". This means that slice "0" of any multi-slice qrunner will act on *all* files in a given queue, which in turn results in race conditions wherein slice 0 and slice n will begin to process a message, one will complete processing and remove the file, and the other will crash. Patch: *** Switchboard.py Fri Aug 13 16:43:12 2004 --- Switchboard.py_new Fri Aug 13 16:43:48 2004 *************** *** 164,170 **** when, digest = filebase.split('+') # Throw out any files which don't match our bitrange. BAW: test # performance and end-cases of this algorithm. ! if not lower or (lower <= long(digest, 16) < upper): times[float(when)] = filebase # FIFO sort keys = times.keys() --- 164,170 ---- when, digest = filebase.split('+') # Throw out any files which don't match our bitrange. BAW: test # performance and end-cases of this algorithm. ! if (lower == upper) or (lower <= long(digest, 16) < upper): times[float(when)] = filebase # FIFO sort keys = times.keys() Brian Greenberg -- grnbrg@cc.umanitoba.ca ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1008983&group_id=103 From noreply at sourceforge.net Fri Oct 22 02:26:07 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 22 02:26:12 2004 Subject: [ mailman-Patches-1045656 ] Race in LockFile.py resulting in extraneous log entries. Message-ID: Patches item #1045656, was opened at 2004-10-12 19:50 Message generated for change (Settings changed) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045656&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 3 Submitted By: Brian Greenberg (grnbrg) >Assigned to: Tokio Kikuchi (tkikuchi) Summary: Race in LockFile.py resulting in extraneous log entries. Initial Comment: There is a race condition (that does not affect correct operation of Mailman) in .../Mailman/LockFile.py. This race results in entries to the "locks" log file (usually in pairs) that are unnecessary and confusing. If there is a process holding a lock for a file, and a process waiting for that lock to be freed, the following sequence can occur: 1) The waiting process executes os.link(). Since the running process still has the lock, this fails with EEXIST. 2) The running process releases the lock, and removes the lock file. 3) The waiting process proceeds with it's checks, and checks self.__linkcount() which returns -1 due to an ENOENT error. This throws an error into the "locks" log file. 4) The waiting process continues processing, checks it's timeout, and then checks to see if the lock lifetime has expired. The lifetime check is based on a call to self.__releasetime(), which returns -1, due to an ENOENT error. This results in the lockfile being declared stale, and self.__break() is called. This then throws a second error into the "locks" log file. The attached patch checks for these ENOENT errors, immediately restarting the loop when they are detected. It does not affect operation is the lock file exists and is held by another process. Brian Greenberg. ---------------------------------------------------------------------- Comment By: Brian Greenberg (grnbrg) Date: 2004-10-15 14:22 Message: Logged In: YES user_id=902583 This would fix this bug, as long as CLOCK_SLOP is large enough. But I don't think it's the Right Thing, as you are returning a result that says that the lockfile has a lifetime, when it in fact simply no longer exists. For a function whose purpose is to report the mtime of the master lockfile, -1 is the correct response if the file doesn't exist. The code that calls that function should check for and interpret that condition. ---------------------------------------------------------------------- Comment By: SHIGENO Kazutaka (shigeno) Date: 2004-10-15 00:11 Message: Logged In: YES user_id=1138453 How about changing as follows about self.__releasetime()? @@ -448,7 +448,7 @@ return os.stat(self.__lockfile)[ST_MTIME] except OSError, e: if e.errno <> errno.ENOENT: raise - return -1 + return time.time() def __linkcount(self): try: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045656&group_id=103 From noreply at sourceforge.net Fri Oct 22 03:52:32 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 22 03:52:44 2004 Subject: [ mailman-Patches-1008983 ] qrunner w/ multiple slices crashing. Message-ID: Patches item #1008983, was opened at 2004-08-13 17:45 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1008983&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 7 Submitted By: Brian Greenberg (grnbrg) Assigned to: Tokio Kikuchi (tkikuchi) Summary: qrunner w/ multiple slices crashing. Initial Comment: When running qrunner with multiple instances of a particular class (ie: qrunner -r OutgoingRunner:0:4 -r OutgoingRunner:1:4 -r OutgoingRunner:2:4 -r OutgoingRunner:3:4 ) the qrunner processes for this class will periodically crash, leaving the following traces: logs/qrunner: Aug 13 15:27:51 2004 (29188) Master qrunner detected subprocess exit (pid: 23829, sig: None, sts: 1, class: OutgoingRunner, slice: 1/4) [restarting] logs/error: Aug 13 15:27:51 2004 qrunner(23829): Traceback (most recent call last): Aug 13 15:27:51 2004 qrunner(23829): File "/usr/local/mailman/bin/qrunner", line 270, in ? Aug 13 15:27:51 2004 qrunner(23829): main() Aug 13 15:27:51 2004 qrunner(23829): File "/usr/local/mailman/bin/qrunner", line 230, in main Aug 13 15:27:51 2004 qrunner(23829): qrunner.run() Aug 13 15:27:51 2004 qrunner(23829): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 70, in run Aug 13 15:27:51 2004 qrunner(23829): filecnt = self._oneloop() Aug 13 15:27:51 2004 qrunner(23829): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 99, in _oneloop Aug 13 15:27:51 2004 qrunner(23829): msg, msgdata = self._switchboard.dequeue(filebase) Aug 13 15:27:51 2004 qrunner(23829): File "/usr/local/mailman/Mailman/Queue/Switchboard.py", line 143, in dequeue Aug 13 15:27:51 2004 qrunner(23829): fp = open(filename) Aug 13 15:27:51 2004 qrunner(23829): IOError : [Errno 2] No such file or directory: '/var/priv/mail/mailman/qfiles/out/1092428866.8410051+70dcb0bb96e6460d8cd2a a8103cce318cfa3ed1f.pck' This is caused by a logic error in mailman/Mailman/Queues/Switchboard.py:files. Specifically, when there are not multiple slices running for a particular qrunner class, self.__upper and self.__lower are both set to None in Switchboard.py:__init__. Switchboard.py:files contains the statement: if not lower or (lower <= long(digest, 16) < upper): times[float](when)] = filebase ie: if there is only one slice (because "lower" is not "None") or if this filename is within the range of the slice that this qrunner is managing, then add it to the list. The problem is that the first slice of any multi-slice qrunner has a lower bound of "0". This means that slice "0" of any multi-slice qrunner will act on *all* files in a given queue, which in turn results in race conditions wherein slice 0 and slice n will begin to process a message, one will complete processing and remove the file, and the other will crash. Patch: *** Switchboard.py Fri Aug 13 16:43:12 2004 --- Switchboard.py_new Fri Aug 13 16:43:48 2004 *************** *** 164,170 **** when, digest = filebase.split('+') # Throw out any files which don't match our bitrange. BAW: test # performance and end-cases of this algorithm. ! if not lower or (lower <= long(digest, 16) < upper): times[float(when)] = filebase # FIFO sort keys = times.keys() --- 164,170 ---- when, digest = filebase.split('+') # Throw out any files which don't match our bitrange. BAW: test # performance and end-cases of this algorithm. ! if (lower == upper) or (lower <= long(digest, 16) < upper): times[float(when)] = filebase # FIFO sort keys = times.keys() Brian Greenberg -- grnbrg@cc.umanitoba.ca ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-10-21 21:52 Message: Logged In: YES user_id=12800 Better: the "if not lower" should probably be changed to "if lower is None". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1008983&group_id=103 From noreply at sourceforge.net Fri Oct 22 09:49:14 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 22 09:49:20 2004 Subject: [ mailman-Patches-1008983 ] qrunner w/ multiple slices crashing. Message-ID: Patches item #1008983, was opened at 2004-08-13 21:45 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1008983&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 7 Submitted By: Brian Greenberg (grnbrg) Assigned to: Tokio Kikuchi (tkikuchi) Summary: qrunner w/ multiple slices crashing. Initial Comment: When running qrunner with multiple instances of a particular class (ie: qrunner -r OutgoingRunner:0:4 -r OutgoingRunner:1:4 -r OutgoingRunner:2:4 -r OutgoingRunner:3:4 ) the qrunner processes for this class will periodically crash, leaving the following traces: logs/qrunner: Aug 13 15:27:51 2004 (29188) Master qrunner detected subprocess exit (pid: 23829, sig: None, sts: 1, class: OutgoingRunner, slice: 1/4) [restarting] logs/error: Aug 13 15:27:51 2004 qrunner(23829): Traceback (most recent call last): Aug 13 15:27:51 2004 qrunner(23829): File "/usr/local/mailman/bin/qrunner", line 270, in ? Aug 13 15:27:51 2004 qrunner(23829): main() Aug 13 15:27:51 2004 qrunner(23829): File "/usr/local/mailman/bin/qrunner", line 230, in main Aug 13 15:27:51 2004 qrunner(23829): qrunner.run() Aug 13 15:27:51 2004 qrunner(23829): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 70, in run Aug 13 15:27:51 2004 qrunner(23829): filecnt = self._oneloop() Aug 13 15:27:51 2004 qrunner(23829): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 99, in _oneloop Aug 13 15:27:51 2004 qrunner(23829): msg, msgdata = self._switchboard.dequeue(filebase) Aug 13 15:27:51 2004 qrunner(23829): File "/usr/local/mailman/Mailman/Queue/Switchboard.py", line 143, in dequeue Aug 13 15:27:51 2004 qrunner(23829): fp = open(filename) Aug 13 15:27:51 2004 qrunner(23829): IOError : [Errno 2] No such file or directory: '/var/priv/mail/mailman/qfiles/out/1092428866.8410051+70dcb0bb96e6460d8cd2a a8103cce318cfa3ed1f.pck' This is caused by a logic error in mailman/Mailman/Queues/Switchboard.py:files. Specifically, when there are not multiple slices running for a particular qrunner class, self.__upper and self.__lower are both set to None in Switchboard.py:__init__. Switchboard.py:files contains the statement: if not lower or (lower <= long(digest, 16) < upper): times[float](when)] = filebase ie: if there is only one slice (because "lower" is not "None") or if this filename is within the range of the slice that this qrunner is managing, then add it to the list. The problem is that the first slice of any multi-slice qrunner has a lower bound of "0". This means that slice "0" of any multi-slice qrunner will act on *all* files in a given queue, which in turn results in race conditions wherein slice 0 and slice n will begin to process a message, one will complete processing and remove the file, and the other will crash. Patch: *** Switchboard.py Fri Aug 13 16:43:12 2004 --- Switchboard.py_new Fri Aug 13 16:43:48 2004 *************** *** 164,170 **** when, digest = filebase.split('+') # Throw out any files which don't match our bitrange. BAW: test # performance and end-cases of this algorithm. ! if not lower or (lower <= long(digest, 16) < upper): times[float(when)] = filebase # FIFO sort keys = times.keys() --- 164,170 ---- when, digest = filebase.split('+') # Throw out any files which don't match our bitrange. BAW: test # performance and end-cases of this algorithm. ! if (lower == upper) or (lower <= long(digest, 16) < upper): times[float(when)] = filebase # FIFO sort keys = times.keys() Brian Greenberg -- grnbrg@cc.umanitoba.ca ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-22 07:49 Message: Logged In: YES user_id=67709 I am testing one of my working server (moderate size ~3000 list) with Barry's patch. Also try setting (OutgoingRunner 2). So, if nothing happens in a day or two, this will go into CVS. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-10-22 01:52 Message: Logged In: YES user_id=12800 Better: the "if not lower" should probably be changed to "if lower is None". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1008983&group_id=103 From noreply at sourceforge.net Fri Oct 22 10:26:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 22 10:27:02 2004 Subject: [ mailman-Patches-1045656 ] Race in LockFile.py resulting in extraneous log entries. Message-ID: Patches item #1045656, was opened at 2004-10-12 19:50 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045656&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 3 Submitted By: Brian Greenberg (grnbrg) Assigned to: Tokio Kikuchi (tkikuchi) Summary: Race in LockFile.py resulting in extraneous log entries. Initial Comment: There is a race condition (that does not affect correct operation of Mailman) in .../Mailman/LockFile.py. This race results in entries to the "locks" log file (usually in pairs) that are unnecessary and confusing. If there is a process holding a lock for a file, and a process waiting for that lock to be freed, the following sequence can occur: 1) The waiting process executes os.link(). Since the running process still has the lock, this fails with EEXIST. 2) The running process releases the lock, and removes the lock file. 3) The waiting process proceeds with it's checks, and checks self.__linkcount() which returns -1 due to an ENOENT error. This throws an error into the "locks" log file. 4) The waiting process continues processing, checks it's timeout, and then checks to see if the lock lifetime has expired. The lifetime check is based on a call to self.__releasetime(), which returns -1, due to an ENOENT error. This results in the lockfile being declared stale, and self.__break() is called. This then throws a second error into the "locks" log file. The attached patch checks for these ENOENT errors, immediately restarting the loop when they are detected. It does not affect operation is the lock file exists and is held by another process. Brian Greenberg. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-22 08:26 Message: Logged In: YES user_id=67709 Will you be more specific how this race occurs? My installation on FreeBSD doesn't looks like show this symptom in locks log file. I tested with two terminals invoking python -i bin/withlist testlist and try to lock with m.Lock() in both the terminal. One of term is forced to wait until the I type m.Unlock() in the other term. I then looked into logs dir but nothing avail. ---------------------------------------------------------------------- Comment By: Brian Greenberg (grnbrg) Date: 2004-10-15 14:22 Message: Logged In: YES user_id=902583 This would fix this bug, as long as CLOCK_SLOP is large enough. But I don't think it's the Right Thing, as you are returning a result that says that the lockfile has a lifetime, when it in fact simply no longer exists. For a function whose purpose is to report the mtime of the master lockfile, -1 is the correct response if the file doesn't exist. The code that calls that function should check for and interpret that condition. ---------------------------------------------------------------------- Comment By: SHIGENO Kazutaka (shigeno) Date: 2004-10-15 00:11 Message: Logged In: YES user_id=1138453 How about changing as follows about self.__releasetime()? @@ -448,7 +448,7 @@ return os.stat(self.__lockfile)[ST_MTIME] except OSError, e: if e.errno <> errno.ENOENT: raise - return -1 + return time.time() def __linkcount(self): try: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045656&group_id=103 From noreply at sourceforge.net Fri Oct 22 14:06:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 22 14:06:32 2004 Subject: [ mailman-Patches-1045656 ] Race in LockFile.py resulting in extraneous log entries. Message-ID: Patches item #1045656, was opened at 2004-10-12 15:50 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045656&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 3 Submitted By: Brian Greenberg (grnbrg) Assigned to: Tokio Kikuchi (tkikuchi) Summary: Race in LockFile.py resulting in extraneous log entries. Initial Comment: There is a race condition (that does not affect correct operation of Mailman) in .../Mailman/LockFile.py. This race results in entries to the "locks" log file (usually in pairs) that are unnecessary and confusing. If there is a process holding a lock for a file, and a process waiting for that lock to be freed, the following sequence can occur: 1) The waiting process executes os.link(). Since the running process still has the lock, this fails with EEXIST. 2) The running process releases the lock, and removes the lock file. 3) The waiting process proceeds with it's checks, and checks self.__linkcount() which returns -1 due to an ENOENT error. This throws an error into the "locks" log file. 4) The waiting process continues processing, checks it's timeout, and then checks to see if the lock lifetime has expired. The lifetime check is based on a call to self.__releasetime(), which returns -1, due to an ENOENT error. This results in the lockfile being declared stale, and self.__break() is called. This then throws a second error into the "locks" log file. The attached patch checks for these ENOENT errors, immediately restarting the loop when they are detected. It does not affect operation is the lock file exists and is held by another process. Brian Greenberg. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-10-22 08:06 Message: Logged In: YES user_id=12800 I haven't had time to look at this in detail, but I'll just include a general warning that LockFile.py is /very/ fragile. It's also critical to the proper operation of Mailman. So any changes, even seemingly innocent onces, must be very thoroughly tested. My inclination would be to reject any change that wasn't absolutely necessary, but I won't veto this change if it is well-tested and fixes a verified bug (tho' it sounds like tkikuchi can't reproduce it). ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-22 04:26 Message: Logged In: YES user_id=67709 Will you be more specific how this race occurs? My installation on FreeBSD doesn't looks like show this symptom in locks log file. I tested with two terminals invoking python -i bin/withlist testlist and try to lock with m.Lock() in both the terminal. One of term is forced to wait until the I type m.Unlock() in the other term. I then looked into logs dir but nothing avail. ---------------------------------------------------------------------- Comment By: Brian Greenberg (grnbrg) Date: 2004-10-15 10:22 Message: Logged In: YES user_id=902583 This would fix this bug, as long as CLOCK_SLOP is large enough. But I don't think it's the Right Thing, as you are returning a result that says that the lockfile has a lifetime, when it in fact simply no longer exists. For a function whose purpose is to report the mtime of the master lockfile, -1 is the correct response if the file doesn't exist. The code that calls that function should check for and interpret that condition. ---------------------------------------------------------------------- Comment By: SHIGENO Kazutaka (shigeno) Date: 2004-10-14 20:11 Message: Logged In: YES user_id=1138453 How about changing as follows about self.__releasetime()? @@ -448,7 +448,7 @@ return os.stat(self.__lockfile)[ST_MTIME] except OSError, e: if e.errno <> errno.ENOENT: raise - return -1 + return time.time() def __linkcount(self): try: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045656&group_id=103 From noreply at sourceforge.net Fri Oct 22 15:02:24 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 22 15:02:32 2004 Subject: [ mailman-Bugs-1050878 ] "Cancel my subscription request" error Message-ID: Bugs item #1050878, was opened at 2004-10-20 16:49 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1050878&group_id=103 Category: (un)subscribing Group: 2.1 (stable) >Status: Closed Resolution: None Priority: 5 Submitted By: cmika (cmika) Assigned to: Nobody/Anonymous (nobody) Summary: "Cancel my subscription request" error Initial Comment: Bug in Mailman version 2.1.5 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/local/lib/mailman/scripts/driver", line 87, in run_main main() File "/usr/obj/ports/mailman-2.1.5/fake-i386/usr/local/lib/mailman/Mailman/Cgi/confirm.py", line 114, in main File "/usr/obj/ports/mailman-2.1.5/fake-i386/usr/local/lib/mailman/Mailman/Cgi/confirm.py", line 312, in subscription_cancel File "/usr/obj/ports/mailman-2.1.5/fake-i386/usr/local/lib/mailman/Mailman/Pending.py", line 141, in pend_confirm AssertionError Python information: Variable Value sys.version 2.2.3 (#1, Mar 23 2004, 19:11:01) [GCC 2.95.3 20010125 (prerelease, propolice)] sys.executable /usr/local/bin/python2.2 sys.prefix /usr/local sys.exec_prefix /usr/local sys.path /usr/local sys.platform openbsd3 Environment variables: Variable Value PATH_INFO /friends HTTP_ACCEPT text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 CONTENT_TYPE application/x-www-form-urlencoded HTTP_REFERER https://lists.seenothing.org/confirm/friends/26ebbe661ef86491452776e04efd2aafd9788a6f SERVER_SOFTWARE Apache/1.3.29 (Unix) PHP/4.3.8 mod_ssl/2.8.16 OpenSSL/0.9.7c PYTHONPATH /usr/local/lib/mailman SCRIPT_FILENAME /usr/local/lib/mailman/cgi-bin/confirm SERVER_ADMIN webmaster@lists.seenothing.org SCRIPT_NAME /confirm SERVER_SIGNATURE Apache/1.3.29 Server at lists.seenothing.org Port 443 REQUEST_METHOD POST HTTP_HOST lists.seenothing.org HTTP_KEEP_ALIVE 300 SERVER_PROTOCOL HTTP/1.1 QUERY_STRING REQUEST_URI /confirm/friends CONTENT_LENGTH 117 HTTP_ACCEPT_CHARSET ISO-8859-1,utf-8;q=0.7,*;q=0.7 HTTP_USER_AGENT Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040809 Galeon/1.3.17 HTTP_CONNECTION keep-alive HTTP_COOKIE friends+user+cmika--at--seenothing.org=2802000000696b957641732800000038323862613031396536373461656238326664646166363064643930623331666538626361613262 SERVER_NAME lists.seenothing.org REMOTE_ADDR 66.80.107.196 REMOTE_PORT 60843 HTTP_ACCEPT_LANGUAGE en PATH_TRANSLATED /usr/local/lib/mailman/cgi-bin/friends SERVER_PORT 443 GATEWAY_INTERFACE CGI/1.1 HTTP_ACCEPT_ENCODING gzip,deflate SERVER_ADDR 192.168.1.2 DOCUMENT_ROOT /var/www/htdocs When a user tries to cancel subscription request, mailman comes up with an error. Mailman's installed on an OpenBSD 3.5 machine, using packages. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-22 13:02 Message: Logged In: YES user_id=67709 This was fixed in CVS. See closed item #981188 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1050878&group_id=103 From noreply at sourceforge.net Fri Oct 22 20:53:31 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 22 20:53:41 2004 Subject: [ mailman-Patches-1045656 ] Race in LockFile.py resulting in extraneous log entries. Message-ID: Patches item #1045656, was opened at 2004-10-12 14:50 Message generated for change (Comment added) made by grnbrg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045656&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 3 Submitted By: Brian Greenberg (grnbrg) Assigned to: Tokio Kikuchi (tkikuchi) Summary: Race in LockFile.py resulting in extraneous log entries. Initial Comment: There is a race condition (that does not affect correct operation of Mailman) in .../Mailman/LockFile.py. This race results in entries to the "locks" log file (usually in pairs) that are unnecessary and confusing. If there is a process holding a lock for a file, and a process waiting for that lock to be freed, the following sequence can occur: 1) The waiting process executes os.link(). Since the running process still has the lock, this fails with EEXIST. 2) The running process releases the lock, and removes the lock file. 3) The waiting process proceeds with it's checks, and checks self.__linkcount() which returns -1 due to an ENOENT error. This throws an error into the "locks" log file. 4) The waiting process continues processing, checks it's timeout, and then checks to see if the lock lifetime has expired. The lifetime check is based on a call to self.__releasetime(), which returns -1, due to an ENOENT error. This results in the lockfile being declared stale, and self.__break() is called. This then throws a second error into the "locks" log file. The attached patch checks for these ENOENT errors, immediately restarting the loop when they are detected. It does not affect operation is the lock file exists and is held by another process. Brian Greenberg. ---------------------------------------------------------------------- >Comment By: Brian Greenberg (grnbrg) Date: 2004-10-22 13:53 Message: Logged In: YES user_id=902583 I'm running on a Solaris box, which may or may not have any impact on the issue. I'm not sure how to force reproduction -- races are hard to intentially duplicate. I first noticed the problem under a heavy load due to an admin "oops" -- 30,000+ news articles being gatewayed into a test list. :) Once the oops was fixed, the error logs continued to occasionally appear, and rather than assume that everything was ok, I tracked down the source of the problem. I did this by desk-checking the source, and identified the race by a bit of guesswork. Once these changes were made, the problem stopped. The race occurs as follows: 1) A qrunner runs LockFile.lock() to request a particular lock. 2) At LockFile.py:256, this qrunner attempts to link it's temp lock file to the global lockfile. This link fails with a EEXIST error, because another process currently holds the lock. The assumption is made at this point that the global lockfile exists. This (false) assumption continues through to the end of the loop at LockFile.py:312. In fact, the global lockfile may cease to exist (because the qrunner that has it calls unlock()) at any time. 3) The process holding the lock calls unlock(). 4) The waiting process (which just got an EEXIST) goes through it's various sanity checks, which include checking the linkcount and mtime of the global lockfile, which now does not exist. Since it is assumed to exist, the -1 results returned make no sense, and are unconditionally logged. 5) At LockFile.py:303, the (incorrectly assumed) existing lock is broken, and control goes back to the top of the loop (after a quick __sleep()) As far as impact, the patch should have minimal side effects. I pulled the function calls out of the if statements, so there is no change in the number of calls. Further, all the new code does is to check for the "-1" return that indicates that the global lockfile no longer exists, and immediately restarts the loop if that is the case. It might not be a bad idea to add a "self.__sleep()" before the continue, but I didn't think it was needed. Hope that adds enough detail to trace what I think is happening, and verify that it won't break anything. FWIW, I have not had any problems, nor any errors logged since applying this locally. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-10-22 07:06 Message: Logged In: YES user_id=12800 I haven't had time to look at this in detail, but I'll just include a general warning that LockFile.py is /very/ fragile. It's also critical to the proper operation of Mailman. So any changes, even seemingly innocent onces, must be very thoroughly tested. My inclination would be to reject any change that wasn't absolutely necessary, but I won't veto this change if it is well-tested and fixes a verified bug (tho' it sounds like tkikuchi can't reproduce it). ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-22 03:26 Message: Logged In: YES user_id=67709 Will you be more specific how this race occurs? My installation on FreeBSD doesn't looks like show this symptom in locks log file. I tested with two terminals invoking python -i bin/withlist testlist and try to lock with m.Lock() in both the terminal. One of term is forced to wait until the I type m.Unlock() in the other term. I then looked into logs dir but nothing avail. ---------------------------------------------------------------------- Comment By: Brian Greenberg (grnbrg) Date: 2004-10-15 09:22 Message: Logged In: YES user_id=902583 This would fix this bug, as long as CLOCK_SLOP is large enough. But I don't think it's the Right Thing, as you are returning a result that says that the lockfile has a lifetime, when it in fact simply no longer exists. For a function whose purpose is to report the mtime of the master lockfile, -1 is the correct response if the file doesn't exist. The code that calls that function should check for and interpret that condition. ---------------------------------------------------------------------- Comment By: SHIGENO Kazutaka (shigeno) Date: 2004-10-14 19:11 Message: Logged In: YES user_id=1138453 How about changing as follows about self.__releasetime()? @@ -448,7 +448,7 @@ return os.stat(self.__lockfile)[ST_MTIME] except OSError, e: if e.errno <> errno.ENOENT: raise - return -1 + return time.time() def __linkcount(self): try: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045656&group_id=103 From noreply at sourceforge.net Sun Oct 24 10:02:13 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 24 10:02:24 2004 Subject: [ mailman-Patches-1045656 ] Race in LockFile.py resulting in extraneous log entries. Message-ID: Patches item #1045656, was opened at 2004-10-12 19:50 Message generated for change (Comment added) made by ppsys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045656&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 3 Submitted By: Brian Greenberg (grnbrg) Assigned to: Tokio Kikuchi (tkikuchi) Summary: Race in LockFile.py resulting in extraneous log entries. Initial Comment: There is a race condition (that does not affect correct operation of Mailman) in .../Mailman/LockFile.py. This race results in entries to the "locks" log file (usually in pairs) that are unnecessary and confusing. If there is a process holding a lock for a file, and a process waiting for that lock to be freed, the following sequence can occur: 1) The waiting process executes os.link(). Since the running process still has the lock, this fails with EEXIST. 2) The running process releases the lock, and removes the lock file. 3) The waiting process proceeds with it's checks, and checks self.__linkcount() which returns -1 due to an ENOENT error. This throws an error into the "locks" log file. 4) The waiting process continues processing, checks it's timeout, and then checks to see if the lock lifetime has expired. The lifetime check is based on a call to self.__releasetime(), which returns -1, due to an ENOENT error. This results in the lockfile being declared stale, and self.__break() is called. This then throws a second error into the "locks" log file. The attached patch checks for these ENOENT errors, immediately restarting the loop when they are detected. It does not affect operation is the lock file exists and is held by another process. Brian Greenberg. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2004-10-24 08:02 Message: Logged In: YES user_id=75166 The comments in the LockFile.py header code make the point that the entire mechanism is to deal with NFS robustness/compatibilty issues. The extranenous logging that concerns grnbrg is appearing on Solaris (version and build unspecified) and attempts to reproduce it, that have thus far failed, appear to be on FreeBSD. I suspect that the majority of MM installs are on various versions and builds of Linux. These OSen will all have substantially different NFS implementations and major differences in their kernel that probably affect NFS implementation and operation. Because of these differences I have already encountered sufficient problems with interworking of Linux NFS clients with Solaris NFS servers to convince me that changing LockFile.py without sufficient testing in order to clear an essentially cosmetic problem on one host OS is a an unecessary risk to stability across the board. Just testing on one host is not good enough and reading code even less so; it is the dynamics of operation in live situations that are the issue. A test programme needs to at least nod in the direction of heterogenous NFS client/host configurations of various types being in used for validation and verification of any changes. ---------------------------------------------------------------------- Comment By: Brian Greenberg (grnbrg) Date: 2004-10-22 18:53 Message: Logged In: YES user_id=902583 I'm running on a Solaris box, which may or may not have any impact on the issue. I'm not sure how to force reproduction -- races are hard to intentially duplicate. I first noticed the problem under a heavy load due to an admin "oops" -- 30,000+ news articles being gatewayed into a test list. :) Once the oops was fixed, the error logs continued to occasionally appear, and rather than assume that everything was ok, I tracked down the source of the problem. I did this by desk-checking the source, and identified the race by a bit of guesswork. Once these changes were made, the problem stopped. The race occurs as follows: 1) A qrunner runs LockFile.lock() to request a particular lock. 2) At LockFile.py:256, this qrunner attempts to link it's temp lock file to the global lockfile. This link fails with a EEXIST error, because another process currently holds the lock. The assumption is made at this point that the global lockfile exists. This (false) assumption continues through to the end of the loop at LockFile.py:312. In fact, the global lockfile may cease to exist (because the qrunner that has it calls unlock()) at any time. 3) The process holding the lock calls unlock(). 4) The waiting process (which just got an EEXIST) goes through it's various sanity checks, which include checking the linkcount and mtime of the global lockfile, which now does not exist. Since it is assumed to exist, the -1 results returned make no sense, and are unconditionally logged. 5) At LockFile.py:303, the (incorrectly assumed) existing lock is broken, and control goes back to the top of the loop (after a quick __sleep()) As far as impact, the patch should have minimal side effects. I pulled the function calls out of the if statements, so there is no change in the number of calls. Further, all the new code does is to check for the "-1" return that indicates that the global lockfile no longer exists, and immediately restarts the loop if that is the case. It might not be a bad idea to add a "self.__sleep()" before the continue, but I didn't think it was needed. Hope that adds enough detail to trace what I think is happening, and verify that it won't break anything. FWIW, I have not had any problems, nor any errors logged since applying this locally. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-10-22 12:06 Message: Logged In: YES user_id=12800 I haven't had time to look at this in detail, but I'll just include a general warning that LockFile.py is /very/ fragile. It's also critical to the proper operation of Mailman. So any changes, even seemingly innocent onces, must be very thoroughly tested. My inclination would be to reject any change that wasn't absolutely necessary, but I won't veto this change if it is well-tested and fixes a verified bug (tho' it sounds like tkikuchi can't reproduce it). ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-22 08:26 Message: Logged In: YES user_id=67709 Will you be more specific how this race occurs? My installation on FreeBSD doesn't looks like show this symptom in locks log file. I tested with two terminals invoking python -i bin/withlist testlist and try to lock with m.Lock() in both the terminal. One of term is forced to wait until the I type m.Unlock() in the other term. I then looked into logs dir but nothing avail. ---------------------------------------------------------------------- Comment By: Brian Greenberg (grnbrg) Date: 2004-10-15 14:22 Message: Logged In: YES user_id=902583 This would fix this bug, as long as CLOCK_SLOP is large enough. But I don't think it's the Right Thing, as you are returning a result that says that the lockfile has a lifetime, when it in fact simply no longer exists. For a function whose purpose is to report the mtime of the master lockfile, -1 is the correct response if the file doesn't exist. The code that calls that function should check for and interpret that condition. ---------------------------------------------------------------------- Comment By: SHIGENO Kazutaka (shigeno) Date: 2004-10-15 00:11 Message: Logged In: YES user_id=1138453 How about changing as follows about self.__releasetime()? @@ -448,7 +448,7 @@ return os.stat(self.__lockfile)[ST_MTIME] except OSError, e: if e.errno <> errno.ENOENT: raise - return -1 + return time.time() def __linkcount(self): try: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045656&group_id=103 From noreply at sourceforge.net Mon Oct 25 02:02:19 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 25 02:02:25 2004 Subject: [ mailman-Patches-1045656 ] Race in LockFile.py resulting in extraneous log entries. Message-ID: Patches item #1045656, was opened at 2004-10-12 19:50 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045656&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open >Resolution: Postponed Priority: 3 Submitted By: Brian Greenberg (grnbrg) Assigned to: Tokio Kikuchi (tkikuchi) Summary: Race in LockFile.py resulting in extraneous log entries. Initial Comment: There is a race condition (that does not affect correct operation of Mailman) in .../Mailman/LockFile.py. This race results in entries to the "locks" log file (usually in pairs) that are unnecessary and confusing. If there is a process holding a lock for a file, and a process waiting for that lock to be freed, the following sequence can occur: 1) The waiting process executes os.link(). Since the running process still has the lock, this fails with EEXIST. 2) The running process releases the lock, and removes the lock file. 3) The waiting process proceeds with it's checks, and checks self.__linkcount() which returns -1 due to an ENOENT error. This throws an error into the "locks" log file. 4) The waiting process continues processing, checks it's timeout, and then checks to see if the lock lifetime has expired. The lifetime check is based on a call to self.__releasetime(), which returns -1, due to an ENOENT error. This results in the lockfile being declared stale, and self.__break() is called. This then throws a second error into the "locks" log file. The attached patch checks for these ENOENT errors, immediately restarting the loop when they are detected. It does not affect operation is the lock file exists and is held by another process. Brian Greenberg. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-25 00:02 Message: Logged In: YES user_id=67709 OK. I found the log output in my solaris installation. But, I can't reproduce the said log-pair using bin/withlist. It looks like occurrence of this log output is unpredictable and need more checking before applying the patch. I found [unexpected linkcount: -1/lifetime has expired, breaking] pair in Solaris [lifetime has expired, breaking] only in BSD/OS no locks log in FreeBSD So, the behaviour is highly OS dependent I guess. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2004-10-24 08:02 Message: Logged In: YES user_id=75166 The comments in the LockFile.py header code make the point that the entire mechanism is to deal with NFS robustness/compatibilty issues. The extranenous logging that concerns grnbrg is appearing on Solaris (version and build unspecified) and attempts to reproduce it, that have thus far failed, appear to be on FreeBSD. I suspect that the majority of MM installs are on various versions and builds of Linux. These OSen will all have substantially different NFS implementations and major differences in their kernel that probably affect NFS implementation and operation. Because of these differences I have already encountered sufficient problems with interworking of Linux NFS clients with Solaris NFS servers to convince me that changing LockFile.py without sufficient testing in order to clear an essentially cosmetic problem on one host OS is a an unecessary risk to stability across the board. Just testing on one host is not good enough and reading code even less so; it is the dynamics of operation in live situations that are the issue. A test programme needs to at least nod in the direction of heterogenous NFS client/host configurations of various types being in used for validation and verification of any changes. ---------------------------------------------------------------------- Comment By: Brian Greenberg (grnbrg) Date: 2004-10-22 18:53 Message: Logged In: YES user_id=902583 I'm running on a Solaris box, which may or may not have any impact on the issue. I'm not sure how to force reproduction -- races are hard to intentially duplicate. I first noticed the problem under a heavy load due to an admin "oops" -- 30,000+ news articles being gatewayed into a test list. :) Once the oops was fixed, the error logs continued to occasionally appear, and rather than assume that everything was ok, I tracked down the source of the problem. I did this by desk-checking the source, and identified the race by a bit of guesswork. Once these changes were made, the problem stopped. The race occurs as follows: 1) A qrunner runs LockFile.lock() to request a particular lock. 2) At LockFile.py:256, this qrunner attempts to link it's temp lock file to the global lockfile. This link fails with a EEXIST error, because another process currently holds the lock. The assumption is made at this point that the global lockfile exists. This (false) assumption continues through to the end of the loop at LockFile.py:312. In fact, the global lockfile may cease to exist (because the qrunner that has it calls unlock()) at any time. 3) The process holding the lock calls unlock(). 4) The waiting process (which just got an EEXIST) goes through it's various sanity checks, which include checking the linkcount and mtime of the global lockfile, which now does not exist. Since it is assumed to exist, the -1 results returned make no sense, and are unconditionally logged. 5) At LockFile.py:303, the (incorrectly assumed) existing lock is broken, and control goes back to the top of the loop (after a quick __sleep()) As far as impact, the patch should have minimal side effects. I pulled the function calls out of the if statements, so there is no change in the number of calls. Further, all the new code does is to check for the "-1" return that indicates that the global lockfile no longer exists, and immediately restarts the loop if that is the case. It might not be a bad idea to add a "self.__sleep()" before the continue, but I didn't think it was needed. Hope that adds enough detail to trace what I think is happening, and verify that it won't break anything. FWIW, I have not had any problems, nor any errors logged since applying this locally. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-10-22 12:06 Message: Logged In: YES user_id=12800 I haven't had time to look at this in detail, but I'll just include a general warning that LockFile.py is /very/ fragile. It's also critical to the proper operation of Mailman. So any changes, even seemingly innocent onces, must be very thoroughly tested. My inclination would be to reject any change that wasn't absolutely necessary, but I won't veto this change if it is well-tested and fixes a verified bug (tho' it sounds like tkikuchi can't reproduce it). ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-22 08:26 Message: Logged In: YES user_id=67709 Will you be more specific how this race occurs? My installation on FreeBSD doesn't looks like show this symptom in locks log file. I tested with two terminals invoking python -i bin/withlist testlist and try to lock with m.Lock() in both the terminal. One of term is forced to wait until the I type m.Unlock() in the other term. I then looked into logs dir but nothing avail. ---------------------------------------------------------------------- Comment By: Brian Greenberg (grnbrg) Date: 2004-10-15 14:22 Message: Logged In: YES user_id=902583 This would fix this bug, as long as CLOCK_SLOP is large enough. But I don't think it's the Right Thing, as you are returning a result that says that the lockfile has a lifetime, when it in fact simply no longer exists. For a function whose purpose is to report the mtime of the master lockfile, -1 is the correct response if the file doesn't exist. The code that calls that function should check for and interpret that condition. ---------------------------------------------------------------------- Comment By: SHIGENO Kazutaka (shigeno) Date: 2004-10-15 00:11 Message: Logged In: YES user_id=1138453 How about changing as follows about self.__releasetime()? @@ -448,7 +448,7 @@ return os.stat(self.__lockfile)[ST_MTIME] except OSError, e: if e.errno <> errno.ENOENT: raise - return -1 + return time.time() def __linkcount(self): try: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045656&group_id=103 From noreply at sourceforge.net Mon Oct 25 09:35:35 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 25 09:35:38 2004 Subject: [ mailman-Patches-1053558 ] i18n: Header Filter Rules (& fix) Message-ID: Patches item #1053558, was opened at 2004-10-25 16:35 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=1053558&group_id=103 Category: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Hatuka*nezumi (hatukanezumi) Assigned to: Nobody/Anonymous (nobody) Summary: i18n: Header Filter Rules (& fix) Initial Comment: - Decode headers to be matched. - Normalize header & pattern so that compatibility characters (fullwidth forms of ASCII, Compatibility Ideographs etc.) will be matched. Normalization Form KC (NFKC) is used. note: This feature is available on Python >= 2.3. - Fix: Ignore empty lines in pattern to prevent matching any strings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1053558&group_id=103 From noreply at sourceforge.net Mon Oct 25 15:57:27 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 25 15:57:29 2004 Subject: [ mailman-Patches-1053739 ] Fix colors in HTML pages Message-ID: Patches item #1053739, was opened at 2004-10-25 15:57 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=1053739&group_id=103 Category: Web UI Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Nico (nico18) Assigned to: Nobody/Anonymous (nobody) Summary: Fix colors in HTML pages Initial Comment: The HTML pages in mailman-2.1 set the background color, but not the foreground color. This results in pages which are not readable if you have set your default colors in your browser to white on black, for example. This patch against current mailman-2.1 CVS fixes that bug by setting the text color to black in pages in which the background color is set to white. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1053739&group_id=103 From noreply at sourceforge.net Tue Oct 26 06:21:56 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 26 06:22:00 2004 Subject: [ mailman-Patches-1053558 ] i18n: Header Filter Rules (& fix) Message-ID: Patches item #1053558, was opened at 2004-10-25 16:35 Message generated for change (Comment added) made by hatukanezumi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1053558&group_id=103 Category: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Hatuka*nezumi (hatukanezumi) Assigned to: Nobody/Anonymous (nobody) Summary: i18n: Header Filter Rules (& fix) Initial Comment: - Decode headers to be matched. - Normalize header & pattern so that compatibility characters (fullwidth forms of ASCII, Compatibility Ideographs etc.) will be matched. Normalization Form KC (NFKC) is used. note: This feature is available on Python >= 2.3. - Fix: Ignore empty lines in pattern to prevent matching any strings. ---------------------------------------------------------------------- >Comment By: Hatuka*nezumi (hatukanezumi) Date: 2004-10-26 13:21 Message: Logged In: YES user_id=529503 Error handlings are added. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1053558&group_id=103 From noreply at sourceforge.net Tue Oct 26 18:46:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 26 18:47:11 2004 Subject: [ mailman-Patches-1045656 ] Race in LockFile.py resulting in extraneous log entries. Message-ID: Patches item #1045656, was opened at 2004-10-12 14:50 Message generated for change (Comment added) made by grnbrg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045656&group_id=103 Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: Postponed Priority: 3 Submitted By: Brian Greenberg (grnbrg) Assigned to: Tokio Kikuchi (tkikuchi) Summary: Race in LockFile.py resulting in extraneous log entries. Initial Comment: There is a race condition (that does not affect correct operation of Mailman) in .../Mailman/LockFile.py. This race results in entries to the "locks" log file (usually in pairs) that are unnecessary and confusing. If there is a process holding a lock for a file, and a process waiting for that lock to be freed, the following sequence can occur: 1) The waiting process executes os.link(). Since the running process still has the lock, this fails with EEXIST. 2) The running process releases the lock, and removes the lock file. 3) The waiting process proceeds with it's checks, and checks self.__linkcount() which returns -1 due to an ENOENT error. This throws an error into the "locks" log file. 4) The waiting process continues processing, checks it's timeout, and then checks to see if the lock lifetime has expired. The lifetime check is based on a call to self.__releasetime(), which returns -1, due to an ENOENT error. This results in the lockfile being declared stale, and self.__break() is called. This then throws a second error into the "locks" log file. The attached patch checks for these ENOENT errors, immediately restarting the loop when they are detected. It does not affect operation is the lock file exists and is held by another process. Brian Greenberg. ---------------------------------------------------------------------- >Comment By: Brian Greenberg (grnbrg) Date: 2004-10-26 11:46 Message: Logged In: YES user_id=902583 I'm running Solaris 8, with the locks and qfiles on local disk. mm 2.1.5 and python 2.3.3. There are a little over 1000 lists, with traffic of 300-500 posts per day, on average. Given that it's cosmetic, there is no rush. I'm open to testing suggestions... ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-24 19:02 Message: Logged In: YES user_id=67709 OK. I found the log output in my solaris installation. But, I can't reproduce the said log-pair using bin/withlist. It looks like occurrence of this log output is unpredictable and need more checking before applying the patch. I found [unexpected linkcount: -1/lifetime has expired, breaking] pair in Solaris [lifetime has expired, breaking] only in BSD/OS no locks log in FreeBSD So, the behaviour is highly OS dependent I guess. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2004-10-24 03:02 Message: Logged In: YES user_id=75166 The comments in the LockFile.py header code make the point that the entire mechanism is to deal with NFS robustness/compatibilty issues. The extranenous logging that concerns grnbrg is appearing on Solaris (version and build unspecified) and attempts to reproduce it, that have thus far failed, appear to be on FreeBSD. I suspect that the majority of MM installs are on various versions and builds of Linux. These OSen will all have substantially different NFS implementations and major differences in their kernel that probably affect NFS implementation and operation. Because of these differences I have already encountered sufficient problems with interworking of Linux NFS clients with Solaris NFS servers to convince me that changing LockFile.py without sufficient testing in order to clear an essentially cosmetic problem on one host OS is a an unecessary risk to stability across the board. Just testing on one host is not good enough and reading code even less so; it is the dynamics of operation in live situations that are the issue. A test programme needs to at least nod in the direction of heterogenous NFS client/host configurations of various types being in used for validation and verification of any changes. ---------------------------------------------------------------------- Comment By: Brian Greenberg (grnbrg) Date: 2004-10-22 13:53 Message: Logged In: YES user_id=902583 I'm running on a Solaris box, which may or may not have any impact on the issue. I'm not sure how to force reproduction -- races are hard to intentially duplicate. I first noticed the problem under a heavy load due to an admin "oops" -- 30,000+ news articles being gatewayed into a test list. :) Once the oops was fixed, the error logs continued to occasionally appear, and rather than assume that everything was ok, I tracked down the source of the problem. I did this by desk-checking the source, and identified the race by a bit of guesswork. Once these changes were made, the problem stopped. The race occurs as follows: 1) A qrunner runs LockFile.lock() to request a particular lock. 2) At LockFile.py:256, this qrunner attempts to link it's temp lock file to the global lockfile. This link fails with a EEXIST error, because another process currently holds the lock. The assumption is made at this point that the global lockfile exists. This (false) assumption continues through to the end of the loop at LockFile.py:312. In fact, the global lockfile may cease to exist (because the qrunner that has it calls unlock()) at any time. 3) The process holding the lock calls unlock(). 4) The waiting process (which just got an EEXIST) goes through it's various sanity checks, which include checking the linkcount and mtime of the global lockfile, which now does not exist. Since it is assumed to exist, the -1 results returned make no sense, and are unconditionally logged. 5) At LockFile.py:303, the (incorrectly assumed) existing lock is broken, and control goes back to the top of the loop (after a quick __sleep()) As far as impact, the patch should have minimal side effects. I pulled the function calls out of the if statements, so there is no change in the number of calls. Further, all the new code does is to check for the "-1" return that indicates that the global lockfile no longer exists, and immediately restarts the loop if that is the case. It might not be a bad idea to add a "self.__sleep()" before the continue, but I didn't think it was needed. Hope that adds enough detail to trace what I think is happening, and verify that it won't break anything. FWIW, I have not had any problems, nor any errors logged since applying this locally. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-10-22 07:06 Message: Logged In: YES user_id=12800 I haven't had time to look at this in detail, but I'll just include a general warning that LockFile.py is /very/ fragile. It's also critical to the proper operation of Mailman. So any changes, even seemingly innocent onces, must be very thoroughly tested. My inclination would be to reject any change that wasn't absolutely necessary, but I won't veto this change if it is well-tested and fixes a verified bug (tho' it sounds like tkikuchi can't reproduce it). ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-22 03:26 Message: Logged In: YES user_id=67709 Will you be more specific how this race occurs? My installation on FreeBSD doesn't looks like show this symptom in locks log file. I tested with two terminals invoking python -i bin/withlist testlist and try to lock with m.Lock() in both the terminal. One of term is forced to wait until the I type m.Unlock() in the other term. I then looked into logs dir but nothing avail. ---------------------------------------------------------------------- Comment By: Brian Greenberg (grnbrg) Date: 2004-10-15 09:22 Message: Logged In: YES user_id=902583 This would fix this bug, as long as CLOCK_SLOP is large enough. But I don't think it's the Right Thing, as you are returning a result that says that the lockfile has a lifetime, when it in fact simply no longer exists. For a function whose purpose is to report the mtime of the master lockfile, -1 is the correct response if the file doesn't exist. The code that calls that function should check for and interpret that condition. ---------------------------------------------------------------------- Comment By: SHIGENO Kazutaka (shigeno) Date: 2004-10-14 19:11 Message: Logged In: YES user_id=1138453 How about changing as follows about self.__releasetime()? @@ -448,7 +448,7 @@ return os.stat(self.__lockfile)[ST_MTIME] except OSError, e: if e.errno <> errno.ENOENT: raise - return -1 + return time.time() def __linkcount(self): try: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1045656&group_id=103 From noreply at sourceforge.net Wed Oct 27 01:58:18 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 27 01:58:21 2004 Subject: [ mailman-Bugs-1054944 ] Default templates set bgcolors Message-ID: Bugs item #1054944, was opened at 2004-10-26 23:58 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=1054944&group_id=103 Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: MJ Ray (slef) Assigned to: Nobody/Anonymous (nobody) Summary: Default templates set bgcolors Initial Comment: Many of the templates for the CGI and for the archives set background colours but do not set text colours. This leads to readers who don't use dark-on-light default colours getting very hard-to-read pages. Mailman is not following Web Content Accessibility Guideline 2.2 I attach a patch which fixes templates/en in a minimal way. I hope that's OK. If not, please direct me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1054944&group_id=103 From noreply at sourceforge.net Wed Oct 27 11:16:57 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 27 11:17:00 2004 Subject: [ mailman-Patches-1055166 ] i18n: Topics Message-ID: Patches item #1055166, was opened at 2004-10-27 18: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=1055166&group_id=103 Category: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Hatuka*nezumi (hatukanezumi) Assigned to: Nobody/Anonymous (nobody) Summary: i18n: Topics Initial Comment: * See also: patch #1053558. - Decode headers/body to be matched. - Normalize header & pattern so that compatibility characters (fullwidth forms of ASCII, Compatibility Ideographs etc.) will be matched. Normalization Form KC (NFKC) is used. note: This feature is available on Python >= 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1055166&group_id=103 From noreply at sourceforge.net Thu Oct 28 03:26:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 28 03:26:32 2004 Subject: [ mailman-Bugs-1055809 ] Obvious: regex handling by Tagger.py vs. SpamDetect.py Message-ID: Bugs item #1055809, was opened at 2004-10-28 10:26 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=1055809&group_id=103 Category: None Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Hatuka*nezumi (hatukanezumi) Assigned to: Nobody/Anonymous (nobody) Summary: Obvious: regex handling by Tagger.py vs. SpamDetect.py Initial Comment: o Tagger handler handles a pattern string as one regex with re.VERBOSE flag. o SpamDetect handler handles a pattern string as newline-separated multiple regex'es without re.VERBOSE flag. Which behaviour is preferred? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1055809&group_id=103 From noreply at sourceforge.net Thu Oct 28 03:26:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 28 03:27:00 2004 Subject: [ mailman-Bugs-1055809 ] Obvious: regex handling by Tagger.py vs. SpamDetect.py Message-ID: Bugs item #1055809, was opened at 2004-10-28 10:26 Message generated for change (Settings changed) made by hatukanezumi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1055809&group_id=103 Category: None Group: 2.1 (stable) Status: Open Resolution: None >Priority: 7 Submitted By: Hatuka*nezumi (hatukanezumi) Assigned to: Nobody/Anonymous (nobody) Summary: Obvious: regex handling by Tagger.py vs. SpamDetect.py Initial Comment: o Tagger handler handles a pattern string as one regex with re.VERBOSE flag. o SpamDetect handler handles a pattern string as newline-separated multiple regex'es without re.VERBOSE flag. Which behaviour is preferred? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1055809&group_id=103 From noreply at sourceforge.net Thu Oct 28 03:31:15 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 28 03:31:18 2004 Subject: [ mailman-Patches-1055166 ] i18n: Topics Message-ID: Patches item #1055166, was opened at 2004-10-27 18:16 Message generated for change (Comment added) made by hatukanezumi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1055166&group_id=103 Category: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Hatuka*nezumi (hatukanezumi) Assigned to: Nobody/Anonymous (nobody) Summary: i18n: Topics Initial Comment: * See also: patch #1053558. - Decode headers/body to be matched. - Normalize header & pattern so that compatibility characters (fullwidth forms of ASCII, Compatibility Ideographs etc.) will be matched. Normalization Form KC (NFKC) is used. note: This feature is available on Python >= 2.3. ---------------------------------------------------------------------- >Comment By: Hatuka*nezumi (hatukanezumi) Date: 2004-10-28 10:31 Message: Logged In: YES user_id=529503 And see also bug #1055809. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1055166&group_id=103 From noreply at sourceforge.net Fri Oct 29 03:08:54 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 29 03:08:58 2004 Subject: [ mailman-Bugs-1056486 ] No option to set List-Id? Message-ID: Bugs item #1056486, was opened at 2004-10-29 01: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=1056486&group_id=103 Category: configuring/installing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: MJ Ray (slef) Assigned to: Nobody/Anonymous (nobody) Summary: No option to set List-Id? Initial Comment: RFC-2919 says to preserve List-Id if a list moves between hosts. I couldn't find an option in Mailman to specify the List-Id (to preserve the current List-Id and help existing filters). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1056486&group_id=103 From noreply at sourceforge.net Sat Oct 30 06:17:28 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 30 06:18:37 2004 Subject: [ mailman-Bugs-1041791 ] Bug in Mailman version 2.1.5 - help Message-ID: Bugs item #1041791, was opened at 2004-10-06 17:14 Message generated for change (Comment added) made by bongervw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1041791&group_id=103 Category: None Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: FeniX (zmrozek) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in Mailman version 2.1.5 - help Initial Comment: Bug in Mailman version 2.1.5 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/lib/mailman/scripts/driver", line 96, in run_main main() File "/usr/lib/mailman/Mailman/Cgi/listinfo.py", line 42, in main listinfo_overview() File "/usr/lib/mailman/Mailman/Cgi/listinfo.py", line 88, in listinfo_overview if mlist.advertised: File "/usr/lib/mailman/Mailman/MailList.py", line 144, in __getattr__ raise AttributeError, name AttributeError: advertised Python information: Variable Value sys.version 2.3.4 (#2, Sep 24 2004, 08:39:09) [GCC 3. 3.4 (Debian 1:3.3.4-12)] sys.executable /usr/bin/python sys.prefix /usr sys.exec_prefix /usr sys.path /usr sys.platform linux2 Environment variables: Variable Value HTTP_COOKIE openwebmail-loginname=jurek; openwebmail-httpcompress=0 SERVER_SOFTWARE Apache/1.3.31 (Debian GNU/Linux) mod_gzip/1.3.26.1a SCRIPT_NAME /mailman/listinfo SERVER_SIGNATURE REQUEST_METHOD GET SERVER_PROTOCOL HTTP/1.1 QUERY_STRING HTTP_TE deflate, gzip, chunked, identity, trailers HTTP_ACCEPT_CHARSET iso-8859-2, utf-8, utf-16, iso- 8859-1;q=0.6, *;q=0.1 HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Opera 7.54 [pl] HTTP_CONNECTION Keep-Alive, TE SERVER_NAME eko.org.pl REMOTE_ADDR 156.17.228.163 SERVER_PORT 80 SERVER_ADDR 195.116.86.81 DOCUMENT_ROOT /httpd/htdocs/www.eko.wroc.pl PYTHONPATH /var/lib/mailman SCRIPT_FILENAME /httpd/cgi-bin/mailman/listinfo SERVER_ADMIN webmaster@eko.wroc.pl HTTP_HOST eko.org.pl HTTP_COOKIE2 $Version=1 HTTP_CACHE_CONTROL no-cache REQUEST_URI /mailman/listinfo HTTP_ACCEPT text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 GATEWAY_INTERFACE CGI/1.1 REMOTE_PORT 2632 HTTP_ACCEPT_LANGUAGE pl;q=1.0,en;q=0.9 HTTP_ACCEPT_ENCODING deflate, gzip, x-gzip, identity, *;q=0 UNIQUE_ID QWRfL8N0VlEAACVGm7I ---------------------------------------------------------------------- Comment By: Vance Wheelock II (bongervw) Date: 2004-10-30 00:17 Message: Logged In: YES user_id=100213 I had the same issue after upgrading to 2.1.5.... This can be caused when you have a corrupted list or a list does not contain all of it's pieces. I have a small number of lists, so I ran the list_members script for each list until I found the offending list. In my case it was easy because it was a dummy "test" list that I could remove. If others have this issue on a valid list, then they will need to backup the lists files and recreate it. (someone else may have a beter way to fix the corruption depending upon what it is) ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-13 09:06 Message: Logged In: YES user_id=67709 Can you explain more detail of the environment ? Is this your fresh install of mailman, or upgrading from older version ? Install from source or package ? What do you you when you exec 'ls -l /lists/*' ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1041791&group_id=103 From noreply at sourceforge.net Sun Oct 31 03:03:46 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 31 03:03:51 2004 Subject: [ mailman-Bugs-948152 ] Out of date link on Docs webpage Message-ID: Bugs item #948152, was opened at 2004-05-05 01:57 Message generated for change (Settings changed) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=948152&group_id=103 Category: documentation Group: 2.1 (stable) >Status: Closed Resolution: None Priority: 5 Submitted By: quetza (user99) Assigned to: Nobody/Anonymous (nobody) Summary: Out of date link on Docs webpage Initial Comment: On http://www.list.org/docs.html there is a link to "HOWTO on using Exim and Mailman" (http://www.exim.org/howto/mailman.html) This refers to an old version of Exim (and mailman). The link should be: http://www.exim.org/howto/mailman21.html ---------------------------------------------------------------------- Comment By: Terri Oda (spot) Date: 2004-10-02 23:27 Message: Logged In: YES user_id=110886 I've changed this in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=948152&group_id=103 From noreply at sourceforge.net Sun Oct 31 05:11:53 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 31 05:12:00 2004 Subject: [ mailman-Patches-1008983 ] qrunner w/ multiple slices crashing. Message-ID: Patches item #1008983, was opened at 2004-08-13 21:45 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1008983&group_id=103 Category: mail delivery Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 7 Submitted By: Brian Greenberg (grnbrg) Assigned to: Tokio Kikuchi (tkikuchi) Summary: qrunner w/ multiple slices crashing. Initial Comment: When running qrunner with multiple instances of a particular class (ie: qrunner -r OutgoingRunner:0:4 -r OutgoingRunner:1:4 -r OutgoingRunner:2:4 -r OutgoingRunner:3:4 ) the qrunner processes for this class will periodically crash, leaving the following traces: logs/qrunner: Aug 13 15:27:51 2004 (29188) Master qrunner detected subprocess exit (pid: 23829, sig: None, sts: 1, class: OutgoingRunner, slice: 1/4) [restarting] logs/error: Aug 13 15:27:51 2004 qrunner(23829): Traceback (most recent call last): Aug 13 15:27:51 2004 qrunner(23829): File "/usr/local/mailman/bin/qrunner", line 270, in ? Aug 13 15:27:51 2004 qrunner(23829): main() Aug 13 15:27:51 2004 qrunner(23829): File "/usr/local/mailman/bin/qrunner", line 230, in main Aug 13 15:27:51 2004 qrunner(23829): qrunner.run() Aug 13 15:27:51 2004 qrunner(23829): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 70, in run Aug 13 15:27:51 2004 qrunner(23829): filecnt = self._oneloop() Aug 13 15:27:51 2004 qrunner(23829): File "/usr/local/mailman/Mailman/Queue/Runner.py", line 99, in _oneloop Aug 13 15:27:51 2004 qrunner(23829): msg, msgdata = self._switchboard.dequeue(filebase) Aug 13 15:27:51 2004 qrunner(23829): File "/usr/local/mailman/Mailman/Queue/Switchboard.py", line 143, in dequeue Aug 13 15:27:51 2004 qrunner(23829): fp = open(filename) Aug 13 15:27:51 2004 qrunner(23829): IOError : [Errno 2] No such file or directory: '/var/priv/mail/mailman/qfiles/out/1092428866.8410051+70dcb0bb96e6460d8cd2a a8103cce318cfa3ed1f.pck' This is caused by a logic error in mailman/Mailman/Queues/Switchboard.py:files. Specifically, when there are not multiple slices running for a particular qrunner class, self.__upper and self.__lower are both set to None in Switchboard.py:__init__. Switchboard.py:files contains the statement: if not lower or (lower <= long(digest, 16) < upper): times[float](when)] = filebase ie: if there is only one slice (because "lower" is not "None") or if this filename is within the range of the slice that this qrunner is managing, then add it to the list. The problem is that the first slice of any multi-slice qrunner has a lower bound of "0". This means that slice "0" of any multi-slice qrunner will act on *all* files in a given queue, which in turn results in race conditions wherein slice 0 and slice n will begin to process a message, one will complete processing and remove the file, and the other will crash. Patch: *** Switchboard.py Fri Aug 13 16:43:12 2004 --- Switchboard.py_new Fri Aug 13 16:43:48 2004 *************** *** 164,170 **** when, digest = filebase.split('+') # Throw out any files which don't match our bitrange. BAW: test # performance and end-cases of this algorithm. ! if not lower or (lower <= long(digest, 16) < upper): times[float(when)] = filebase # FIFO sort keys = times.keys() --- 164,170 ---- when, digest = filebase.split('+') # Throw out any files which don't match our bitrange. BAW: test # performance and end-cases of this algorithm. ! if (lower == upper) or (lower <= long(digest, 16) < upper): times[float(when)] = filebase # FIFO sort keys = times.keys() Brian Greenberg -- grnbrg@cc.umanitoba.ca ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-31 04:11 Message: Logged In: YES user_id=67709 fixed in CVS ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-10-22 07:49 Message: Logged In: YES user_id=67709 I am testing one of my working server (moderate size ~3000 list) with Barry's patch. Also try setting (OutgoingRunner 2). So, if nothing happens in a day or two, this will go into CVS. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2004-10-22 01:52 Message: Logged In: YES user_id=12800 Better: the "if not lower" should probably be changed to "if lower is None". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1008983&group_id=103 From noreply at sourceforge.net Sun Oct 31 06:39:22 2004 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 31 06:39:26 2004 Subject: [ mailman-Patches-1057579 ] add urlhost/emailhost options to newlist Message-ID: Patches item #1057579, was opened at 2004-10-31 05:39 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=1057579&group_id=103 Category: command line scripts Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: add urlhost/emailhost options to newlist Initial Comment: Discussions in Mailman-Developers lead to add new options to bin/newlist in such a way that current urlhost/emailhost confusion may be cleared. $ newlist --urlhost=www.dom.ain --emailhost=mail.dom.ain listname We also keep @ notation for backward compatibility: $ newlist listname@www.dom.ain This is a draft patch for program part. Documentation is yet to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1057579&group_id=103