Re: [gentoo-user] meld ERROR - ImportError: This platform lacks a functioning sem_open

[Joseph]

On 12/29/13 00:27, Edward M wrote:
>On Sat, 28 Dec 2013 23:44:49 -0700
>Joseph <syscon780@×××××.com> wrote:
>
>> I've solved the problem by installing meld-1.6.0 from attic, 1.7.0
>> and 1.8.2 don't work. I've tried python2.7 and 3.2 make no
>> difference.
>
>I am wondering if the issue your system is having is related to one
>of the following:
>
>-------------------------------------------------------------------------
>
>2012-11-06-PYTHON_TARGETS-deployment
>  Title                     PYTHON_TARGETS deployment
>  Author                    Michał Górny <mgorny@g.o>
>  Posted                    2012-11-06
>  Revision                  1
>
>Recently, a few new Python eclasses have been deployed. As ebuilds
>migrate, the way they support multiple Python implementations will
>change. The previous method built Python modules for Python
>implementations selected through `eselect python'. The new method uses
>the PYTHON_TARGETS USE flags to explicitly name the implementations the
>modules shall be built for.
>
>If you are running a modern system with only Python 2.7 & 3.2 installed,
>then you don't have to do anything. The defaults will simply fit you,
>and let you keep your system up-to-date when new Python versions are
>deployed.
>
>However, if you'd like to use another set of Python implementations, you
>will need to set PYTHON_TARGETS in your make.conf file appropriately.
>This variable names the enabled implementations in the standard way
>common to all USE_EXPAND variables.
>
>For example, a setup enabling all major Python implementations would
>look like:
>
>	PYTHON_TARGETS="python2_7 python3_2 pypy1_9 jython2_5"
>
>The variable should list all Python implementations which are going to
>be used on the system; missing a particular value there will result
>in missing Python modules.
>
>A complete list of all possible values can be obtained using a command
>equivalent to the following:
>
>	emerge -1pv dev-python/python-exec
>
>For more details, please see the python-r1 User's Guide [1].
>
>[1] http://www.gentoo.org/proj/en/Python/python-r1/user-guide.xml
>
>------------------------------------------------------------------------------
>2013-11-07-python-exec-package-move
>  Title                     python-exec package move
>  Author                    Michał Górny <mgorny@g.o>
>  Posted                    2013-11-07
>  Revision                  1
>
>Due to the recent issues which caused dev-python/python-exec:0 to be
>removed prematurely [1], we had to perform an urgent package move.
>Since we could not use the automatic updates support in portage, users
>will notice two python-exec packages and possibly blockers.
>
>Currently, dev-lang/python-exec is the real package that contains
>python-exec and that will be used in the future. dev-python/python-exec
>is a virtual package that is kept for compatibility with dependencies
>in already-installed packages.
>
>In the most favorable scenario, the package will be upgraded correctly
>on your next world update if you use the '--deep' (-D) and '--update'
>(-u) options. If you don't want to perform a complete world update
>or if it fails for you, you may as well manually upgrade
>dev-python/python-exec:
>
>  emerge -1 dev-python/python-exec
>
>This will cause portage to update both python-exec packages and resolve
>the blockers properly.
>
>Please note that if you have applied any kind of package-specific
>modifications to dev-python/python-exec (such as applying keywords
>through 'package.accept_keywords'), you will need to copy them to
>dev-lang/python-exec as well.
>
>If you have applied keywords to dev-python/python-exec in order
>to unmask Python 3.3 on a stable system, please consider removing
>the keywords and reading our wiki page that explains how to properly
>unmask USE flags [2].
>
>We apologize for all the inconveniences. If you have any more issues
>with python-exec, please do not hesitate to contact as at #gentoo-python
>IRC channel (@freenode) or the gentoo-python@l.g.o mailing
>list.
>
>[1]:https://bugs.gentoo.org/show_bug.cgi?id=489440
>[2]:https://wiki.gentoo.org/wiki/Unmasking_non-stable_Python_implementations

I think this problem has something to do with this bug:
https://bugs.gentoo.org/show_bug.cgi?id=496328

-- 
Joseph