Good day Gents, I believe there are really two bugs here. One is the build failure on 32-bit, and the other is flaky autopkgtest execution. Errors on 32-bit architectures are stable and in every cases are a variation around type mismatches, because the test suite looks to assume running on 64-bit platforms. Here is an example of one of the many such error:
E ValueError: Buffer dtype mismatch, expected 'const long' but got
'long long'
And another one:
E Exception: Starts/Ends not int64 or int32: int64
E Falsifying example: test_merge(
E strand=True,
E
gr=+--------------+-----------+-----------+------------+-----------+--------------+
E | Chromosome | Start | End | Name | Score
| Strand |
E | (category) | (int64) | (int64) | (object) | (int64)
| (category) |
E
|--------------+-----------+-----------+------------+-----------+--------------|
E | chr1 | 1 | 2 | a | 0
| + |
E
+--------------+-----------+-----------+------------+-----------+--------------+
E Stranded PyRanges object has 1 rows and 6 columns from 1
chromosomes.
E For printing, the PyRanges was sorted on Chromosome and
Strand., # or any other generated value
E )
Error logs do not fit in my scrollback of 8k lines. In this
case, I believe the sanest approach to resolve the situation is
to skip tests on non-64-bit and move on. The package is a
scientific application, and 32-bit support has gone the way of
the dodo in that field. I don't expect substancial regressions
beyond the types mismatches reported by the test suite if
someone happens to have interest in running this sort of
workload on 32-bit.
Santiago, about the errors you witnessed with pyranges on random
occurrences, do you have build logs somewhere? The package has
a history of heavy ressource usage at test time, and I suspect
bad parallelism conditions would have caused e.g. out of memory
conditions. I've had 0% failure rate on my end after many
tries, but also lowish cores count combined to stupidly large
amount of swap along my RAM. There is also the possibility of
having run into race conditions, but the rate of failures you
hit does not match rare conditions (unless you threw several
dozens of cores at the problem). The package has been a problem
with ressource consumption to other contributors in the past, so
I think I will drop parallelism anyway.
Have a nice day, :)
--
.''`. Étienne Mollier <emoll...@debian.org>
: :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/pts/3, please excuse my verbosity
`- on air: Asia - Time Again
signature.asc
Description: PGP signature
