Bug#919929: blis breaks python-scipy autopkgtest
reassing 919929 src:python-scipy 1.1.0-2 retitle 919929 python-scipy: autopkgtest fails intermittently user debian...@lists.debian.org usertags 919929 - breaks needs-update usertags 919929 flaky severity 919929 important thanks Hi Graham, Julian, On 29-01-2019 18:59, Julian Taylor wrote: > On 29.01.19 12:01, Graham Inggs wrote: >> On 2019/01/20 21:09, Paul Gevers wrote: >> From testing's test logs [1], python-scipy 1.1.0-2 passed with >> blis/0.5.1-5 on 2019-01-21 05:22:48 UTC. It then passed with >> blis/0.5.1-6 and blis/0.5.1-7, but failed with blis/0.5.1-7 on >> 2019-01-27 17:55:32 UTC. >> >> From unstable's test logs [2], python-scipy 1.1.0-2 seems to have many >> intermittent failures since 2018-12-02. That is what we call flaky behavior. >> I'm unsure what to do with this bug, perhaps re-assign to python-scipy >> only? Done so. > I am confused, scipy does not use blis. Indeed, and in the failing log one can search for "blis" and not find it at all, except for the call to autopkgtest. So the failure can't be caused by blis. > It tests libblas, openblas and atlas but blis was so far I know never > configured as a blas source in the tests. > Unless something has changed with those packages that they pull blis > this might be a false positive. Yes it is. Julian, can you please investigate the failing log files and please make the tests robust against whatever goes wrong. If you really can't fix it and still want the tests to run, consider adding the "flaky" restriction to the tests that intermittently fail. > If blis is ready enough to be used prime time, let me know we can add it > to numpy's and scipy's testsuites. No idea, and no opinion about that. Paul signature.asc Description: OpenPGP digital signature
Bug#919929: blis breaks python-scipy autopkgtest
On 29.01.19 12:01, Graham Inggs wrote: > Hi Paul > > On 2019/01/20 21:09, Paul Gevers wrote: >> With a recent upload of blis the autopkgtest of python-scipy fails in >> testing when that autopkgtest is run with the binary packages of blis >> from unstable. It passes when run with only packages from testing. In >> tabular form: >> pass fail >> blis from testing 0.5.1-5 >> python-scipy from testing 1.1.0-2 >> all others from testing from testing > > From testing's test logs [1], python-scipy 1.1.0-2 passed with > blis/0.5.1-5 on 2019-01-21 05:22:48 UTC. It then passed with > blis/0.5.1-6 and blis/0.5.1-7, but failed with blis/0.5.1-7 on > 2019-01-27 17:55:32 UTC. > > From unstable's test logs [2], python-scipy 1.1.0-2 seems to have many > intermittent failures since 2018-12-02. > > I'm unsure what to do with this bug, perhaps re-assign to python-scipy > only? I am confused, scipy does not use blis. It tests libblas, openblas and atlas but blis was so far I know never configured as a blas source in the tests. Unless something has changed with those packages that they pull blis this might be a false positive. If blis is ready enough to be used prime time, let me know we can add it to numpy's and scipy's testsuites.
Bug#919929: blis breaks python-scipy autopkgtest
Hi Paul On 2019/01/20 21:09, Paul Gevers wrote: With a recent upload of blis the autopkgtest of python-scipy fails in testing when that autopkgtest is run with the binary packages of blis from unstable. It passes when run with only packages from testing. In tabular form: passfail blis from testing0.5.1-5 python-scipy from testing1.1.0-2 all others from testingfrom testing From testing's test logs [1], python-scipy 1.1.0-2 passed with blis/0.5.1-5 on 2019-01-21 05:22:48 UTC. It then passed with blis/0.5.1-6 and blis/0.5.1-7, but failed with blis/0.5.1-7 on 2019-01-27 17:55:32 UTC. From unstable's test logs [2], python-scipy 1.1.0-2 seems to have many intermittent failures since 2018-12-02. I'm unsure what to do with this bug, perhaps re-assign to python-scipy only? Regards Graham [1] https://ci.debian.net/packages/p/python-scipy/testing/amd64/ [2] https://ci.debian.net/packages/p/python-scipy/unstable/amd64/
Bug#919929: blis breaks python-scipy autopkgtest
Source: blis, python-scipy
Control: found -1 blis/0.5.1-5
Control: found -1 python-scipy/1.1.0-2
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update
Dear maintainers,
With a recent upload of blis the autopkgtest of python-scipy fails in
testing when that autopkgtest is run with the binary packages of blis
from unstable. It passes when run with only packages from testing. In
tabular form:
passfail
blis from testing0.5.1-5
python-scipy from testing1.1.0-2
all others from testingfrom testing
I copied some of the output at the bottom of this report. On a quick
view, similar errors occur for python3.
Currently this regression is blocking the migration of blis to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package? If needed, please change the bug's severity.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=blis
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-scipy/1739165/log.gz
=== FAILURES
===
TestInt32Overflow.test_matvecs
self =
@pytest.mark.slow
def test_matvecs(self):
# Check *_matvecs routines
n = self.n
i = np.array([0, n-1])
j = np.array([0, n-1])
data = np.array([1, 2], dtype=np.int8)
m = coo_matrix((data, (i, j)))
b = np.ones((n, n), dtype=np.int8)
for sptype in (csr_matrix, csc_matrix, bsr_matrix):
m2 = sptype(m)
> r = m2.dot(b)
b = array([[1, 1, 1, ..., 1, 1, 1],
[1, 1, 1, ..., 1, 1, 1],
[1, 1, ...],
[1, 1, 1, ..., 1, 1, 1],
[1, 1, 1, ..., 1, 1, 1]], dtype=int8)
data = array([1, 2], dtype=int8)
i = array([0, 4])
j = array([0, 4])
m = <5x5 sparse matrix of type ''
with 2 stored elements in COOrdinate format>
m2 = <5x5 sparse matrix of type ''
with 2 stored elements in Compressed Sparse Row format>
n = 5
self =
sptype =
/usr/lib/python2.7/dist-packages/scipy/sparse/tests/test_sparsetools.py:142:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
/usr/lib/python2.7/dist-packages/scipy/sparse/base.py:361: in dot
return self * other
/usr/lib/python2.7/dist-packages/scipy/sparse/base.py:470: in __mul__
return self._mul_multivector(other)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
self = <5x5 sparse matrix of type ''
with 2 stored elements in Compressed Sparse Row format>
other = array([[1, 1, 1, ..., 1, 1, 1],
[1, 1, 1, ..., 1, 1, 1],
[1, 1, ...],
[1, 1, 1, ..., 1, 1, 1],
[1, 1, 1, ..., 1, 1, 1]], dtype=int8)
def _mul_multivector(self, other):
M,N = self.shape
n_vecs = other.shape[1] # number of column vectors
result = np.zeros((M,n_vecs), dtype=upcast_char(self.dtype.char,
> other.dtype.char))
E MemoryError
M = 5
N = 5
n_vecs = 5
other = array([[1, 1, 1, ..., 1, 1, 1],
[1, 1, 1, ..., 1, 1, 1],
[1, 1, ...],
[1, 1, 1, ..., 1, 1, 1],
[1, 1, 1, ..., 1, 1, 1]], dtype=int8)
self = <5x5 sparse matrix of type ''
with 2 stored elements in Compressed Sparse Row format>
/usr/lib/python2.7/dist-packages/scipy/sparse/compressed.py:469: MemoryError
__ TestInt32Overflow.test_dia_matvec
___
self =
@pytest.mark.slow
def test_dia_matvec(self):
# Check: huge dia_matrix _matvec
n = self.n
> data = np.ones((n, n), dtype=np.int8)
n = 5
self =
/usr/lib/python2.7/dist-packages/scipy/sparse/tests/test_sparsetools.py:155:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _
shape = (5, 5), dtype = , order = 'C'
@set_module('numpy')
def ones(shape, dtype=None, order='C'):
"""
Return a new array of given shape and type, filled with ones.
Parameters
--
shape : int or sequence of ints
Shape of the new array, e.g., ``(2, 3)`` or ``2``.
dtype : data-type, optional
The desired data-type for the array, e.g., `numpy.int8`.
Default is
`numpy.float64`.
order : {'C', 'F'}, optional, default: C
Whether to store multi-dimensional data in row-major
(C-style) or column-major (Fortran-style) order in
