bug lies in (presently) unused code path
user [EMAIL PROTECTED] usertag 469001 -goal-python2.5 severity 469001 normal retitle 469001 buggy Python API memory handling in unused source code found 469001 0.6.0-8 thanks Hi, the code that exhibits the buggy PyObject_NEW/PyMem_DEL behaviour (in python-scipy-0.6.0/scipy/sandbox/netcdf/_netcdf.c) is not actually compiled and the results shipped. As such, while a fix still seems to be worthwile it does not affect the python2.5 release goal. I am thus removing the usertag. Just be sure not to include the buggy C module before fixing it. Noticing that a pure python implementation (python-scipy-0.6.0/scipy/io/netcdf.py) is used, it might be nice to see whether the netcdfg-dev build-dependency should be revisited. (CCing debian-python because the bugs will disappear from the release-goal list.) Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
pysparse: no PyObject_New / PyMem_Del confusion, removing goal-python2.5
user [EMAIL PROTECTED] usertag 468991 -goal-python2.5 severity 468991 normal retitle 468991 Python API memory handling could use cleanup found 468991 1.0.1-4 thanks Hi, as detailed in my mail to the bug report[1], the memory handling with PyObject_* vs. PyMem_* is done correctly in pysparse, but I did find some mismatch between the deprecated macros and the recommended functions. Thus I am retitling this bug and removing the goal-python2.5 tag. At it might still be worth while to clean things up, I leave the bug open at a lower severity. (As usual, CCing debian-python for not making the bug disappear from the goal-python2.5 list without a trace.) Kind regards T. 1. http://bugs.debian.org/468991 -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
buggy Python API memory handling in (uncompiled) example C code
user [EMAIL PROTECTED] usertag 468987 -goal-python2.5 severity 468987 normal retitle 468987 buggy Python API memory handling in example C code found 468987 0.beta1-3.4 thanks Hi, the code that exhibits the buggy PyObject_NEW/PyMem_DEL behaviour (in pygdchart2-0.beta1/doc/images/gdmodule-0.42/_gdmodule.c) is an example(?) and as such not actually compiled. As such, while a fix still seems to be worthwile it does not affect the python2.5 release goal. I am thus removing the usertag. (CCing debian-python because the bugs will disappear from the release-goal list.) Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
bug lies in (presently) unused code path
user [EMAIL PROTECTED] usertag 468977 -goal-python2.5 retitle 468977 Python API memory handling bug in unused code path found 468977 0.90.1-3.1 thanks Hi, the code that exhibits the buggy PyObject_NEW/PyMem_DEL behaviour (in matplotlib-0.90.1/src/_subprocess.c) is not actually compiled and the results shipped[1]. As such, while a fix still seems to be worthwile it does not affect the python2.5 release goal. I am thus removing the usertag. Just be that it does not get activated its present buggy form. (CCing debian-python because the bugs will disappear from the release-goal list.) Kind regards T. 1. from matplotlib-0.90.1/src/_subprocess.c: * Currently, this extension module is only required when using the * subprocess module on Windows, but in the future, stubs for other * platforms might be added here as well. and it is indeed not compliled on Debian. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
