Upgrade script broke (not the first time).
from Mailman import MailList from Mailman.LockFile import TimeOutError from Mailman.i18n import _
I'm getting error:
Traceback (most recent call last): File "/usr/lib/mailman/bin/update", line 51, in ? from Mailman.i18n import _ ImportError: No module named i18n
It doesn't balk on the line before, so it doesn't seem to be a path issue.
When I comment that line out (for grins), it balks on:
from Mailman.Queue.Switchboard import Switchboard from Mailman import OldStyleMemberships from Mailman.MemberAdaptor import BYBOUNCE, ENABLED
Any clues?
-- _Deirdre http://deirdre.net "Cannot run out of time. There is infinite time. You are finite. Zathras is finite. This....is wrong tool." -- Zathras
In this message
http://mail.python.org/pipermail/mailman-users/2003-June/029660.html
Deirdre Saoirse Moen described a problem upgrade she had while upgrading Mailman on a Debian GNU/Linux system. We just encountered the same problem, when we tried to do
# apt-get install mailman
to go from MM 2.0.8 to 2.1.5-4. We eventually solved it, though it required some local klugery. We do not claim the solution below is elegant :-), but anyway Mailman 2.1.5 is working now. In case it helps anyone, here is what we did...
Details:
In MM 2.0.8 under Debian, virtually all of Mailman lived under /var/lib/mailman/.
In MM 2.1.5, it seems that static data (scripts, templates, etc) lives under /usr/lib/mailman/, and dynamic data under /var/lib/mailman/. (Benjamin "Mako" Hill, a Debian developer, confirmed in IRC that this is the standard way things are done these days.)
However, due to some Pythonvironmental weirdness, the scripts under /usr/lib/mailman/bin/ were still trying to import from the old /var/lib/mailman/Mailman/ directory, instead of from the new /usr/lib/mailman/Mailman/ directory.
We still don't know why the Python import paths were messed up. Our solution was simply to take every directory under /var/lib/mailman/ that has the same name as a directory under /usr/lib/mailman/, and make the former a symlink to the latter. Thus:
# cd /var/lib/mailman # for name in Mailman bin cron mail scripts do mv ${name} old-${name} ln -s /usr/lib/mailman/${name} . done #
(That's not an actual transcript, but you get the idea.)
The result looks like this:
# cd /var/lib/mailman # ls -l total 664 [...] Mailman -> /usr/lib/mailman/Mailman [...] archives [...] bin -> /usr/lib/mailman/bin [...] cgi-bin -> /usr/lib/cgi-bin/mailman [...] cron -> /usr/lib/mailman/cron [...] data [...] filters [...] icons [...] lists [...] locks [...] logs -> ../../log/mailman [...] mail -> /usr/lib/mailman/mail [...] mailman [...] messages [...] old-Mailman [...] old-bin [...] old-cron [...] old-mail [...] old-scripts [...] qfiles [...] scripts -> /usr/lib/mailman/scripts [...] spam [...] templates [...] tests #
Currently, "apt-get install mailman" works fine (it's basically a no-op, but the point is that all the post-install configuration stuff runs smoothly). Brian and I expect future 'apt-get install mailman' invocations to work as well, based on what apt-get seems to be trying to do. But who knows, we could be wrong :-).
Best, -Karl Fogel and Brian Fitzpatrick
kfogel {+at-sign+} red-bean.com fitz {+at-sign+} red-bean.com
Two things I left out of this previous message:
http://mail.python.org/pipermail/mailman-users/2005-January/041687.html
We fixed an apparent coding error in /usr/lib/mailman/bin/update. On line 556, we changed "addr = data[0].address" to "addr = data[0]", since data[0] was already an address string, not a list.
Further conversation with a Mailman expert (in irc.freenode.net channel #mailman) revealed that our allegedly non-elegant solution was actually what apt-get should have done anyway -- the symlinks we made are standard on a healthy Debian system. IRC transcript follows, just for reference.
--------------------8-<-------cut-here---------8-<-----------------------
<kfogel> http://mail.python.org/pipermail/mailman-users/2005-January/041687.html <kfogel> horrific details of our upgrade are at that url <kfogel> we did eventually get it working, and the new version (2.1.5) looks spiffy. <kfogel> I like the new moderation stuff. <Jim7J1AJH> Sounds like your upgrade didn't make all the symbolic links. <kfogel> Jim7J1AJH: I'm not sure what 'apt-get install mailman' was supposed to do in detail, but yeah, that seems like a fair assertion. <Jim7J1AJH> On the one Debian machine that I use Mailman on, /var/lib/mailman has several symlinks into the /usr/lib/mailman tree... where all the code lives. <kfogel> oh <kfogel> So we're not the only ones to have gone this route... <Jim7J1AJH> It is the "Debian" standard. <kfogel> IOW, we just manually reproduced what apt-get is supposed to do anyway? <kfogel> Great. <kfogel> At least that means future upgrades are likely to work. <Jim7J1AJH> Sounds like it. <Jim7J1AJH> Yup. <kfogel> If you want to post to that effect in response to my post, somebody somewhere a year from now would probably save 40 minutes of time. <kfogel> Your call :-). <Jim7J1AJH> /var/lib/mailman's Mailman, bin, cgi-bin, mail, and scripts all symlink into /usr/lib/mailman. <kfogel> heh! <kfogel> So, we linked cron, and we didn't link cgi-bin. <kfogel> Two points of difference.
- kfogel goes to link cgi-bin <Jim7J1AJH> Oops... yes, cron too. <Jim7J1AJH> You're right. <Jim7J1AJH> lrwxrwxrwx 1 root root 24 Nov 22 02:44 cgi-bin -> /usr/lib/cgi-bin/mailman <kfogel> Ah. <Jim7J1AJH> l <Jim7J1AJH> and one bit of Debian policy I find really goofy, they do: <Jim7J1AJH> lrwxrwxrwx 1 root root 12 Nov 22 02:44 templates -> /etc/mailman <kfogel> There is no /usr/lib/mailman/cgi-bin, but there is a /usr/lib/cgi-bin/mailman <kfogel> just as you said <kfogel> oy oy
- kfogel 's head spins with symlinks <Jim7J1AJH> Yes. One has to wonder what the packager was thinking. <Jim7J1AJH> That and leaving the 'cgi-bin' in the default URLs seems bogus to me. <Jim7J1AJH> They also do: <Jim7J1AJH> lrwxrwxrwx 1 root root 25 Nov 22 02:44 icons -> /usr/share/images/mailman <kfogel> AAAAAH <kfogel> good <kfogel> /var/lib/mailman/cgi-bin was already a link to the right place, we didn't have to do it. <Jim7J1AJH> lrwxrwxrwx 1 root root 18 Nov 22 02:44 locks -> ../../lock/mailman <Jim7J1AJH> lrwxrwxrwx 1 root root 17 Nov 22 02:44 logs -> ../../log/mailman <kfogel> huh <kfogel> locks is not a symlink for us <kfogel> but logs is, and in the way you describe <kfogel> I'm going to fix locks <kfogel> Leaving templates alone though. <Jim7J1AJH> They also put a symlink so that mm_cfg.py really lives in /etc/mailman <Jim7J1AJH> instead of in /usr/lib/mailman/Mailman <kfogel> goodness <kfogel> I'm sure there were Good Reasons for all of these decisions. <kfogel> But it sure makes debugging tough. <Jim7J1AJH> One would hope so. <Jim7J1AJH> Or answering people's questions when they show up using the Debian package. <kfogel> :-)
participants (2)
-
Deirdre Saoirse Moen -
Karl Fogel