Re: RFR: src:lapack's 64bit-indexing variant

[Mo Zhou <lumin@debian.org>]

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.