mailman @2.1.22_0: ImportError: cannot import name C_

[KiyoshiGotow]

I have tried to update mailman from 2.1.20_0 to 2.1.22_0, and got an error message as follows.

The current version of mailman on my system is 2.1.20_0, and it seems to work fine. The version of python is 2.7.11_2.

$ sudo port clean mailman
Password:
--->  Cleaning mailman
$ sudo port upgrade mailman
--->  Computing dependencies for mailman
--->  Fetching archive for mailman
--->  Attempting to fetch mailman-2.1.22_0.darwin_12.x86_64.tbz2 from http://sea.us.packages.macports.org/macports/packages/mailman
--->  Attempting to fetch mailman-2.1.22_0.darwin_12.x86_64.tbz2 from https://packages.macports.org/mailman
--->  Attempting to fetch mailman-2.1.22_0.darwin_12.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/mailman
      [                                        ]   0.0 %        speed: 0 B/s        --->  Fetching distfiles for mailman
--->  Verifying checksums for mailman
--->  Extracting mailman
--->  Applying patches to mailman
--->  Configuring mailman
--->  Building mailman
--->  Staging mailman into destroot
Error: org.macports.destroot for port mailman returned: command execution failed
Please see the log file for port mailman for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_mail_mailman/mailman/main.log
Error: Unable to upgrade port: 1
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets

[ryandesign (Ryan Carsten Schmidt)]

Relevant error from log appears to be:

:info:destroot Traceback (most recent call last):
:info:destroot   File "./bin/check_perms", line 48, in <module>
:info:destroot     from Mailman.i18n import C_
:info:destroot ImportError: cannot import name C_

[Schamschula (Marius Schamschula)]

Hmm. This looks like a locale error. I will investigate.

[Schamschula (Marius Schamschula)]

I'm stumped: I just cleanly installed mailman in my Mountain Lion VM w/o any problems.

Is there anything non-standard, i.e. are you using MacPorts clang or some such thing?

[KiyoshiGotow]

Thank you for your comments. Clang is new for me. I re-installed MacPorts-2.3.4-10.8-MountainLion.pkg, and updated Xcode to the latest version. I used MacPorts and Xcode with default settings as installed. I tried to install mailman, and got an error message as follows.

The main.log says that main compiler is clang 425.0.28 though not blacklisted in compiler_blacklist_versions-1.0.tcl. I used Xcode clang compiler without intentions. This might be the cause of an error as you pointed out.

Could you please recommend the compiler that is suitable for mailman installation, and the way to use it?

I attached the main.log for your reference.

$ sudo port clean --all mailman Password: ---> Cleaning mailman $ sudo port install mailman ---> Computing dependencies for mailman ---> Fetching archive for mailman ---> Attempting to fetch mailman-2.1.22_0.darwin_12.x86_64.tbz2 from ​http://sea.us.packages.macports.org/macports/packages/mailman ---> Attempting to fetch mailman-2.1.22_0.darwin_12.x86_64.tbz2 from ​http://jog.id.packages.macports.org/macports/packages/mailman ---> Attempting to fetch mailman-2.1.22_0.darwin_12.x86_64.tbz2 from ​https://packages.macports.org/mailman ---> Fetching distfiles for mailman ---> Attempting to fetch mailman-2.1.22.tgz from ​http://jog.id.distfiles.macports.org/macports/distfiles/mailman ---> Verifying checksums for mailman ---> Extracting mailman ---> Applying patches to mailman ---> Configuring mailman ---> Building mailman ---> Staging mailman into destroot Error: org.macports.destroot for port mailman returned: command execution failed Please see the log file for port mailman for details:

/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_mail_mailman/mailman/main.log

To report a bug, follow the instructions in the guide:

​http://guide.macports.org/#project.tickets

Error: Processing of port mailman failed

[macports-bug-report-yf@…]

It seems that ./bin/check_perms script tries to import module function Mailman.i18n from previously installed version of Mailman module, in mailman 2.1.20. (C_ function has been introduced since 2.1.21 for i18n improvement of command line tools.)

Please check which module is imported on checkperm processing.

(I'm sorry but I don't have MacPorts environment, so this is my mere conjecture....)

[macports-bug-report-yf@…]

Cc Me!

[macports-bug-report-yf@…]

I've read mail/mailman/Portfire rev 149395.

In line 105-106, ./bin/check_perms will try to import Mailman.i18n module not from ./Mailman (= ${destroot}${sharedir}/Mailman) but ${sharedir}/Mailman if exists, because check_perms script has import paths.py which insert ${sharedir}/Mailman into top of module search path, then import Mailman.i18n module. So if older version of mailman has been installed and check_perms script uses incompatible module with older version, it can cause an error.

[macports-bug-report-yf@…]

To reproduce the problem,

(1) Install mailman 2.1.20 or earlier in the same path the MacPorts will install mailman-2.1.22

or

(2) Place empty file as Mailman/i18n.py to the path the mailman-2.1.22 MacPorts will install Mailman/i18n.py module to.

then try to install mailman-2.1.22 via MacPorts.

To fix it, (A) Abandon to run check_perms before install or (B) For destroot phase, create special version of check_perms which refers modules from under ${destroot} precedingly

[Schamschula (Marius Schamschula)]

I've set check_perms to an absolute path: r149540.

[KiyoshiGotow]

I tried to upgrade mailman-2.1.22_0 with new ports r149540 from mailman-2.1.20_0, and got an error message as follows. I confirmed that new ports r149540 is in /opt/local/var/macports/sources/rsync.macports.org/relese/tarballs/ports/mail.man/Portfile. The current version of Python on my system is 2.7.12_1. I attached the main.log for your reference.

I would appreciate if you could give any comments or advices.

$ sudo port clean --all mailman
Password:
---> Cleaning mailman
dependencies for mailman
---> Fetching archive for mailman
---> Attempting to fetch mailman-2.1.22_0.darwin_12.x86_64.tbz2 from ​https://packages.macports.org/mailman

---> Attempting to fetch mailman-2.1.22_0.darwin_12.x86_64.tbz2 from ​http://jog.id.packages.macports.org/macports/packages/mailman

---> Attempting to fetch mailman-2.1.22_0.darwin_12.x86_64.tbz2 from ​http://mse.uk.packages.macports.org/sites/packages.macports.org/mailman

[ ] 0.0 % speed: 0 B/s ---> Fetching distfiles for mailman

---> Attempting to fetch mailman-2.1.22.tgz from ​https://distfiles.macports.org/mailman
---> Verifying checksums for mailman
---> Extracting mailman
---> Applying patches to mailman
---> Configuring mailman
---> Building mailman
---> Staging mailman into destroot
Error: org.macports.destroot for port mailman returned: command execution failed Please see the log file for port mailman for details:

/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_mail_mailman/mailman/main.log

Error: Unable to upgrade port: 1 To report a bug, follow the instructions in the guide:

​http://guide.macports.org/#project.tickets

[Schamschula (Marius Schamschula)]

I've thrown the towel on check_perms: r149823

[macports-bug-report-yf@…]

Replying to mps@…:

I've thrown the towel on check_perms: r149823

IMO, there is no mean to run check_perms on post-destroot phase, because

(1) It checks files/dirs permission of installed environment, including /etc, working directories, archive directories, etc., with absolute paths (i.e. not checking under staging root dir).
(2) Without option -f bin/check_perms do nothing but printinting bogus permissions or groupownership, not correcting them actually. (exit status is always 0 except on invalid arguments or Python exception).

So, I think the change of r149823 is appropriate for this problem.

[macports-bug-report-yf@…]

(1) It checks files/dirs permission of installed environment, including /etc, working directories, archive directories, etc., with absolute paths (i.e. not checking under staging root dir).

I'm very sorry this is not correct, because files/patch-Defaults.py.in modifies Mailman/Defaults.py.in, which allows to check under ${DESTDIR} specified by environment variable.

However, on bin/check_perms (or other scripts) execution, bin/paths.py is imported before mm_cfg.py and Defaults.py, so ${sharedir} is inserted to the top of module search path, so mm_cfg.py, Defaults.py and other Mailman modules are imported from ${sharedir} if old installation exists.

To avoid this, you can modify misc/paths.py.in to refer DESTDIR environment variable in the same way as Mailman/Defaults.py.in , which is modified by ports file patch-Defaults.py.in . (This will change not only bin/paths.py, but also cron/paths.py, scripts/paths.py, and tests/paths.py, though)

[KiyoshiGotow]

Finally mailman has been upgraded to 2.1.22_0 from 2.1.20_0 with port r149823 on OSX 10.8.5. I made no further modification. After upgrade I ran "check_perms -f" command, and got a reply of "No problems found". The new mailman 2.1.22_0 appears to be working properly so far.

Thank everyone who discussed the problem and provided the revised port r149823.