On 12/29/13 00:27, Edward M wrote:
On Sat, 28 Dec 2013 23:44:49 -0700
Joseph <[email protected]> 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 <[email protected]>
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 <[email protected]>
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 [email protected] 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
