[Python-modules-team] Bug#489726: should numpy be built with atlas?

Matthias Klose doko at cs.tu-berlin.de
Tue Jul 8 09:52:38 UTC 2008


otizonaizit at yahoo.com writes:
> On Mon, Jul 7, 2008 at 2:12 PM, Matthias Klose <doko at cs.tu-berlin.de> wrote:
> > Package: python-numpy
> > Version: 1:1.1.0-2
> > Severity: serious
> >
> > python-numpy now has an unconditional dependency on libatlas3gf-base,
> > needing the "specialized" atlas libraries as a runtime
> > dependency. Users still should have the option to use the standard
> > blas and lapack libs instead of the untested/unmaintained atlas
> > libraries in debian.
> 
> The problem is that the new (>1.0) numpy building system needs ATLAS 
> at compile time to enable fast matrix-multiplication. If ATLAS is not found
> at compile time, numpy.core._dotblas.so is not built and slow matrix 
> multiplication is used even if the end user has ATLAS installed. In the old
> numpy _dotblas.so was always compiled using refblas and the end user 
> would still have had the option of using ATLAS. I'm not sure I understand 
> why ATLAS is now needed at compile time, but look here:
> http://scipy.org/scipy/numpy/ticket/667
> and here:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464784
> 
> I think python-numpy should stay as it is now and a bug-wishlist should be 
> reported to the atlas package to encourage packaging of the new stable
>  version (3.8.2). Filing a ticket on numpy trac may help, but the fate of 
> ticket 667 seems to indicate that there's no will of fixing this bug upstream...

thanks for the update. Looking at the blas package, I see that the
cblas library is included in libblas3.  So it looks like the numpy
check is wrong, testing for a package name, and not for a
feature. This seems to explain why it did work in etch, and this
should be fixed in python-numpy.

  Matthias





More information about the Python-modules-team mailing list