Here's an updated ebuild for dev-python/matplotlib version 1.2. It is the first matplotlib version to support python 3. As such, I modified portage's dev-python/matplotlib-1.1.1 to build support for python 3 too. Other changes include: -URL change -restrict mirror (since 1.2 is not yet in portage/on mirrors) -Removed matplotlib-1.1.1-ft-refcount.patch. Should be included in source repo. -Deleted references to pyparsing; not present in source repo. In my overlay; https://github.com/nbigaouette/ebuilds/blob/master/dev-python/matplotlib/matplotlib-1.2.0.ebuild Attaching the ebuild next. Reproducible: Always
Created attachment 329890 [details] dev-python/matplotlib/matplotlib-1.2.0.ebuild
Note that I had trouble compiling with "gtk" use flag. I think it was due to a python 3 issue with pyobject. Exact error is: src/_gtkagg.cpp: In function ‘PyObject* init_gtkagg()’: src/_gtkagg.cpp:137:5: error: return-statement with no value, in function returning ‘PyObject*’ src/_gtkagg.cpp:138:5: error: ‘PyCObject_Check’ was not declared in this scope src/_gtkagg.cpp:138:5: error: ‘PyCObject_AsVoidPtr’ was not declared in this scope src/_gtkagg.cpp:138:5: error: return-statement with no value, in function returning ‘PyObject*’ src/_gtkagg.cpp:138:5: error: return-statement with no value, in function returning ‘PyObject*’ error: command 'x86_64-pc-linux-gnu-g++' failed with exit status 1
Created attachment 329918 [details] diff -ub diff -ub /usr/portage/dev-python/matplotlib/matplotlib-1.1.1.ebuild attachment.cgi\?id\=329890
Created attachment 330386 [details, diff] diff between 1.1.1 and a semi -working 1.2.0 This is a list of changes that has given me an ebuild working for 2.7 and 3.2. The patch I've used should be attached shortly. It needs polish: - AFAICT, dev-python/six is needed only for python 3; at the same time, dev-python/pygtk is needed only for python 2 - python 3 needs gtk+[introspection] (and I'd make this gtk+:3[introspection]) - on a semi-related note, it looks like it uses libglade[introspection], what IMHO makes very little sense (even for python 2 - pygtk 2.14 (or perhaps 2.16) shouldn't be a problem) - as you may see I disagree with some of the changes made in 1.1.1 ebuild; on the other hand, bug 414797 is still untouched
Created attachment 330388 [details, diff] patch used with the previous changes
# ebuild matplotlib-1.2.0.ebuild clean test yields one instance of a regression File "/usr/lib64/python3.2/site-packages/pyparsing.py", line 894, in _parseCache exc.__traceback__ = None NameError: global name 'exc' is not defined occurs to the tune of Ran 1214 tests in 424.185s FAILED (KNOWNFAIL=94, SKIP=3, errors=806) This is known as a major stumbling block. At face value it appears to be a downstream effect of a bug in pyparsing, but this is where it gets tricky seeing the build originally designed an inbuilt pyparsing. I suspect that the patching done thus far has knocked over what was previously working. It's clearly a regression in this form. It also comes to grief with USE=doc. The building of the docs in this package is massive, the biggest I've seen in a python package, drawing from tex packages. This makes for regression number 2. # USE_PYTHON=2.7 USE=doc ebuild matplotlib-1.2.0.ebuild clean install <string>:20: RuntimeWarning: invalid value encountered in absolute /usr/lib64/python2.7/site-packages/numpy/core/fromnumeric.py:2374: RuntimeWarning: invalid value encountered in double_scalars return mean(axis, dtype, out) /mnt/gen2/TmpDir/portage/dev-python/matplotlib-1.2.0/work/matplotlib-1.2.0/build-2.7/lib.linux-x86_64-2.7/matplotlib/font_manager.py:1214: UserWarning: findfont: Font family ['Courier'] not found. Falling back to Bitstream Vera Sans (prop.get_family(), self.defaultFamily[fontext])) python2.7: CXX/Python2/cxx_extensions.cxx:1320: virtual Py::PythonExtensionBase::~PythonExtensionBase(): Assertion `ob_refcnt == 0' failed. Building HTML failed. * ERROR: dev-python/matplotlib-1.2.0 failed (compile phase): * doc generation failed The patch to setup.py has partially worked. When you go patching a setup.py, it requires verification and approval from upstream. On a happier note, matplotlib # USE="docfltk gtk latex qt4 tk wxwidget" ebuild matplotlib-1.2.0.ebuild clean install yields ....................................................... running install_egg_info Writing /mnt/gen2/TmpDir/portage/dev-python/matplotlib-1.2.0/temp/images/3.2/usr/lib64/python3.2/site-packages/matplotlib-1.2.0-py3.2.egg-info >>> Completed installing matplotlib-1.2.0 into /mnt/gen2/TmpDir/portage/dev-python/matplotlib-1.2.0/image/
As for the first, it takes a bit of digging in svn, but... http://pyparsing.svn.sourceforge.net/viewvc/pyparsing?view=revision&revision=219 so it's only a matter of release being delayed. (furthermore, the above comes in major part from http://sourceforge.net/mailarchive/message.php?msg_id=30107833, so it seems the patching isn't that heavy after all) As for patching setup.py, it's needed only for the ebuild, cause setup.cfg affects both python2 *and* python3. AFAIU, ebuild removes check_for_gtk(), cause the check needs a running X server. Those two conditions combined result in the failure from comment 2.
On an interesting note: with that little bug in pyparsing fixed, testsuite doesn't complete for either 2.7 or 3.2. Both fail with the mentioned assertion in pycxx. I wonder if this is something already fixed in upstream pycxx or at least in master of matplotlib. Interestingly enough, there aren't *that* many differences between pycxx trunk and the version in matplotlib. Perhaps http://cxx.svn.sourceforge.net/viewvc/cxx?view=revision&revision=267 will help ?
Hmm, the test suite actually completes by taking out the tests for mathfont', 'cm', font_tests.
If you check the issue in above URL you'll see the block by refcount has been revised and fixed again. (Tip to Rafal, be prepared to file upstream). The test phase by Nicolas, leaving intact since it works perfectly. The setup.py edits have been made into a patch. The only oddity that remains is the building of the docs. If python3 is selected by USE_PYTHON or pulled in by distutils + USE doc set, the build fails on python3 building the docs. Curiously the build appears to leave the building by python3 out in the cold, presumably on the basis that python2 can always be called to do it. It's for upstream to make docs buildable by python3. On the whole, a commendable effort by N. Bigaoutte and R. Muzylo. Bumped 29 Nov.
The ebuild now prevents any building if the main python version is 3. It would be nice if it only did so if the doc use flag is active. I locally tried adding "use doc &&" to the if clause of the check, and it worked for me (the build completed succesfully).
It seems my first point from comment 4 was misunderstood. dev-python/pygtk is python2 only, there's no dev-python/pygtk:3 I haven't put it correctly in the ebuild, as I don't fully understand how to say "depend on dev-python/pygtk only for python2 slots", though I suspect there is a way to do it (python.eclass is a bit confusing, though it has good reasons to be that way). (on a semi-related note, it looks like *upstream* needs to work on python3/gtk3, cause that backend might just be a bit broken right now) (on a not really related note, regarding ChangeLog: is copy/paste that hard ? while it's not exactly the same thing as under http://blog.flameeyes.eu/tag/i18n/, it still irks me)
It would be nice if it only did so if the doc use flag is active. I missed that on the initial commit (amongst the many alterations). It was absent for around only 24 hours before adding it, just long enough. "though I suspect there is a way to do it (python.eclass is a bit confusing," work in progress, shall be corrected soon. is copy/paste that hard ? Answer; No. Any attempt at direct comparison to flameeyes is by its nature a brave one. Your whole name was in fact copy pasted into the Changelog entry, the integrity of the alphabet or your nationality, for want of a better term, kept intact. Beyond that, your final point is quite lost on me.
The last comment was due to a little pet peeve of mine (and me being bit short-tempered at the time of making the comment), not simply in regard of my name, but something I call "near-ASCII fascism" (the whole "latin1 should be good enough" - no, it's not; while I hate to quote Microsoft employees here, see http://blogs.msdn.com/b/michkap/archive/2005/02/05/367666.aspx).
...also, there's no such thing as libglade[introspection] - I got confused by code that's likely broken.
(In reply to comment #14) > The last comment was due to a little pet peeve of mine (and me being bit > short-tempered at the time of making the comment), not simply in regard of > my name, but something I call "near-ASCII fascism" (the whole "latin1 should > be good enough" - no, it's not; while I hate to quote Microsoft employees > here, see http://blogs.msdn.com/b/michkap/archive/2005/02/05/367666.aspx). roger that. If Polish is the game and the diacritic fails the critique, there are a couple of Polish devs in gentoo python who may be able to kick the diacritic into shape.
