Mailman-coders February 2006

mailman-coders@python.org

1 participants
42 discussions

[ mailman-Feature Requests-1439790 ] Make all web interface pages XHTML compliant
by SourceForge.net 27 Feb '06

27 Feb '06

Feature Requests item #1439790, was opened at 2006-02-27 09:56 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=1439790&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dragon (dragon93) Assigned to: Nobody/Anonymous (nobody) Summary: Make all web interface pages XHTML compliant Initial Comment: It would be very nice to have the web interface to Mailman updated to current W3C recommended standards for page markup. XHTML 1.0 strict with CSS Level 2 should be the goal. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1439790&group_…

1 0

[ mailman-Patches-1437867 ] Bug: canonstr() with funny character
by SourceForge.net 23 Feb '06

23 Feb '06

Patches item #1437867, was opened at 2006-02-24 13:53 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=1437867&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Web UI Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Hatuka*nezumi (hatukanezumi) Assigned to: Nobody/Anonymous (nobody) Summary: Bug: canonstr() with funny character Initial Comment: Utils.canonstr() generates traceback when user's realname contains some unconvertible characters (\ufffd etc.). A patch is attached. Tracebacks (line numbers have some offsets): Traceback (most recent call last): File "/usr/local/mailman/scripts/driver", line 87, in run_main main() File "/usr/local/mailman/Mailman/Cgi/admin.py", line 176, in main change_options(mlist, category, subcat, cgidata, doc) File "/usr/local/mailman/Mailman/Cgi/admin.py", line 1497, in change_options newname = Utils.canonstr(newname, mlist.preferred_language) File "/usr/local/mailman/Mailman/Utils.py", line 850, in canonstr newstr = EMPTYSTRING.join(newparts) UnicodeDecodeError: 'ascii' codec can't decode byte 0x8e in position 0: ordinal not in range(128) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1437867&group_…

1 0

[ mailman-Bugs-1437581 ] Mailman Auto-unsubscribes Bad Addresses?
by SourceForge.net 23 Feb '06

23 Feb '06

Bugs item #1437581, was opened at 2006-02-23 10:01 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1437581&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: (un)subscribing Group: 2.1 (stable) >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Bruce Scherzinger (bascherz) Assigned to: Nobody/Anonymous (nobody) Summary: Mailman Auto-unsubscribes Bad Addresses? Initial Comment: I haven't seen any settings for this, and I can only describe it based on the information that I have. But today I received bounce notices identically timestamped for three separate email addresses in the same domain. The notices all indicated the addresses had been unsubscribed from a specific Mailman list. I don't know what initiated the action, and these same addresses are still subscribed to other, less- frequently used lists. I sent emails directly to the three addresses to notify them of the issue, and I got back a response from their email server as follows (actual email addresses omitted or replaced for privacy reasons): - - - - - - - - - - - - - - - - Return-Path: <> X-Envelope-To: <my_email_address> X-Spam-Status: No, hits=2.4 required=5.0 tests=AWL: -0.181,HTML_30_40: 0.879,HTML_MESSAGE: 0.001, MIME_HTML_MOSTLY: 1.54,VIRUS_WARNING268B: 0.2 X-Spam-Level: ** Return-Path: <> Delivered-To: <my_email_address> Received: (qmail 29847 invoked by uid 399); 23 Feb 2006 17:21:13 -0000 X-Virus-Scan: Scanned by clamdmail 0.15 (no viruses); Thu, 23 Feb 2006 11:21:13 -0600 Received: from unknown (HELO eastrmmtao06.cox.net) (68.230.240.33) by mail.opentransfer.com with SMTP; 23 Feb 2006 17:21:13 -0000 To: <my_email_address> From: Mail Administrator <Postmaster(a)cox.net> Reply-To: <Postmaster(a)cox.net> Subject: Mail System Error - Returned Mail Date: Thu, 23 Feb 2006 12:21:06 -0500 Message-ID: <omitted> MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; Boundary="===========================_ _= 9638061(9108)1140715266" --===========================_ _= 9638061(9108) 1140715266 Content-Type: text/plain This Message was undeliverable due to the following reason: Each of the following recipients was rejected by a remote mail server. The reasons given by the server are included to help you determine why each recipient was rejected. Recipient: <addr1(a)erols.com> Reason: #5.1.1 bad address addr1(a)erols.com Recipient: <addr2(a)erols.com> Reason: #5.1.1 bad address addr2(a)erols.com Recipient: <addr3(a)erols.com> Reason: #5.1.1 bad address addr3(a)erols.com - - - - - - - - - - - - - - - - So, all three addresses are bad. Does Mailman automatically unsubscribe addresses if it can't deliver to them? Or, is there a way to spoof it to get it to delete addresses? Is it possible the email server (erols.com in this case) can determine that there are messages being sent from a Mailman email list and send unsubscribe requests to the Mailman server to make them stop? ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-02-23 16:36 Message: Logged In: YES user_id=1123998 I am closing this because mailman is doing what it should. The users were unsubscribed by bounce processing. The settings for this are list by list on the Bounce processing page of the admin web interface. Mailman registers the bounce notices that it receives in response to post deliveries and handles them according to bounce settings. The remote server has no direct involvement with the unsubscribe. It just returns a notice to mailman just like the notice returned to you when you mailed these addresses directly. The process is described on the Bounce processing page. And yes, bounce notifications can be spoofed, but with normal default settings, the spoofer would have to send 5 spoofed notices on different days, and then the member would have list delivery disabled and be sent a warning, and be sent two more warnings at one week intervals before being unsubscribed. Also, you can select the option to notify the list owner when the subscription is disabled, so unsubscribing a user by spoofing bounces is not likely to be successful if the user actually has any interest in the list. ---------------------------------------------------------------------- Comment By: Bruce Scherzinger (bascherz) Date: 2006-02-23 10:10 Message: Logged In: YES user_id=1415850 I failed to mention that the webhosting company has Mailman v2.1.6 installed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1437581&group_…

1 0

[ mailman-Bugs-1437581 ] Mailman Auto-unsubscribes Bad Addresses?
by SourceForge.net 23 Feb '06

23 Feb '06

Bugs item #1437581, was opened at 2006-02-23 13:01 Message generated for change (Comment added) made by bascherz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1437581&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Bruce Scherzinger (bascherz) Assigned to: Nobody/Anonymous (nobody) Summary: Mailman Auto-unsubscribes Bad Addresses? Initial Comment: I haven't seen any settings for this, and I can only describe it based on the information that I have. But today I received bounce notices identically timestamped for three separate email addresses in the same domain. The notices all indicated the addresses had been unsubscribed from a specific Mailman list. I don't know what initiated the action, and these same addresses are still subscribed to other, less- frequently used lists. I sent emails directly to the three addresses to notify them of the issue, and I got back a response from their email server as follows (actual email addresses omitted or replaced for privacy reasons): - - - - - - - - - - - - - - - - Return-Path: <> X-Envelope-To: <my_email_address> X-Spam-Status: No, hits=2.4 required=5.0 tests=AWL: -0.181,HTML_30_40: 0.879,HTML_MESSAGE: 0.001, MIME_HTML_MOSTLY: 1.54,VIRUS_WARNING268B: 0.2 X-Spam-Level: ** Return-Path: <> Delivered-To: <my_email_address> Received: (qmail 29847 invoked by uid 399); 23 Feb 2006 17:21:13 -0000 X-Virus-Scan: Scanned by clamdmail 0.15 (no viruses); Thu, 23 Feb 2006 11:21:13 -0600 Received: from unknown (HELO eastrmmtao06.cox.net) (68.230.240.33) by mail.opentransfer.com with SMTP; 23 Feb 2006 17:21:13 -0000 To: <my_email_address> From: Mail Administrator <Postmaster(a)cox.net> Reply-To: <Postmaster(a)cox.net> Subject: Mail System Error - Returned Mail Date: Thu, 23 Feb 2006 12:21:06 -0500 Message-ID: <omitted> MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; Boundary="===========================_ _= 9638061(9108)1140715266" --===========================_ _= 9638061(9108) 1140715266 Content-Type: text/plain This Message was undeliverable due to the following reason: Each of the following recipients was rejected by a remote mail server. The reasons given by the server are included to help you determine why each recipient was rejected. Recipient: <addr1(a)erols.com> Reason: #5.1.1 bad address addr1(a)erols.com Recipient: <addr2(a)erols.com> Reason: #5.1.1 bad address addr2(a)erols.com Recipient: <addr3(a)erols.com> Reason: #5.1.1 bad address addr3(a)erols.com - - - - - - - - - - - - - - - - So, all three addresses are bad. Does Mailman automatically unsubscribe addresses if it can't deliver to them? Or, is there a way to spoof it to get it to delete addresses? Is it possible the email server (erols.com in this case) can determine that there are messages being sent from a Mailman email list and send unsubscribe requests to the Mailman server to make them stop? ---------------------------------------------------------------------- >Comment By: Bruce Scherzinger (bascherz) Date: 2006-02-23 13:10 Message: Logged In: YES user_id=1415850 I failed to mention that the webhosting company has Mailman v2.1.6 installed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1437581&group_…

1 0

[ mailman-Bugs-1437581 ] Mailman Auto-unsubscribes Bad Addresses?
by SourceForge.net 23 Feb '06

23 Feb '06

Bugs item #1437581, was opened at 2006-02-23 13:01 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=1437581&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Bruce Scherzinger (bascherz) Assigned to: Nobody/Anonymous (nobody) Summary: Mailman Auto-unsubscribes Bad Addresses? Initial Comment: I haven't seen any settings for this, and I can only describe it based on the information that I have. But today I received bounce notices identically timestamped for three separate email addresses in the same domain. The notices all indicated the addresses had been unsubscribed from a specific Mailman list. I don't know what initiated the action, and these same addresses are still subscribed to other, less- frequently used lists. I sent emails directly to the three addresses to notify them of the issue, and I got back a response from their email server as follows (actual email addresses omitted or replaced for privacy reasons): - - - - - - - - - - - - - - - - Return-Path: <> X-Envelope-To: <my_email_address> X-Spam-Status: No, hits=2.4 required=5.0 tests=AWL: -0.181,HTML_30_40: 0.879,HTML_MESSAGE: 0.001, MIME_HTML_MOSTLY: 1.54,VIRUS_WARNING268B: 0.2 X-Spam-Level: ** Return-Path: <> Delivered-To: <my_email_address> Received: (qmail 29847 invoked by uid 399); 23 Feb 2006 17:21:13 -0000 X-Virus-Scan: Scanned by clamdmail 0.15 (no viruses); Thu, 23 Feb 2006 11:21:13 -0600 Received: from unknown (HELO eastrmmtao06.cox.net) (68.230.240.33) by mail.opentransfer.com with SMTP; 23 Feb 2006 17:21:13 -0000 To: <my_email_address> From: Mail Administrator <Postmaster(a)cox.net> Reply-To: <Postmaster(a)cox.net> Subject: Mail System Error - Returned Mail Date: Thu, 23 Feb 2006 12:21:06 -0500 Message-ID: <omitted> MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; Boundary="===========================_ _= 9638061(9108)1140715266" --===========================_ _= 9638061(9108) 1140715266 Content-Type: text/plain This Message was undeliverable due to the following reason: Each of the following recipients was rejected by a remote mail server. The reasons given by the server are included to help you determine why each recipient was rejected. Recipient: <addr1(a)erols.com> Reason: #5.1.1 bad address addr1(a)erols.com Recipient: <addr2(a)erols.com> Reason: #5.1.1 bad address addr2(a)erols.com Recipient: <addr3(a)erols.com> Reason: #5.1.1 bad address addr3(a)erols.com - - - - - - - - - - - - - - - - So, all three addresses are bad. Does Mailman automatically unsubscribe addresses if it can't deliver to them? Or, is there a way to spoof it to get it to delete addresses? Is it possible the email server (erols.com in this case) can determine that there are messages being sent from a Mailman email list and send unsubscribe requests to the Mailman server to make them stop? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1437581&group_…

1 0

[ mailman-Bugs-1433673 ] Wrong timezone in list archive index pages
by SourceForge.net 22 Feb '06

22 Feb '06

Bugs item #1433673, was opened at 2006-02-17 08:08 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1433673&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Pipermail Group: 2.1 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Schoinobates Volans (schoinobates) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong timezone in list archive index pages Initial Comment: This is Debian bug #352876 (see http://bugs.debian.org/352876) The timezone used on the list archive index pages for the starting, ending, last message and archived on dates is wrong. All these times are given in GMT (the standard timezone for the UK) but are claimed to be BST (British Summer Time, the daylight saving time used between March and October, equivalent to GMT+1). For example, the last message to one of my lists was sent at Fri, 10 Feb 2006 10:07:40 +0000, but according to the archives by thread page, the ending and last message dates are "Fri Feb 10 10:07:40 BST 2006". The timezone is correct in the archive page for the message though, where it is given as "Fri Feb 10 10:07:40 GMT 2006" The times given during the summer are correct, where everything is in BST. Original submitter claims timezone data and clock is correct on the machine. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-02-22 20:34 Message: Logged In: YES user_id=1123998 I've thought about this some more and I've come up with a different fix which will use tm_isdst from time.localtime() in those cases where time.strptime() returns tm_isdst = -1. Thanks to Roger Lynn for the motivation. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-02-22 08:47 Message: Logged In: YES user_id=1123998 >Isn't the real problem that the time zone has been >stripped from the string in the first place? Sort of. The problem here is that the string is produced by time.asctime() which doesn't put a timezone in the string. Changing this would be a significant change to the archiver which might well break something else - at least if I did it :-) ---------------------------------------------------------------------- Comment By: Roger Lynn (rogerlynn) Date: 2006-02-22 07:58 Message: Logged In: YES user_id=781651 Isn't the real problem that the time zone has been stripped from the string in the first place? ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-02-19 13:48 Message: Logged In: YES user_id=1123998 Patch has been committed to CVS. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-02-17 19:35 Message: Logged In: YES user_id=1123998 The underlying problem is a bug in i18n.ctime(). When i18n.ctime is passed a time string, it uses time.strptime() to convert the string into a struct_time. If the string doesn't contain a time zone, strptime() returns tm_isdst = -1 which the following code treats as 1 rather than unknown. The attached patch (2.1.7 base) will use the phrase "Server Local Time" translated into the list language instead of BST or whatever. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1433673&group_…

1 0

[ mailman-Bugs-1433673 ] Wrong timezone in list archive index pages
by SourceForge.net 22 Feb '06

22 Feb '06

Bugs item #1433673, was opened at 2006-02-17 08:08 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1433673&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Pipermail Group: 2.1 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Schoinobates Volans (schoinobates) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong timezone in list archive index pages Initial Comment: This is Debian bug #352876 (see http://bugs.debian.org/352876) The timezone used on the list archive index pages for the starting, ending, last message and archived on dates is wrong. All these times are given in GMT (the standard timezone for the UK) but are claimed to be BST (British Summer Time, the daylight saving time used between March and October, equivalent to GMT+1). For example, the last message to one of my lists was sent at Fri, 10 Feb 2006 10:07:40 +0000, but according to the archives by thread page, the ending and last message dates are "Fri Feb 10 10:07:40 BST 2006". The timezone is correct in the archive page for the message though, where it is given as "Fri Feb 10 10:07:40 GMT 2006" The times given during the summer are correct, where everything is in BST. Original submitter claims timezone data and clock is correct on the machine. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-02-22 08:47 Message: Logged In: YES user_id=1123998 >Isn't the real problem that the time zone has been >stripped from the string in the first place? Sort of. The problem here is that the string is produced by time.asctime() which doesn't put a timezone in the string. Changing this would be a significant change to the archiver which might well break something else - at least if I did it :-) ---------------------------------------------------------------------- Comment By: Roger Lynn (rogerlynn) Date: 2006-02-22 07:58 Message: Logged In: YES user_id=781651 Isn't the real problem that the time zone has been stripped from the string in the first place? ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-02-19 13:48 Message: Logged In: YES user_id=1123998 Patch has been committed to CVS. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-02-17 19:35 Message: Logged In: YES user_id=1123998 The underlying problem is a bug in i18n.ctime(). When i18n.ctime is passed a time string, it uses time.strptime() to convert the string into a struct_time. If the string doesn't contain a time zone, strptime() returns tm_isdst = -1 which the following code treats as 1 rather than unknown. The attached patch (2.1.7 base) will use the phrase "Server Local Time" translated into the list language instead of BST or whatever. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1433673&group_…

1 0

[ mailman-Bugs-1435722 ] Subscription fails with some Language combinations
by SourceForge.net 22 Feb '06

22 Feb '06

Bugs item #1435722, was opened at 2006-02-21 00:41 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1435722&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: (un)subscribing Group: 2.1 (stable) >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Klaus Steinberger (kst) Assigned to: Nobody/Anonymous (nobody) Summary: Subscription fails with some Language combinations Initial Comment: I have some list with both english(USA) and german language enabled. If somebody tries to subscribe and selects german language, they get the "We hit a bug message". This does not happen if german is the only option, just if both english and german are enabled. Also english must be the default to hit the bug. Here are the error log details: admin(4095): [----- Mailman Version: 2.1.7 -----] admin(4095): [----- Traceback ------] admin(4095): Traceback (most recent call last): admin(4095): File "/var/mailman/scripts/driver", line 101, in run_main admin(4095): main() admin(4095): File "/var/mailman/Mailman/Cgi/subscribe.py", line 96, in main admin(4095): process_form(mlist, doc, cgidata, language) admin(4095): File "/var/mailman/Mailman/Cgi/subscribe.py", line 176, in process_form admin(4095): mlist.AddMember(userdesc, remote) admin(4095): File "/var/mailman/Mailman/MailList.py", line 899, in AddMember admin(4095): msg['Subject'] = self.GetConfirmJoinSubject(realname, cookie) admin(4095): File "/var/mailman/Mailman/MailList.py", line 216, in GetConfirmJoinSubject admin(4095): cset, header_name='subject') admin(4095): File "/var/tmp/mailman-root/var/mailman/pythonlib/email/Header.py", line 188, in __init__ admin(4095): File "/var/tmp/mailman-root/var/mailman/pythonlib/email/Header.py", line 272, in append admin(4095): UnicodeError: ASCII decoding error: ordinal not in range(128) admin(4095): [----- Python Information -----] admin(4095): sys.version = 2.2.2 (#1, Feb 24 2003, 19:13:11) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] admin(4095): sys.executable = /usr/bin/python admin(4095): sys.prefix = /usr admin(4095): sys.exec_prefix = /usr admin(4095): sys.path = /usr admin(4095): sys.platform = linux2 admin(4095): [----- Environment Variables -----] admin(4095): PATH_INFO: /test admin(4095): CONTENT_LENGTH: 140 admin(4095): SERVER_PORT: 443 admin(4095): HTTP_COOKIE: site=2802000000691dc6fa43732800000063323164313562353536396239393738616631303133646639393034626532623334636264363564 admin(4095): SCRIPT_FILENAME: /var/mailman/cgi-bin/subscribe admin(4095): PYTHONPATH: /var/mailman admin(4095): SERVER_SOFTWARE: Apache/2.0.51 (Fedora) admin(4095): SERVER_ADMIN: Rechnergruppe(a)Physik.Uni-Muenchen.DE admin(4095): SCRIPT_NAME: /mailman/subscribe admin(4095): SCRIPT_URI: https://lists.physik.uni-muenchen.de/mailman/subscribe/test admin(4095): SERVER_SIGNATURE: <address>Apache/2.0.51 (Fedora) Server at lists.physik.uni-muenchen.de Port 443</address> admin(4095): admin(4095): REQUEST_METHOD: POST admin(4095): HTTP_HOST: lists.physik.uni-muenchen.de admin(4095): SCRIPT_URL: /mailman/subscribe/test admin(4095): HTTPS: on admin(4095): SERVER_PROTOCOL: HTTP/1.1 admin(4095): QUERY_STRING: admin(4095): PATH_TRANSLATED: /var/www/sites1/lists.physik.uni-muenchen.de/test admin(4095): REQUEST_URI: /mailman/subscribe/test admin(4095): HTTP_ACCEPT: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 admin(4095): HTTP_ACCEPT_CHARSET: ISO-8859-1,utf-8;q=0.7,*;q=0.7 admin(4095): HTTP_USER_AGENT: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050927 Fedora/1.0.7-1.1.fc3.mll.1 Firefox/1.0.7 admin(4095): HTTP_CONNECTION: keep-alive admin(4095): HTTP_REFERER: https://lists.physik.uni-muenchen.de/mailman/listinfo/test admin(4095): SERVER_NAME: lists.physik.uni-muenchen.de admin(4095): REMOTE_ADDR: 141.84.29.17 admin(4095): REMOTE_PORT: 44945 admin(4095): HTTP_ACCEPT_LANGUAGE: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 admin(4095): UNIQUE_ID: s6td58A2KoEAAHdvB6gAAAAB admin(4095): CONTENT_TYPE: application/x-www-form-urlencoded admin(4095): GATEWAY_INTERFACE: CGI/1.1 admin(4095): DOCUMENT_ROOT: /var/www/sites1/lists.physik.uni-muenchen.de/ admin(4095): HTTP_ACCEPT_ENCODING: gzip,deflate admin(4095): SERVER_ADDR: 192.54.42.132 admin(4095): HTTP_KEEP_ALIVE: 300 ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-02-22 08:29 Message: Logged In: YES user_id=1123998 Patch commited in CVS. ---------------------------------------------------------------------- Comment By: Klaus Steinberger (kst) Date: 2006-02-21 13:24 Message: Logged In: YES user_id=52018 Thanks! That's really fast response. I built a new RPM for my system with this patch and it works like a charm. Sincerly, Klaus ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-02-21 13:04 Message: Logged In: YES user_id=1123998 Revised patch. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-02-21 10:17 Message: Logged In: YES user_id=1123998 There are two ways to deal with this bug in your case. You can avoid it by changing the character set for 'en' in the language table from 'us-ascii' to 'iso-8859-1'. You would do this by putting: add_language('en', 'English (USA)', 'iso-8859-1') in mm_cfg.py. Or, you can actually fix it with the attached patch to Mailman/MailList.py. If possible, try the patch and let us know how it works for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1435722&group_…

1 0

[ mailman-Bugs-1433673 ] Wrong timezone in list archive index pages
by SourceForge.net 22 Feb '06

22 Feb '06

Bugs item #1433673, was opened at 2006-02-17 16:08 Message generated for change (Comment added) made by rogerlynn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1433673&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Pipermail Group: 2.1 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Schoinobates Volans (schoinobates) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong timezone in list archive index pages Initial Comment: This is Debian bug #352876 (see http://bugs.debian.org/352876) The timezone used on the list archive index pages for the starting, ending, last message and archived on dates is wrong. All these times are given in GMT (the standard timezone for the UK) but are claimed to be BST (British Summer Time, the daylight saving time used between March and October, equivalent to GMT+1). For example, the last message to one of my lists was sent at Fri, 10 Feb 2006 10:07:40 +0000, but according to the archives by thread page, the ending and last message dates are "Fri Feb 10 10:07:40 BST 2006". The timezone is correct in the archive page for the message though, where it is given as "Fri Feb 10 10:07:40 GMT 2006" The times given during the summer are correct, where everything is in BST. Original submitter claims timezone data and clock is correct on the machine. ---------------------------------------------------------------------- Comment By: Roger Lynn (rogerlynn) Date: 2006-02-22 15:58 Message: Logged In: YES user_id=781651 Isn't the real problem that the time zone has been stripped from the string in the first place? ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-02-19 21:48 Message: Logged In: YES user_id=1123998 Patch has been committed to CVS. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-02-18 03:35 Message: Logged In: YES user_id=1123998 The underlying problem is a bug in i18n.ctime(). When i18n.ctime is passed a time string, it uses time.strptime() to convert the string into a struct_time. If the string doesn't contain a time zone, strptime() returns tm_isdst = -1 which the following code treats as 1 rather than unknown. The attached patch (2.1.7 base) will use the phrase "Server Local Time" translated into the list language instead of BST or whatever. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1433673&group_…

1 0

[ mailman-Bugs-1435722 ] Subscription fails with some Language combinations
by SourceForge.net 21 Feb '06

21 Feb '06

Bugs item #1435722, was opened at 2006-02-21 09:41 Message generated for change (Comment added) made by kst You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1435722&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Klaus Steinberger (kst) Assigned to: Nobody/Anonymous (nobody) Summary: Subscription fails with some Language combinations Initial Comment: I have some list with both english(USA) and german language enabled. If somebody tries to subscribe and selects german language, they get the "We hit a bug message". This does not happen if german is the only option, just if both english and german are enabled. Also english must be the default to hit the bug. Here are the error log details: admin(4095): [----- Mailman Version: 2.1.7 -----] admin(4095): [----- Traceback ------] admin(4095): Traceback (most recent call last): admin(4095): File "/var/mailman/scripts/driver", line 101, in run_main admin(4095): main() admin(4095): File "/var/mailman/Mailman/Cgi/subscribe.py", line 96, in main admin(4095): process_form(mlist, doc, cgidata, language) admin(4095): File "/var/mailman/Mailman/Cgi/subscribe.py", line 176, in process_form admin(4095): mlist.AddMember(userdesc, remote) admin(4095): File "/var/mailman/Mailman/MailList.py", line 899, in AddMember admin(4095): msg['Subject'] = self.GetConfirmJoinSubject(realname, cookie) admin(4095): File "/var/mailman/Mailman/MailList.py", line 216, in GetConfirmJoinSubject admin(4095): cset, header_name='subject') admin(4095): File "/var/tmp/mailman-root/var/mailman/pythonlib/email/Header.py", line 188, in __init__ admin(4095): File "/var/tmp/mailman-root/var/mailman/pythonlib/email/Header.py", line 272, in append admin(4095): UnicodeError: ASCII decoding error: ordinal not in range(128) admin(4095): [----- Python Information -----] admin(4095): sys.version = 2.2.2 (#1, Feb 24 2003, 19:13:11) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] admin(4095): sys.executable = /usr/bin/python admin(4095): sys.prefix = /usr admin(4095): sys.exec_prefix = /usr admin(4095): sys.path = /usr admin(4095): sys.platform = linux2 admin(4095): [----- Environment Variables -----] admin(4095): PATH_INFO: /test admin(4095): CONTENT_LENGTH: 140 admin(4095): SERVER_PORT: 443 admin(4095): HTTP_COOKIE: site=2802000000691dc6fa43732800000063323164313562353536396239393738616631303133646639393034626532623334636264363564 admin(4095): SCRIPT_FILENAME: /var/mailman/cgi-bin/subscribe admin(4095): PYTHONPATH: /var/mailman admin(4095): SERVER_SOFTWARE: Apache/2.0.51 (Fedora) admin(4095): SERVER_ADMIN: Rechnergruppe(a)Physik.Uni-Muenchen.DE admin(4095): SCRIPT_NAME: /mailman/subscribe admin(4095): SCRIPT_URI: https://lists.physik.uni-muenchen.de/mailman/subscribe/test admin(4095): SERVER_SIGNATURE: <address>Apache/2.0.51 (Fedora) Server at lists.physik.uni-muenchen.de Port 443</address> admin(4095): admin(4095): REQUEST_METHOD: POST admin(4095): HTTP_HOST: lists.physik.uni-muenchen.de admin(4095): SCRIPT_URL: /mailman/subscribe/test admin(4095): HTTPS: on admin(4095): SERVER_PROTOCOL: HTTP/1.1 admin(4095): QUERY_STRING: admin(4095): PATH_TRANSLATED: /var/www/sites1/lists.physik.uni-muenchen.de/test admin(4095): REQUEST_URI: /mailman/subscribe/test admin(4095): HTTP_ACCEPT: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 admin(4095): HTTP_ACCEPT_CHARSET: ISO-8859-1,utf-8;q=0.7,*;q=0.7 admin(4095): HTTP_USER_AGENT: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050927 Fedora/1.0.7-1.1.fc3.mll.1 Firefox/1.0.7 admin(4095): HTTP_CONNECTION: keep-alive admin(4095): HTTP_REFERER: https://lists.physik.uni-muenchen.de/mailman/listinfo/test admin(4095): SERVER_NAME: lists.physik.uni-muenchen.de admin(4095): REMOTE_ADDR: 141.84.29.17 admin(4095): REMOTE_PORT: 44945 admin(4095): HTTP_ACCEPT_LANGUAGE: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 admin(4095): UNIQUE_ID: s6td58A2KoEAAHdvB6gAAAAB admin(4095): CONTENT_TYPE: application/x-www-form-urlencoded admin(4095): GATEWAY_INTERFACE: CGI/1.1 admin(4095): DOCUMENT_ROOT: /var/www/sites1/lists.physik.uni-muenchen.de/ admin(4095): HTTP_ACCEPT_ENCODING: gzip,deflate admin(4095): SERVER_ADDR: 192.54.42.132 admin(4095): HTTP_KEEP_ALIVE: 300 ---------------------------------------------------------------------- >Comment By: Klaus Steinberger (kst) Date: 2006-02-21 22:24 Message: Logged In: YES user_id=52018 Thanks! That's really fast response. I built a new RPM for my system with this patch and it works like a charm. Sincerly, Klaus ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-02-21 22:04 Message: Logged In: YES user_id=1123998 Revised patch. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-02-21 19:17 Message: Logged In: YES user_id=1123998 There are two ways to deal with this bug in your case. You can avoid it by changing the character set for 'en' in the language table from 'us-ascii' to 'iso-8859-1'. You would do this by putting: add_language('en', 'English (USA)', 'iso-8859-1') in mm_cfg.py. Or, you can actually fix it with the attached patch to Mailman/MailList.py. If possible, try the patch and let us know how it works for you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1435722&group_…

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Mailman-coders February 2006