Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
Per the developers' web site, numeric's maintenance has ceased and user should transition to numpy as quickly as possible. Numpy (and scipy) are already in portage. The motivation for this bug report is that numeric seems to be one of the things holding back the unmasking of python 2.5. But since numeric has been dead for almost 2 years I see no justification for it having block an active project whose release was 7 months ago.
Easier said than done: there's *loads* of stuff depending on dev-python/numeric, absolutely a no go ATM.
Created an attachment (id=121744) [details] list of ebuilds that depend on dev-python/numeric
Hi Yes, Jakub is right, many packages still depend on numeric. It would be faster to help on bug #176914 rather than waiting for upstream to switch from numeric to numpy. I will try to see if some of packages from the posted list could benefit a version bump or an ebuild cleaning to get rid of the numeric dependency. Sébastien
Can you just instead have numeric depend on python 2.4?
That's quite a mess! I am amazed how many well maintained packages (pymol comes to mind) still depend on numeric more than one year after numeric has been deprecated. I have the feeling that making numeric + python-2.5 64bit safe will be very tricky without good knowledge of the code base and probably break again soon. Maybe we should rather contact upstream for all packages that still need numeric asking about the status of transitioning to numpy and masking packages if there's no reasonable timeline. Markus
I just checked my Fedora 7 install and it has both python 2.5 and numeric installed by default. Now I don't know how they do it... maybe they don't have the same package dependencies that we do, but they do have numeric/python 2.5 and it does apparently run on x64. I'd be more than happy if someone could assist me in to looking into how it's done on Fedora.
> and it does apparently run on x64. I'd be more than happy if someone could > assist me in to looking into how it's done on Fedora. http://cvs.fedora.redhat.com/viewcvs/devel/python-numeric/?root=extras shows you the spec file and patches. Looking at it, they do less patching than us, it might compile, but should not pass the tests. Could you try the test Tests/test.py from the targz as in bug #176914 on your fedora amd64 box?
(In reply to comment #4) > Can you just instead have numeric depend on python 2.4? I'm currently looking at it. I am also looking at the source code to have it worked on amd64. It is not so straight forward. Meanwhile, here is a list of the packages that are guilty and possible alternative/solution to the numeric dep: dev-python/f2py-* needs numpy stable, then sunset it dev-python/fonttools sunset it? dev-python/gnuplot-py needs patch dev-python/matplotlib lives well without numeric dev-python/pycairo-1.2.* needs pycairo-1.4.* stable dev-python/pycdf needs bump dev-python/pyclimate-* does not work without numeric dev-python/pygame-* ?? dev-python/pygtk-* ?? dev-python/pyqwt needs bump dev-python/python-biggles does not work without numeric dev-python/rpy needs patch dev-python/scientificpython next stable version with numpy dev-python/ttfquery sunset it? dev-python/visual-* ?? games-arcade/pydance ?? games-rpg/galaxymage ?? gnome-extra/music-applet ?? sci-biology/biopython ?? sci-chemistry/pymol ?? sci-libs/plplot ?? sci-libs/pymmlib needs bump sci-physics/camfr needs bump Some of those (??) I have looked at them, or I simply don't know. pygtk and pygame need extra care since lots of other packages depend on it. Anyone could fill the ?? Here is a decent page for possible patches: http://www.scipy.org/Porting_to_NumPy
Un(In reply to comment #7) > > Could you try the test Tests/test.py from the targz as in bug #176914 on your > fedora amd64 box? Unfortunately my Fedora 7 box is not running on x64. I was just mentioning that it apparently *does* run on x64. What I could do is d/l the x64 and run it from the Live CD. Give me some time to do that.
(In reply to comment #7) Apparently the Fedora folks neglected to check to see if their Live CD actually fits on a CD. The x64 ISO is 780.... about 80MB too big to burn on a standard CDR. I ended up burning it to a DVDR. They also apparently do not run or ignore the tests. From the Fedora 7 Live x64 CD: [fedora@localhost ~]$ cat /etc/redhat-release ; uname -a ; python -V ; rpm -q python-numeric Fedora release 7 (Moonshine) Linux localhost.localdomain 2.6.21-1.3194.fc7 #1 SMP Wed May 23 22:47:07 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux Python 2.5 python-numeric-24.2-4.fc7 [fedora@localhost disk]$ cd /media/disk/Test/ [fedora@localhost Test]$ ls llstest.py test.py testwin.bat [fedora@localhost Test]$ python test.py ......E.E...........E.........E.............. ====================================================================== ERROR: test concatenate ---------------------------------------------------------------------- Traceback (most recent call last): File "test.py", line 433, in testConcatenate assert_eq(Numeric.concatenate((self.a[:3], self.a[3:])), [0,1,2,3,4,5]) File "test.py", line 28, in assert_eq assert eq(a,b) File "test.py", line 24, in eq (aa.shape, a, ab.shape, b)) ValueError: sequences have different shapes: a(3,)=array([0, 1, 2]) b(6,)=[0, 1, 2, 3, 4, 5] ====================================================================== ERROR: Test the diagonal function. ---------------------------------------------------------------------- Traceback (most recent call last): File "test.py", line 584, in testDiagonal assert_eq(Numeric.diagonal(c,1), [[2,7,4], [2,7,4]]) File "test.py", line 28, in assert_eq assert eq(a,b) File "test.py", line 24, in eq (aa.shape, a, ab.shape, b)) ValueError: sequences have different shapes: a(4, 2)=array([[5, 1], [6, 2], [7, 3], [8, 4]]) b(2, 3)=[[2, 7, 4], [2, 7, 4]] ====================================================================== ERROR: Test of average function. ---------------------------------------------------------------------- Traceback (most recent call last): File "test.py", line 297, in testAverage c.shape=(3,2) ValueError: total size of new array must be unchanged ====================================================================== ERROR: Test slicing, like x[1:3] ---------------------------------------------------------------------- Traceback (most recent call last): File "test.py", line 141, in testSlice assert_eq(a[0:], a) File "test.py", line 28, in assert_eq assert eq(a,b) File "test.py", line 24, in eq (aa.shape, a, ab.shape, b)) ValueError: sequences have different shapes: a(0,)=zeros((0,), 'l') b(4,)=array([1, 2, 3, 4]) ---------------------------------------------------------------------- Ran 45 tests in 0.146s FAILED (errors=4) [fedora@localhost Test]$ cd [fedora@localhost ~]$ cd /media/disk/Test/ [fedora@localhost Test]$ python test.py ......E.E...........E.........E.............. ====================================================================== ERROR: test concatenate ---------------------------------------------------------------------- Traceback (most recent call last): File "test.py", line 433, in testConcatenate assert_eq(Numeric.concatenate((self.a[:3], self.a[3:])), [0,1,2,3,4,5]) File "test.py", line 28, in assert_eq assert eq(a,b) File "test.py", line 24, in eq (aa.shape, a, ab.shape, b)) ValueError: sequences have different shapes: a(3,)=array([0, 1, 2]) b(6,)=[0, 1, 2, 3, 4, 5] ====================================================================== ERROR: Test the diagonal function. ---------------------------------------------------------------------- Traceback (most recent call last): File "test.py", line 584, in testDiagonal assert_eq(Numeric.diagonal(c,1), [[2,7,4], [2,7,4]]) File "test.py", line 28, in assert_eq assert eq(a,b) File "test.py", line 24, in eq (aa.shape, a, ab.shape, b)) ValueError: sequences have different shapes: a(4, 2)=array([[5, 1], [6, 2], [7, 3], [8, 4]]) b(2, 3)=[[2, 7, 4], [2, 7, 4]] ====================================================================== ERROR: Test of average function. ---------------------------------------------------------------------- Traceback (most recent call last): File "test.py", line 297, in testAverage c.shape=(3,2) ValueError: total size of new array must be unchanged ====================================================================== ERROR: Test slicing, like x[1:3] ---------------------------------------------------------------------- Traceback (most recent call last): File "test.py", line 141, in testSlice assert_eq(a[0:], a) File "test.py", line 28, in assert_eq assert eq(a,b) File "test.py", line 24, in eq (aa.shape, a, ab.shape, b)) ValueError: sequences have different shapes: a(0,)=zeros((0,), 'l') b(4,)=array([1, 2, 3, 4]) ---------------------------------------------------------------------- Ran 45 tests in 0.119s FAILED (errors=4)
I am pretty sure that quite a few upstream devs are not aware of the fact that their packages may break on 64bit arches with python-2.5 due to numeric. Maybe this will convince them to finally move to numpy ;)
I'll ping the pymol developer and inquire about numpy.
You may already be aware, this "Porting to Numpy" page specifically mentions pygame and pygtk... even including patches. It's done by the SciPy people... why doesn't upstream do this themselves? The page, however, doesn't seem to have been modified since February: http://www.scipy.org/Porting_to_NumPy pymol, at least recent versions, seem to require numpy. biopython still requires Numeric as of March 2007. Their web site implies they will be porting to numpy.
I just talked to the pymol maintainer and he pointed out to me that numeric is not strictly required for pymol. As a matter of fact, the default in setup.py is to not use numeric (via commenting out _PYMOL_NUMPY); since our ebuilds don't seem to change this behavior (je_fro might want to correct me here) it looks to me as if numeric is not actually used by pymol at the moment and can be removed from DEPEND. Markus
Yup, you're absolutely right. I'm removing the numeric dependency in pymol-0.99_rc10.
pycdf has been cleaned up per bug #181778.
From the biopython site: "Note that BioPython has not (yet) switched to the 'new' numpy library. You need the 'old' Numeric library, version 24.2 is recommended" Hopefully the transition is in the works...
Status update: dev-python/f2py-* stable numpy on ia64 and x86, then sunset it or update it from numpy dev-python/fonttools sunset it? alternative packages? dev-python/gnuplot-py needs patch dev-python/matplotlib lives well without numeric dev-python/pyclimate-* does not work without numeric, dead upstream, no revdeps dev-python/pygame-* needs patch: http://www.scipy.org/Porting_to_NumPy / pygame-1.8 will support numpy dev-python/pygtk-* needs patch: http://www.scipy.org/Porting_to_NumPy http://bugzilla.gnome.org/show_bug.cgi?id=397544 dev-python/pyqwt needs bump dev-python/python-biggles ported in CVS dev-python/rpy needs patch: http://www.scipy.org/Porting_to_NumPy dev-python/scientificpython next stable version with numpy dev-python/ttfquery sunset it? alternative packages? dev-python/visual-* numeric is optional, alternatively it can use numarray games-rpg/galaxymage reported upstream https://gna.org/bugs/index.php?9528 gnome-extra/music-applet low use of numeric, contacted upstream sci-biology/biopython seems that port in its way upstream, not ready sci-libs/plplot reported upstream http://sourceforge.net/tracker/index.php?func=detail&aid=1755542&group_id=2915&atid=202915 sci-libs/pymmlib needs bump sci-physics/camfr ported version is coming soon!
dev-python/pyopengl is on the list too, but it's missing dev-python/numeric dependency.
(In reply to comment #18) > Status update: > > dev-python/fonttools sunset it? alternative packages? The new version in the tree uses numpy. > dev-python/gnuplot-py needs patch I've backported upstream's patches for this one. I'm waiting numpy to have enough keywords to do a revbump. > dev-python/pygtk-* needs patch: There's a working patch and an ebuild on bug 176914. It'll need testing before we can commit it to the tree. > dev-python/python-biggles ported in CVS I've contacted upstream to learn when they're planning to release a new version. If I don't hear from them soon, I'll backport the changes in CVS. > dev-python/ttfquery sunset it? alternative packages? The new version in the tree uses numpy.
pbienst just commited a new camfr bump. That makes one less package to port ;-)
camfr fixed.
*** Bug 209767 has been marked as a duplicate of this bug. ***
Regarding biopython, see http://portal.open-bio.org/pipermail/biopython-dev/2007-March/002722.html for some details. But, I see numpy referenced in installation docs ... http://www.biopython.org/DIST/docs/install/Installation.html ... so it seems biopython ebuild could get changed. BTW, numpy-1.1.0 is out.
For the biopython issue, watch http://bugzilla.open-bio.org/show_bug.cgi?id=2516 and http://bugzilla.open-bio.org/show_bug.cgi?id=2251. The install docs I have mentioned in previous comment were not up-to-date and will get fixed in a while.
For the record, numeric fails with python-2.6 which is scheduled to go stable soon. >>> Source compiled. ......E.............E......E..E.............. ====================================================================== ERROR: test concatenate ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/tmp/portage/dev-python/numeric-24.2-r6/work/Numeric-24.2/Test/test.py", line 433, in testConcatenate assert_eq(Numeric.concatenate((self.a[:3], self.a[3:])), [0,1,2,3,4,5]) File "/var/tmp/portage/dev-python/numeric-24.2-r6/work/Numeric-24.2/Test/test.py", line 28, in assert_eq assert eq(a,b) File "/var/tmp/portage/dev-python/numeric-24.2-r6/work/Numeric-24.2/Test/test.py", line 24, in eq (aa.shape, a, ab.shape, b)) ValueError: sequences have different shapes: a(3,)=array([0, 1, 2]) b(6,)=[0, 1, 2, 3, 4, 5] ====================================================================== ERROR: Test of average function. ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/tmp/portage/dev-python/numeric-24.2-r6/work/Numeric-24.2/Test/test.py", line 297, in testAverage c.shape=(3,2) ValueError: total size of new array must be unchanged ====================================================================== ERROR: Test various object arrays ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/tmp/portage/dev-python/numeric-24.2-r6/work/Numeric-24.2/Test/test.py", line 334, in testObject a = Numeric.array([f,w,b],'O') ValueError: invalid input sequence ====================================================================== ERROR: Test slicing, like x[1:3] ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/tmp/portage/dev-python/numeric-24.2-r6/work/Numeric-24.2/Test/test.py", line 141, in testSlice assert_eq(a[0:], a) File "/var/tmp/portage/dev-python/numeric-24.2-r6/work/Numeric-24.2/Test/test.py", line 28, in assert_eq assert eq(a,b) File "/var/tmp/portage/dev-python/numeric-24.2-r6/work/Numeric-24.2/Test/test.py", line 24, in eq (aa.shape, a, ab.shape, b)) ValueError: sequences have different shapes: a(0,)=zeros((0,), 'l') b(4,)=array([1, 2, 3, 4]) ---------------------------------------------------------------------- Ran 45 tests in 0.153s FAILED (errors=4)
It appears nothing depends on numeric anymore. The last to maintain it was Fabian Groffen, though I'm not sure why. Fabian, is there any reason to keep numeric around?
I can't imagine me maintaining any piece of python software. I did add patches/changes from the Prefix overlay, though. I think you can just proceed.
(In reply to comment #27) > It appears nothing depends on numeric anymore. That's wrong. There are still a couple of ebuild which contain it as *DEPEND and are not masked.
Okay, I used equery to check. What did you use?
qgrep -v dev-python/numeric|sed -e "s|:.*$||g" which gave following packages: dev-python/pyclimate-1.2.1 dev-python/pyclimate-1.2.1-r1 version 1.2.2 has no numeric dep dev-python/pygtk-2.12.1-r2 dev-python/pygtk-2.14.1 has versions w/o numeric dep. Interestingly 2 of 6 have. dev-python/visual-3.2.9-r2 version 5* which is in ~arch doesn't depend on numeric games-rpg/galaxymage-0.3.0 is the only version sci-chemistry/mead-2.2.7 is latest version and has optional dep of numeric for python support. sci-libs/plplot-5.5.2 sci-libs/pymmlib-0.9.7
sci-libs/plplot-5.5.2 All newer versions are clean sci-libs/pymmlib-0.9.7 Version 1* is clean
Sorry my fault.
