Re: [Numpy-discussion] ANN: NumPy 1.9.0 release candidate 1 available
On 08/27/2014 11:07 AM, Julian Taylor wrote: Hello, Almost punctually for EuroScipy we have finally managed to release the first release candidate of NumPy 1.9. We intend to only fix bugs until the final release which we plan to do in the next 1-2 weeks. I'm seeing the following errors from setup.py: non-existing path in 'numpy/f2py': 'docs' non-existing path in 'numpy/f2py': 'f2py.1' non-existing path in 'numpy/lib': 'benchmarks' It would be nice if f2py.1 was installed in /usr/share/man/man1/f2py.1. Filed as https://github.com/numpy/numpy/issues/5010 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.7.2rc1 release
On 11/3/2013 9:42 AM, Julian Taylor wrote: Hi all, I'm happy to announce the release candidate of Numpy 1.7.2. This is a bugfix only release supporting Python 2.4 - 2.7 and 3.1 - 3.3. More than 37 issues were fixed, the most important issues are listed in the release notes: https://github.com/numpy/numpy/blob/v1.7.2rc1/doc/release/1.7.2-notes.rst It is supposed to not break any existing code, so please test the releases and report any issues you find. Builds and tests okay on Fedora 20. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: Numpy 1.8.0 beta 1 release
On 09/01/2013 10:54 AM, Charles R Harris wrote: Hi all, I'm happy to announce the first beta release of Numpy 1.8.0. Please try this beta and report any issues on the numpy-dev mailing list. Source tarballs and release notes can be found at https://sourceforge.net/projects/numpy/files/NumPy/1.8.0b1/. The Windows and OS X installers will follow when the infrastructure issues are dealt with. Chuck The Fedora packages appear to build fine on F19, F20, and Rawhide. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Fwd: Package: scipy-0.11.0-0.1.rc2.fc18 Tag: f18-updates-candidate Status: failed Built by: orion
On 09/21/2012 11:41 AM, Ondřej Čertík wrote:
Hi Orion,
On Thu, Sep 20, 2012 at 2:56 PM, Orion Poplawski or...@cora.nwra.com wrote:
This is a plea for some help. We've been having trouble getting scipy to
pass all of the tests in the Fedora 18 build with python 3.3 (although it
seems to build okay in Fedora 19). Below are the logs of the build. There
appears to be some kind of memory corruption that manifests itself a little
differently on 32-bit vs. 64-bit. I really have no idea myself how to
pursue debugging this, though I'm happy to provide any more needed
information.
Thanks for testing the latest beta2 release.
Task 4509077 on buildvm-35.phx2.fedoraproject.org
Task Type: buildArch (scipy-0.11.0-0.1.rc2.fc18.src.rpm, i686)
logs:
http://koji.fedoraproject.org/koji/getfile?taskID=4509077name=build.log
This link has the following stacktrace:
/lib/libpython3.3m.so.1.0(PyMem_Free+0x1c)[0xbf044c]
/usr/lib/python3.3/site-packages/numpy/core/multiarray.cpython-33m.so(+0x4d52b)[0x42252b]
/usr/lib/python3.3/site-packages/numpy/core/multiarray.cpython-33m.so(+0xcb7c5)[0x4a07c5]
/usr/lib/python3.3/site-packages/numpy/core/multiarray.cpython-33m.so(+0xcbc5e)[0x4a0c5e]
Which indeed looks like in NumPy. Would you be able to obtain full stacktrace?
There has certainly been segfaults in Python 3.3 with NumPy, but we've
fixed all that we could reproduce. That doesn't mean there couldn't be
more. If you could nail it down a little bit more, that would be
great. I'll help once I can reproduce it somehow.
Ondrej
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Trying to get back to this as we still see it with numpy 1.7.0 and scipy 0.11.
I'm seeing a segfault in malloc_consolidate(), which seems like would only
occur if there were problems earlier, so I'm not sure a stack trace is all
that useful.
Starting program: /usr/bin/python3
/export/home/orion/redhat/BUILDROOT/scipy-0.11.0-3.fc19.x86_64/usr/lib64/python3.3/site-packages/scipy/linalg/tests/test_decomp.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib64/libthread_db.so.1.
..
Program received signal SIGSEGV, Segmentation fault.
0x003d8d67bdad in malloc_consolidate (av=av@entry=0x3d8d9b1740 main_arena)
at malloc.c:4151
4151 unlink(av, nextchunk, bck, fwd);
Here's some:
#0 0x003d8d67bdad in malloc_consolidate (av=av@entry=0x3d8d9b1740
main_arena)
at malloc.c:4151
#1 0x003d8d67d09e in _int_malloc (av=0x3d8d9b1740 main_arena,
bytes=optimized out)
at malloc.c:3422
#2 0x003d8d67f443 in __GI___libc_malloc (bytes=2632) at malloc.c:2862
#3 0x7121816c in PyArray_IterNew (obj=numpy.ndarray at remote
0xe02fd0)
at numpy/core/src/multiarray/iterators.c:385
#4 0x71218201 in PyArray_IterAllButAxis (obj=obj@entry=
numpy.ndarray at remote 0xe02fd0, inaxis=inaxis@entry=0x7fff873c)
at numpy/core/src/multiarray/iterators.c:488
#5 0x71257970 in _new_argsort (which=NPY_QUICKSORT, axis=0,
op=0xe02fd0)
at numpy/core/src/multiarray/item_selection.c:815
#6 PyArray_ArgSort (op=op@entry=0xe02fd0, axis=0, which=NPY_QUICKSORT)
at numpy/core/src/multiarray/item_selection.c:1104
#7 0x7125873a in array_argsort (self=0xe02fd0, args=optimized out,
kwds=optimized out) at numpy/core/src/multiarray/methods.c:1213
#8 0x003b74d0cc8e in call_function (oparg=optimized out,
pp_stack=0x7fff8998)
at /usr/src/debug/Python-3.3.0/Python/ceval.c:4091
#9 PyEval_EvalFrameEx (f=f@entry=
Frame 0xd3ecb0, for file
/usr/lib64/python3.3/site-packages/numpy/core/fromnumeric.py, line 681, in
argsort (a=numpy.ndarray at remote 0xe02fd0, axis=-1, kind='quicksort',
order=None, argsort=built-in method argsort of numpy.ndarray object at remote
0xe02fd0),
throwflag=throwflag@entry=0) at
/usr/src/debug/Python-3.3.0/Python/ceval.c:2703
#10 0x003b74d0de63 in PyEval_EvalCodeEx (_co=_co@entry=code at remote
0x71a8ac00,
globals=optimized out, locals=locals@entry=0x0, args=optimized out,
argcount=argcount@entry=1, kws=0xe23ab8, kwcount=kwcount@entry=0,
defs=0x71a965b8,
defcount=3, kwdefs=0x0, closure=0x0) at
/usr/src/debug/Python-3.3.0/Python/ceval.c:3462
#11 0x003b74d0c707 in fast_function (nk=0, na=1, n=optimized out,
pp_stack=
0x7fff8c88, func=function at remote 0x71160320)
at /usr/src/debug/Python-3.3.0/Python/ceval.c:4189
#12 call_function (oparg=optimized out, pp_stack=0x7fff8c88)
at /usr/src/debug/Python-3.3.0/Python/ceval.c:4112
(gdb) up 3
#3 0x7121816c in PyArray_IterNew (obj=numpy.ndarray at remote
0xe02fd0)
at numpy/core/src/multiarray/iterators.c:385
385 it = (PyArrayIterObject *)PyArray_malloc(sizeof(PyArrayIterObject));
(gdb) print *obj
$4 = {ob_refcnt = 5, ob_type
Re: [Numpy-discussion] Fwd: Package: scipy-0.11.0-0.1.rc2.fc18 Tag: f18-updates-candidate Status: failed Built by: orion
On 02/13/2013 05:18 PM, Ondřej Čertík wrote:
(gdb) up 3
#3 0x7121816c in PyArray_IterNew (obj=numpy.ndarray at remote
0xe02fd0)
at numpy/core/src/multiarray/iterators.c:385
385 it = (PyArrayIterObject
*)PyArray_malloc(sizeof(PyArrayIterObject));
(gdb) print *obj
$4 = {ob_refcnt = 5, ob_type = 0x714c6900 PyArray_Type}
(gdb) list
380 PyErr_BadInternalCall();
381 return NULL;
382 }
383 ao = (PyArrayObject *)obj;
384
385 it = (PyArrayIterObject
*)PyArray_malloc(sizeof(PyArrayIterObject));
386 PyObject_Init((PyObject *)it, PyArrayIter_Type);
387 /* it = PyObject_New(PyArrayIterObject, PyArrayIter_Type);*/
388 if (it == NULL) {
389 return NULL;
^^^ This is very useful, thanks! How can it segfault on the line 385 though?
That would suggest that something has gone terribly wrong before and
this call to malloc simply is the final nail to the coffin.
Otherwise I thought that malloc can't really segfault like this, can it?
Ondrej
Yeah, that's why I didn't think the backtrace would be very useful -
it's gone off the deep-end long before. The valgrind reports seem more
useful. Need to get the scipy debug stuff installed properly. I'm
guessing the interfacing with atlas is not correct.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane or...@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Fwd: Package: scipy-0.11.0-0.1.rc2.fc18 Tag: f18-updates-candidate Status: failed Built by: orion
On 02/13/2013 05:33 PM, Charles R Harris wrote: On Wed, Feb 13, 2013 at 5:18 PM, Ondřej Čertík ondrej.cer...@gmail.com mailto:ondrej.cer...@gmail.com wrote: Orion, On Wed, Feb 13, 2013 at 4:06 PM, Orion Poplawski or...@cora.nwra.com mailto:or...@cora.nwra.com wrote: snip dsbevx_ Looks suspicious. There was a problem with 3.3 https://github.com/scipy/scipy/pull/404 and scipy in that function which should be fixed in the next release. See also the discussion on gmane http://thread.gmane.org/gmane.comp.python.scientific.devel/17216/focus=17218. Chuck Thank you! That looks like exactly the issue! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Fwd: Package: scipy-0.11.0-0.1.rc2.fc18 Tag: f18-updates-candidate Status: failed Built by: orion
This is a plea for some help. We've been having trouble getting scipy to pass all of the tests in the Fedora 18 build with python 3.3 (although it seems to build okay in Fedora 19). Below are the logs of the build. There appears to be some kind of memory corruption that manifests itself a little differently on 32-bit vs. 64-bit. I really have no idea myself how to pursue debugging this, though I'm happy to provide any more needed information. Thanks, Orion Original Message Subject: Package: scipy-0.11.0-0.1.rc2.fc18 Tag: f18-updates-candidate Status: failed Built by: orion Date: Thu, 20 Sep 2012 21:01:54 + (UTC) From: Fedora Koji Build System build...@fedoraproject.org To: au...@fedoraproject.org, jspal...@fedoraproject.org, voro...@fedoraproject.org, torwan...@fedoraproject.org, alaguna...@fedoraproject.org, ur...@fedoraproject.org, or...@fedoraproject.org Package: scipy-0.11.0-0.1.rc2.fc18 Tag: f18-updates-candidate Status: failed Built by: orion ID: 350761 Started: Thu, 20 Sep 2012 20:39:45 UTC Finished: Thu, 20 Sep 2012 21:01:32 UTC scipy-0.11.0-0.1.rc2.fc18 (350761) failed on buildvm-33.phx2.fedoraproject.org (x86_64), buildvm-35.phx2.fedoraproject.org (i386), buildvm-34.phx2.fedoraproject.org (noarch): BuildError: error building package (arch x86_64), mock exited with status 1; see build.log for more information SRPMS: scipy-0.11.0-0.1.rc2.fc18.src.rpm Failed tasks: - Task 4509076 on buildvm-33.phx2.fedoraproject.org Task Type: buildArch (scipy-0.11.0-0.1.rc2.fc18.src.rpm, x86_64) logs: http://koji.fedoraproject.org/koji/getfile?taskID=4509076name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=4509076name=mock_output.log http://koji.fedoraproject.org/koji/getfile?taskID=4509076name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=4509076name=state.log Task 4509077 on buildvm-35.phx2.fedoraproject.org Task Type: buildArch (scipy-0.11.0-0.1.rc2.fc18.src.rpm, i686) logs: http://koji.fedoraproject.org/koji/getfile?taskID=4509077name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=4509077name=mock_output.log http://koji.fedoraproject.org/koji/getfile?taskID=4509077name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=4509077name=state.log Task 4509063 on buildvm-34.phx2.fedoraproject.org Task Type: build (f18-candidate, /scipy:cb69bd06f0d930fbe8840d89b918b617e28af63f) Closed tasks: - Task 4509064 on buildvm-30.phx2.fedoraproject.org Task Type: buildSRPMFromSCM (/scipy:cb69bd06f0d930fbe8840d89b918b617e28af63f) logs: http://koji.fedoraproject.org/koji/getfile?taskID=4509064name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=4509064name=checkout.log http://koji.fedoraproject.org/koji/getfile?taskID=4509064name=mock_output.log http://koji.fedoraproject.org/koji/getfile?taskID=4509064name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=4509064name=state.log Task Info: http://koji.fedoraproject.org/koji/taskinfo?taskID=4509063 Build Info: http://koji.fedoraproject.org/koji/buildinfo?buildID=350761 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Fwd: Package: scipy-0.11.0-0.1.rc2.fc18 Tag: f18-updates-candidate Status: failed Built by: orion
On 09/20/2012 04:04 PM, Nathaniel Smith wrote: On Thu, Sep 20, 2012 at 10:56 PM, Orion Poplawski or...@cora.nwra.com wrote: This is a plea for some help. We've been having trouble getting scipy to pass all of the tests in the Fedora 18 build with python 3.3 (although it seems to build okay in Fedora 19). Below are the logs of the build. There appears to be some kind of memory corruption that manifests itself a little differently on 32-bit vs. 64-bit. I really have no idea myself how to pursue debugging this, though I'm happy to provide any more needed information. You should probably ask the scipy list, but since we're on the numpy list... what version of numpy are you even building against? There's no released version of numpy that works with python 3.3... -n I'm building against numpy 1.7.0b2. I'll ask on the scipy list as well, but one reason I'm mentioning it here is the the backtrace on the 32-bit dump mentions numpy fuctions. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.7.0b1 release
) ^ mtrand.pyx:1140:75: undeclared name not builtin: NPY_ARRAY_ALIGNED I'm afraid I know nothing about Cython. Looks like there were a lot of changes between 1.6.2 and 1.7.0b1 in mtrand.pyx. I'll try not rebuilding and see if we see the original problem. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.7.0b1 release
On 08/22/2012 09:55 AM, Orion Poplawski wrote: On 08/21/2012 10:24 AM, Ondřej Čertík wrote: Hi, I'm pleased to announce the availability of the first beta release of NumPy 1.7.0b1. Currently in trying to support python 3.3 in Fedora Rawhide (F19) and Fedora 18 we are doing: # Regenerate Cython c sources # This is needed with numpy-1.6.2.tar.gz with python 3.3 to avoid an exception # with an import call in the generated .c file in the tarball that uses the # old default of -1: # File mtrand.pyx, line 126, in init mtrand (numpy/random/mtrand/mtrand.c:20679) # ValueError: level must be = 0 # due to the changes in import in 3.3 # Regenerating with a newer Cython fixes it: pushd numpy/random/mtrand/ rm -v mtrand.c cython mtrand.pyx popd If I drop the cython generation it builds, but the python 3 test failure I get now is: + /usr/bin/python3 -c 'import pkg_resources, numpy ; numpy.test()' /usr/lib/python3.3/site-packages/nose/core.py:247: ResourceWarning: unclosed file _io.TextIOWrapper name='/usr/lib/python3.3/site-packages/nose/usage.txt' mode='r' encoding='ANSI_X3.4-1968' os.path.dirname(__file__), 'usage.txt'), 'r').read() S! .. ..K..! .. ..K...EKK..K..S.E! .. ./usr/lib64/python3.3/zipfile.py:1513: ResourceWarning: unclosed file _io.BufferedReader name='/tmp/tmpemcede.npz' self.fp = None
Re: [Numpy-discussion] ANN: NumPy 1.7.0b1 release
On 08/22/2012 10:26 AM, Orion Poplawski wrote: On 08/22/2012 09:55 AM, Orion Poplawski wrote: On 08/21/2012 10:24 AM, Ondřej Čertík wrote: Hi, I'm pleased to announce the availability of the first beta release of NumPy 1.7.0b1. Currently in trying to support python 3.3 in Fedora Rawhide (F19) and Fedora 18 we are doing: # Regenerate Cython c sources # This is needed with numpy-1.6.2.tar.gz with python 3.3 to avoid an exception # with an import call in the generated .c file in the tarball that uses the # old default of -1: # File mtrand.pyx, line 126, in init mtrand (numpy/random/mtrand/mtrand.c:20679) # ValueError: level must be = 0 # due to the changes in import in 3.3 # Regenerating with a newer Cython fixes it: pushd numpy/random/mtrand/ rm -v mtrand.c cython mtrand.pyx popd If I drop the cython generation it builds, but the python 3 test failure I get now is: .. ERROR: Ticket #16 -- Traceback (most recent call last): File /builddir/build/BUILDROOT/numpy-1.7.0-0.2.b1.fc19.x86_64/usr/lib64/python3.3/site-packages/numpy/core/tests/test_regression.py, line 41, in test_pickle_transposed b = pickle.load(f) EOFError == ERROR: Failure: ValueError (can't handle version 187 of numpy.ndarray pickle) -- Traceback (most recent call last): File /usr/lib/python3.3/site-packages/nose/failure.py, line 37, in runTest raise self.exc_class(self.exc_val).with_traceback(self.tb) File /usr/lib/python3.3/site-packages/nose/loader.py, line 232, in generate for test in g(): File /builddir/build/BUILDROOT/numpy-1.7.0-0.2.b1.fc19.x86_64/usr/lib64/python3.3/site-packages/numpy/lib/tests/test_format.py, line 429, in test_roundtrip arr2 = roundtrip(arr) File /builddir/build/BUILDROOT/numpy-1.7.0-0.2.b1.fc19.x86_64/usr/lib64/python3.3/site-packages/numpy/lib/tests/test_format.py, line 420, in roundtrip arr2 = format.read_array(f2) File /builddir/build/BUILDROOT/numpy-1.7.0-0.2.b1.fc19.x86_64/usr/lib64/python3.3/site-packages/numpy/lib/format.py, line 449, in read_array array = pickle.load(fp) ValueError: can't handle version 187 of numpy.ndarray pickle I should note that I'm taking numpy/core/src/multiarray/scalarapi.c and numpy/core/src/multiarray/scalartypes.c.src from git master, which I thought had the fix for this. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.7.0b1 release
On 08/22/2012 12:36 PM, Ronan Lamy wrote: Le mercredi 22 août 2012 à 10:59 -0600, Orion Poplawski a écrit : If I drop the cython generation it builds, but the python 3 test failure I get now is: .. ERROR: Ticket #16 -- Traceback (most recent call last): File /builddir/build/BUILDROOT/numpy-1.7.0-0.2.b1.fc19.x86_64/usr/lib64/python3.3/site-packages/numpy/core/tests/test_regression.py, line 41, in test_pickle_transposed b = pickle.load(f) EOFError == ERROR: Failure: ValueError (can't handle version 187 of numpy.ndarray pickle) -- Traceback (most recent call last): File /usr/lib/python3.3/site-packages/nose/failure.py, line 37, in runTest raise self.exc_class(self.exc_val).with_traceback(self.tb) File /usr/lib/python3.3/site-packages/nose/loader.py, line 232, in generate for test in g(): File /builddir/build/BUILDROOT/numpy-1.7.0-0.2.b1.fc19.x86_64/usr/lib64/python3.3/site-packages/numpy/lib/tests/test_format.py, line 429, in test_roundtrip arr2 = roundtrip(arr) File /builddir/build/BUILDROOT/numpy-1.7.0-0.2.b1.fc19.x86_64/usr/lib64/python3.3/site-packages/numpy/lib/tests/test_format.py, line 420, in roundtrip arr2 = format.read_array(f2) File /builddir/build/BUILDROOT/numpy-1.7.0-0.2.b1.fc19.x86_64/usr/lib64/python3.3/site-packages/numpy/lib/format.py, line 449, in read_array array = pickle.load(fp) ValueError: can't handle version 187 of numpy.ndarray pickle I should note that I'm taking numpy/core/src/multiarray/scalarapi.c and numpy/core/src/multiarray/scalartypes.c.src from git master, which I thought had the fix for this. Note that the fix is actually in numpy/core/src/multiarray/methods.c, see https://github.com/numpy/numpy/pull/371/ Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ANN: NumPy 1.6.2 release candidate 1
On 05/05/2012 12:15 PM, Ralf Gommers wrote: Hi, I'm pleased to announce the availability of the first release candidate of NumPy 1.6.2. This is a maintenance release. Due to the delay of the NumPy 1.7.0, this release contains far more fixes than a regular NumPy bugfix release. It also includes a number of documentation and build improvements. Sources and binary installers can be found at https://sourceforge.net/projects/numpy/files/NumPy/1.6.2rc1/ Please test this release and report any issues on the numpy-discussion mailing list. Built fine in Fedora Rawhide (F18). Ran 3210 tests in 17.036s OK (KNOWNFAIL=3, SKIP=1) Running unit tests for numpy NumPy version 1.6.2rc1 NumPy is installed in /builddir/build/BUILDROOT/numpy-1.6.2-0.1.rc1.fc18.x86_64/usr/lib64/python2.7/site-packages/numpy Python version 2.7.3 (default, Apr 30 2012, 20:31:33) [GCC 4.7.0 20120416 (Red Hat 4.7.0-2)] nose version 1.1.2 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] 1.6.0b1 installs stuff in /usr/lib/python2.7/site-packages/doc
I'm looking at updating the numpy package in Fedora rawhide to 1.6.0b1. It appears to install a bunch of suff in /usr/lib64/python2.7/site-packages/doc (see below for examples). This seems wrong. Thoughts? /usr/lib64/python2.7/site-packages/doc/cython/MANIFEST /usr/lib64/python2.7/site-packages/doc/cython/Makefile /usr/lib64/python2.7/site-packages/doc/cython/README.txt /usr/lib64/python2.7/site-packages/doc/cython/c_numpy.pxd /usr/lib64/python2.7/site-packages/doc/cython/c_python.pxd /usr/lib64/python2.7/site-packages/doc/cython/numpyx.pyx /usr/lib64/python2.7/site-packages/doc/cython/run_test.py /usr/lib64/python2.7/site-packages/doc/cython/run_test.pyc /usr/lib64/python2.7/site-packages/doc/cython/run_test.pyo /usr/lib64/python2.7/site-packages/doc/cython/setup.py /usr/lib64/python2.7/site-packages/doc/cython/setup.pyc /usr/lib64/python2.7/site-packages/doc/cython/setup.pyo /usr/lib64/python2.7/site-packages/doc/pyrex/MANIFEST /usr/lib64/python2.7/site-packages/doc/pyrex/Makefile /usr/lib64/python2.7/site-packages/doc/pyrex/README.txt /usr/lib64/python2.7/site-packages/doc/pyrex/c_numpy.pxd /usr/lib64/python2.7/site-packages/doc/pyrex/c_python.pxd /usr/lib64/python2.7/site-packages/doc/pyrex/notes /usr/lib64/python2.7/site-packages/doc/pyrex/numpyx.c /usr/lib64/python2.7/site-packages/doc/pyrex/numpyx.pyx /usr/lib64/python2.7/site-packages/doc/pyrex/run_test.py /usr/lib64/python2.7/site-packages/doc/pyrex/run_test.pyc /usr/lib64/python2.7/site-packages/doc/pyrex/run_test.pyo /usr/lib64/python2.7/site-packages/doc/pyrex/setup.py /usr/lib64/python2.7/site-packages/doc/pyrex/setup.pyc /usr/lib64/python2.7/site-packages/doc/pyrex/setup.pyo /usr/lib64/python2.7/site-packages/doc/swig/Array.i /usr/lib64/python2.7/site-packages/doc/swig/Array1.cxx /usr/lib64/python2.7/site-packages/doc/swig/Array1.h -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.6.0b1 installs stuff in /usr/lib/python2.7/site-packages/doc
On 03/31/2011 01:08 PM, Ralf Gommers wrote: But they're not documentation files. The line is a bit blurry, but something like the numpy.i SWIG interface face is meant for using numpy, not documenting usage of SWIG and numpy (maybe most similar to what's in core/include/ ?). The actual documentation of how to use numpy.i is included in the reference guide, and is not present in that dir. Perhaps to make clear this is not documentation, put it in something like numpy/interfacing/swig/, etc.? How are these files used? Are they used by the python code directly? Just used by people wanting to use swig/cython/pyrex to interface with numpy? If the latter, they don't belong in python/site-packages but something lib /usr/share/numpy. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.6.0b1 installs stuff in /usr/lib/python2.7/site-packages/doc
On 03/31/2011 01:12 PM, Robert Kern wrote: Well, they're meant to be copied into your own code, which is why they end up under a doc/ directory. Lots of things like this tend to end up in doc/ directories. perhaps /usr/share/doc/numpy then. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] 1.6.0b1 installs stuff in /usr/lib/python2.7/site-packages/doc
On 03/31/2011 01:21 PM, Robert Kern wrote:
On Thu, Mar 31, 2011 at 14:16, Orion Poplawskior...@cora.nwra.com wrote:
On 03/31/2011 01:12 PM, Robert Kern wrote:
Well, they're meant to be copied into your own code, which is why they
end up under a doc/ directory. Lots of things like this tend to end up
in doc/ directories.
perhaps /usr/share/doc/numpy then.
This is up to the various Linux packagers of numpy. They have their
own tools to do this according to their own policies. Doing *anything*
in our setup.py to install these files will just make their jobs
harder. That's why I think that this needs to be handled in the binary
installers, not the setup.py.
Fedora already copies everything in doc/* to /usr/share/doc/numpy-%{version},
so yeah, no need to put it anywhere.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane or...@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
