I found the damn error causing tracebacks in MailList from "ValueError: list.index(x): x not in list."

I was right that it was in the languages section, because that's the only place in MailList we call index. I had to unravel the language support though.

While it's building the options list which will be handed off to the cgi form, it's trying to create the "pretty" names for the languages installed on that list. At line 352 we do

langs = self.GetAvailableLanguages()

(where self is the current MailList). GetAvailableLanguages brute force just walks the directory and looks for subdirs, by calling Utils.GetDirectories(self._full_path). If there's a subdir, it's a language. (Which means don't be creating subdirs under lists; mailman will think you've added a new language. I'm thinking the template dir should be listname/templates/language so as to avoid confusion...)

If there are no subdirs, then there are no languages. langs is set to [].

at line 381, in the monolithic setting of the config_info['general'] block, we have:

('preferred_language', mm_cfg.Select, (langs, map(_, map(Utils.GetLanguageDescr, langs)), langs.index(self.preferred_language)), 0, _("Default language for this list."), _("All messages not related to an specific user will be displayed in this language.")),

Since self.preferred_language is forced to en on every new list, when we do the langs.index(self.preferred_language), in this scenario, well, gosh, taking an index of something not in the list is bad, since we're doing nothing to catch any possible exceptions...

So the short term workaround, for me, is to make sure all the lists have en installed. Ideally the code needs to cope with a missing language cleanly. This, I guess, makes it more important for the update proc to forcibly install *something* in a new en directory for any list that doesn't have one.

-Ron