Control: reassign -1 libblas3 3.12.1-6
Control: affects -1 + python3-numpy
Control: tags -1 + moreinfo
On Sat, 04 Oct 2025 at 22:00:13 +0200, Matthias Urlichs wrote:
I had to do this:
/usr/lib/x86_64-linux-gnu$ sudo ln -s blas/libblas.so.3 .
/usr/lib/x86_64-linux-gnu$ sudo ln -s lapack/liblapack.so.3 .
... to get a plain "import numpy" to work.
This sounds like a problem with the libblas.so.3 alternative. The way it
is meant to work is something like this:
/usr/lib/x86_64-linux-gnu/libblas.so.3
-> /etc/alternatives/libblas.so.3-x86_64-linux-gnu
-> /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3
and similarly
/usr/lib/x86_64-linux-gnu/liblapack.so.3
-> /etc/alternatives/liblapack.so.3-x86_64-linux-gnu
-> /usr/lib/x86_64-linux-gnu/openblas-pthread/liblapack.so.3
(but you might have a different implementation of the alternatives, like
the reference implementations libblas3 and liblapack3, which are in blas
and lapack directories instead of the openblas-pthread directory that
contains the implementation used on my system).
If I understand the overall system correctly, numpy is meant to load the
basenames libblas.so.3 and liblapack.so.3, which in practice means
/usr/lib/x86_64-linux-gnu/libblas.so.3 and
/usr/lib/x86_64-linux-gnu/liblapack.so.3, and the various
implementations of the libblas.so.3 and liblapack.so.3 virtual packages
are responsible for providing those; in which case this wouldn't be a
python3-numpy bug.
Please check /var/log/apt - has something gone wrong with those
packages' maintainer scripts on your system?
I couldn't immediately reproduce a similar bug by installing
python3-numpy, libblas3 and liblapack3 into a debian:sid-slim podman
container.
smcv
