Warnings from senddigests
I've just installed Mailman version 2.1.11.
In general, it works fine.
Whenever my mailman cron job runs senddigests, I get the following warnings (on stdout or stderr, mailed to me by cron):
/home/mailman/Mailman/Handlers/Scrubber.py:192: DeprecationWarning: get_type() deprecated; use get_content_type() ctype = part.get_type(part.get_default_type()) /home/mailman/Mailman/Handlers/Scrubber.py:303: DeprecationWarning: get_type() deprecated; use get_content_type() ctype = part.get_type() List: jdtest: problem processing /home/mailman/lists/jdtest/digest.mbox: iso-8859-15
The first two sounds like very minor problems in Scrubber.py.
I wonder about the last one. My test list does have messages in ISO 8815-15 (that is the character set my mail client uses for a message containing the Euro sign - at least if it also contains the Danish non-usascii letters).
I currently have to digest subscribers, so I don't know if this a real problem. Does Mailman perhaps simply not support ISO 8859-15?
Jesper Dybdal, Denmark. http://www.dybdal.dk (in Danish).
Jesper Dybdal wrote:
I've just installed Mailman version 2.1.11.
In general, it works fine.
Given the below, I'm surprised.
Whenever my mailman cron job runs senddigests, I get the following warnings (on stdout or stderr, mailed to me by cron):
/home/mailman/Mailman/Handlers/Scrubber.py:192: DeprecationWarning: get_type() deprecated; use get_content_type() ctype = part.get_type(part.get_default_type()) /home/mailman/Mailman/Handlers/Scrubber.py:303: DeprecationWarning: get_type() deprecated; use get_content_type() ctype = part.get_type() List: jdtest: problem processing /home/mailman/lists/jdtest/digest.mbox: iso-8859-15
The first two sounds like very minor problems in Scrubber.py.
Mailman 2.1.11 is not compatible with Python 2.6. Most of the errors are deprecation warnings similar to those above and also involving hashlib. You'll probably find lots more in Mailman's error log.
There are however more serious problems involving string exceptions and also incompatibilites in the email package. I'm surprised it works at all, unless this is a package that doesn't install email 2.5.8 in Mailman's pythonlib.
I wonder about the last one. My test list does have messages in ISO 8815-15 (that is the character set my mail client uses for a message containing the Euro sign - at least if it also contains the Danish non-usascii letters).
I currently have to digest subscribers, so I don't know if this a real problem. Does Mailman perhaps simply not support ISO 8859-15?
Mailman supports any character set supported by the underlying Python and should not have any problems with iso-8859-15, The error message you get from senddigests is not too informative. All it says is that something in the send digest processing for the jdtest list threw an exception and the error message from the exception was 'iso-8859-15'. Thus it's pretty hard to diagnose, but you need to address the Python incompatibility first anyway, and that may solve the other problem.
If you installed from source, you can rerun configure with --with-python pointing to a Python 2.4 or 2.5 and make install, or you can get the current 2.1 branch from Launchpad (bzr branch lp:mailman/stable) which is Python 2.6 compatible and install that (there will be a 2.1.12 release soon).
If you installed from a package and don't want to upgrade to the latest 2.1 source from Launchpad, you will have to do whatever is necessary to make your package use an older Python.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Sat, 03 Jan 2009 00:51:33 +0100, I wrote:
I currently have to digest subscribers, so I don't know if this a real problem.
That should have been "*no* digest subscribers" - sorry.
On Sat, 3 Jan 2009 08:51:10 -0800, Mark Sapiro <mark@msapiro.net> wrote:
Mailman 2.1.11 is not compatible with Python 2.6. Most of the errors are deprecation warnings similar to those above and also involving hashlib. You'll probably find lots more in Mailman's error log.
Now I'm confused. Why do you think I am using Python 2.6?
I am actually using Python 2.4.5 (installed using the Slackware 11.0 Python package):
jesper@nuser:~$ python -V Python 2.4.5
And yes, there are quite a few of those warnings in the error log. Mailman seems to work in general, but I haven't tried digests - which probably do not work, given the error message.
But everything I've read seems to indicate that Python 2.4.5 should be fine for Mailman.
I've installed Mailman straight from the 2.1.11 distribution, except for a Postfix VERP patch and some file rights changes to make it run with suexec.
It runs on a Slackware 11.0 Linux with some packages upgraded from source or from Slackware upgrades. The kernel is Linux 2.6.26.2.
Jesper Dybdal, Denmark. http://www.dybdal.dk (in Danish).
Jesper Dybdal wrote:
On Sat, 3 Jan 2009 08:51:10 -0800, Mark Sapiro <mark@msapiro.net> wrote:
Mailman 2.1.11 is not compatible with Python 2.6. Most of the errors are deprecation warnings similar to those above and also involving hashlib. You'll probably find lots more in Mailman's error log.
Now I'm confused. Why do you think I am using Python 2.6?
I am actually using Python 2.4.5 (installed using the Slackware 11.0 Python package):
jesper@nuser:~$ python -V Python 2.4.5
And yes, there are quite a few of those warnings in the error log. Mailman seems to work in general, but I haven't tried digests - which probably do not work, given the error message.
I'm not sure about the digests problem. You could try 'bin/withlist -i' and then at the >>> prompt type
unicode('abcde', 'iso-8859-15')
if this prints
u'abcde'
Mailman is able to access the iso-8859-15 codecs and there should be no problem with iso-8859-15. If it prints
LookupError: unknown encoding: iso-8859-15
There is an issue, and you could try the same test with 'python' instead of 'bin/withlist -i' to see if it's Mailman specific or a Python problem.
(In either case, type control-D to the next >>> prompt to exit.)
But everything I've read seems to indicate that Python 2.4.5 should be fine for Mailman.
Yes. That's correct.
I've installed Mailman straight from the 2.1.11 distribution, except for a Postfix VERP patch and some file rights changes to make it run with suexec.
It runs on a Slackware 11.0 Linux with some packages upgraded from source or from Slackware upgrades. The kernel is Linux 2.6.26.2.
Sorry. I jumped to an unwarranted assumption. I thought the deprecation warnings were from Python 2.6. Actually they probably come from the Python 2.4.5 email package which would indicate that for some reason, either the email 2.5.8 package that comes with Mailman 2.1.11 did not get installed in Mailman's pythonlib directory or for some reason, the paths.py module in Mailman's bin, cron and scripts directories is not inserting the correct path to pythonlib in sys.path.
Is there a pythonlib directory in Mailman's "prefix" directory and does it contain an 'email' subdirectory?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Sat, 3 Jan 2009 10:19:17 -0800, Mark Sapiro <mark@msapiro.net> wrote:
I'm not sure about the digests problem. You could try 'bin/withlist -i' and then at the >>> prompt type
unicode('abcde', 'iso-8859-15')
if this prints
u'abcde'
Mailman is able to access the iso-8859-15 codecs and there should be no problem with iso-8859-15.
It does print "u'abcde'". Good!
I thought the deprecation warnings were from Python 2.6. Actually they probably come from the Python 2.4.5 email package which would indicate that for some reason, either the email 2.5.8 package that comes with Mailman 2.1.11 did not get installed in Mailman's pythonlib directory or for some reason, the paths.py module in Mailman's bin, cron and scripts directories is not inserting the correct path to pythonlib in sys.path.
Is there a pythonlib directory in Mailman's "prefix" directory and does it contain an 'email' subdirectory?
I think you've diagnosed the problem. There is a pythonlib directory, but it is empty.
I built Mailman as user "root" (knowing perfectly well that this is not the thing to do unless you choose to trust your software providers), but I ran "make install" as user "mailman" in order to ensure that the resulting files would have the correct owner.
I'll have a further look at the install procedure, but if you have any idea how it could have failed, I'd really like to hear about it.
Jesper Dybdal, Denmark. http://www.dybdal.dk (in Danish).
Jesper Dybdal wrote:
I think you've diagnosed the problem. There is a pythonlib directory, but it is empty.
I built Mailman as user "root" (knowing perfectly well that this is not the thing to do unless you choose to trust your software providers), but I ran "make install" as user "mailman" in order to ensure that the resulting files would have the correct owner.
This is backwards from the normal installation. It doesn't matter what user does the configure (and make if you did both make and make install), but normally, make install is run as root. Root ends up owning most everything this way, but that doesn't matter as all the directories are SETGID and everything ends up in the 'mailman' group which is what counts.
I'll have a further look at the install procedure, but if you have any idea how it could have failed, I'd really like to hear about it.
Try to cd to the misc/ subdirectory of the directory that you unpacked and configured in and run
make install-packages
in that directory. Note that depending on your exact C compiler, it is possible to get thousands of warnings similar to
src/_koco_uhc.h:3007: warning: pointer targets in initialization differ in signedness.
These are harmless, but for this reason, it is a good idea to do something like
make install-packages 2>make.error.log
so you can sift through the error output and find any errors that might otherwise be lost amongst those warnings.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Sat, 3 Jan 2009 16:48:40 -0800, Mark Sapiro <mark@msapiro.net> wrote:
Try to cd to the misc/ subdirectory of the directory that you unpacked and configured in and run
make install-packages
Problem found and solved: I had run "make" as root, but "make install" as "mailman", and "make install-packages", which I assume is part of "make install", needs to be able to write to files in the source directory structure where "make" was run.
I had naively assumed that "make install" did nothing but copy existing files.
Running "make install-packages" as root solved the problem.
And in the future, I'll run "make install" as root.
Thanks for your help!
Jesper Dybdal, Denmark. http://www.dybdal.dk (in Danish).
Jesper Dybdal wrote:
Problem found and solved:
Good!
It is still not clear to me if this will also fix the
List: jdtest: problem processing /home/mailman/lists/jdtest/digest.mbox: iso-8859-15
issue. It may or may not. You can try running
cron/senddigests -l jdtest
manually as the mailman user to see if it's fixed. If it's not, we can try to figure out what's causing it.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Sun, 4 Jan 2009 08:43:31 -0800, Mark Sapiro <mark@msapiro.net> wrote:
It is still not clear to me if this will also fix the
List: jdtest: problem processing /home/mailman/lists/jdtest/digest.mbox: iso-8859-15
issue. It may or may not. You can try running
cron/senddigests -l jdtest
manually as the mailman user to see if it's fixed.
Sorry - I forgot to mention that I had run senddigests (exactly as cron does - there are as yet no real users of any list, so testing is easy): it gave no warnings and it did send a digest to a subscriber that I had set to receive digests.
The only strange thing I now notice is that even if the digest consists of messages that were all originally in iso-8859-1 encoding, the digest is in usascii, with question marks substituted for non-usascii characters. Is it necessary to use MIME digests in order to get non-usascii characters correct?
Otherwise, everything seems to be fine.
Again, thanks for your help. (I don't quite understand how I've been able to overlook the error messages from the original failing pythonlib installation attempt, but I must obviously somehow have overlooked them.)
Jesper Dybdal, Denmark. http://www.dybdal.dk (in Danish).
Jesper Dybdal wrote:
The only strange thing I now notice is that even if the digest consists of messages that were all originally in iso-8859-1 encoding, the digest is in usascii, with question marks substituted for non-usascii characters. Is it necessary to use MIME digests in order to get non-usascii characters correct?
The digests are prepared in the list's preferred language. This affects which masthead.txt template is used and the translation of i18n strings.
It also affects the character set used for the plain format digest which is 'us-ascii' if the list's preferred language is English. If the list's preferred language is Danish, the character set used will be iso-8859-1, but of course all the non-message text will be Danish too.
As you suggest, the messages in the MIME format digest are in their original character sets, so this is not an issue there.
It is possible to change the character set for English to iso-8859-1, by putting
add_language('en', 'English (USA)', 'iso-8859-1', 'ltr')
in mm_cfg.py. As far as I know, no problems result from doing this.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
Jesper Dybdal -
Mark Sapiro