^[[33;01m*^[[0m esetup.py: WARNING: ^[[33;01m*^[[0m esetup.py: WARNING: ^[[33;01m*^[[0m esetup.py: WARNING: cat: /tmp/.X1-lock: No such file or directory cat: /tmp/.X1-lock: No such file or directory kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec] kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec] ^[[31;01m*^[[0m ERROR: dev-python/matplotlib-1.3.1::gentoo failed (compile phase): ^[[31;01m*^[[0m ERROR: dev-python/matplotlib-1.3.1::gentoo failed (compile phase): ^[[31;01m*^[[0m ERROR: dev-python/matplotlib-1.3.1::gentoo failed (compile phase): ^[[31;01m*^[[0m virtualmake: the wrap_setup distutils-r1_python_compile failed. ^[[31;01m*^[[0m virtualmake: the wrap_setup distutils-r1_python_compile failed. ^[[31;01m*^[[0m virtualmake: the wrap_setup distutils-r1_python_compile failed. Reproducible: Always
Created attachment 387422 [details] build.log
Not related to bug #504202, as I do not even have dev-python/wxpython installed.
Maybe related: Xlib: extension "RANDR" missing on display ":1". (message early in the compile phase)
The issue persists. Any ideas or suggestions how to fix or work around it?
$ emerge =dev-python/matplotlib-1.3.1 -pv These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] x11-base/xorg-server-1.16.1:0/1.16.1 USE="glamor ipv6 nptl suid udev xorg xvfb* -dmx -doc -kdrive -minimal (-selinux) -static-libs -systemd -tslib -unwind -wayland -xnest" 0 KiB [ebuild R ] dev-python/matplotlib-1.3.1 USE="cairo gtk qt4 wxwidgets -doc -examples -excel -fltk -gtk3 -latex -pyside {-test} -tk" PYTHON_TARGETS="python2_7 python3_3 python3_4 (-python3_2)" 0 KiB Perhaps you can report the state of your emerged x11-base/xorg-server re USE flags. The key one is xvfb
Also portage has 1.4.0 and 1.4.2, what happens with those?
(In reply to Ian Delaney from comment #5) > Perhaps you can report the state of your emerged x11-base/xorg-server re USE > flags. The key one is xvfb $ emerge =dev-python/matplotlib-1.3.1 xorg-server -pv […] [ebuild R ] x11-base/xorg-server-1.16.1:0/1.16.1 USE="glamor ipv6 nptl suid systemd udev wayland xorg xvfb -dmx -doc -kdrive -minimal (-selinux) -static-libs -tslib -unwind -xnest" 0 KiB [ebuild R ] dev-python/matplotlib-1.3.1 USE="cairo gtk latex qt4 -doc -examples -excel -fltk -gtk3 -pyside {-test} -tk -wxwidgets" PYTHON_TARGETS="python2_7 python3_3 python3_4%* (-python3_2) (-python2_6%)" 0 KiB […] (In reply to Ian Delaney from comment #6) > Also portage has 1.4.0 and 1.4.2, what happens with those? $ equery depends matplotlib […] sci-mathematics/sage-6.3-r1 (>=dev-python/matplotlib-1.3.1[python_targets_python2_7(-)?,-python_single_target_python2_7(-)]) (<dev-python/matplotlib-1.4.0[python_targets_python2_7(-)?,-python_single_target_python2_7(-)])
This does occur for me with DISPLAY set to :1. Also fails without the output of Xlib: extension "RANDR" missing ... with DISPLAY set to ":0". Also, by "portage has 1.4.0 and 1.4.2, what happens with those?" I meant can you build these versions, like so; ~/cvsPortage/gentoo-x86/dev-python/matplotlib $ PYTHON_TARGETS=python2_7 ebuild matplotlib-1.4.0.ebuild clean compile * python2_7: running distutils-r1_run_phase python_compile_all >>> Source compiled. Normally new version that works trumps a broken past version however (<dev-python/matplotlib-1.4.0[python_targets_python2_7(-)?,-python_single_target_python2_7(-)]) kinf of over-rides this.
jlec: Why are we wrapping the src_compile phase with virtualmake? Do we actually need and X server to build this?
Looking at the ebuilds in the tree, it looks like this was removed in later ebuilds. Please try >=matplotlib-1.4.0.
This works: # emerge -1a --nodeps \>matplotlib-1.4 These are the packages that would be merged, in order: [ebuild U ] dev-python/matplotlib-1.4.2 [1.3.1] PYTHON_TARGETS="python3_4%*" Can you please backport the change to matplotlib-1.3.1, as I need that version for sage?
Please reopen if this problem still exists with version 1.4
(In reply to Justin Lecher from comment #12) > Please reopen if this problem still exists with version 1.4 As mentioned in comment #11, version 1.4.2 worked.
