On Mon, Feb 8, 2016 at 10:23 AM, Matthew Brett <matthew.br...@gmail.com> wrote: > On Mon, Feb 8, 2016 at 3:57 AM, Evgeni Burovski > <evgeny.burovs...@gmail.com> wrote: >> ---------- Forwarded message ---------- >> From: Evgeni Burovski <evgeny.burovs...@gmail.com> >> Date: Mon, Feb 8, 2016 at 11:56 AM >> Subject: Re: [Numpy-discussion] Multi-distribution Linux wheels - please test >> To: Discussion of Numerical Python <numpy-discussion@scipy.org> >> >> >> On Sat, Feb 6, 2016 at 8:26 PM, Matthew Brett <matthew.br...@gmail.com> >> wrote: >>> Hi, >>> >>> As some of you may have seen, Robert McGibbon and Nathaniel have just >>> guided a PEP for multi-distribution Linux wheels past the approval >>> process over on distutils-sig: >>> >>> https://www.python.org/dev/peps/pep-0513/ >>> >>> The PEP includes a docker image on which y'all can build wheels which >>> match the PEP: >>> >>> https://quay.io/repository/manylinux/manylinux >>> >>> Now we're at the stage where we need stress-testing of the built >>> wheels to find any problems we hadn't thought of. >>> >>> I've built numpy and scipy wheels here: >>> >>> https://nipy.bic.berkeley.edu/manylinux/ >>> >>> So, if you have a Linux distribution handy, we would love to hear from >>> you about the results of testing these guys, maybe on the lines of: >>> >>> pip install -f https://nipy.bic.berkeley.edu/manylinux numpy scipy >>> python -c 'import numpy; numpy.test()' >>> python -c 'import scipy; scipy.test()' >>> >>> These manylinux wheels should soon be available on pypi, and soon >>> after, installable with latest pip, so we would like to fix as many >>> problems as possible before going live. >>> >>> Cheers, >>> >>> Matthew >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion@scipy.org >>> https://mail.scipy.org/mailman/listinfo/numpy-discussion >> >> >> >> Hi, >> >> Bog-standard Ubuntu 12.04, fresh virtualenv: >> >> Python 2.7.3 (default, Jun 22 2015, 19:33:41) >> [GCC 4.6.3] on linux2 >> Type "help", "copyright", "credits" or "license" for more information. >>>>> import numpy >>>>> numpy.__version__ >> '1.10.4' >>>>> numpy.test() >> Running unit tests for numpy >> NumPy version 1.10.4 >> NumPy relaxed strides checking option: False >> NumPy is installed in >> /home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/numpy >> Python version 2.7.3 (default, Jun 22 2015, 19:33:41) [GCC 4.6.3] >> nose version 1.3.7 >> >> <snip> >> >> ====================================================================== >> ERROR: test_multiarray.TestNewBufferProtocol.test_relaxed_strides >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File >> "/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/nose/case.py", >> line 197, in runTest >> self.test(*self.arg) >> File >> "/home/br/virtualenvs/manylinux/local/lib/python2.7/site-packages/numpy/core/tests/test_multiarray.py", >> line 5366, in test_relaxed_strides >> fd.write(c.data) >> TypeError: 'buffer' does not have the buffer interface >> >> ---------------------------------------------------------------------- >> >> >> * Scipy tests pass with one error in TestNanFuncs, but the interpreter >> crashes immediately afterwards. >> >> >> Same machine, python 3.5: both numpy and scipy tests pass. > > Ouch - great that you found these, I'll take a look,
I think these are problems with numpy and Python 2.7.3 - because I got the same "TypeError: 'buffer' does not have the buffer interface" on numpy with OS X with Python.org python 2.7.3, installing from a wheel, or installing from source. I also get a scipy segfault with scipy 0.17.0 installed from an OSX wheel, with output ending: test_check_finite (test_basic.TestLstsq) ... /Users/mb312/.virtualenvs/test/lib/python2.7/site-packages/scipy/linalg/basic.py:884: RuntimeWarning: internal gelsd driver lwork query error, required iwork dimension not returned. This is likely the result of LAPACK bug 0038, fixed in LAPACK 3.2.2 (released July 21, 2010). Falling back to 'gelss' driver. warnings.warn(mesg, RuntimeWarning) ok test_random_complex_exact (test_basic.TestLstsq) ... FAIL test_random_complex_overdet (test_basic.TestLstsq) ... Bus error This is so whether scipy is running on top of source- or wheel-built numpy, and for a scipy built from source. Same numpy error installing on a bare Ubuntu 12.04, either installing from a wheel built on 12.04 on travis: pip install -f http://travis-wheels.scikit-image.org --trusted-host travis-wheels.scikit-image.org --no-index numpy or from numpy built from source. I can't replicate the segfault with manylinux wheels and scipy. On the other hand, I get a new test error for numpy from manylinux, scipy from manylinux, like this: $ python -c 'import scipy.linalg; scipy.linalg.test()' ====================================================================== FAIL: test_decomp.test_eigh('general ', 6, 'F', True, False, False, (2, 4)) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/usr/local/lib/python2.7/dist-packages/scipy/linalg/tests/test_decomp.py", line 658, in eigenhproblem_general assert_array_almost_equal(diag2_, ones(diag2_.shape[0]), DIGITS[dtype]) File "/usr/local/lib/python2.7/dist-packages/numpy/testing/utils.py", line 892, in assert_array_almost_equal precision=decimal) File "/usr/local/lib/python2.7/dist-packages/numpy/testing/utils.py", line 713, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not almost equal to 4 decimals (mismatch 100.0%) x: array([ 0., 0., 0.], dtype=float32) y: array([ 1., 1., 1.]) ---------------------------------------------------------------------- Ran 1507 tests in 14.928s FAILED (KNOWNFAIL=4, SKIP=1, failures=1) This is a very odd error, which we don't get when running over a numpy installed from source, linked to ATLAS, and doesn't happen when running the tests via: nosetests /usr/local/lib/python2.7/dist-packages/scipy/linalg So, something about the copy of numpy (linked to openblas) is affecting the results of scipy (also linked to openblas), and only with a particular environment / test order. If you'd like to try and see whether y'all can do a better job of debugging than me: # Run this script inside a docker container started with this incantation: # docker run -ti --rm ubuntu:12.04 /bin/bash apt-get update apt-get install -y python curl apt-get install libpython2.7 # this won't be necessary with next iteration of manylinux wheel builds curl -LO https://bootstrap.pypa.io/get-pip.py python get-pip.py pip install -f https://nipy.bic.berkeley.edu/manylinux numpy scipy nose python -c 'import scipy.linalg; scipy.linalg.test()' Cheers, Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
