[EMAIL PROTECTED] writes: > On Mon, Jul 7, 2008 at 2:12 PM, Matthias Klose <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
