Re: [gentoo-user] meld ERROR - ImportError: This platform lacks a functioning sem_open
On Sat, 28 Dec 2013 23:44:49 -0700 Joseph syscon...@gmail.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 AuthorMichał Górny mgo...@gentoo.org Posted2012-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 AuthorMichał Górny mgo...@gentoo.org Posted2013-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-pyt...@lists.gentoo.org mailing list. [1]:https://bugs.gentoo.org/show_bug.cgi?id=489440 [2]:https://wiki.gentoo.org/wiki/Unmasking_non-stable_Python_implementations
Re: [gentoo-user] meld ERROR - ImportError: This platform lacks a functioning sem_open
Hi, A few days ago there was a similar issue discussed in http://www.gossamer-threads.com/lists/gentoo/user/281003 In the last answer James proposed a solution that seemingly resolved that issue. Wkr Hinnerk Joseph syscon...@gmail.com wrote: I just upgraded my system and meld as well. I'm using cfg-update -u to compare files that did change utilizing meld When I try to compare two file as root using meld I get: meld /etc/ddclient/ddclient.conf /etc/ddclient/._cfg_ddclient.conf Traceback (most recent call last): File /usr/bin/meld, line 173, in module main() File /usr/bin/meld, line 165, in main new_window = app.parse_args(sys.argv[1:]) File /usr/lib64/meld/meld/meldapp.py, line 169, in parse_args tab = open_paths(args, options.auto_compare, options.auto_merge) File /usr/lib64/meld/meld/meldwindow.py, line 796, in open_paths tab = self.append_diff(paths, auto_compare, auto_merge) File /usr/lib64/meld/meld/meldwindow.py, line 746, in append_diff return self.append_filediff(paths, merge_output=merge_output) File /usr/lib64/meld/meld/meldwindow.py, line 703, in append_filediff doc = filediff.FileDiff(app.prefs, len(files)) File /usr/lib64/meld/meld/filediff.py, line 214, in __init__ self._cached_match = CachedSequenceMatcher() File /usr/lib64/meld/meld/filediff.py, line 72, in __init__ None, matchers.init_worker, maxtasksperchild=1) File /usr/lib64/python2.7/multiprocessing/__init__.py, line 232, in Pool return Pool(processes, initializer, initargs, maxtasksperchild) File /usr/lib64/python2.7/multiprocessing/pool.py, line 138, in __init__ self._setup_queues() File /usr/lib64/python2.7/multiprocessing/pool.py, line 232, in _setup_queues from .queues import SimpleQueue File /usr/lib64/python2.7/multiprocessing/queues.py, line 48, in module from multiprocessing.synchronize import Lock, BoundedSemaphore, Semaphore, Condition File /usr/lib64/python2.7/multiprocessing/synchronize.py, line 59, in module function, see issue 3770.) ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770. -- Joseph -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Re: [gentoo-user] meld ERROR - ImportError: This platform lacks a functioning sem_open
Hinnerk van Bruinehsen h.v.bruineh...@fu-berlin.de wrote: Hi, A few days ago there was a similar issue discussed in http://www.gossamer-threads.com/lists/gentoo/user/281003 In the last answer James proposed a solution that seemingly resolved that issue. Wkr Hinnerk Joseph syscon...@gmail.com wrote: I just upgraded my system and meld as well. I'm using cfg-update -u to compare files that did change utilizing meld When I try to compare two file as root using meld I get: meld /etc/ddclient/ddclient.conf /etc/ddclient/._cfg_ddclient.conf Traceback (most recent call last): File /usr/bin/meld, line 173, in module main() File /usr/bin/meld, line 165, in main new_window = app.parse_args(sys.argv[1:]) File /usr/lib64/meld/meld/meldapp.py, line 169, in parse_args tab = open_paths(args, options.auto_compare, options.auto_merge) File /usr/lib64/meld/meld/meldwindow.py, line 796, in open_paths tab = self.append_diff(paths, auto_compare, auto_merge) File /usr/lib64/meld/meld/meldwindow.py, line 746, in append_diff return self.append_filediff(paths, merge_output=merge_output) File /usr/lib64/meld/meld/meldwindow.py, line 703, in append_filediff doc = filediff.FileDiff(app.prefs, len(files)) File /usr/lib64/meld/meld/filediff.py, line 214, in __init__ self._cached_match = CachedSequenceMatcher() File /usr/lib64/meld/meld/filediff.py, line 72, in __init__ None, matchers.init_worker, maxtasksperchild=1) File /usr/lib64/python2.7/multiprocessing/__init__.py, line 232, in Pool return Pool(processes, initializer, initargs, maxtasksperchild) File /usr/lib64/python2.7/multiprocessing/pool.py, line 138, in __init__ self._setup_queues() File /usr/lib64/python2.7/multiprocessing/pool.py, line 232, in _setup_queues from .queues import SimpleQueue File /usr/lib64/python2.7/multiprocessing/queues.py, line 48, in module from multiprocessing.synchronize import Lock, BoundedSemaphore, Semaphore, Condition File /usr/lib64/python2.7/multiprocessing/synchronize.py, line 59, in module function, see issue 3770.) ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770. Sorry for top-posting. The mail client on NY phone wasn't properly configured...
Re: [gentoo-user] meld ERROR - ImportError: This platform lacks a functioning sem_open
On 12/29/13 13:14, Hinnerk van Bruinehsen wrote: Hi, A few days ago there was a similar issue discussed in [1]http://www.gossamer-threads.com/lists/gentoo/user/281003 In the last answer James proposed a solution that seemingly resolved that issue. Wkr Hinnerk Joseph syscon...@gmail.com wrote: I just upgraded my system and meld as well. I'm using cfg-update -u to compare files that did change utilizing meld When I try to compare two file as root using meld I get: meld /etc/ddclient/ddclient.conf /etc/ddclient/._cfg_ddclient.conf Traceback (most recent call last): File /usr/bin/meld, line 173, in module main() File /usr/bin/meld, line 165, in main new_window = app.parse_args(sys.argv[1:]) File /usr/lib64/meld/meld/[2]meldapp.py, line 169, in parse_args tab = open_paths(args, options.auto_compare, options.auto_merge) File /usr/lib64/meld/meld/[3]meldwindow.py, line 796, in open_paths tab = self.append_diff(paths, auto_compare, auto_merge) File /usr/lib64/meld/meld/[4]meldwindow.py, line 746, in append_diff return self.append_filediff(paths, merge_output=merge_output) File /usr/lib64/meld/meld/[5]meldwindow.py, line 703, in append_filediff doc = filediff.FileDiff(app.prefs, len(files)) File /usr/lib64/meld/meld/[6]filediff.py, line 214, in __init__ self._cached_match = CachedSequenceMatcher() File /usr/lib64/meld/meld/[7]filediff.py, line 72, in __init__ None, matchers.init_worker, maxtasksperchild=1) File /usr/lib64/python2.7/multiprocessing/__init__.py, line 232, in Pool return Pool(processes, initializer, initargs, maxtasksperchild) File /usr/lib64/python2.7/multiprocessing/[8]pool.py, line 138, in __init__ self._setup_queues() File /usr/lib64/python2.7/multiprocessing/[9]pool.py, line 232, in _setup_qu eues from .queues import SimpleQueue File /usr/lib64/python2.7/multiprocessing/[10]queues.py, line 48, in module from multiprocessing.synchronize import Lock, BoundedSemaphore, Semaphore, C ondition File /usr/lib64/python2.7/multiprocessing/[11]synchronize.py, line 59, in m odule function, see issue 3770.) ImportError: This platform lacks a functioning sem_open implementation, therefor e, the required synchronization primitives needed will not function, see issue 3 770. -- Joseph I've changed to permission on /dev/shm to 1777 and recompile both pythons 2.7.5-r3 and 3.3.2-r2 but it makes no difference. Meld 1.8.2 starts empty OK but when I try to open any file I get that error. -- Joseph
Re: [gentoo-user] meld ERROR - ImportError: This platform lacks a functioning sem_open
On 12/29/13 18:56, Adam Carter 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.
FYI meld 1.8.2 works for me. From the use flags you can deduce that it
cant use 3.2, only 2.6 or 2.7.
[ebuild R] dev-util/meld-1.8.2 USE=gnome highlight
PYTHON_SINGLE_TARGET=python2_7 -python2_6 PYTHON_TARGETS=python2_7
-python2_6 0 kB
From the ebuild;
PYTHON_COMPAT=( python2_{6,7} )
Yes, meld-1.8.2 start OK without specifying any file but when I try to open any
file with meld, that is the time I get an error.
--
Joseph
Re: [gentoo-user] meld ERROR - ImportError: This platform lacks a functioning sem_open
On 12/29/13 00:27, Edward M wrote: On Sat, 28 Dec 2013 23:44:49 -0700 Joseph syscon...@gmail.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 AuthorMichał Górny mgo...@gentoo.org Posted2012-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 AuthorMichał Górny mgo...@gentoo.org Posted2013-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-pyt...@lists.gentoo.org 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
Re: [gentoo-user] meld ERROR - ImportError: This platform lacks a functioning sem_open
On Sun, 29 Dec 2013 11:58:47 -0700 Joseph syscon...@gmail.com wrote: I think this problem has something to do with this bug: https://bugs.gentoo.org/show_bug.cgi?id=496328 Did this occur from a recent emerge --rsync update. If so i'm concern about rsyncing and updating at this time?
Re: [gentoo-user] meld ERROR - ImportError: This platform lacks a functioning sem_open
On 12/29/13 14:28, Edward M wrote: On Sun, 29 Dec 2013 11:58:47 -0700 Joseph syscon...@gmail.com wrote: I think this problem has something to do with this bug: https://bugs.gentoo.org/show_bug.cgi?id=496328 Did this occur from a recent emerge --rsync update. If so i'm concern about rsyncing and updating at this time? Yes, it was recent upgrade. I had similar problem with meld-1.7.0 (so I had it masked) but 1.8.2 sipped IN and is showing the same problem. I suggest use 1.6.0 from attic or mask ver. =1.7.0 All other packages are working OK, and all of them compiled without errors. -- Joseph
Re: [gentoo-user] meld ERROR - ImportError: This platform lacks a functioning sem_open
On Sun, 29 Dec 2013 19:04:47 -0700 Joseph syscon...@gmail.com wrote: On 12/29/13 14:28, Edward M wrote: On Sun, 29 Dec 2013 11:58:47 -0700 Joseph syscon...@gmail.com wrote: I think this problem has something to do with this bug: https://bugs.gentoo.org/show_bug.cgi?id=496328 Did this occur from a recent emerge --rsync update. If so i'm concern about rsyncing and updating at this time? Yes, it was recent upgrade. I had similar problem with meld-1.7.0 (so I had it masked) but 1.8.2 sipped IN and is showing the same problem. I suggest use 1.6.0 from attic or mask ver. =1.7.0 All other packages are working OK, and all of them compiled without errors. Thank you for the suggestion. I really appreciate it
Re: [gentoo-user] meld ERROR - ImportError: This platform lacks a functioning sem_open
On 12/29/13 19:27, Edward M wrote: On Sun, 29 Dec 2013 19:04:47 -0700 Joseph syscon...@gmail.com wrote: On 12/29/13 14:28, Edward M wrote: On Sun, 29 Dec 2013 11:58:47 -0700 Joseph syscon...@gmail.com wrote: I think this problem has something to do with this bug: https://bugs.gentoo.org/show_bug.cgi?id=496328 Did this occur from a recent emerge --rsync update. If so i'm concern about rsyncing and updating at this time? Yes, it was recent upgrade. I had similar problem with meld-1.7.0 (so I had it masked) but 1.8.2 sipped IN and is showing the same problem. I suggest use 1.6.0 from attic or mask ver. =1.7.0 All other packages are working OK, and all of them compiled without errors. Thank you for the suggestion. I really appreciate it Another problem after upgrade I have is the ownership change on mounted USB stick. I can not change the ownership even as root :-( So I can not delete them or save a file to USB stick. -- Joseph
Re: [gentoo-user] meld ERROR - ImportError: This platform lacks a functioning sem_open
On Sun, Dec 29, 2013 at 11:10 AM, Joseph syscon...@gmail.com wrote: I just upgraded my system and meld as well. I'm using cfg-update -u to compare files that did change utilizing meld When I try to compare two file as root using meld I get: meld /etc/ddclient/ddclient.conf /etc/ddclient/._cfg_ddclient.conf Traceback (most recent call last): File /usr/bin/meld, line 173, in module main() File /usr/bin/meld, line 165, in main new_window = app.parse_args(sys.argv[1:]) File /usr/lib64/meld/meld/meldapp.py, Since meld is written in python, the easiest thing to try is running python-updater, in case a python upgrade has broken something.
Re: [gentoo-user] meld ERROR - ImportError: This platform lacks a functioning sem_open
On 12/29/13 13:35, Adam Carter wrote: On Sun, Dec 29, 2013 at 11:10 AM, Joseph [1]syscon...@gmail.com wrote: I just upgraded my system and meld as well. I'm using cfg-update -u to compare files that did change utilizing meld When I try to compare two file as root using meld I get: meld /etc/ddclient/ddclient.conf /etc/ddclient/._cfg_ddclient.conf Traceback (most recent call last): File /usr/bin/meld, line 173, in module main() File /usr/bin/meld, line 165, in main new_window = app.parse_args(sys.argv[1:]) File /usr/lib64/meld/meld/meldapp.py, Since meld is written in python, the easiest thing to try is running python-updater, in case a python upgrade has broken something. I did run python-updater, it doesn't help. I re-emerge python as well; it makes no difference. I think I had a problem before with meld-1.7.0 because I mask it. Now, 1.8.2 has the same problem. I might have to dig out from attic 1.6.0 :-/ -- Joseph
Re: [gentoo-user] meld ERROR - ImportError: This platform lacks a functioning sem_open
On 12/29/13 13:35, Adam Carter wrote: On Sun, Dec 29, 2013 at 11:10 AM, Joseph [1]syscon...@gmail.com wrote: I just upgraded my system and meld as well. I'm using cfg-update -u to compare files that did change utilizing meld When I try to compare two file as root using meld I get: meld /etc/ddclient/ddclient.conf /etc/ddclient/._cfg_ddclient.conf Traceback (most recent call last): File /usr/bin/meld, line 173, in module main() File /usr/bin/meld, line 165, in main new_window = app.parse_args(sys.argv[1:]) File /usr/lib64/meld/meld/meldapp.py, Since meld is written in python, the easiest thing to try is running python-updater, in case a python upgrade has broken something. 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. -- Joseph
Re: [gentoo-user] meld ERROR - ImportError: This platform lacks a functioning sem_open
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.
FYI meld 1.8.2 works for me. From the use flags you can deduce that it cant
use 3.2, only 2.6 or 2.7.
[ebuild R] dev-util/meld-1.8.2 USE=gnome highlight
PYTHON_SINGLE_TARGET=python2_7 -python2_6 PYTHON_TARGETS=python2_7
-python2_6 0 kB
From the ebuild;
PYTHON_COMPAT=( python2_{6,7} )
