Fixed in python-numeric-24.2-1.

If I'm not mistaken this package is no longer maintained upstream, so this
update may be too little too late.  But let me know if you'd like me to backport
this update to Fedora Core 6.

> If I'm not mistaken this package is no longer maintained upstream, so this
> update may be too little too late.  But let me know if you'd like me to backport
> this update to Fedora Core 6.

Would be great if you would release 24.2 as FC6 update.

I have done some work to let Numeric use the BLAS and LAPACK already available
in Fedora Extras and also link Numeric with gsl. On the way I fixed minor spec
issue. See patches.

I guess this can be done in FC7 after the Extras Core merge?

BTW: seems like pygtk2 is the only thing in Fedora *Core* which requires
python-numeric, however I all I get when grepping is:

$ grep -ic numeric $(rpm -ql pygtk2) | grep -v :0
/usr/lib64/python2.4/site-packages/gtk-2.0/gtk/_gtk.so:2
/usr/share/doc/pygtk2-2.10.3/MAPPING:2
/usr/share/doc/pygtk2-2.10.3/NEWS:3
/usr/share/doc/pygtk2-2.10.3/README:1
$ strings /usr/lib64/python2.4/site-packages/gtk-2.0/gtk/_gtk.so | grep -i Numeric
gtk_spin_button_get_numeric
gtk_spin_button_set_numeric
Expected numeric argument for column.
i:GtkSpinButton.set_numeric

Can python-numeric be moved to Extras?

There we have these:

python-matplotlib-0:0.87.7-1.fc6.x86_64
fonttools-0:2.0-0.10.20060223cvs.fc6.x86_64
rpy-0:0.4.6-15.fc6.x86_64
rpy-0:0.4.6-13.fc6.x86_64
pygsl-0:0.3.2-6.fc6.x86_64
gnome-sudoku-0:0.5.0-1.fc6.noarch
pygame-0:1.7.1-9.fc6.x86_64

SPEC patch:

--- python-numeric.spec.old     2006-12-07 17:38:06.000000000 +0100
+++ python-numeric.spec 2007-01-01 21:58:59.000000000 +0100
@@ -2,21 +2,24 @@

 Name: python-numeric
 Version: 24.2
-Release: 3
+Release: 3.1%{?dist}
 License: Python
 Group: Development/Languages
 Summary: Numerical Extension to Python
 URL: http://numpy.sourceforge.net
-BuildRoot: %{_tmppath}/%{name}-%{version}-root
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+Requires: gsl, blas, lapack
 Source: Numeric-%{version}.tar.gz

 ### Patches ###

 Patch1: Numeric-24.2-fix-dlamc3.patch
+Patch2: Numeric-24.2-gsl-blas-lapack.patch

 ### Build Dependencies ###

 BuildRequires: python2-devel
+BuildRequires: gsl-devel blas-devel lapack-devel

 %description
 Numeric is a python module that provides support for numerical
@@ -25,6 +28,7 @@
 %prep
 %setup -q -n Numeric-%{version}
 %patch1 -p1 -b .fix-dlamc3
+%patch2 -p1 -b .gsl-blas-lapack

 %build
 env CFLAGS="$RPM_OPT_FLAGS" /usr/bin/python setup.py build
@@ -44,6 +48,10 @@
 %{_includedir}/python*/Numeric/

 %changelog
+* Mon Jan  1 2007 Terje Rosten <terje.rosten@ntnu.no> - 24.2-3.1
+- Add patch to use link with gsl, blas and lapack.
+- Some rpmlint fixes: buildroot, disttag
+
 * Thu Dec  7 2006 Jeremy Katz <katzj@redhat.com> - 24.2-3
 - rebuild against python 2.5


Numeric-24.2-gsl-blas-lapack.patch:

--- Numeric-24.2.old/customize.py       2005-11-13 03:40:14.000000000 +0100
+++ Numeric-24.2/customize.py   2007-01-01 20:19:17.000000000 +0100
@@ -19,10 +19,10 @@
 lapack_extra_link_args = []

 # Example: using ATLAS
-if 0:
+if 1:
     use_system_lapack = 1
-    lapack_library_dirs = ['/usr/lib/atlas']
-    lapack_libraries = ['lapack', 'cblas', 'f77blas', 'atlas', 'g2c']
+    lapack_library_dirs = ['/usr']
+    lapack_libraries = ['lapack', 'gslcblas', 'blas', 'gfortran' ]

 # Example: Some Linux distributions have ATLAS, but not LAPACK (if you're
 #          liblapack file is smaller than a megabyte, this is probably you)
@@ -51,7 +51,7 @@

 # Example: using the Gnu Scientific Library's CBLAS interface
 # This is useful if GSL was compiled against an optimized Fortran BLAS.
-if 0:
+if 1:
     use_dotblas = 1
     dotblas_include_dirs = ['/usr/include/gsl/']
     dotblas_cblas_header = '<gsl_cblas.h>'

I'm releasing 24.2 as a Fedora Core 6 Update as you requested.

Please file a separate bug report for the rest of your questions.

I don't think we can move this package to Extras at this time since a Core
package depends on it.  If you can prove that pygtk2 can safely drop this
dependency, then perhaps it can be moved.  But I'm not an authority on this kind
of thing.