[ python-Bugs-1464056 ] curses library in python 2.4.3 broken
Bugs item #1464056, was opened at 2006-04-04 14:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: nomind (vnainar) Assigned to: Nobody/Anonymous (nobody) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464444 ] ctypes should be able to link with installed libffi
Bugs item #146, was opened at 2006-04-04 21:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=146&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=146&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1463926 ] can't build on cygwin - PyArg_Parse_SizeT undefined
Bugs item #1463926, was opened at 2006-04-03 17:54 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463926&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Anthony Baxter (anthonybaxter) Summary: can't build on cygwin - PyArg_Parse_SizeT undefined Initial Comment: Something's not right on cygwin with the trunk. Example failing build: http://www.python.org/dev/buildbot/all/x86%20cygwin%20trunk/builds/3/step-configure/0 http://www.python.org/dev/buildbot/all/x86%20cygwin%20trunk/builds/3/step-compile/0 http://www.python.org/dev/buildbot/all/x86%20cygwin%20trunk/builds/3/step-test/0 Wrapping the PY_SSIZE_T_CLEAN bit at the top of modsupport.h in an "#if 0"/"#endif" makes it compile, at least. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-04 13:43 Message: Logged In: YES user_id=33168 Anthony fixed this. Closing. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1463926&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464506 ] ctypes testsuite hardcodes libc soname
Bugs item #1464506, was opened at 2006-04-04 23:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464506&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Thomas Heller (theller)
Summary: ctypes testsuite hardcodes libc soname
Initial Comment:
on Debian alpha-linux and Debian/Ubuntu hppa-linux,
libc's soname is libc.so.6.1. A more portable way to
find about the libc soname might be to check ldd on the
python executable (or any other executable)
$ ldd /bin/ls | awk '/libc\.so/ {print $3}'
/lib/tls/libc.so.6.1
$ objdump -p /bin/ls | awk '/NEEDED *libc\.so/ {print $2}'
libc.so.6.1
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464506&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464444 ] ctypes should be able to link with installed libffi
Bugs item #146, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=146&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-05 00:14 Message: Logged In: YES user_id=21627 Why is it desirable to link with the system ffi? That just adds an external dependency, for a negligable space saving (on x86, libffi.so.4.0.1 is 7840 bytes). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=146&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464056 ] curses library in python 2.4.3 broken
Bugs item #1464056, was opened at 2006-04-04 10:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: nomind (vnainar) Assigned to: Nobody/Anonymous (nobody) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library -- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-05 00:16 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464444 ] ctypes should be able to link with installed libffi
Bugs item #146, was opened at 2006-04-04 21:42 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=146&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Thomas Heller (theller) Summary: ctypes should be able to link with installed libffi Initial Comment: ctypes always uses the included libffi implementation (which should be updated to current GCC HEAD). Pleae add an option to build and link against a libffi, which is installed on the system. attached is a hack to just always build using the installed libffi. I'm unsure how to find the correct ffi implementation (maybe check for LIBFFI_H defined in the ffi header?), and where to implement this check (configure.ac --with-system-ffi=/usr?). -- >Comment By: Matthias Klose (doko) Date: 2006-04-05 00:43 Message: Logged In: YES user_id=60903 It's not an external dependency, if it's not found. The size is not the argument. For distributors it's an additional maintainance burden to update copies of libraries. Security advisories for zlib (and pcre?) show this. patch updated. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-05 00:14 Message: Logged In: YES user_id=21627 Why is it desirable to link with the system ffi? That just adds an external dependency, for a negligable space saving (on x86, libffi.so.4.0.1 is 7840 bytes). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=146&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464571 ] Changes to generator object's gi_frame attr
Bugs item #1464571, was opened at 2006-04-04 19:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Changes to generator object's gi_frame attr Initial Comment: In 2.4 (as late as 2.4.3), a generator's gi_frame attribute was always a frame object. In the current SVN revision (43631), gi_frame is sometimes None, a change I can't find any documentation of in the What's New for 2.5 section. If this was intentional, it should be documented -- I can't be the only one with packages that used this behaviour. If it was unintentional, I'd appreciate it if this could be fixed before 2.5 goes out. I don't have a (simple) repro case at this time, but I'll post one as soon as I can simplify the current one down. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464571 ] Changes to generator object's gi_frame attr
Bugs item #1464571, was opened at 2006-04-04 19:44 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: Changes to generator object's gi_frame attr Initial Comment: In 2.4 (as late as 2.4.3), a generator's gi_frame attribute was always a frame object. In the current SVN revision (43631), gi_frame is sometimes None, a change I can't find any documentation of in the What's New for 2.5 section. If this was intentional, it should be documented -- I can't be the only one with packages that used this behaviour. If it was unintentional, I'd appreciate it if this could be fixed before 2.5 goes out. I don't have a (simple) repro case at this time, but I'll post one as soon as I can simplify the current one down. -- >Comment By: Collin Winter (collinwinter) Date: 2006-04-04 19:53 Message: Logged In: YES user_id=1344176 *stops, thinks, comes up with repro case in 30 seconds* This does indeed seem to be intentional (introduced in r39239 during the implementation of PEP 342). To trigger this, all you have to do is run a generator til exhaustion (ie, StopIteration); at this point, the frame is decref'd and gi_frame is set to None. I'd appreciate it if this could be added to the "Porting to 2.5" section of What's New. Sorry for the confusion. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464571&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464658 ] PyList_GetItem() clarification
Bugs item #1464658, was opened at 2006-04-04 23:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464658&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Seefeld (stefan) Assigned to: Nobody/Anonymous (nobody) Summary: PyList_GetItem() clarification Initial Comment: The PyList_GetItem function is documented at http://docs.python.org/api/listObjects.html as returning "...the object at position pos...". However, even though in python -1 is a valid index, this function expects a 'real' index. 1) I believe it would be worthwhile pointing out in the API docs that in fact a positive value is expected. 2) It would be good to change the function signature to expect an unsigned int instead of an int for the index. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464658&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1464506 ] ctypes testsuite hardcodes libc soname
Bugs item #1464506, was opened at 2006-04-04 14:14
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464506&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Thomas Heller (theller)
Summary: ctypes testsuite hardcodes libc soname
Initial Comment:
on Debian alpha-linux and Debian/Ubuntu hppa-linux,
libc's soname is libc.so.6.1. A more portable way to
find about the libc soname might be to check ldd on the
python executable (or any other executable)
$ ldd /bin/ls | awk '/libc\.so/ {print $3}'
/lib/tls/libc.so.6.1
$ objdump -p /bin/ls | awk '/NEEDED *libc\.so/ {print $2}'
libc.so.6.1
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-04 21:38
Message:
Logged In: YES
user_id=33168
Heh, I added ldd support in ctypes/_loader.py _findLib_ld.
Does that address this issue? Or perhaps at least partially
address? It looks like in the current buildbot, this part
of ctypes isn't failing. Maybe this can be closed?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464506&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
