Patches item #651406, was opened at 2002-12-10 07:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=651406&group_id=103

Category: None Group: Mailman 2.1

Status: Closed Resolution: None Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: MM 2.0.13 to 2.1b5 upgrade fails

Initial Comment: make install when updating a MM 2.0.13 installation to 2.1b5 initally produced the following exception:

Updating mailing list: mailman Traceback (most recent call last): File "bin/update", line 569, in ? errors = main() File "bin/update", line 446, in main errors = errors + dolist(listname) File "bin/update", line 186, in dolist mlist = MailList.MailList(listname, lock=0) File "/mailman/run/Mailman/MailList.py", line 101, in __init__ self.Load() File "/mailman/run/Mailman/MailList.py", line 600, in Load self.CheckValues() File "/mailman/run/Mailman/MailList.py", line 650, in CheckValues for name, pattern, desc, emptyflag in self.topics: File "/mailman/run/Mailman/MailList.py", line 130, in __getattr__ raise AttributeError, name AttributeError: topics make: *** [update] Error 1

Having corrected the cause of this first exception the following exception was then encountered:

Upgrading from version 0x2000df0 to 0x20100b5 getting rid of old source files Updating mailing list: mailman Traceback (most recent call last): File "bin/update", line 569, in ? errors = main() File "bin/update", line 446, in main errors = errors + dolist(listname) File "bin/update", line 200, in dolist for addr, (reason, when) in mlist.delivery_status.items (): File "/mailman/run/Mailman/MailList.py", line 130, in __getattr__ raise AttributeError, name AttributeError: delivery_status make: *** [update] Error 1

These problems both seem to arise because of the following:

1. The MailList class is derived from the classes TopicMgr and Bouncer (amongst others).

2. The MailList __init__ function calls the __init__ functions of its superclasses if they have that function; which they do not in the case of the of TopicMgr and Bouncer classes

3. The MailList __init__ function calls its own InitTempVars function which in turn calls the InitTempVars functions of MailList's superclasses if they have that function; which they do not in the case of the of class TopicMgr and Bouncer classes

4. The MailList __init__ function does not call the InitVars functions of the TopicMgr and Bouncer classes which is why self.topics and self.delivery_status are undefined attributes of the MailList instance being created; these being instance variables introduced by MM 2.1b5 and missing from MM 2.0.13 instance of the MailList class which is what is being dealt with at the time the update is being done.

Adding the following definition to the TopicMgr and Bouncer class definitions seem to clear the problem although whether this is the best log-tem solution is questionable:

InitTempVars = InitVars

Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-23 22:14

Message: Logged In: YES user_id=12800

I'm closing this one since I've added language to the UPGRADING file alerting people to this (although I suspect the Pinball Machine Rule will apply).

Thanks for figuring this one out.

Comment By: Richard Barrett (ppsys) Date: 2002-12-11 07:19

Message: Logged In: YES user_id=75166

patch revised for MM 2.1b6 and better documented internally

Comment By: Richard Barrett (ppsys) Date: 2002-12-10 09:19

Message: Logged In: YES user_id=75166

The problem is a by product of the 413752 (coerce to plaintext) patch for MM 2.0.13 (mailman-2.0.13-plaintext- 0.17.patch) which had been applied to the existing system

Patch 413752 for MM 2.0.13 changes Version.py as follows:

# config.db schema version number -DATA_FILE_VERSION = 21 +DATA_FILE_VERSION = (21, 'plaintext_patch')

In MM 2.1b5 Version.py

DATA_FILE_VERSION = 88

In the CheckVersion member function of the MailList class the following comparison succeeds, i.e. the existing data structure is seen as being a later revision than MM 2.1b5, when patch 413752 has been applied:

    if self.data_version >= mm_cfg.DATA_FILE_VERSION:

and the CheckVersion function returns without calling the InitVars function to preset the instance variables to the defaults before loading the pickled data values for an existing list.

Changing the comparisom to this solves the problem:

    if (type(self.data_version) is type

(mm_cfg.DATA_FILE_VERSION) and
self.data_version >= mm_cfg.DATA_FILE_VERSION) or
(type(self.data_version) is type(()) and
self.data_version[0] >= mm_cfg.DATA_FILE_VERSION):

Comment By: Richard Barrett (ppsys) Date: 2002-12-10 08:13

Message: Logged In: YES user_id=75166

I was wrong about my hack working because on using the web admin GUI to update lists I got the error feedback given below.

The problem seems to be more deep seated in that the InitVars function of the MailList class does not seem to get called to initialse the MailList instance variables when loading an existing list via the __init__ function but only through the Create member function called from newlist and cgi create.py.

At first blush I would think that MailList InitVars function should be called from the class' __init__ function before loading an existing instance's data into the instance variables; but with three functions initialisation functions, __init__, InitTempVars and InitVars, I'm getting confused as to which are supposed to do what and when.

Bug in Mailman version 2.1b5

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 "/mailman/run/scripts/driver", line 87, in run_main main() File "/mailman/run/Mailman/Cgi/admin.py", line 76, in main i18n.set_language(mlist.preferred_language) File "/mailman/run/Mailman/MailList.py", line 130, in __getattr__ raise AttributeError, name AttributeError: preferred_language

You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=651406&group_id=103