[Debian-science-sagemath] Buster todo list

[Tobias Hansen]

On 1/23/19 8:38 AM, Ximin Luo wrote:
> François Bissey:
>> You may be interested in the discussion I had with other people at
>> https://trac.sagemath.org/ticket/26596#comment:21
>> and
>> https://github.com/cschwan/sage-on-gentoo/commit/1a5fefec74c222ee5d0673bb439c6d5a3b0c6e1e#commitcomment-30999803
>>
>> My summary:
>> There is a subtle difference of behavior in xerblas as shipped by openblas (as a part of blas) and netlib's lapack function of the same name (shipped as part of lapack). If you ship an integrated openblas with lapack included you get the base blas function from openblas (that's the one vanilla sage sees). If you have a separate lapack based on netlib you get to load netlib's xerblas first. You may find that if you preload openblas first the problem may go away.
>>
> Thanks for the hint. Our problem was slightly similar but different.
>
> It seems that in Debian, since we install both atlas and lapack, the "system" libblas.so and liblapack.so by default point to the atlas implementations. Once I run "sudo update-alternatives" to make the following changes:
>
> update-alternatives: using /usr/lib/x86_64-linux-gnu/blas/libblas.so.3 to provide /usr/lib/x86_64-linux-gnu/libblas.so.3 (libblas.so.3-x86_64-linux-gnu) in manual mode
> update-alternatives: using /usr/lib/x86_64-linux-gnu/blas/libblas.so to provide /usr/lib/x86_64-linux-gnu/libblas.so (libblas.so-x86_64-linux-gnu) in manual mode
> update-alternatives: using /usr/lib/x86_64-linux-gnu/lapack/liblapack.so to provide /usr/lib/x86_64-linux-gnu/liblapack.so (liblapack.so-x86_64-linux-gnu) in manual mode
> update-alternatives: using /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3 to provide /usr/lib/x86_64-linux-gnu/liblapack.so.3 (liblapack.so.3-x86_64-linux-gnu) in manual mode
>
> then matrix_double_dense.pyx passes again. All of those source files come from the lapack package.
>
> (Actually, narrowing it down further, only libblas.so.3 was required to be not-atlas, the other files could come from atlas. But it's cleaner and probably safer to switch them all at once.)
>
> So it seems that atlas is the culprit here, there is something wrong with its zgees or xerbla implementation. Tobias do you know why we are using both atlas and lapack at the same time? Can we just avoid atlas completely?

We used to use openblas on the architectures that it supports and atlas on the others. We changed to atlas in 8.3-1~exp1 to "work around crashes with openblas 0.3.2" (fom changelog).

I don't know why we depend on lapack. I think that dependency has been there a long time. Feel free to change it. Maybe we should revert the change from 8.3-1~exp1 and remove lapack?

Best,

Tobias