Following discussion in bug #181653 I tried the patch from http://www.scipy.org/Porting_to_NumPy to see how it works. Well, it needed some work but it seems to work for me now. However, I must complain about state of autotools in pygtk. It does not supply three of the macros it uses in configure.in so unless you provide those macros, eautoreconf fails. However those macros were not that hard to find (that's an upstream bug for me). What's more this patch needs numpy at least 1.0, cause otherwise check for includes fails. Reproducible: Always Steps to Reproduce:
Created attachment 125197 [details, diff] Patch that seems to work.
Created attachment 125199 [details] Missing macros
Upstream bug:. http://bugzilla.gnome.org/show_bug.cgi?id=397544
If the python team wants to unmask python 2.5 fast we can work on pygtk to support numpy instead until the upstream fix the problem.
of course temporary patching numeric to work on python 2.5 could be an option too.
(In reply to comment #4) > If the python team wants to unmask python 2.5 fast we can work on pygtk to > support numpy instead until the upstream fix the problem. > Upstream has already fixed the problem in svn and there are quite a few packages other than this one to fix before we can punt numeric. So I'll contact the pygtk team and ask when they're planning to release a new version which uses numpy instead of numeric. We are in no hurry to unmask 2.5 until all problems are fixed.
Ok to correct myself, turns out this hasn't been fixed in svn and I'm not sure if it'll be fixed in the near future. I don't want to rush things but we should slowly consider porting pygtk to numpy. I'm attaching a patch which also include missing macros and an ebuild that builds fine. Gnome people I'll appreciate if you can test it. There are more than 130 packages in the tree depending on pygtk so we don't want to mess with it before we're absolutely sure everything works fine :-)
Created attachment 125297 [details, diff] pygtk-2.10.6-numpy.patch As I said this one includes missing macros as well. So I made the two previous attachments obsolete.
Created attachment 125298 [details, diff] pygtk-2.10.6.ebuild.diff Changes to ebuild required to make it work.
Just to be clear: there's nothing broken with 2.4, right? As said, pygtk is a fundamental package for tons of apps, and I'd prefer not to break it. Maybe we can get this working in the overlay, and then later patch into portage?
(In reply to comment #10) > Just to be clear: there's nothing broken with 2.4, right? As said, pygtk is a > fundamental package for tons of apps, and I'd prefer not to break it. Maybe we > can get this working in the overlay, and then later patch into portage? > nothing is broken with 2.4 and nor is anything broken with 2.5 on 32 bit. I didn't mean to rush this and I totally agree with your idea of testing this in an overlay before we push it into the tree.
the current numeric on the tree works on amd64 with py2.5 so we don't have to worry now. The python team can unmask py2.5 when they want it won't affect us
Upstream doesn't care about this, they haven't done anything about numpy in 2 years (check their cvs). The patch in this bug is being used, with slight changes, at least in debian and red hat. Maybe we should apply this patch too and wait unitl upstream wakes up.
Created attachment 179051 [details] pygtk-2.13.0-numpy.patch Here is an updated patch. @gnome: could you test this, may be in the overlay? The ebuild needs the same changes as the one above. I tried matplotlib and it worked fine, but I think it does not use the numeric stuff from pygtk. Thanks.
upstream finally committed this... following patches apply cleanly to 2.14.1, changed ebuild attached too (eautoreconf needed)
Created attachment 187917 [details, diff] patch to make it use numpy
Created attachment 187918 [details, diff] fixes a warning introduced by other patch
Created attachment 187920 [details] updated ebuild
I think switching to numpy with above patches should be reconsidered as numeric fails to build with python-2.6 which is scheduled to go stable soon.
in 2.14.1-r1. Thanks for reporting and producing a patch.
