Re: Python 2.6 - ctypes (specifically _ctypes) cannot be imported - Eclipse pydev integration broken as a result
On Jun 23 15:04, Yaakov S wrote: On Wed, 2010-06-23 at 15:55 -0400, Christopher Faylor wrote: I've opted for using the union of previous and curr requirements but that's not really too great either. This is one of many places where we could use a real package manager. And you're not the only one. The problem with that is it can pull in old libraries which (if nothing else depends on them) are simply not necessary, and e.g. on my system, ImageBase real estate is at a premium. Here's a radical question: do we really need to allow for multiple versions of every package? Other distros don't do this, why should we? Fedora does, for instance, as soon as packages have been updated at least once. There's always a way to go back to the previous package, which is rather helpful if a package shows strange behaviour after an update. Happened to me the week before with a package in F13. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Python 2.6 - ctypes (specifically _ctypes) cannot be imported - Eclipse pydev integration broken as a result
On Wed, 2010-06-23 at 10:37 +0200, Kay Drangmeister wrote: Hi. I updated cygwin a day ago and thus upgraded from python 2.5 to python 2.6. Now the eclipse integration (pydev plugin) does no longer work correctly, I drilled down the problem to the issue that ctypes cannot be imported correctly. (This worked with python 2.5.) Can I do something specific to track down the problem further? cygcheck /usr/lib/python2.6/lib-dynload/_ctypes.dll My hunch is that cygffi-4.dll cannot be found, as that is a new dep of python ctypes. If I'm right, install the libffi4 package and it should work. (Jason: libffi4 is missing from python's requires:, and libncurses9 is still listed instead of libncursesw10. I fixed these on sourceware; please be sure to fix your local copy as well.) Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Python 2.6 - ctypes (specifically _ctypes) cannot be imported - Eclipse pydev integration broken as a result
Yaakov, On Wed, Jun 23, 2010 at 03:48:15AM -0500, Yaakov (Cygwin/X) wrote: (Jason: libffi4 is missing from python's requires:, and libncurses9 is still listed instead of libncursesw10. I fixed these on sourceware; please be sure to fix your local copy as well.) Done. However, if a user downgrades from python-2.6.5-2 to python-2.5.5-1, then the ncurses dependency will not be correct -- it should be libncurses10 instead of libncursesw10. Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Python 2.6 - ctypes (specifically _ctypes) cannot be imported - Eclipse pydev integration broken as a result
On Wed, 2010-06-23 at 07:20 -0400, Jason Tishler wrote: Done. However, if a user downgrades from python-2.6.5-2 to python-2.5.5-1, then the ncurses dependency will not be correct -- it should be libncurses10 instead of libncursesw10. That's a general problem with setup: it doesn't allow for different requires: for curr: and prev:. I always keep my deps correct for curr:, figuring that users will have prev:s deps from when it was curr:. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Python 2.6 - ctypes (specifically _ctypes) cannot be imported - Eclipse pydev integration broken as a result
On Wed, Jun 23, 2010 at 02:51:58PM -0500, Yaakov (Cygwin/X) wrote: On Wed, 2010-06-23 at 07:20 -0400, Jason Tishler wrote: Done. However, if a user downgrades from python-2.6.5-2 to python-2.5.5-1, then the ncurses dependency will not be correct -- it should be libncurses10 instead of libncursesw10. That's a general problem with setup: it doesn't allow for different requires: for curr: and prev:. I always keep my deps correct for curr:, figuring that users will have prev:s deps from when it was curr:. I've opted for using the union of previous and curr requirements but that's not really too great either. This is one of many places where we could use a real package manager. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Python 2.6 - ctypes (specifically _ctypes) cannot be imported - Eclipse pydev integration broken as a result
On Wed, 2010-06-23 at 15:55 -0400, Christopher Faylor wrote: I've opted for using the union of previous and curr requirements but that's not really too great either. This is one of many places where we could use a real package manager. And you're not the only one. The problem with that is it can pull in old libraries which (if nothing else depends on them) are simply not necessary, and e.g. on my system, ImageBase real estate is at a premium. Here's a radical question: do we really need to allow for multiple versions of every package? Other distros don't do this, why should we? Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Python 2.6 - ctypes (specifically _ctypes) cannot be imported - Eclipse pydev integration broken as a result
On Wed, Jun 23, 2010 at 03:04:02PM -0500, Yaakov (Cygwin/X) wrote: On Wed, 2010-06-23 at 15:55 -0400, Christopher Faylor wrote: I've opted for using the union of previous and curr requirements but that's not really too great either. This is one of many places where we could use a real package manager. And you're not the only one. The problem with that is it can pull in old libraries which (if nothing else depends on them) are simply not necessary, and e.g. on my system, ImageBase real estate is at a premium. Here's a radical question: do we really need to allow for multiple versions of every package? Other distros don't do this, why should we? I think that the reason that other distros don't do this is that they do more testing on their releases than we do - probably because they do real releases, unlike Cygwin. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Python 2.6 ?
On 2010-04-30 16:39, Yaakov (Cygwin/X) wrote: cvs2svn dblatex gobject-introspection python-cairo python-gamin python-gobject2.0 python-gobject2.0-devel python-gsf python-gtk2.0 python-gtk2.0-demo python-gtk2.0-devel python-libxml2 python-libxslt python-numpy python-pygtk python-xdg xcb-proto These are mine to rebuild (and I've got lots more in Ports). These packages have been rebuilt and are waiting in a staging area on sourceware. No rush, I've still got ~150 packages to rebuilt for Ports. Yaakov
Re: Python 2.6 ?
Jason, Another patch is required for Python 2.6 to export PySignal_SetWakeupFd in the implib, which is a new symbol in 2.6 and is used by PyGObject. Please add this to your 2.6 package before we switch so that PyGObject/PyGtk doesn't break. Thanks, --- origsrc/Python-2.6.5/Include/pyerrors.h 2008-06-08 23:58:54.0 -0500 +++ src/Python-2.6.5/Include/pyerrors.h 2010-05-12 04:19:31.535297200 -0500 @@ -232,7 +232,7 @@ PyAPI_FUNC(int) PyErr_CheckSignals(void) PyAPI_FUNC(void) PyErr_SetInterrupt(void); /* In signalmodule.c */ -int PySignal_SetWakeupFd(int fd); +PyAPI_FUNC(int) PySignal_SetWakeupFd(int fd); /* Support for adding program text to SyntaxErrors */ PyAPI_FUNC(void) PyErr_SyntaxLocation(const char *, int);
Re: Python 2.6 ?
Yaakov, On Wed, May 12, 2010 at 04:44:27AM -0500, Yaakov (Cygwin/X) wrote: Another patch is required for Python 2.6 to export PySignal_SetWakeupFd in the implib, which is a new symbol in 2.6 and is used by PyGObject. Please add this to your 2.6 package before we switch so that PyGObject/PyGtk doesn't break. I appreciate the heads up. I will include this patch (and 2.6.5-system-libffi.patch) in my next release. Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
Monkey wrench [Was: Re: Python 2.6 ?]
On 4/30/2010 1:03 PM, Jason Tishler wrote: On Fri, Apr 30, 2010 at 10:43:14AM -0600, Eric Blake wrote: Is there a quick list of all packages that depend on python? Would this be a good time to think about transitioning tcl/tk and friends to X (since python = idle uses tcl/tk, and you're already talking about a backwards incompatible change). /me runs and hides -- Chuck
Re: Monkey wrench [Was: Re: Python 2.6 ?]
On 2010-04-30 13:11, Charles Wilson wrote: Would this be a good time to think about transitioning tcl/tk and friends to X (since python= idle uses tcl/tk, and you're already talking about a backwards incompatible change). That doesn't necessarily have to be done at the same time. Yaakov
Re: Monkey wrench [Was: Re: Python 2.6 ?]
On Fri, Apr 30, 2010 at 02:13:53PM -0500, Yaakov (Cygwin/X) wrote: On 2010-04-30 13:11, Charles Wilson wrote: Would this be a good time to think about transitioning tcl/tk and friends to X (since python= idle uses tcl/tk, and you're already talking about a backwards incompatible change). That doesn't necessarily have to be done at the same time. Agreed. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
Re: Python 2.6 ?
On 2010-04-30 12:03, Jason Tishler wrote: Numeric pygtk2 pylibxml2 pylibxslt These were mine and are obsolete. gtk-doc libglade2.0-devel libglib2.0-devel libgtk2.0-devel openbox rsvg These are mine but they just contain scripts, so they need not be rebuilt. cvs2svn dblatex gobject-introspection python-cairo python-gamin python-gobject2.0 python-gobject2.0-devel python-gsf python-gtk2.0 python-gtk2.0-demo python-gtk2.0-devel python-libxml2 python-libxslt python-numpy python-pygtk python-xdg xcb-proto These are mine to rebuild (and I've got lots more in Ports). Yaakov
Re: Python 2.6 ?
On 2010-04-27 17:01, Jason Tishler wrote: I'm ready to release python-2.6.5-1 as experimental. How long should the module maintainers be given to transition their modules to Python 2.6? Is 3 months reasonable? I would like to add the transition date to my release announcement. One one hand, we do need to give maintainers with Python-dependent packages enough time to rebuilt. OTOH those who update their packages frequently might not switch until later to avoid maintaining experimental packages over time, or others might just push it off until they're forced to rebuild. I would say one month max -- say May 31, and anything after that may be considered unmaintained if the maintainer refuses to respond. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Python 2.6 ?
Yaakov, On Tue, Jan 26, 2010 at 02:47:13PM -0600, Yaakov (Cygwin/X) wrote: So if we keep with only one 2.x version at a time, then 2.6.4 as experimental is probably the best bet, with a clear schedule to maintainers of when 2.6 will go stable so the transition has a chance of being smooth. I'm ready to release python-2.6.5-1 as experimental. How long should the module maintainers be given to transition their modules to Python 2.6? Is 3 months reasonable? I would like to add the transition date to my release announcement. Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Python 2.6 status
On 19/04/2010 20:44, Jason Tishler wrote: 2. Yaakov recently created a libffi patch that I haven't had a chance to test yet. Please CC me into this discussion. I've put a lot of work into fixing libffi in GCC, and then porting the patches to upstream libffi; I'd like to know if there's anything missing. cheers, DaveK -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Python 2.6 status
On 2010-04-20 18:27, Dave Korn wrote:
On 19/04/2010 20:44, Jason Tishler wrote:
2. Yaakov recently created a libffi patch that I haven't had a chance to
test yet.
Please CC me into this discussion. I've put a lot of work into fixing
libffi in GCC, and then porting the patches to upstream libffi; I'd like to
know if there's anything missing.
The patch isn't for libffi per se, but for Python to find libffi in
GCC's directories instead of /usr/{include,lib}/ (or more specifically,
not look so hard for it).
Yaakov
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Python 2.6 status
Hugh, On Mon, Apr 19, 2010 at 10:20:37AM -0600, Hugh Davis wrote: The last postings regarding Python 2.6 mentioned needing a coordinated effort with all the packages that have dependencies on python. Is there a status on how this effort is coming? Any estimate on when an experimental or final package might be available? As of last week, I have a releasable Cygwin Python 2.6 with the following caveats: 1. It is not built against libncursesw-devel, but Python 2.6 added ncursesw support. 2. Yaakov recently created a libffi patch that I haven't had a chance to test yet. I would like to release an experimental Cygwin Python 2.6 and then resolve the above (IMO) minor issues in a follow-up release. Any objections? Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: Python 2.6 status
Jason I would like to release an experimental Cygwin Python 2.6 and then resolve the above (IMO) minor issues in a follow-up release. Any objections? That sounds great to me. Thanks Hugh -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Python 2.6 ?
Yaakov,
On Wed, Jan 27, 2010 at 05:23:46PM -0600, Yaakov (Cygwin/X) wrote:
On 27/01/2010 13:34, Jason Tishler wrote:
I prefer the above approach. However, what happens if 2.7 is
released during the 2.5 to 2.6 transition period?
2.7 is currently holding at alpha2. The 2.7 release schedule[1] shows
that 2.7 final is due in June, and even if it's on time, it could be
months before most software is ready for 2.7 and even longer before
anything actually *needs* it. I doubt most distros will make it the
default 2.x version until 2011, so I still think 2.6 is the way to go
right now.
[snip]
I've started to make some progress in releasing Python 2.5 and 2.6 for
Cygwin 1.7. I've decided to switch to cygport, so I was hoping you
could review my work and answer another question. Note I used your
python-2.5.4-10.cygport from cygwin-ports SVN as my starting point.
The attached patches are my changes:
1. I removed your 2.5.2-tkinter-x11.patch and added a 2.5.5-tkinter.patch,
so _tkinter builds and runs against the Win32 tcltk instead of the X11
version. FWIW, this is consistent with the _tkinter module that has
been in the standard Cygwin distribution for years.
2. I added 2.5.5-curses.patch and CPPFLAGS=-I/usr/include/ncurses, so
the _curses and _curses_panel modules will build cleanly against the
latest ncurses.
3. I changed requires in tkinter.hint as per #1 above.
Are you OK with these changes?
I would like to release 2.5.5 first and then 2.6.4. Unfortunately,
there is no HTML documentation specifically for 2.5.5, so I guess I
should use the documentation from 2.5.4. Do you know of any clever ways
to mix 2.5.5 source and 2.5.4 documentation without having to hardcode
versions in the cygport file?
Thanks,
Jason
--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
--- python-2.5.4-10.cygport.orig2010-02-11 16:47:25.454038100 -0500
+++ python-2.5.4-10.cygport 2010-02-12 08:58:01.641802800 -0500
@@ -11,9 +11,10 @@
2.5.2-destdir.patch
2.5.2-no-libm.patch
2.5.2-ossaudio.patch
- 2.5.2-tkinter-x11.patch
2.5.2-ctypes-util-find_library.patch
2.5.4-gcc4.patch
+ 2.5.5-curses.patch
+ 2.5.5-tkinter.patch
SRC_DIR=Python-${PV}
@@ -43,6 +44,7 @@
--with-libc=
--with-libm=
--with-system-ffi
+ CPPFLAGS=-I/usr/include/ncurses
src_install() {
--- CYGWIN-PATCHES/tkinter.hint.orig2010-02-12 11:51:28.597161100 -0500
+++ CYGWIN-PATCHES/tkinter.hint 2010-02-12 11:52:22.397236500 -0500
@@ -1,5 +1,5 @@
category: Python X11
-requires: python tcl tk tk-tix
+requires: python tcltk
external-source: python
sdesc: Python Tkinter GUI module
ldesc: Python is an interpreted, interactive object-oriented
--- Include/py_curses.h.orig2003-06-29 11:46:21.0 -0400
+++ Include/py_curses.h 2010-02-05 08:11:51.857091600 -0500
@@ -39,6 +39,10 @@
#endif
#endif
+#ifdef __CYGWIN__
+#define NCURSES_INTERNALS
+#endif
+
#ifdef HAVE_NCURSES_H
#include ncurses.h
#else
--- setup.py.orig 2010-02-11 20:33:58.674306600 -0500
+++ setup.py2010-02-11 20:43:03.625069500 -0500
@@ -1266,6 +1266,8 @@
if platform == 'sunos5':
include_dirs.append('/usr/openwin/include')
added_lib_dirs.append('/usr/openwin/lib')
+elif platform == 'cygwin':
+include_dirs.append('/usr/include')
elif os.path.exists('/usr/X11R6/include'):
include_dirs.append('/usr/X11R6/include')
added_lib_dirs.append('/usr/X11R6/lib64')
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Python 2.6 ?
On 12/02/2010 13:11, Jason Tishler wrote: I've started to make some progress in releasing Python 2.5 and 2.6 for Cygwin 1.7. I've decided to switch to cygport, so I was hoping you could review my work and answer another question. Note I used your python-2.5.4-10.cygport from cygwin-ports SVN as my starting point. Sure. 1. I removed your 2.5.2-tkinter-x11.patch and added a 2.5.5-tkinter.patch, so _tkinter builds and runs against the Win32 tcltk instead of the X11 version. FWIW, this is consistent with the _tkinter module that has been in the standard Cygwin distribution for years. 3. I changed requires in tkinter.hint as per #1 above. Ports' Tcl/Tk is X11, where the distro's is Win32-based, so the distro version must still use the latter. Note that there have been discussions about switching the distro's Tcl/Tk to X11 as well, so whenever that does happen you'll need that patch. 2. I added 2.5.5-curses.patch and CPPFLAGS=-I/usr/include/ncurses, so the _curses and _curses_panel modules will build cleanly against the latest ncurses. Right, my last package was built for libncurses9. Are you OK with these changes? Looks fine. One more thing: don't use 2.5.2-ossaudio.patch. Cygwin is missing /dev/mixer so the module doesn't really work. I would like to release 2.5.5 first and then 2.6.4. Unfortunately, there is no HTML documentation specifically for 2.5.5, so I guess I should use the documentation from 2.5.4. Do you know of any clever ways to mix 2.5.5 source and 2.5.4 documentation without having to hardcode versions in the cygport file? No, in this case you'll have to hardcode the documentation version. I just committed a 2.5.5 .cygport which shows you how this can be done. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Python 2.6 ?
Yaakov, On Fri, Feb 12, 2010 at 01:49:44PM -0600, Yaakov (Cygwin/X) wrote: On 12/02/2010 13:11, Jason Tishler wrote: 3. I changed requires in tkinter.hint as per #1 above. Ports' Tcl/Tk is X11, where the distro's is Win32-based, so the distro version must still use the latter. Note that there have been discussions about switching the distro's Tcl/Tk to X11 as well, so whenever that does happen you'll need that patch. Understood and thanks for the heads-up. Are you OK with these changes? Looks fine. I appreciate the review. One more thing: don't use 2.5.2-ossaudio.patch. Cygwin is missing /dev/mixer so the module doesn't really work. Will do. I would like to release 2.5.5 first and then 2.6.4. Unfortunately, there is no HTML documentation specifically for 2.5.5, so I guess I should use the documentation from 2.5.4. Do you know of any clever ways to mix 2.5.5 source and 2.5.4 documentation without having to hardcode versions in the cygport file? No, in this case you'll have to hardcode the documentation version. I just committed a 2.5.5 .cygport which shows you how this can be done. Nice approach. I really appreciate your help. Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Python 2.6 ?
Yaakov, On Tue, Jan 26, 2010 at 02:47:13PM -0600, Yaakov (Cygwin/X) wrote: On 26/01/2010 07:56, Jason Tishler wrote: Agreed, especially since the Python web site indicates the following: The current production versions are Python 2.6.4 and Python 3.1.1. Which raises another point: 3.x are meant to be installed in parallel with 2.x (/usr/bin/python3 instead of /usr/bin/python, etc.). So a separate python3 package might also be in order. Agreed, but let's focus on the 2.5 to 2.6 (or 2.7) upgrade first. [snip] What do you propose? Should I release a Python 2.6 as experimental, use alternatives, or another approach? [snip] So if we keep with only one 2.x version at a time, then 2.6.4 as experimental is probably the best bet, with a clear schedule to maintainers of when 2.6 will go stable so the transition has a chance of being smooth. I prefer the above approach. However, what happens if 2.7 is released during the 2.5 to 2.6 transition period? If, OTOH, we start supporting 2.5, 2.6, and (soon) 2.7 simultaneously, then the packaging scheme for Python would need to significantly change. I would like to avoid supporting multiple 2.x packages simultaneously. While you're at it, could you please include my ctypes patches: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/lang/python2.6/2.5.2-ctypes-util-find_library.patch http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/lang/python3/3.0rc3-ctypes-util-find_library.patch This is critical for typical ctypes usage, where only a library name is given (e.g. PyOpenGL). It means that the -devel package is required, but the same is true of the techniques used on Linux. OK, but what do you mean by the -devel package is required? After reading the patch, I think you mean the binutils package. Please confirm. BTW, is the threading workaround mentioned in the following post still necessary? http://cygwin.com/ml/cygwin/2009-07/msg00831.html Last time I checked, yes for both 2.6 and 3.1. Bummers, now it is necessary for 3.x too. :,( Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Python 2.6 ?
On 27/01/2010 13:34, Jason Tishler wrote:
I prefer the above approach. However, what happens if 2.7 is released
during the 2.5 to 2.6 transition period?
2.7 is currently holding at alpha2. The 2.7 release schedule[1] shows
that 2.7 final is due in June, and even if it's on time, it could be
months before most software is ready for 2.7 and even longer before
anything actually *needs* it. I doubt most distros will make it the
default 2.x version until 2011, so I still think 2.6 is the way to go
right now.
I would like to avoid supporting multiple 2.x packages simultaneously.
Fair enough, especially as 2.7 is due to be the last version of the 2.x
series.
OK, but what do you mean by the -devel package is required? After
reading the patch, I think you mean the binutils package. Please
confirm.
You are correct that binutils becomes a dependency of python. What I
meant to say is that, e.g. as is done in PyOpenGL,
ctypes.util.find_library('GL') will require /usr/lib/libGL.dll.a to be
installed, meaning that libGL-devel (which already requires: libGL1)
will be in python-opengl's requires:. I understand this might sound
strange at first, but if you look at the Linux code in ctypes/util.py,
not only do you need the -devel package and binutils, but gcc (!) as well.
If the binutils dependency bothers you for python as a whole, you could
always split out python-ctypes into a separate binary package. You will
see that my .cygport files do that for the test modules (as they are
generally not needed for normal operation), Tkinter (as the Ports
version uses *NIX/X11 Tcl/Tk, which adds several deps not needed by the
rest of Python), and Idle (which depends on Tkinter).
Yaakov
[1] http://www.python.org/dev/peps/pep-0373/
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Python 2.6 ?
Yaakov, On Tue, Jan 26, 2010 at 02:55:23AM -0600, Yaakov (Cygwin/X) wrote: What are your plans for upgrading the distro Python to 2.6? I was waiting for Cygwin 1.7 to be released. I guess I can't use that excuse anymore... :,) I'm finally starting to see some programs require 2.6 now, so I think the time has finally come that to consider an upgrade. Agreed, especially since the Python web site indicates the following: The current production versions are Python 2.6.4 and Python 3.1.1. Of course, any upgrade to Python affects a lot of packages, Wow, I didn't realize there were so many Cygwin packages dependent on Python: $ wget -q -O - http://mirror.nyi.net/cygwin/setup.ini | \ grep '^requires:.* python' setup.ini | wc -l 54 so I hope that we can coordinate this in order to have a smooth transition. What do you propose? Should I release a Python 2.6 as experimental, use alternatives, or another approach? BTW, is the threading workaround mentioned in the following post still necessary? http://cygwin.com/ml/cygwin/2009-07/msg00831.html Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Python 2.6 ?
On 26/01/2010 07:56, Jason Tishler wrote: Agreed, especially since the Python web site indicates the following: The current production versions are Python 2.6.4 and Python 3.1.1. Which raises another point: 3.x are meant to be installed in parallel with 2.x (/usr/bin/python3 instead of /usr/bin/python, etc.). So a separate python3 package might also be in order. Wow, I didn't realize there were so many Cygwin packages dependent on Python: $ wget -q -O - http://mirror.nyi.net/cygwin/setup.ini | \ grep '^requires:.* python' setup.ini | wc -l 54 You think that's a lot? Ports has another two to three *hundred* on top of that. That's why I want this to be coordinated. What do you propose? Should I release a Python 2.6 as experimental, use alternatives, or another approach? That depends, primarily, if we intend on support more than one 2.x version at a time. Until now, we have not. (Of course, this does not preclude a python3 package, as stated above.) Either way, I don't think we want to use alternatives, as that means that anybody can choose which version is their /usr/bin/python, etc. There must only be one default version of Python across the entire distro at any given time, otherwise things break. So if we keep with only one 2.x version at a time, then 2.6.4 as experimental is probably the best bet, with a clear schedule to maintainers of when 2.6 will go stable so the transition has a chance of being smooth. If, OTOH, we start supporting 2.5, 2.6, and (soon) 2.7 simultaneously, then the packaging scheme for Python would need to significantly change. While you're at it, could you please include my ctypes patches: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/lang/python2.6/2.5.2-ctypes-util-find_library.patch http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/lang/python3/3.0rc3-ctypes-util-find_library.patch This is critical for typical ctypes usage, where only a library name is given (e.g. PyOpenGL). It means that the -devel package is required, but the same is true of the techniques used on Linux. BTW, is the threading workaround mentioned in the following post still necessary? http://cygwin.com/ml/cygwin/2009-07/msg00831.html Last time I checked, yes for both 2.6 and 3.1. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: python 2.6
On 26/01/2009 09:20, Jason Tishler wrote: I don't know, but building Python 2.6 with openssl support causes the treading related operations to core dump. Maybe this particular code path tickles a problem in Cygwin? For some reason, Python 2.5.2 and 3.0 do not exhibit the same behavior. It seems the correlation is that in 2.6, _ssl itself uses threads; in 2.5 it did not, but in 3.1 it does and those same tests pass, as they do if _ssl.dll is not present in 2.6. I don't know the cause but I did find an easy workaround: Forcefully disabling threads in _ssl.c by adding #undef WITH_THREAD immediately after #include Python.h creates a _ssl.dll that allows the tests to pass. While this may seem a bit crude, it's really the same situation that existed in 2.5, where the core is threaded and _ssl isn't thread-aware. As for updating Cygwin's python to 2.6, I see that 2.5 is the default version in stable and up, with 2.6/3.1 available only in experimental. I suggest we do similarly; leave the distro default at 2.5.4 (rebuilt for 1.7) and add non-default (IOW nothing non-versioned in /usr/bin) python2.6 and python3.1 packages for users to try. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: python 2.6
Yaakov, On Thu, Jan 22, 2009 at 08:45:51PM -0600, Yaakov (Cygwin/X) wrote: Jason Tishler wrote: Yaakov, did you have openssl-devel installed when you built Python 2.6.1? Yes, that is clearly indicated in the documentation. Sorry I missing this detail: $ fgrep openssl-devel /usr/share/doc/Cygwin/python2.6-2.6.1.README $ $ fgrep -e -devel /usr/share/doc/Cygwin/python2.6-2.6.1.README (besides corresponding -devel packages) Thanks for the confirmation. If so, are you able to run the regression test [2] without threading related problems? Testing it now, I'm seeing the same results as you. What exactly is the correlation between openssl and threads? I don't know, but building Python 2.6 with openssl support causes the treading related operations to core dump. Maybe this particular code path tickles a problem in Cygwin? For some reason, Python 2.5.2 and 3.0 do not exhibit the same behavior. I will continue to try to debug this problem, but any help will be greatly appreciated. Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: python 2.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jason Tishler wrote: Yaakov, did you have openssl-devel installed when you built Python 2.6.1? Yes, that is clearly indicated in the documentation. If so, are you able to run the regression test [2] without threading related problems? Testing it now, I'm seeing the same results as you. What exactly is the correlation between openssl and threads? Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkl5L18ACgkQpiWmPGlmQSNQCwCgqvnUS6l7YJH90YdPtYdoiNUU h9oAnj7Suwd3Ypk4OAo9x0945BrchzR2 =eDG1 -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: python 2.6
Yaakov, On Tue, Jan 13, 2009 at 12:12:58PM -0500, Jason Tishler wrote: I know of another user who does not have this problem too. I noticed that both of these users do not have openssl-devel installed. As an experiment, I removed the openssl-devel package and built a completely new Python 2.6.1. I was able to run test_asynchat in a loop 300 times without any core dumps [1]. Additionally, I was also able to run the regression test without any of the threading related tests core dumping. As another experiment, I ran Cygwin Ports Python 2.6.1 and it core dumps in exactly the same way as the one I built when I had the openssl-devel package installed. Yaakov, did you have openssl-devel installed when you built Python 2.6.1? If so, are you able to run the regression test [2] without threading related problems? [snip] [2] Run at least test_asynchat with something like the following: ./python.exe -E -tt Lib/test/regrtest.py -l test_asynchat Please kindly respond to the above. I believe it is an important data point and will eliminate any possibility of cockpit error on my part. Thanks, Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: python 2.6
On Tue, Jan 13, 2009 at 03:17:01AM +0200, George Ciobanu wrote: First of all, sorry for breaking the thread, but I'm not a subscriber to this list. Please cc me on the next email. Just wanted to let you know that I don't see the issue you are describing in my environment when running make test. I've attached the cygcheck info. [snip] I know of another user who does not have this problem too. I noticed that both of these users do not have openssl-devel installed. As an experiment, I removed the openssl-devel package and built a completely new Python 2.6.1. I was able to run test_asynchat in a loop 300 times without any core dumps [1]. Additionally, I was also able to run the regression test without any of the threading related tests core dumping. As another experiment, I ran Cygwin Ports Python 2.6.1 and it core dumps in exactly the same way as the one I built when I had the openssl-devel package installed. Yaakov, did you have openssl-devel installed when you built Python 2.6.1? If so, are you able to run the regression test [2] without threading related problems? George, are you willing to install openssl-devel, build a completely new Python, run the regression test [2], and report back your findings to the list? Thanks, Jason [1] Although test_asynchat failed occasionally (about 5% of the time) with a sem_init: Resource temporarily unavailable error. [2] Run at least test_asynchat with something like the following: ./python.exe -E -tt Lib/test/regrtest.py -l test_asynchat -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: python 2.6
Jason Tishler wrote: George, are you willing to install openssl-devel, build a completely new Python, run the regression test [2], and report back your findings to the list? After I've installed openssl-dev and rebuilt from scratch Python. I could see both error conditions: sem_init: Resource temporarily unavailable - surprisingly enough I've seen it on the first run only $ ./python.exe -E -tt Lib/test/regrtest.py -l test_asynchat test_asynchat 9 [unknown (0xE28)] python 2580 _cygtls::handle_exceptions: Error while du mping state (probably corrupted stack) 1600540 [unknown (0x1A0)] python 2580 _cygtls::handle_exceptions: Error while du mping state (probably corrupted stack) Segmentation fault (core dumped) George -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: python 2.6
On Sat, Jan 10, 2009 at 01:58:37PM +0200, George Ciobanu wrote:
Is there a plan to move a newer version of python, such as 2.6?
Has anyone tried to incorporate it so far?
Yes, I started to package Python 2.6.1 and 3.0 before the holidays.
Unfortunately, I ran into problems with Python 2.6.1 during the testing
phase. When I executed the regression test, every threading related
test caused python.exe to core dump. FWIW, the threading related tests
for Python 2.5.2 or 3.0 do not core dump under the same Cygwin 1.5.25
installation. See attached for the cygcheck output.
I built a debug-able Cygwin DLL (from the cygwin-1.5.25-15 source
tarball) and Python executable, so I could try to debug the problem.
The following is a sample gdb session:
$ gdb python.exe
...
(gdb) run Lib/test/regrtest.py -l test_asynchat
Starting program: /tmp/Python-2.6.1.threading/python.exe Lib/test/regrtest.py
-l test_asynchat
[New thread 2232.0xdc0]
[New thread 2232.0x45c]
test_asynchat
[New thread 2232.0xc64]
[New thread 2232.0xf68]
[New thread 2232.0xe54]
Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 2232.0xc64]
0x00666b16 in ?? ()
(gdb) bt
#0 0x00666b16 in ?? ()
#1 0x18c00023 in ?? ()
#2 0x61077b13 in pthread_testcancel ()
at ../../../../winsup/cygwin/pthread.cc:139
#3 0x610b45e2 in semaphore::wait (sem=0x71e540)
at ../../../../winsup/cygwin/thread.cc:3157
#4 0x61093558 in _sigfe () at ../../../../winsup/cygwin/cygerrno.h:31
#5 0x7c96e0f0 in ntdll!RtlpNtMakeTemporaryKey ()
from /mnt/c/WINDOWS/system32/ntdll.dll
#6 0x6ba9e927 in cygcrypto-0!ERR_set_implementation ()
from /usr/bin/cygcrypto-0.9.8.dll
#7 0x0001 in ?? ()
#8 0x6bb1b98d in x509_dir_lookup () from /usr/bin/cygcrypto-0.9.8.dll
#9 0x01a3 in ?? ()
#10 0x18c0ca18 in ?? ()
#11 0x188d in ?? ()
#12 0x18c0caa0 in ?? ()
#13 0x6ba9ebf8 in cygcrypto-0!ERR_set_implementation ()
from /usr/bin/cygcrypto-0.9.8.dll
#14 0x00724288 in ?? ()
#15 0x in ?? ()
(gdb) f 2
#2 0x61077b13 in pthread_testcancel ()
at ../../../../winsup/cygwin/pthread.cc:139
139 pthread::self ()-testcancel ();
Current language: auto; currently c++
(gdb) list
134 }
135
136 void
137 pthread_testcancel ()
138 {
139 pthread::self ()-testcancel ();
140 }
141
142 void
143 _pthread_cleanup_push (__pthread_cleanup_handler *handler)
My WAG is that Cygwin is SEGV-ing in the following (from
winsup/cygwin/thread.cc):
pthread *
pthread::self ()
{
pthread *thread = get_tls_self_pointer ();
if (!thread)
{
thread = pthread_null::get_null_pthread ();
set_tls_self_pointer (thread);
}
return thread;
}
Unfortunately, I'm not sure how to debug this further. Any help will be
greatly appreciated.
Thanks,
Jason
--
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6
Cygwin Configuration Diagnostics
Current System Time: Mon Jan 12 15:30:03 2009
Windows XP Professional Ver 5.1 Build 2600 Service Pack 2
Path: c:\home\jtishler\bin
C:\cygwin\usr\local\bin
C:\cygwin\bin
c:\Program Files\bin
c:\Program Files\vim\vim60
c:\WINDOWS\system32
c:\WINDOWS
c:\Python23
c:\Program Files\Tcl\bin
C:\cygwin\lib\lapack
c:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE
.
Output from C:\cygwin\bin\id.exe (nontsec)
UID: 178097(jtishler)GID: 10513(DomainUsers)
556(Network Configuration Operators) 555(Remote Desktop Users)
545(Users) 1010(Debugger Users)
10513(DomainUsers)
Output from C:\cygwin\bin\id.exe (ntsec)
UID: 178097(jtishler)GID: 10513(DomainUsers)
556(Network Configuration Operators) 555(Remote Desktop Users)
545(Users) 1010(Debugger Users)
10513(DomainUsers)
SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS
USER = 'jtishler'
PWD = '/tmp'
CYGWIN = 'ntsec'
HOME = '/home/jtishler'
MAKE_MODE = 'UNIX'
Use '-r' to scan registry
a: fd N/AN/A
c: hd NTFS 69452Mb 90% CP CS UN PA FC System Disk
d: cd N/AN/A
q: hd N/AN/A
C:\cygwin / system binmode
c:\home/home system binmode
C:\misc/misc system binmode
C:\cygwin/bin /usr/bin system binmode
C:\Program Files\Java\jdk1.5.0_10 /usr/java system binmode
C:\cygwin/lib /usr/lib system binmode
C:\apache-ant-1.7.0/usr/local/antsystem binmode
C:\tibco\ems /usr/local/emssystem binmode
C:\maven-1.0.2
Re: python 2.6
Hi Jason, First of all, sorry for breaking the thread, but I'm not a subscriber to this list. Please cc me on the next email. Just wanted to let you know that I don't see the issue you are describing in my environment when running make test. I've attached the cygcheck info. My run blocks at test_httpservers, but I suspect this is because I haven't been able to compile it fully. I've traced this problem to graminit.o which contains the missing symbol, but I haven't had the time to look in depth into this. $ make running build running build_ext building 'parser' extension gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.5.25-i686-2.6/home/ George/Python-2.6.1/Modules/parsermodule.o -L/usr/local/lib -L. -lpython2.6 -o b uild/lib.cygwin-1.5.25-i686-2.6/parser.dll build/temp.cygwin-1.5.25-i686-2.6/home/George/Python-2.6.1/Modules/parsermodule. o: In function `parser_expr': /home/George/Python-2.6.1/Modules/parsermodule.c:552: undefined reference to `__ PyParser_Grammar' build/temp.cygwin-1.5.25-i686-2.6/home/George/Python-2.6.1/Modules/parsermodule. o: In function `parser_suite': /home/George/Python-2.6.1/Modules/parsermodule.c:552: undefined reference to `__ PyParser_Grammar' collect2: ld returned 1 exit status Failed to find the necessary bits to build these modules: _bsddb _hashlib _sqlite3 _ssl _tkinter bsddb185 bz2gdbm linuxaudiodev nisossaudiodevreadline spwd sunaudiodev To find the necessary bits, look in setup.py in detect_modules() for the module' s name. Failed to build these modules: parser running build_scripts Thanks, George George Ciobanu wrote: Hi, Is there a plan to move a newer version of python, such as 2.6? Has anyone tried to incorporate it so far? Thanks, George $ cygcheck -s Cygwin Configuration Diagnostics Current System Time: Tue Jan 13 03:00:36 2009 Windows XP Professional Ver 5.1 Build 2600 Service Pack 3 Path: . c:\programs\bin C:\cygwin\usr\x11R6\bin C:\cygwin\bin C:\cygwin\usr\local\bin c:\WINDOWS\system32 c:\WINDOWS c:\Program Files\PsTools Output from C:\cygwin\bin\id.exe (nontsec) UID: 1003(George) GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1003(George) GID: 513(None) 0(root) 513(None) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'George' PWD = '/home/George' HOME = '/home/George' MAKE_MODE = 'unix' Use '-r' to scan registry c: hd NTFS 20002Mb 89% CP CS UN PA FC d: hd NTFS 29996Mb 58% CP CS UN PA FC New Volume e: cd N/AN/A f: cd N/AN/A C:\cygwin / system binmode C:\cygwin/bin /usr/bin system binmode C:\cygwin/lib /usr/lib system binmode . /cygdrive system binmode,cygdrive Found: C:\cygwin\bin\awk.exe Found: C:\cygwin\bin\bash.exe Found: C:\cygwin\bin\cat.exe Found: C:\cygwin\bin\cp.exe Found: C:\cygwin\bin\cpp.exe Not Found: crontab Found: C:\cygwin\bin\find.exe Found: C:\cygwin\bin\gcc.exe Not Found: gdb Found: C:\cygwin\bin\grep.exe Found: C:\cygwin\bin\kill.exe Found: C:\cygwin\bin\ld.exe Found: C:\cygwin\bin\ls.exe Found: C:\cygwin\bin\make.exe Found: C:\cygwin\bin\mv.exe Not Found: patch Found: C:\cygwin\bin\perl.exe Found: C:\cygwin\bin\rm.exe Found: C:\cygwin\bin\sed.exe Not Found: ssh Found: C:\cygwin\bin\sh.exe Found: C:\cygwin\bin\tar.exe Found: C:\cygwin\bin\test.exe Not Found: vi Not Found: vim 61k 2008/04/01 C:\cygwin\bin\cygbz2-1.dll 7k 2003/10/19 C:\cygwin\bin\cygcrypt-0.dll 1064k 2008/09/30 C:\cygwin\bin\cygcrypto-0.9.8.dll 703k 2007/12/17 C:\cygwin\bin\cygdb-4.2.dll 943k 2007/12/17 C:\cygwin\bin\cygdb-4.5.dll 1036k 2007/12/17 C:\cygwin\bin\cygdb_cxx-4.2.dll 1296k 2007/12/17 C:\cygwin\bin\cygdb_cxx-4.5.dll 118k 2008/05/09 C:\cygwin\bin\cygexpat-1.dll 40k 2006/11/15 C:\cygwin\bin\cygform-8.dll 19k 2006/11/19 C:\cygwin\bin\cyggdbm-4.dll 8k 2006/11/19 C:\cygwin\bin\cyggdbm_compat-4.dll 135k 2008/07/04 C:\cygwin\bin\cygglib-1-2-0.dll 11k 2008/07/04 C:\cygwin\bin\cyggmodule-1-2-0.dll 8k 2008/07/04 C:\cygwin\bin\cyggthread-1-2-0.dll 24k 2008/11/29 C:\cygwin\bin\cyghistory6.dll 271k 2007/08/24 C:\cygwin\bin\cygicons-0.dll 978k 2008/11/10 C:\cygwin\bin\cygiconv-2.dll 37k 2003/08/10 C:\cygwin\bin\cygintl-2.dll 31k 2005/11/20 C:\cygwin\bin\cygintl-3.dll 31k 2008/11/10 C:\cygwin\bin\cygintl-8.dll 12k 2008/08/26 C:\cygwin\bin\cyglzmadec-0.dll 21k 2006/11/15 C:\cygwin\bin\cygmenu-8.dll 67k 2006/11/15 C:\cygwin\bin\cygncurses++-8.dll 237k 2006/11/15 C:\cygwin\bin\cygncurses-8.dll 12k 2006/11/15 C:\cygwin\bin\cygpanel-8.dll 181k 2008/09/07 C:\cygwin\bin\cygpcre-0.dll 302k 2008/09/07 C:\cygwin\bin\cygpcrecpp-0.dll 7k 2008/09/07
Re: python 2.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 George Ciobanu wrote: My run blocks at test_httpservers, but I suspect this is because I haven't been able to compile it fully. I've traced this problem to graminit.o which contains the missing symbol, but I haven't had the time to look in depth into this. http://bugs.python.org/issue4279 Patch committed to 2.6, 3.0, and trunk. Yaakov -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAklsLsEACgkQpiWmPGlmQSNBVwCgjGhwoj/jGDzHee9sfYTr1m/S y6UAn1WoFjxadNRtWFZ75q8XI1iMgN1y =rx4U -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
