It appears that the new server is running 2.1.10 or later with the "sibling lists" feature, and the old server from which the lists were moved did not have this feature, so the lists did not have the corresponding regular_exclude_lists and regular_include_lists attributes.

However, that doesn't explain what is happening, because the first time the moved list is instantiated on the new server, Mailman should detect that the list's data_version is less than the installation's DATA_FILE_VERSION and update the list's attributes. So, the question is why didn't this happen, or if it did, why weren't the regular_exclude_lists and regular_include_lists attributes added?

Did the old installation have patches that increased it's DATA_FILE_VERSION?

Ah, of course, I completely forgot about that! Yes, I had applied this patch as you recommended when I installed the old version back in 2007:

http://sourceforge.net/tracker/index.php?func=detail&aid=403066&group_id=103&atid=350103

You mentioned at the time that the functionality provided by the patch (to auto-allow subscribers from certain domains, while everyone else still requires approval) will be provided in a future release:

http://www.mail-archive.com/mailman-users@python.org/msg45982.html

However I can't find the option in the current Mailman release. Do you know if it has been added or can I apply this patch again?

Many thanks, Adam.

It has been implemented on the 2.2 branch which is not yet released, so yes, you need to apply the patch to 2.1.12 if you need the functionality.

Also, rather than incrementing Version.DATA_FILE_VERSION further and setting yourself up for this kind of problem again, you could leave it at 97 and run the following (after applying the auto approval patch) to make sure all lists get updated

#!/bin/sh f=mktemp echo "mlist.data_version = 96" >$f for list in /path/to/bin/list_lists --bare; do /path/to/bin/config_list -i $f $list done rm $f

Excellent, I applied the patch (had to do some bits manually because of indentation changes), ran your script and now everything's working perfectly!

Many thanks for your help!

Cheers, Adam.

Adam Nielsen wrote:

...

...

Also, rather than incrementing Version.DATA_FILE_VERSION further and setting yourself up for this kind of problem again, you could leave it at 97 and run the following (after applying the auto approval patch) to make sure all lists get updated

#!/bin/sh f=mktemp echo "mlist.data_version = 96" >$f for list in /path/to/bin/list_lists --bare; do /path/to/bin/config_list -i $f $list done rm $f

Excellent, I applied the patch (had to do some bits manually because of indentation changes), ran your script and now everything's working perfectly!

And I have now upgraded Mailman again to 2.1.13 and reapplied the auto-approval patch, however I am not sure whether I need to do anything with version numbers. Since the data_version was 97 before the patch, and now there's new configuration values, should I run the above code or not? It looks like the code resets the version back to an old number, so presumably Mailman upgrades the list when it next accesses it, but because the list is already at 97 I'm worried that if I reset it back to 96 I might lose some data.

Can anyone let me know what (if anything) I need to do?

The short answer is you need to run config_list with the "mlist.data_version = 96" input on only those lists which you created with Mailman 2.1.13 before you applied the patch. Probably this is no lists so you don't need to do anything.

The long answer is the patch adds a new list attribute subscribe_auto_approval. Lists created without the patch do not have this attribute, and this will cause exceptions when the attribute is referenced by the patched code.

Mailman has a mechanism for updating old list configurationson the fly and adding missing attributes and in cases like upgrading 2.0 to 2.1 even refactoring old attributes into new ones. This mechanism is triggered by the list's data_version being less than the current schema. So setting the data_version of a list to 96 when the current schema is 97 will cause Mailman to invoke the versions.py updating process on the list the next time it is loaded.

In your case, this will do no harm, but it isn't necessary unless you have a list or lists that were created without the patch and not previously updated.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan