That workaround didn't work. I patched the makefile to make the tests verbose in order to avoid timeout during tests. However timeout still happened:
https://buildd.debian.org/status/package.php?p=lapack&suite=experimental That means the 4 weird architectures got stuck at a strange line due to some reason. Should we disable the BLAS64/LAPACK64 builds for the 4 architectures and head towards openblas64? mips64el, s390x, ppc64, sparc64, they are not typical architectures used for intensive scientific computing. On 2019-09-04 02:21, Mo Zhou wrote: > Finally the 3.8.0-3 build result on all architectures > are available: > https://buildd.debian.org/status/package.php?p=lapack&suite=experimental > It passed on all architectures except 4 (mips64el, ppc64, sparc64, > s390x) > that weirdly timeout during the tests. > > Yunqiang Su (@syq) has helped me rebuild the package on > mips64el. And we found that it's just mips64el runs the test > too slow. > > The most straightforward way to mitigate the timeout issue > is to have test programs print something to stdout. However > I'm curious how the 4 architecture take half a day to finish > the tests that the others only take a few seconds. > > On 2019-08-20 17:40, Sébastien Villemot wrote: >> Le mardi 20 août 2019 à 19:29 +0200, Gilles Filippini a écrit : >>> Mo Zhou a écrit le 20/08/2019 à 18:21 : >>> > On 2019-08-20 16:15, Sébastien Villemot wrote: >>> > > I realize that I don’t know what we should put in the Architecture >>> > > field in debian/control for the BLAS64/LAPACK64 packages. AFAIK there >>> > > is no 64-bit wildcard. >>> > > >>> > > One option is to painfully list all the existing 64-bit architectures >>> > > (including ports), but this is not very maintainable over the long-run. >>> > > Is there a better option? I guess we’re not the first ones to face this >>> > > problem. >>> > >>> > dpkg-architecture has a flag: >>> > >>> > DEB_HOST_ARCH_BITS=64 (on amd64) >>> > >>> > that can be used in d/rules. >>> > >>> > For d/control I cannot think of anything other than manually listing. >>> >>> You can keep 'Architecture: any' in d/control, and set DH_OPTIONS in >>> d/rules to filter out the binary package with '-N<pkgname>'. >> >> Thanks for this tip! It is much better than manually listing the >> architectures.
