bug error when subscribing through web after Mailman 2.1.12 upgrade
Since upgrading to version 2.1.12, I have experienced a number of errors that have resulted in a "You've Hit a Bug". So far, I have been able to patch things up. The latest occurs when a user attempts to subscribe from the web. Here is the error log information:
admin(9559): [----- Mailman Version: 2.1.12 -----] admin(9559): [----- Traceback ------] admin(9559): Traceback (most recent call last): admin(9559): File "/usr/local/mailman/scripts/driver", line 112, in run_main admin(9559): main() admin(9559): File "/usr/local/mailman/Mailman/Cgi/subscribe.py", line 97, in main admin(9559): process_form(mlist, doc, cgidata, language) admin(9559): File "/usr/local/mailman/Mailman/Cgi/subscribe.py", line 177, in process_form admin(9559): mlist.AddMember(userdesc, remote) admin(9559): File "/usr/local/mailman/Mailman/MailList.py", line 894, in AddMember admin(9559): listinfo_url = self.getScriptUrl('listinfo', absolute=1) admin(9559): File "/usr/local/mailman/Mailman/MailList.py", line 146, in __getattr__ admin(9559): raise AttributeError, name admin(9559): AttributeError: getScriptUrl admin(9559): [----- Python Information -----] admin(9559): sys.version = 2.5 (r25:51908, Jul 17 2007, 11:25:13) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-20)] admin(9559): sys.executable = /usr/local/bin/python admin(9559): sys.prefix = /usr/local admin(9559): sys.exec_prefix = /usr/local admin(9559): sys.path = /usr/local admin(9559): sys.platform = linux2 admin(9559): [----- Environment Variables -----] admin(9559): HTTP_COOKIE: orcollabproj+admin=2802000000693832674a732800000065396231343338353461343335393035633531633966663335636564306366643338663533326234; ei-news+admin=280200000069243a674a732800000062313735653035626465346563393937346135303333616437643337656231663631393734306233; ola2010+admin=280200000069953a674a732800000064373236653737626132383038653838313930646234616662643139343531383334653536353764; orshots+admin=2802000000694e3c674a732800000035383661646366366230653064346432666536643064353263386631366366336665666164613539; test7+admin=280200000069c83f674a732800000037663466353036643030353334346437643332316233636430393266326534633038373935306661 admin(9559): SERVER_SOFTWARE: Apache/2.2.4 (Unix) admin(9559): SCRIPT_NAME: /mailman/subscribe admin(9559): SERVER_SIGNATURE: admin(9559): REQUEST_METHOD: POST admin(9559): HTTP_KEEP_ALIVE: 300 admin(9559): SERVER_PROTOCOL: HTTP/1.1 admin(9559): QUERY_STRING: admin(9559): CONTENT_LENGTH: 101 admin(9559): HTTP_ACCEPT_CHARSET: ISO-8859-1,utf-8;q=0.7,*;q=0.7 admin(9559): HTTP_USER_AGENT: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 admin(9559): HTTP_CONNECTION: keep-alive admin(9559): HTTP_REFERER: http://listsmart.osl.state.or.us/mailman/listinfo/test7 admin(9559): SERVER_NAME: listsmart.osl.state.or.us admin(9559): REMOTE_ADDR: 159.121.122.135 admin(9559): PATH_TRANSLATED: /usr/local/apache2/htdocs/test7 admin(9559): SERVER_PORT: 80 admin(9559): SERVER_ADDR: 159.121.122.233 admin(9559): DOCUMENT_ROOT: /usr/local/apache2/htdocs admin(9559): PYTHONPATH: /usr/local/mailman admin(9559): SCRIPT_FILENAME: /usr/local/mailman/cgi-bin/subscribe admin(9559): SERVER_ADMIN: root@swiki.osl.state.or.us admin(9559): HTTP_HOST: listsmart.osl.state.or.us admin(9559): REQUEST_URI: /mailman/subscribe/test7 admin(9559): HTTP_ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 admin(9559): GATEWAY_INTERFACE: CGI/1.1 admin(9559): REMOTE_PORT: 1638 admin(9559): HTTP_ACCEPT_LANGUAGE: en-us,en;q=0.5 admin(9559): CONTENT_TYPE: application/x-www-form-urlencoded admin(9559): HTTP_ACCEPT_ENCODING: gzip,deflate admin(9559): PATH_INFO: /test7
-- Christopher Adams adamsca@gmail.com
Christopher Adams wrote:
Since upgrading to version 2.1.12, I have experienced a number of errors that have resulted in a "You've Hit a Bug". So far, I have been able to patch things up. The latest occurs when a user attempts to subscribe from the web. Here is the error log information:
admin(9559): [----- Mailman Version: 2.1.12 -----] admin(9559): [----- Traceback ------] admin(9559): Traceback (most recent call last): admin(9559): File "/usr/local/mailman/scripts/driver", line 112, in run_main admin(9559): main() admin(9559): File "/usr/local/mailman/Mailman/Cgi/subscribe.py", line 97, in main admin(9559): process_form(mlist, doc, cgidata, language) admin(9559): File "/usr/local/mailman/Mailman/Cgi/subscribe.py", line 177, in process_form admin(9559): mlist.AddMember(userdesc, remote)
Here in the traceback, the subscribe CGI is calling the list object's AddMember method to add the member
admin(9559): File "/usr/local/mailman/Mailman/MailList.py", line 894, in AddMember admin(9559): listinfo_url = self.getScriptUrl('listinfo', absolute=1)
Then within the AddMember method in /usr/local/mailman/Mailman/MailList.py, the above line calls the list's getScriptUrl method which triggers the exception below saying the list object has no getScriptUrl method.
There are two things seriously wrong here:
In the 2.1.12 released MailList.py, there is no line containing the name 'listinfo_url' anywhere in the module
the 'getScriptUrl' list method doesn't exist, thus the exception. The method's name is 'GetScriptURL'.
admin(9559): File "/usr/local/mailman/Mailman/MailList.py", line 146, in __getattr__ admin(9559): raise AttributeError, name admin(9559): AttributeError: getScriptUrl
So, the question here is where did this MailList.py module come from? Is this a source install or a package? Did you modify it in any way? It is clearly not an unmodified source distribution, and it is clearly broken.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark,
The modification to MailList.py is something that you suggested awhile back and I had carried it through as Mailman was upgraded. Here is the thread from 2005.
http://mail.python.org/pipermail/mailman-users/2005-January/042116.html
This time, it didn't seem to work and broke it.The problem was the email sent to new list owners had the list address, but didn't complete the actual address. Instead, it results in this:
Send list messages to:
%(emailaddr)s
What is the actual solutilon to the template being populated with the actual list address. This seems like something that would be assumed to exist in an out of the box installation.
Thanks again for your help. I have removed the modifications and it is working correctly again.
Christopher Adams
On Wed, Jul 22, 2009 at 5:50 PM, Mark Sapiro<mark@msapiro.net> wrote:
Christopher Adams wrote:
Since upgrading to version 2.1.12, I have experienced a number of errors that have resulted in a "You've Hit a Bug". So far, I have been able to patch things up. The latest occurs when a user attempts to subscribe from the web. Here is the error log information:
admin(9559): [----- Mailman Version: 2.1.12 -----] admin(9559): [----- Traceback ------] admin(9559): Traceback (most recent call last): admin(9559): File "/usr/local/mailman/scripts/driver", line 112, in run_main admin(9559): main() admin(9559): File "/usr/local/mailman/Mailman/Cgi/subscribe.py", line 97, in main admin(9559): process_form(mlist, doc, cgidata, language) admin(9559): File "/usr/local/mailman/Mailman/Cgi/subscribe.py", line 177, in process_form admin(9559): mlist.AddMember(userdesc, remote)
Here in the traceback, the subscribe CGI is calling the list object's AddMember method to add the member
admin(9559): File "/usr/local/mailman/Mailman/MailList.py", line 894, in AddMember admin(9559): listinfo_url = self.getScriptUrl('listinfo', absolute=1)
Then within the AddMember method in /usr/local/mailman/Mailman/MailList.py, the above line calls the list's getScriptUrl method which triggers the exception below saying the list object has no getScriptUrl method.
There are two things seriously wrong here:
In the 2.1.12 released MailList.py, there is no line containing the name 'listinfo_url' anywhere in the module
the 'getScriptUrl' list method doesn't exist, thus the exception. The method's name is 'GetScriptURL'.
admin(9559): File "/usr/local/mailman/Mailman/MailList.py", line 146, in __getattr__ admin(9559): raise AttributeError, name admin(9559): AttributeError: getScriptUrl
So, the question here is where did this MailList.py module come from? Is this a source install or a package? Did you modify it in any way? It is clearly not an unmodified source distribution, and it is clearly broken.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-- Christopher Adams adamsca@gmail.com
Christopher Adams wrote:
The modification to MailList.py is something that you suggested awhile back and I had carried it through as Mailman was upgraded. Here is the thread from 2005.
http://mail.python.org/pipermail/mailman-users/2005-January/042116.html
This time, it didn't seem to work and broke it.The problem was the email sent to new list owners had the list address, but didn't complete the actual address. Instead, it results in this:
Send list messages to:
%(emailaddr)s
What is the actual solutilon to the template being populated with the actual list address. This seems like something that would be assumed to exist in an out of the box installation.
The problem with the modification is my fault. I said to add
listinfo_url = self.getScriptUrl('listinfo', absolute=1)but this is wrong. It needs to be
listinfo_url = self.GetScriptURL('listinfo', absolute=1)However, this has nothing to do with the mail sent to the owner of a new list. This particular modification was to add a definition of 'listinfo_url' to the substitutions in the verify.txt template for the confirmation message sent to someone subscribing when the policy includes 'confirm'. The same modification is also required when the verify.txt template is used for an address change confirmation.
Adding %(emailaddr)s to the newlist.txt template requires a different modification to MailList.py.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark,
Yes, you are correct. I realized that I was referring to the wrong fix after sending my message. I certainly didn't want to insinuate that you gave me bad information.
That aside, the question still stands. Why are these fixes needed to force the templates to display as it seems they should be default? What about a list adminstrator who doesn't have full run of the system to make these fixes? An administrator who does have full run would have to know some python and understand the way Mailman works on the backend. I guess that is the hope for an adminstrator, isn't it?
On Thu, Jul 23, 2009 at 7:39 AM, Mark Sapiro<mark@msapiro.net> wrote:
Christopher Adams wrote:
The modification to MailList.py is something that you suggested awhile back and I had carried it through as Mailman was upgraded. Here is the thread from 2005.
http://mail.python.org/pipermail/mailman-users/2005-January/042116.html
This time, it didn't seem to work and broke it.The problem was the email sent to new list owners had the list address, but didn't complete the actual address. Instead, it results in this:
Send list messages to:
%(emailaddr)s
What is the actual solutilon to the template being populated with the actual list address. This seems like something that would be assumed to exist in an out of the box installation.
The problem with the modification is my fault. I said to add
listinfo_url = self.getScriptUrl('listinfo', absolute=1)
but this is wrong. It needs to be
listinfo_url = self.GetScriptURL('listinfo', absolute=1)
However, this has nothing to do with the mail sent to the owner of a new list. This particular modification was to add a definition of 'listinfo_url' to the substitutions in the verify.txt template for the confirmation message sent to someone subscribing when the policy includes 'confirm'. The same modification is also required when the verify.txt template is used for an address change confirmation.
Adding %(emailaddr)s to the newlist.txt template requires a different modification to MailList.py.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
-- Christopher Adams adamsca@gmail.com
Christopher Adams wrote:
That aside, the question still stands. Why are these fixes needed to force the templates to display as it seems they should be default? What about a list adminstrator who doesn't have full run of the system to make these fixes? An administrator who does have full run would have to know some python and understand the way Mailman works on the backend. I guess that is the hope for an adminstrator, isn't it?
The way current mailman works, you can't just arbitrarily add replacements to templates. Each template is processed with a dictionary of replacements that is specific to that template. The fact that you see some substitution in template-A does not mean you can use the same substitution in template-B because the dictionary for template-B probably doesn't include it.
That said, one thing on my to-do list for Mailman 2.2 is to have a global set of replacements that can be used in all templates, but that does not currently exist.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
Christopher Adams -
Mark Sapiro