Is it safe to upgrade to Python 2.3 from 2.2.2 with an existing MailMan installation without breaking things?
Bill
-- bill bradford mrbill@mrbill.net austin, texas
On Tue, 2003-07-29 at 22:58, Bill Bradford wrote:
Is it safe to upgrade to Python 2.3 from 2.2.2 with an existing MailMan installation without breaking things?
I'm sad to say I haven't had a lick of time to thoroughly test this. I /think/ it should be okay, but I'm updating my personal servers now so I can eat my own dog food.
-Barry
Howdy. I just upgraded to the latest 2.1.2 stable source (I had been running the last beta previously). After upgrading, as expected all template files got stomped on so I set about recreating them as appropriate. After doing so however I have two stumpers which looking at the source code for the archiver (and various other files), I am stumped to solve.
The first issue is that specifically "templates/en/options.html" does not seem to be honoured. It is either looking in the wrong place (wrong language maybe) or doing something completely unknown. I can change the template but it does not affect what the CGI scripts ultimately display. Looking at the code suggests that this should behave no differently than say, "listinfo.html" (which works fine) but damned if I can figure out why this is happening.
The second issue which has me really embarrassed because I know I licked it once is that I cannot figure out where the headers for the archives are coming from. Sometime in the past I figured out how to change these but now the updated templates from "templates/en/" are not consulted when the archives get updated (i.e .when a new message comes in it uses an old template) nor can I find where this template lives. The source suggests that there may be some caching happening (going by class/function names) but I have not been able to narrow it down from there. I am guessing it they are either in a db file somewhere or outside the Mailman tree but I am lost finding 'em (grepping and running find has not been able to track them down).
No errors show in the logs either for the record.
Any suggestions on how to nail either of these frustrating template issues greatly appreciated.
Cheers,
Ron
On July 30, 2003 06:11 pm, you wrote:
Howdy. I just upgraded to the latest 2.1.2 stable source (I had been running the last beta previously). After upgrading, as expected all template files got stomped on so I set about recreating them as appropriate. After doing so however I have two stumpers which looking at the source code for the archiver (and various other files), I am stumped to solve.
Howdy. To follow up on my post, I noticed the following in Utils.py talking about how templates were looked for:
# 1. the list-specific language directory
# lists/<listname>/<language>
#
# 2. the domain-specific language directory
# templates/<list.host_name>/<language>
#
# 3. the site-wide language directory
# templates/site/<language>
#
# 4. the global default language directory
# templates/<language>Looking closer I see that some templates are used, some are not as the code base is still a tad inconsistent in that area.
"options.html" is not being used in most cases because the code simply does not call up a template. "Cgi/options.py" only uses options.html in some cases (if you are not successful logging in, no template is used). The latest version of Mailman re-breaks cookies in Konqueror (the beta had fixed this) so I was actually getting the error page and not immediately noticing that this is handled differently in the code.
So this is just a case of misleading behaviour / out of sync documentation I guess.
Where I am still totally stumped though is for the archive templates. I simply do not understand why the templates are being ignored. Looking at HyperArch.py we have the following functions:
def quick_maketext(templatefile, dict=None, lang=None, mlist=None):
This seems to be where the templates are all parsed. Looking through it I see the following:
template = _templatecache.get((templatefile, lang)) if template is None: # Use the basic maketext, with defaults to get the raw template template = Utils.maketext(templatefile, lang=lang, raw=1) _templatecache[(templatefile, lang)] = template
So the first time through the template is loaded and from then on it sits in the global array _template. The main thing here is that the maketext call should be returning an error if it cannot load the template (which has been edited) but instead it does not and the generated archive pages do not match the templates as stored in the templates folder.
Any ideas what gives here? Why are my templates being ignored for the archives?
Cheers
PS: I hate the lack of formal closure for if statements in Python (yes, I do like idiot mittens thank you very much).
=)
On Thursday, July 31, 2003, at 09:16 pm, Ron Brogden wrote:
On July 30, 2003 06:11 pm, you wrote:
Howdy. I just upgraded to the latest 2.1.2 stable source (I had been running the last beta previously). After upgrading, as expected all template files got stomped on so I set about recreating them as appropriate. After doing so however I have two stumpers which
looking at the source code for the archiver (and various other files), I am
stumped to solve.Howdy. To follow up on my post, I noticed the following in Utils.py
talking about how templates were looked for:# 1. the list-specific language directory # lists/<listname>/<language> # # 2. the domain-specific language directory # templates/<list.host_name>/<language> # # 3. the site-wide language directory # templates/site/<language> # # 4. the global default language directory # templates/<language>Looking closer I see that some templates are used, some are not as the
code base is still a tad inconsistent in that area."options.html" is not being used in most cases because the code simply
does not call up a template. "Cgi/options.py" only uses options.html in
some cases (if you are not successful logging in, no template is used).
The latest version of Mailman re-breaks cookies in Konqueror (the beta had
fixed this) so I was actually getting the error page and not immediately
noticing that this is handled differently in the code.So this is just a case of misleading behaviour / out of sync
documentation I guess.Where I am still totally stumped though is for the archive templates.
I simply do not understand why the templates are being ignored. Looking
at HyperArch.py we have the following functions:def quick_maketext(templatefile, dict=None, lang=None, mlist=None):
This seems to be where the templates are all parsed. Looking through
it I see the following:template = _templatecache.get((templatefile, lang)) if template is None: # Use the basic maketext, with defaults to get the raw template template = Utils.maketext(templatefile, lang=lang, raw=1) _templatecache[(templatefile, lang)] = template
So the first time through the template is loaded and from then on it
sits in the global array _template. The main thing here is that the maketext
call should be returning an error if it cannot load the template (which has
been edited) but instead it does not and the generated archive pages do not
match the templates as stored in the templates folder.Any ideas what gives here? Why are my templates being ignored for the archives?
There is a known bug in MM 2.1.2 (and earlier 2.1.x) for which a patch
is available. This patch has been folded into the CVS and should thus
appear in the next release of MM (2.1.3?) but for the moment it is
applicable to 2.1.2; see:
http://sourceforge.net/tracker/ index.php?func=detail&aid=730769&group_id=103&atid=100103
Cheers
PS: I hate the lack of formal closure for if statements in Python
(yes, I do like idiot mittens thank you very much).
They are formally closed by exdenting. Indentation is much cleaner than
braces BEGIN/END etc, for indicating block structure, once you are used
to it.
=)
Richard Barrett http://www.openinfo.co.uk
On July 31, 2003 01:58 pm, you wrote:
There is a known bug in MM 2.1.2 (and earlier 2.1.x) for which a patch is available. This patch has been folded into the CVS and should thus appear in the next release of MM (2.1.3?) but for the moment it is applicable to 2.1.2; see: http://sourceforge.net/tracker/ index.php?func=detail&aid=730769&group_id=103&atid=100103
Hello Richard. Thanks for the tip but now I have a new problem (ain't that always the case).
=)
I tried installing the patch but it seemed to have messed up the template parsing (I was suddenly left with unparsed tags such as "%(meta)s" everywhere. I quickly reverted back to the unmodified code but now it appears that this data has been physically cached somewhere so now I have the problem of not being able to clear out the stale cache.
Any idea where this cache is stored? My archives will shortly be useless if I cannot catch this quickly (and a rebuild is nasty, nasty as this is a busy server).
Arrrgh.
=)
Cheers
On Thursday, July 31, 2003, at 10:37 pm, Ron Brogden wrote:
On July 31, 2003 01:58 pm, you wrote:
There is a known bug in MM 2.1.2 (and earlier 2.1.x) for which a patch is available. This patch has been folded into the CVS and should thus appear in the next release of MM (2.1.3?) but for the moment it is applicable to 2.1.2; see: http://sourceforge.net/tracker/ index.php?func=detail&aid=730769&group_id=103&atid=100103
Hello Richard. Thanks for the tip but now I have a new problem (ain't that always the case).
=)
I tried installing the patch but it seemed to have messed up the template parsing (I was suddenly left with unparsed tags such as "%(meta)s" everywhere. I quickly reverted back to the unmodified code but now it appears that this data has been physically cached somewhere so now I have the problem of not being able to clear out the stale cache.
Any idea where this cache is stored? My archives will shortly be useless if I cannot catch this quickly (and a rebuild is nasty, nasty as this is a busy server).
mailmanctl restart after making the code change. The cache is in process memory and is freshly created on demand within each process each time the mailman daemons or scripts are started. You will also need to rebuild existing mail archives using bin/arch to get the revised templates to affect existing HTML archive pages.
Arrrgh.
=)
Cheers
On July 31, 2003 04:03 pm, you wrote:
mailmanctl restart after making the code change. The cache is in process memory and is freshly created on demand within each process each time the mailman daemons or scripts are started. You will also need to rebuild existing mail archives using bin/arch to get the revised templates to affect existing HTML archive pages.
Howdy. Ok, I now understand a bit more as to what is going on. I had forgotten that Mailman is now effectively resident and that these details would be sitting internally in the queue runner process. When stuff lingered around I figured there was a disk cache involved somewhere buried in the code. My bad.
I think that the previous "fix" actually did work but I inadvertently came across a separate issue which obscured the real problem. The mangled template was a separate issue altogether (removing all language files would have made this a moot point anyway).
Here goes. . .
I have edited archtoc.html (as well as the other templates) to give the archive a unified look. After doing so, the archive templates no longer get parsed properly (i.e. none of the placeholders get replaced). Looking at the source, the only immediate candidate is the "%" symbol in some of the table tags (i.e. "width=100%") but I am not clear yet on how the conversions are done. I know that a dictionary is passed to maketext() which is used but what character exactly is screwing up the tag parsing I am unsure.
I have now restored the stock templates while I troubleshoot but does anyone have any tips for trouble shooting a template that no longer parses?
Thanks again for any help you can provide.
Cheers,
Ron
On Friday, August 1, 2003, at 12:36 am, Ron Brogden wrote:
On July 31, 2003 04:03 pm, you wrote:
mailmanctl restart after making the code change. The cache is in process memory and is freshly created on demand within each process each time the mailman daemons or scripts are started. You will also need to rebuild existing mail archives using bin/arch to get the revised templates to affect existing HTML archive pages.
Howdy. Ok, I now understand a bit more as to what is going on. I had forgotten that Mailman is now effectively resident and that these details would be sitting internally in the queue runner process. When stuff lingered around I figured there was a disk cache involved somewhere buried in the code. My bad.
I think that the previous "fix" actually did work but I inadvertently came across a separate issue which obscured the real problem. The mangled template was a separate issue altogether (removing all language files would have made this a moot point anyway).
Here goes. . .
I have edited archtoc.html (as well as the other templates) to give the archive a unified look. After doing so, the archive templates no longer get parsed properly (i.e. none of the placeholders get replaced). Looking at the source, the only immediate candidate is the "%" symbol in some of the table tags (i.e. "width=100%") but I am not clear yet on how the conversions are done. I know that a dictionary is passed to maketext() which is used but what character exactly is screwing up the tag parsing I am unsure.
To get a single % use %%. For example, running python from the command line this fails:
t = '%(fred)s:%(bert)s x="100%"' v = {'fred': 'abc', 'bert': 'xyz'} t % v Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: not enough arguments for format string
but this succeeds:
t = '%(fred)s:%(bert)s x="100%%"' v = {'fred': 'abc', 'bert': 'xyz'} t % v 'abc:xyz x="100%"'
I have now restored the stock templates while I troubleshoot but does anyone have any tips for trouble shooting a template that no longer parses?
Thanks again for any help you can provide.
Cheers,
Ron
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers
Richard Barrett http://www.openinfo.co.uk
On July 31, 2003 04:52 pm, you wrote:
To get a single % use %%. For example, running python from the command Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: not enough arguments for format string
Thanks Richard, that was the ticket. Mailman wasn't recording any errors in the logs and since the template didn't even partially parse I was initially stumped (I was expecting a linear parsing as opposed to the crazy string / array / tuple handling stuff in Python as I am less familiar with that).
Figures that my Python book would be at home the one day I could really use it.
=)
Now all is well, I just have to set aside several hours to rebuild the archives.
Cheers
--
Island Net AMT Solutions Group Inc. Telephone: 250 383-0096 1412 Quadra Street Toll Free: 1 800 331-3055 Victoria, B.C. Fax: 250 383-6698 V8W 2L1 E-Mail: support@islandnet.com Canada WWW: http://www.islandnet.com/
participants (5)
-
Barry Warsaw -
Bill Bradford -
Richard Barrett -
Richard Barrett -
Ron Brogden