[jira] Updated: (MODPYTHON-21) Enable linking to shared python library
[ http://issues.apache.org/jira/browse/MODPYTHON-21?page=all ] Nicolas Lehuen updated MODPYTHON-21: Component: core Enable linking to shared python library --- Key: MODPYTHON-21 URL: http://issues.apache.org/jira/browse/MODPYTHON-21 Project: mod_python Type: Wish Components: core Versions: 3.2, 2.7.10, 3.1.3 Environment: Slackware Linux-10.0 / Apache-2.0.53 / Python-2.3 Reporter: Damjan Georgievski Priority: Minor I'd suggest to tweak the ./configure script, so that it tries to link to the python dynamic library first, and only if it fails to link the static. The only change wuld be to first try to link without the '-L/usr/lib/python2.3/config' option. A dynamically linked mod_python would get the benefit of always beeing the same version with the installed Python when minor versions are upgraded on the system. I've done this always and I've never had problems. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MODPYTHON-78) No support for Apache 2.1 yet
[ http://issues.apache.org/jira/browse/MODPYTHON-78?page=all ] Nicolas Lehuen updated MODPYTHON-78: Component: core No support for Apache 2.1 yet - Key: MODPYTHON-78 URL: http://issues.apache.org/jira/browse/MODPYTHON-78 Project: mod_python Type: Bug Components: core Versions: 3.2 Reporter: Nicolas Lehuen Fix For: 3.3 See http://article.gmane.org/gmane.comp.apache.mod-python.devel/1425 for some remarks by Jorey Bump, raised during the 3.2.1-BETA tests. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Where do we stand on 3.2.2 final?
Nicolas Lehuen wrote: OK I've checked in Graham's fix for MODPYTHON-83, and unsurprisingly it doesn't break anything on Win32. So I'm ready to provide the next beta build this week end if we can. As for MODPYTHON-84 (the one about req.sendfile)I cannot really test it since there are no symbolic links in Win2k (only junctions and reparse points but that's another story). Likewise, I cannot add a unit test for it in the test suite since, well, I cannot test the unit test... Regards, Nicolas Sendfile calls apr_stat, which is OS specific. In req_sendfile apr_stat is now called with APR_FINFO_NORM instead of APR_READ. So although Windows may not have symbolic links I wanted to ensure the change didn't break normal req_sendfile behaviour as well. Having said that I realize this would be caught by the normal unit tests... doh! Regards, Jim
Re: Where do we stand on 3.2.2 final?
Nicolas Lehuen wrote: OK I've checked in Graham's fix for MODPYTHON-83, and unsurprisingly it doesn't break anything on Win32. So I'm ready to provide the next beta build this week end if we can. +1 I don't see any outstanding issues so if we are doing another beta let's do it today. Just a note on updating src/include/mpversion.h. Should we be changing MPV_PATCH in svn trunk (and by extension MPV_STRING) to track the beta release patch level? In trunk we are still at MPV_PATCH 0, but in tags/release-3-2-2b we are at MPV_PATCH 2. Regards, Jim
Re: Where do we stand on 3.2.2 final?
On Sat, 22 Oct 2005, Jim Gallacher wrote: Just a note on updating src/include/mpversion.h. Should we be changing MPV_PATCH in svn trunk (and by extension MPV_STRING) to track the beta release patch level? In trunk we are still at MPV_PATCH 0, but in tags/release-3-2-2b we are at MPV_PATCH 2. Hmm... It looks like you've set the version number in the tag. The tags should be completely static (i think there may be certain instances where you modify the tag but that's very rare). The version should have been set in the trunk, _then_ you create the tag. Techincally the right way to solve this now is to merge the changes into the trunk, though I'll admit I've never done a merge with svn (yet). Another way is just to edit mpversion manually in the trunk ;) While on the subject - didn't we have some experimental 3.3 stuff - is that in SVN, and if so, is it in the trunk, or do we have a branch for this? Lastly, I agree, let's roll 3.2.3b ASAP. Grisha
Re: Where do we stand on 3.2.2 final?
Nicolas Lehuen wrote: OK, I've added a unit test for req.send_file(fname) and everything seems OK under Windows. Now if anyone want to write a test for the symbolic link issue... Will do. Jim Regards, Nicolas 2005/10/22, Nicolas Lehuen [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: 2005/10/22, Jim Gallacher [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Nicolas Lehuen wrote: OK I've checked in Graham's fix for MODPYTHON-83, and unsurprisingly it doesn't break anything on Win32. So I'm ready to provide the next beta build this week end if we can. As for MODPYTHON-84 (the one about req.sendfile)I cannot really test it since there are no symbolic links in Win2k (only junctions and reparse points but that's another story). Likewise, I cannot add a unit test for it in the test suite since, well, I cannot test the unit test... Regards, Nicolas Sendfile calls apr_stat, which is OS specific. In req_sendfile apr_stat is now called with APR_FINFO_NORM instead of APR_READ. So although Windows may not have symbolic links I wanted to ensure the change didn't break normal req_sendfile behaviour as well. Having said that I realize this would be caught by the normal unit tests... doh! Regards, Jim Well, no, because the current unit test for req.send_file provides values for offset and length. I'll add another test without offset and length, and check for the length of the result on the client side. Regards, Nicolas