FAQ
Hello, I'm getting errors like the following when executing some of
the scripts in the bin directory. Any ideas?

mailman/bin# ./list_lists
Traceback (most recent call last):
File "./list_lists", line 122, in ?
main()
File "./list_lists", line 102, in main
longest = max(len(mlist.real_name), longest)
File "/usr/local/mailman/Mailman/MailList.py", line 144, in __getattr__
raise AttributeError, name
AttributeError: real_name

Thanks

Search Discussions

  • Brad Knowles at Feb 12, 2005 at 11:47 am

    At 3:33 AM -0800 2005-02-12, Mark Panahi wrote:

    Hello, I'm getting errors like the following when executing some of
    the scripts in the bin directory. Any ideas?
    Hmm. What version of Python do you have installed? What version
    of Mailman are you running?

    --
    Brad Knowles, <brad at stop.mail-abuse.org>

    "Those who would give up essential Liberty, to purchase a little
    temporary Safety, deserve neither Liberty nor Safety."

    -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
    Assembly to the Governor, November 11, 1755

    SAGE member since 1995. See <http://www.sage.org/> for more info.
  • Mark Panahi at Feb 12, 2005 at 11:52 am
    mailman 2.1.5, python 2.3.4

    Thanks.

    On Sat, 12 Feb 2005 12:47:40 +0100, Brad Knowles
    wrote:
    At 3:33 AM -0800 2005-02-12, Mark Panahi wrote:

    Hello, I'm getting errors like the following when executing some of
    the scripts in the bin directory. Any ideas?
    Hmm. What version of Python do you have installed? What version
    of Mailman are you running?

    --
    Brad Knowles, <brad at stop.mail-abuse.org>

    "Those who would give up essential Liberty, to purchase a little
    temporary Safety, deserve neither Liberty nor Safety."

    -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
    Assembly to the Governor, November 11, 1755

    SAGE member since 1995. See <http://www.sage.org/> for more info.
  • Mark Sapiro at Feb 12, 2005 at 5:32 pm

    Mark Panahi wrote:
    Hello, I'm getting errors like the following when executing some of
    the scripts in the bin directory. Any ideas?

    mailman/bin# ./list_lists
    Traceback (most recent call last):
    File "./list_lists", line 122, in ?
    main()
    File "./list_lists", line 102, in main
    longest = max(len(mlist.real_name), longest)
    File "/usr/local/mailman/Mailman/MailList.py", line 144, in __getattr__
    raise AttributeError, name
    AttributeError: real_name
    My best guess is some list has a corrupted config.pck.

    bin/checkdb --all

    may find it, but it may not. You could try patching list_lists as
    follows to find the offending list:

    --- bin/list_lists 2005-02-06 14:27:16.593750000 -0800
    +++ bin/list_lists.test 2005-02-12 09:09:11.578125000 -0800
    @@ -99,7 +99,10 @@
    mlist.web_page_url.find(vhost) == -1:
    continue
    mlists.append(mlist)
    - longest = max(len(mlist.real_name), longest)
    + try:
    + longest = max(len(mlist.real_name), longest)
    + except:
    + print 'mlist.real_name exception', n

    if not mlists and not bare:
    print _('No matching mailing lists found')


    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Panahi at Feb 12, 2005 at 11:27 pm
    Well, I tried 'check_db -a -v' and it complains that there are no
    config.pck and config.pck.last files for each list. The thing is, I
    had moved the lists and archive directories from an older installation
    (we had upgraded everything in our server). Seems like these pck files
    are something recent? Anyway to create these? Hmmm, I suppose we
    didn't upgrade properly.

    The "version" command on the old installation doesn't work, but I
    think it was abt 5 years old.

    Thanks,

    Mark

    On Sat, 12 Feb 2005 09:32:43 -0800, Mark Sapiro wrote:
    Mark Panahi wrote:
    Hello, I'm getting errors like the following when executing some of
    the scripts in the bin directory. Any ideas?

    mailman/bin# ./list_lists
    Traceback (most recent call last):
    File "./list_lists", line 122, in ?
    main()
    File "./list_lists", line 102, in main
    longest = max(len(mlist.real_name), longest)
    File "/usr/local/mailman/Mailman/MailList.py", line 144, in __getattr__
    raise AttributeError, name
    AttributeError: real_name
    My best guess is some list has a corrupted config.pck.

    bin/checkdb --all

    may find it, but it may not. You could try patching list_lists as
    follows to find the offending list:

    --- bin/list_lists 2005-02-06 14:27:16.593750000 -0800
    +++ bin/list_lists.test 2005-02-12 09:09:11.578125000 -0800
    @@ -99,7 +99,10 @@
    mlist.web_page_url.find(vhost) == -1:
    continue
    mlists.append(mlist)
    - longest = max(len(mlist.real_name), longest)
    + try:
    + longest = max(len(mlist.real_name), longest)
    + except:
    + print 'mlist.real_name exception', n

    if not mlists and not bare:
    print _('No matching mailing lists found')

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Sapiro at Feb 13, 2005 at 12:08 am

    Mark Panahi wrote:
    Well, I tried 'check_db -a -v' and it complains that there are no
    config.pck and config.pck.last files for each list. The thing is, I
    had moved the lists and archive directories from an older installation
    (we had upgraded everything in our server). Seems like these pck files
    are something recent? Anyway to create these? Hmmm, I suppose we
    didn't upgrade properly.
    So presumably you have config.db and config.db.last files instead. This
    change occurred with 2.0.x to 2.1.x.

    Also, for any list whose configuration has been locked, loaded, saved
    and unlocked, there should be a config.pck because 2.1.x versions
    always save the list as a pickle, not a marshall.

    If you upgrade Mailman on an existing installation, the actual
    configuration data will normally be updated by bin/update which will
    be run by "make install"

    In your case, where you moved the config files from another, older
    installation, I think you may need to run bin/update manually,
    although there are reports that seem to indicate this isn't necessary.
    If you do run it, you will probably need the "-f" option to make it do
    anything, and you should back up everything first.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Panahi at Feb 13, 2005 at 12:55 am
    Well I get this:

    doc local/mailman# bin/update -f
    Upgrading from version 0x20105f0 to 0x20105f0
    getting rid of old source files
    Updating mailing list: birn
    Traceback (most recent call last):
    File "bin/update", line 780, in ?
    errors = main()
    File "bin/update", line 670, in main
    errors = errors + dolist(listname)
    File "bin/update", line 206, in dolist
    for addr, (reason, when) in mlist.delivery_status.items():
    File "/usr/local/mailman/Mailman/MailList.py", line 144, in __getattr__
    raise AttributeError, name
    AttributeError: delivery_status

    Seems like it needs to know that the old lists are from a previous
    version. Any way I can indicate this?

    On Sat, 12 Feb 2005 16:08:49 -0800, Mark Sapiro wrote:
    Mark Panahi wrote:
    Well, I tried 'check_db -a -v' and it complains that there are no
    config.pck and config.pck.last files for each list. The thing is, I
    had moved the lists and archive directories from an older installation
    (we had upgraded everything in our server). Seems like these pck files
    are something recent? Anyway to create these? Hmmm, I suppose we
    didn't upgrade properly.
    So presumably you have config.db and config.db.last files instead. This
    change occurred with 2.0.x to 2.1.x.

    Also, for any list whose configuration has been locked, loaded, saved
    and unlocked, there should be a config.pck because 2.1.x versions
    always save the list as a pickle, not a marshall.

    If you upgrade Mailman on an existing installation, the actual
    configuration data will normally be updated by bin/update which will
    be run by "make install"

    In your case, where you moved the config files from another, older
    installation, I think you may need to run bin/update manually,
    although there are reports that seem to indicate this isn't necessary.
    If you do run it, you will probably need the "-f" option to make it do
    anything, and you should back up everything first.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Sapiro at Feb 13, 2005 at 1:45 am

    Mark Panahi wrote:
    Well I get this:

    doc local/mailman# bin/update -f
    Upgrading from version 0x20105f0 to 0x20105f0
    getting rid of old source files
    Updating mailing list: birn
    Traceback (most recent call last):
    File "bin/update", line 780, in ?
    errors = main()
    File "bin/update", line 670, in main
    errors = errors + dolist(listname)
    File "bin/update", line 206, in dolist
    for addr, (reason, when) in mlist.delivery_status.items():
    File "/usr/local/mailman/Mailman/MailList.py", line 144, in __getattr__
    raise AttributeError, name
    AttributeError: delivery_status

    Seems like it needs to know that the old lists are from a previous
    version. Any way I can indicate this?

    I don't think it needs to know. The -f option told it to process the
    lists and it is trying, but it can't.

    I think there is something wrong with the config for at least the
    'birn' list. Try running bin/dumpdb against the config.db and/or
    config.pck file(s) for this list and comparing what attributes (names,
    not necessarily values) are dumped with those from a "good" list. We
    know bin/list_lists complained about real_name (probably not existing)
    for some list, and bin/update is complaining similarly about
    delivery_status for this list. Note that output from bin/dumpdb can be
    quite large if a list has many members.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Panahi at Feb 13, 2005 at 2:09 am
    Well, now I get this:

    doc local/mailman# bin/dumpdb lists/birn/config.db
    Traceback (most recent call last):
    File "bin/dumpdb", line 156, in ?
    msg = main()
    File "bin/dumpdb", line 126, in main
    d = DumperSwitchboard().read(filename)
    NameError: global name 'DumperSwitchboard' is not defined


    On Sat, 12 Feb 2005 17:45:40 -0800, Mark Sapiro wrote:
    Mark Panahi wrote:
    Well I get this:

    doc local/mailman# bin/update -f
    Upgrading from version 0x20105f0 to 0x20105f0
    getting rid of old source files
    Updating mailing list: birn
    Traceback (most recent call last):
    File "bin/update", line 780, in ?
    errors = main()
    File "bin/update", line 670, in main
    errors = errors + dolist(listname)
    File "bin/update", line 206, in dolist
    for addr, (reason, when) in mlist.delivery_status.items():
    File "/usr/local/mailman/Mailman/MailList.py", line 144, in __getattr__
    raise AttributeError, name
    AttributeError: delivery_status

    Seems like it needs to know that the old lists are from a previous
    version. Any way I can indicate this?
    I don't think it needs to know. The -f option told it to process the
    lists and it is trying, but it can't.

    I think there is something wrong with the config for at least the
    'birn' list. Try running bin/dumpdb against the config.db and/or
    config.pck file(s) for this list and comparing what attributes (names,
    not necessarily values) are dumped with those from a "good" list. We
    know bin/list_lists complained about real_name (probably not existing)
    for some list, and bin/update is complaining similarly about
    delivery_status for this list. Note that output from bin/dumpdb can be
    quite large if a list has many members.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Sapiro at Feb 13, 2005 at 2:52 am

    Mark Panahi wrote:
    Well, now I get this:

    doc local/mailman# bin/dumpdb lists/birn/config.db
    Traceback (most recent call last):
    File "bin/dumpdb", line 156, in ?
    msg = main()
    File "bin/dumpdb", line 126, in main
    d = DumperSwitchboard().read(filename)
    NameError: global name 'DumperSwitchboard' is not defined
    Hmmmm....

    It seems that starting with Mailman 2.1.5, bin/dumpdb can't dump
    marshals, only pickles. This is because the DumperSwitchboard() class
    has been deleted from Mailman/Queue/Switchboard.py even though it is
    still invoked from dumpdb for marshals.

    I don't *think* this is the underlying reason for your problem, but I
    don't know without looking further.

    Perhaps someone else has some info.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Mark Panahi at Feb 13, 2005 at 3:37 am
    Ok, at this point I think I'm just going to recreate all the lists.
    The archives aren't that important, and I can read the db files
    manually to get the member lists. I'll just mass subscribe them.

    Thanks.

    -Mark

    On Sat, 12 Feb 2005 18:52:59 -0800, Mark Sapiro wrote:
    Mark Panahi wrote:
    Well, now I get this:

    doc local/mailman# bin/dumpdb lists/birn/config.db
    Traceback (most recent call last):
    File "bin/dumpdb", line 156, in ?
    msg = main()
    File "bin/dumpdb", line 126, in main
    d = DumperSwitchboard().read(filename)
    NameError: global name 'DumperSwitchboard' is not defined
    Hmmmm....

    It seems that starting with Mailman 2.1.5, bin/dumpdb can't dump
    marshals, only pickles. This is because the DumperSwitchboard() class
    has been deleted from Mailman/Queue/Switchboard.py even though it is
    still invoked from dumpdb for marshals.

    I don't *think* this is the underlying reason for your problem, but I
    don't know without looking further.

    Perhaps someone else has some info.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Brad Knowles at Feb 13, 2005 at 5:27 pm

    At 7:37 PM -0800 2005-02-12, Mark Panahi wrote:

    Ok, at this point I think I'm just going to recreate all the lists.
    The archives aren't that important, and I can read the db files
    manually to get the member lists. I'll just mass subscribe them.
    Remember, you can always import archives later, if you have the
    original mbox-format files to work with.

    --
    Brad Knowles, <brad at stop.mail-abuse.org>

    "Those who would give up essential Liberty, to purchase a little
    temporary Safety, deserve neither Liberty nor Safety."

    -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
    Assembly to the Governor, November 11, 1755

    SAGE member since 1995. See <http://www.sage.org/> for more info.
  • Sean at Feb 16, 2005 at 3:30 pm

    Mark Panahi wrote:
    Well, I tried 'check_db -a -v' and it complains that there are no
    config.pck and config.pck.last files for each list. The thing is, I
    had moved the lists and archive directories from an older installation
    (we had upgraded everything in our server). Seems like these pck files
    are something recent? Anyway to create these? Hmmm, I suppose we
    didn't upgrade properly.
    So presumably you have config.db and config.db.last files instead. This
    change occurred with 2.0.x to 2.1.x.

    Also, for any list whose configuration has been locked, loaded, saved
    and unlocked, there should be a config.pck because 2.1.x versions
    always save the list as a pickle, not a marshall.

    If you upgrade Mailman on an existing installation, the actual
    configuration data will normally be updated by bin/update which will
    be run by "make install"

    In your case, where you moved the config files from another, older
    installation, I think you may need to run bin/update manually,
    although there are reports that seem to indicate this isn't necessary.
    If you do run it, you will probably need the "-f" option to make it do
    anything, and you should back up everything first.

    --
    Mark Sapiro <msapiro at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
    Yes it is possible to import old version config.db files to a newer
    version using config.pck without running bin/update. A simple http
    request to the list on the new installation will generate the config.pck
    files.

    It may be necessary then to update the host_name and web_page_url option
    after such a move depending your set up.

    Sean

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedFeb 12, '05 at 11:33a
activeFeb 16, '05 at 3:30p
posts13
users4
websitelist.org

People

Translate

site design / logo © 2022 Grokbase