[Mailman-Developers] 2.0.14 -> 2.1.5 and pending requests

mjinks at uchicago.edu mjinks at uchicago.edu
Tue Aug 31 01:39:03 CEST 2004


Hi, all.  Just checking to see that I have this right before I expend a
lot of energy cleaning up what I think is a pretty big mess...

Our story so far: we have a list server that was running for years on
Mailman 1.0-rc2, and my mission is to get it up to date.  A couple of
weeks ago, acting on advice from someone on this list (might have been
Barry, actually), we took the system up to the last release of the 2.0
series I could find, which was 2.0.14.  Went okay, mostly.  Now I'd
like to make the jump to the latest.

In testing, bin/update seems to gag on any list with anything in a
request.pck file, like so:

...
Updating mailing list: [whichever]
Updating the held requests database.
Traceback (most recent call last):
  File "/mnt/http-new/opt/pkgs/mailman-2.1.5/bin/update", line 780, in ?
    errors = main()
  File "/mnt/http-new/opt/pkgs/mailman-2.1.5/bin/update", line 670, in
main
    errors = errors + dolist(listname)
  File "/mnt/http-new/opt/pkgs/mailman-2.1.5/bin/update", line 222, in
dolist
    mlist._UpdateRecords()
  File "/mnt/http-new/opt/pkgs/mailman-2.1.5/Mailman/ListAdmin.py", line
533, in _UpdateRecords
    for id, (op, info) in self.__db.items():
ValueError: unpack tuple of wrong size
...


At that point update dies, leaving the named list locked.  So far, lists
with nothing in their request databases seem to get a successful
upgrade.  Lists left locked by the last run are skipped, so we get a
little further each time until I clean up the lock files.

I went a-googling, and didn't find anything that looked like a reference
to this exact problem, but did find this in response to a different
upgrade issue, by Terri Oda in Mailman-Developers on July 30:

	If I recall correctly, Mailman still doesn't always deal gracefully
	with old pending stuff, so you may have to clear out those files
	before doing the upgrade

Ugh: we have, at last count, 2,459 lists.  Many are inactive and could
probably be culled, but even so, there's no way I could go through all
those request files by hand during an acceptable amount of downtime.
Even if I could, they're not my lists; I can't make decisions for the
list owners about administrative requests for their lists, and there's
no way I'll be able to get all the list owners to clean out their
requests without more flowing in.  So if we really do have to have all
the request files empty before an upgrade, there's no way we'll be able
to upgrade.

Have I confused myself?  Is there a better way?

We're running python 2.3.4 on Solaris 9/UltraSPARC.

Thanks,
-j

-- 
Michael Jinks, ENSA, ENSS, VDN, NSIT, The University of Chicago, world
"If the future's not bright, it's colorful." -- Einsturzende Neubauten


More information about the Mailman-Developers mailing list