Summary: | dev-python/matplotlib-1.4.3 broken after upgrade to PyQt5-5.7.1 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | glyphimor |
Component: | Current packages | Assignee: | Gentoo Science Related Packages <sci> |
Status: | RESOLVED WONTFIX | ||
Severity: | major | CC: | gentoo.2019, gentoo, john, kripton, python |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 636054 | ||
Bug Blocks: |
Description
glyphimor
2017-03-20 21:50:08 UTC
Hi, I encountered the same exact problem, which is described here: https://forums.gentoo.org/viewtopic-t-1061048.html In my case emerging live version of matplotlib (dev-python/matplotlib-9999 and few other packages) helped, but I'd rather use stable packages. Confirmed here too on amd64, trying now 1.5.3-r1. 1.5.3-r1 works like a charm with PyQt5 5.7.1 Thanks, please use the new versions. Close this after new versions have been stablized. currently this package fails for everybody upgrading to python 3.5. Can you please proceed with stabilizing this package? +1 for problems, +1 for 1.5.3-r2, +1 for having a stable package to builds Almost a year had passed and this bug is still here. Matplotlib is a important package, specially to academic users. This month I had to setup a Ubuntu virtual machine to prepare some plots to a paper. I know this is not the right place to say that, but I had to. I loved these last ten years of Gentoo. I learned a lot about Linux from it, it made me a better programmer and a better scientist. But it seems Gentoo just got stalled. Thank you very much for this wonderful distro. It was a pleasure to use it. I hope I can find the same feeling in the one I am installing this weekend. All you had to do was unmask a newer version... 9 months is a long time for this, but still, installing Ubuntu instead of a simple unmask is pretty drastic I agree but it's not only matplotlib. There are numerous packages that have these sorts of unaddressed issues. For those of us that depend on our machines for serious work, and additionally need to move forward in the technical world, unmasking packages is a lot of additional work over time. matplotlib is relatively easy. However Jupyter is used by lots of people and unmasking that one caused me to have to unmask 18 additional ~amd64 packages. I don't know how it is now by handbrake ended up being such a hassle that I set up an Ubuntu VM for nothing other than that one application. tensorflow and other technical programs get supported through overlays but it's a lot of extra work. Anyway, I agree, switching distros is a big step. I've done VMs on at least 7-8 other distros during times of frustration, and I suspect that's where Luan is right now, but never pulled the trigger and left Gentoo. Sadly I think it will happen but likely not until I'm forced due to hardware failure or something big like that. (And I've booted Gentoo exclusively since about 2001 or 2002 so leaving would be a BIG deal to me.) Sorry for posting again. Honestly, I was in such a hurry to get the said plots I just did the first thing I thought of. And this pretty much sums up the issue: Gentoo is becoming too much time consuming. Unmasking chains, manual compiling of many programs which are not in the tree, broken system or programs after update and too manual intervention at each update. I wish matplotlib to be the only or main problem. And, for sure, I am not proud of giving up. It was a hard decision. The thing is: I must focus more on science and results I must acquire than on maintain my machine. Not trying to encourage anyone. Really. I hope for a better Gentoo in the future so I can go back to it. WRT John's comment, it isn't only unmasking matplotlb, but additionally unmasking other packages that aren't stable at this time also. That what we who like to be on a stable platform dislike about unmasking stuff: c2RAID6 ~ # emerge -pvDuN @world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ~] dev-python/subprocess32-3.2.7::gentoo USE="{-test}" PYTHON_TARGETS="python2_7" 53 KiB [ebuild N ] dev-python/setuptools_scm-1.15.0::gentoo USE="{-test}" PYTHON_TARGETS="python2_7 python3_5 (-pypy) (-pypy3) -python3_4 -python3_6" 24 KiB [ebuild N ] dev-python/backports-functools-lru-cache-1.4-r1::gentoo USE="-doc {-test}" PYTHON_TARGETS="python2_7 (-pypy)" 7 KiB [ebuild U ~] media-libs/qhull-2015.2::gentoo [2012.1-r4::gentoo] USE="-doc -static-libs" 987 KiB [ebuild U ~] dev-python/matplotlib-2.1.0-r1::gentoo [1.5.3-r2::gentoo] USE="cairo qt5 wxwidgets -doc -examples -excel -gtk2 -gtk3 -latex -pyside {-test} -tk (-fltk%) (-qt4%)" PYTHON_TARGETS="python2_7 python3_5 -python3_4 -python3_6" 32277 KiB Total: 5 packages (2 upgrades, 3 new), Size of downloads: 33346 KiB The following keyword changes are necessary to proceed: (see "package.accept_keywords" in the portage(5) man page for more details) # required by dev-python/matplotlib-2.1.0-r1::gentoo # required by @selected # required by @world (argument) =dev-python/subprocess32-3.2.7 ~amd64 # required by dev-python/matplotlib-2.1.0-r1::gentoo # required by @selected # required by @world (argument) =media-libs/qhull-2015.2 ~amd64 c2RAID6 ~ # I've gone a different way - using virtualenv and pip within that environment. It all seems to run fine, I get access to all stable versions of python packages and don't have to deal with this set of problems. Pretty reasonable and keeps me on Gentoo for now. (In reply to Mark Knecht from comment #10) > I don't know how it is now by handbrake Not much one can do about horribly broken build systems. Everyone interested in a new stable matplotlib should head over to bug 636054 and maybe help fix it. Cleanup done in fe830575e425a875093a98fc75702338dba6b35a. |