Summary: | dev-python/matplotlib-2.0.2 : The following required packages can not be built: * qt4agg | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | Current packages | Assignee: | Gentoo Science Related Packages <sci> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | dan, grozin, Martin.vGagern, mgorny, python, rossi.f |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
dev-python:matplotlib-1.5.1:20160429-113808.log
emerge-history.txt environment |
Description
Toralf Förster
2016-04-29 12:32:15 UTC
Created attachment 432564 [details]
dev-python:matplotlib-1.5.1:20160429-113808.log
Created attachment 432566 [details]
emerge-history.txt
Created attachment 432568 [details]
environment
The same problem (with slight variations). I'm trying to emerge matplotlib-1.5.3 on a ~x86 box with PYTHON_TARGETS="python2_7 python3_5". In 2.7 everything's fine, distutils-r1_run_phase python_compile succeeds. In 3.5 qt4agg: no [Check timed out] ... * The following required packages can not be built: * qt4agg PyQt4 has been successfully emerged for python 2.7 and 3.5 very recently. What can be the reason of this timeout specific to python3? The next attempt has succeeded. It seems this timeout error depends on something random (not the phase of the moon because both the failed attempt and the successful one are today). Is it possible to increase the timeout value to make the test more robust? I confirm the same problem even with the latest stable version, 1.4.3, and PYTHON_TARGETS="python2_7 python3_4 -python3_5" upstream added the timeout to avoid race conditions, but they didn't understand which is the reason of the race itself. See also https://github.com/matplotlib/matplotlib/issues/3738 I have created a patch to reverse the order of backend checks, first the one for qt4 and then qt5. On my system works solving my problem but I don't know if it's a definitive solution for everyone. Here is the simple patch: --- setup.py 2015-02-16 04:46:36.000000000 +0100 +++ setup.py.new 2017-02-21 17:24:28.903840102 +0100 @@ -92,8 +92,8 @@ # being the most preferred. The first one that looks like it will # work will be selected as the default backend. setupext.BackendMacOSX(), - setupext.BackendQt5(), setupext.BackendQt4(), + setupext.BackendQt5(), setupext.BackendPySide(), setupext.BackendGtk3Agg(), setupext.BackendGtk3Cairo(), The same happened to me: matplotlib-2.0.2, PYTHON_TARGETS="python2_7 python3_5 python3_6". The next attempt (without any changes) proceeded farther, and then failed for a different reason. I'll file a separate bug. Could one of you report this upstream since I can't reproduce it? (In reply to Michał Górny from comment #8) > Could one of you report this upstream since I can't reproduce it? Sure I can. But the failure is undeterministic. I have no substantial statistics; from the little one I have it happens with 50% probability. Hello, I have a similar problem: The following required packages can not be built: * gtk3agg Same happened here during an --emptytree rebuild. The folowing rebuild succeded nicely. (In reply to Mircea Sava from comment #11) > Same happened here during an --emptytree rebuild. The folowing rebuild > succeded nicely. Ah, sorry, I forgot to mention my version was actually 1.5.3-r2. I hit comment 10 (the gtk3agg version of this), too, while writing bug 641624 comment 4. Do we have an upstream bug for this yet? Would changing the timeout be a viable workaround? There is a huge gap between the 150 minutes used by the Debian build system described in https://github.com/matplotlib/matplotlib/issues/3738 and the 10 seconds used by https://github.com/matplotlib/matplotlib/pull/3741. If we were to change it to e.g. 180 seconds, then we would stand a better chance to see whether this is just a bad timeout or actually some hanging process? Might run some tests with this if I find the time, but feel free to do the same as I am short on time just now. File a new bug if problem persists. |