Re: mod_python 3.2.7 available for testing
Hi David, One thing I don't understand is why you have foreign PythonOption definitions in your test setup. Are you sure you have re-created a clean testconf.py file from testconf.py.in ? I've write a little bit of documentation in test/README, please try to follow it. It seems to me that the test failures all come from this strange test configuration. It looks like mod_python is interfering with some already existing filters, like MultiView. Note that there is a bug under Win32 which I should have reported way before... In some situation, when an exception is raised in mod_python during normal operation, Apache will segfault the next time is is stopped or restarted. It only occurs with a specific exception is raised, maybe when a handler module fails to load. The reason why I haven't reported it yet is that it only occured on my development computer, not my production servers, so I thought it was something caused by my setup. Apparently you have the same problem, hence the segfault when the Apache server is stopped. I'll have to investigate this problem more thoroughly. So please try to re-run the test in a clean slate environment. It'd be interesting to see why and how your current configuration contaminates the test configuration, though. Regards, Nicolas 2006/2/8, David Fraser [EMAIL PROTECTED]: Jim Gallacher wrote: Gregory (Grisha) Trubetskoy wrote: I think we have enough +1's. (If someone could tally them up in a single e-mail, that'd be great.) Should we start a core-group vote, or wait some more? On the bash issue - I think we can leave it as is, the affected distros will just have to maintain a patch in their build systems. Let's vote. Here is the test summary: +1 Debian (sid), Apache 2.0.55-prefork, Python 2.3.5 +1 Debian (sarge), Apache 2.0.54-worker, Python 2.3.5 +1 Debian (sarge), Apache 2.0.54-prefork, Python 2.3.5 +1 Debian (testing, aka, etch), Apache 2.0.55-worker, Python 2.3.5 +1 Fedora Core 4, Linux 2.6.15, Apache 2.0.54, Python 2.4.1 +1 FreeBSD 4.9 , Apache 2.0.50 (prefork), Python 2.3.4 +1 FreeBSD 4.9 , Apache 2.0.55 (prefork), Python 2.4.2 +1 MacOSX 10.4.4 PPC, Apache-2.0.55-prefork, Python-2.4.2 +1 Slackware 10.1, Apache 2.0.55 (mpm-prefork), Python 2.4 +1 Solaris 10 Sparc, Apache-2.0.55-prefork, Python-2.4.2 +1 Ubuntu 5.10 Breezy (amd64), Apache 2.0.54-worker, Python 2.4.2 +1 Windows 2000 SP4, Apache/2.0.55 + Python/2.2.3 +1 Windows 2000 SP4, Apache/2.0.55 + ActivePython/2.3.5 +1 Windows XP SP2, Apache/2.0.55 + ActivePython/2.4.2 With configure fixed manually to deal with bash bug: +1 Gentoo 2005.1 (amd64), Apache 2.0.55-prefork, Python 2.4.2 Plus we have the following tests from the svn revision which corresponds to 3.2.7: +1 trunk rev 374709 FreeBSD 6.0 Apache 2.0.55-prefork, Python 2.4.2 I know its already been decided, but I thought I'd add another test for Windows (seeing as Nicolas is the only one who has tested so far...) This was with the installers Nicolas built, running the tests out of svn version 375881 +1 Windows XP SP2, Apache/2.0.54, Python 2.4.1 Unfortunately I got a failure too: -1 Windows 2000 SP4, Apache/2.0.49, Python 2.3.3 This even incorporated Apache segfaults ... when trying to stop with server.register_cleanup and apache.register_cleanup Other failures: req.add_handler() when handler list is empty PythonOption override, remove and remove2 PythonOutputFilter test_internal In all, I got 6 failures on the first 45 tests and 3 on the last 6. The PythonOption test failures look like they're conflicting with some PythonOptions in my default Apache config (since the assertion errors include things like jToolkit and jLogbook), so this seems to be an error in the test setup that its not independent of that. The PythonOutputFilter test also seems to be a test error, as it is returning the *contents* of test.py in uppercase instead of TEST OK in uppercase... Similarly test_accesshandler_add_handler_to_empty_hl is returning the contents of test.py I wonder if the segfaults on cleanup relate to my Apache version, if so I can try upgrading. Am I doing something wrong in the testing? Logs attached (zipped as the inclusion of test.py a few times make them quite big)... David
Re: mod_python 3.2.7 available for testing
Nicolas Lehuen wrote: Hi David, One thing I don't understand is why you have foreign PythonOption definitions in your test setup. Are you sure you have re-created a clean testconf.py file from testconf.py.in ? I've write a little bit of documentation in test/README, please try to follow it. Hi Nicolas I don't understand this either. I followed the docs in test/README (I've checked and did that right). I just repeated the test using my patch to use a different service name (attached). This only generated one segfault and failed on the second cleanup test, but not the first... This behaviour seems repeatable (running the tests twice produced exactly the same results) It seems to me that the test failures all come from this strange test configuration. It looks like mod_python is interfering with some already existing filters, like MultiView. Yes, it does indeed seem that way. So from the point of view, these errors shouldn't hold up the release, as they seem to be problems in the test framework. I just thought I'd like to run them, so it seems a good time to try and solve them. Note that there is a bug under Win32 which I should have reported way before... In some situation, when an exception is raised in mod_python during normal operation, Apache will segfault the next time is is stopped or restarted. It only occurs with a specific exception is raised, maybe when a handler module fails to load. The reason why I haven't reported it yet is that it only occured on my development computer, not my production servers, so I thought it was something caused by my setup. Apparently you have the same problem, hence the segfault when the Apache server is stopped. I'll have to investigate this problem more thoroughly. Interesting that it seems to make a difference running under a different service name. I can try help track this down. So please try to re-run the test in a clean slate environment. It'd be interesting to see why and how your current configuration contaminates the test configuration, though. OK I'm busy setting up VMWare to try this - pretty sure it'll pass, so I'll try investigate whats getting the situation confused... Thanks for your feedback David Index: test/testconf.py.in === --- test/testconf.py.in (revision 375881) +++ test/testconf.py.in (working copy) @@ -18,6 +18,9 @@ # Path to the mod_python.so file, should be in the apache modules directory. MOD_PYTHON_SO=@MOD_PYTHON_SO@ +# Set SVCNAME if you want to test via the given service +SVCNAME= + # makes emacs go into python mode ### Local Variables: ### mode:python Index: test/test.py === --- test/test.py (revision 375881) +++ test/test.py (working copy) @@ -176,6 +176,7 @@ TESTHOME = testconf.TESTHOME MOD_PYTHON_SO = testconf.MOD_PYTHON_SO LIBEXECDIR = testconf.LIBEXECDIR +SVCNAME = testconf.SVCNAME SERVER_ROOT = TESTHOME CONFIG = os.path.join(TESTHOME, conf, test.conf) DOCUMENT_ROOT = os.path.join(TESTHOME, htdocs) @@ -299,12 +300,38 @@ f.write(\n# --APPENDED-- \n\n+append) f.close() +def installService(self,extra=''): + +print Installing Test Apache Service +httpd = quoteIfSpace(HTTPD) +config = quoteIfSpace(CONFIG) +cmd = '%s %s -k install -n %s -f %s' % (httpd, extra, SVCNAME, config) +print , cmd +os.system(cmd) +time.sleep(1) +self.httpd_installed = 1 + +def uninstallService(self,extra=''): + +print Uninstalling Test Apache Service +httpd = quoteIfSpace(HTTPD) +cmd = '%s -k uninstall -n %s' % (httpd, SVCNAME) +print , cmd +os.system(cmd) +time.sleep(1) +self.httpd_installed = 0 + def startHttpd(self,extra=''): +if SVCNAME: +self.installService(extra) print Starting Apache httpd = quoteIfSpace(HTTPD) config = quoteIfSpace(CONFIG) -cmd = '%s %s -k start -f %s' % (httpd, extra, config) + if SVCNAME: +cmd = '%s %s -k start -n %s' % (httpd, extra, SVCNAME) +else: +cmd = '%s %s -k start -f %s' % (httpd, extra, config) print , cmd os.system(cmd) time.sleep(1) @@ -315,7 +342,10 @@ print Stopping Apache... httpd = quoteIfSpace(HTTPD) config = quoteIfSpace(CONFIG) -cmd = '%s -k stop -f %s' % (httpd, config) + if SVCNAME: +cmd = '%s -k stop -n %s' % (httpd, SVCNAME) +else: +cmd = '%s -k stop -f %s' % (httpd, config) print , cmd os.system(cmd) time.sleep(1) @@ -337,6 +367,9 @@ self.httpd_running = 0 +if SVCNAME: +self.uninstallService() + class PerRequestTestCase(unittest.TestCase): appendConfig = \nNameVirtualHost *\n\n @@ -1872,6 +1905,8 @@ def
Re: bash bug (was Re: mod_python 3.2.7 available for testing)
Sébastien Arnaud wrote: Hi, I would like to report: +1 Gentoo 2005.1 (amd64), Apache 2.0.55-prefork, Python 2.4.2 After replacing the troubling line (line 3038, configure): from: MP_VERSION=`echo $MP_VERSION | sed s/\\//g` to (Deron's 1st suggestion): MP_VERSION=`echo $MP_VERSION | sed 's///g' ` I guess now it's up to you to decide if you want to integrate the patch or if you want to leave it as is for this release ;) In the interest of actually *releasing* something I think this should wait for a future bug fix release. In the interim the fix is simple enough that someone on an affected platform can manually change configure.in. It's not an ideal solution, but then neither is an endless series of beta and release candidates. ;) I'll create a JIRA issue so this doesn't get lost. Jim
Re: mod_python 3.2.7 available for testing
OK so my core group vote is +1 for this release. It has been tested on a wide array of OSes, both threaded and forked MPMs, Python 2.2, 2.3 and 2.4, so I guess it's okay. A threaded test on MacOSX and Solaris would have been great but maybe the recommended MPM on those platform is the forked one, so we don't have to worry about those. Regards, Nicolas 2006/2/7, Jim Gallacher [EMAIL PROTECTED]: Gregory (Grisha) Trubetskoy wrote: I think we have enough +1's. (If someone could tally them up in a single e-mail, that'd be great.) Should we start a core-group vote, or wait some more? On the bash issue - I think we can leave it as is, the affected distros will just have to maintain a patch in their build systems. Let's vote. Here is the test summary: +1 Debian (sid), Apache 2.0.55-prefork, Python 2.3.5 +1 Debian (sarge), Apache 2.0.54-worker, Python 2.3.5 +1 Debian (sarge), Apache 2.0.54-prefork, Python 2.3.5 +1 Debian (testing, aka, etch), Apache 2.0.55-worker, Python 2.3.5 +1 Fedora Core 4, Linux 2.6.15, Apache 2.0.54, Python 2.4.1 +1 FreeBSD 4.9 , Apache 2.0.50 (prefork), Python 2.3.4 +1 FreeBSD 4.9 , Apache 2.0.55 (prefork), Python 2.4.2 +1 MacOSX 10.4.4 PPC, Apache-2.0.55-prefork, Python-2.4.2 +1 Slackware 10.1, Apache 2.0.55 (mpm-prefork), Python 2.4 +1 Solaris 10 Sparc, Apache-2.0.55-prefork, Python-2.4.2 +1 Ubuntu 5.10 Breezy (amd64), Apache 2.0.54-worker, Python 2.4.2 +1 Windows 2000 SP4, Apache/2.0.55 + Python/2.2.3 +1 Windows 2000 SP4, Apache/2.0.55 + ActivePython/2.3.5 +1 Windows XP SP2, Apache/2.0.55 + ActivePython/2.4.2 With configure fixed manually to deal with bash bug: +1 Gentoo 2005.1 (amd64), Apache 2.0.55-prefork, Python 2.4.2 Plus we have the following tests from the svn revision which corresponds to 3.2.7: +1 trunk rev 374709 FreeBSD 6.0 Apache 2.0.55-prefork, Python 2.4.2 Jim
Re: mod_python 3.2.7 available for testing
On Tue, 7 Feb 2006, Jim Gallacher wrote: I assumed we would have a separate thread for the core vote, but what the heck. :) +1 is my core vote. +1 from me as well. Grisha
Re: mod_python 3.2.7 available for testing
Gregory (Grisha) Trubetskoy wrote: On Tue, 7 Feb 2006, Jim Gallacher wrote: I assumed we would have a separate thread for the core vote, but what the heck. :) +1 is my core vote. +1 from me as well. When the core group votes for a release candidate, is it a consensus vote or a majority vote? To quote from the Apache voting guidelines, An action item requiring consensus approval must receive at least 3 binding +1 votes and no vetos. An action item requiring majority approval must receive at least 3 binding +1 votes and more +1 votes than -1 votes (i.e., a majority with a minimum quorum of three positive votes). My interpretation of the rest of guideline is that a consensus vote is only required for actual code changes. Perhaps we should set our own policy for a vote on a release candidate? See http://httpd.apache.org/dev/guidelines.html. If this is a majority vote, then the polls are closed and 3.2.7 is the winner. :) (And I didn't even use a calulator this time. ;) ) Jim
Re: mod_python 3.2.7 available for testing
On Feb 7, 2006, at 9:32 AM, Jim Gallacher wrote: When the core group votes for a release candidate, is it a consensus vote or a majority vote? To quote from the Apache voting guidelines, An action item requiring consensus approval must receive at least 3 binding +1 votes and no vetos. An action item requiring majority approval must receive at least 3 binding +1 votes and more +1 votes than -1 votes (i.e., a majority with a minimum quorum of three positive votes). Release votes are majority votes. That prevents some forms of voting abuse and allows progress to be made even when it isn't perfect. My interpretation of the rest of guideline is that a consensus vote is only required for actual code changes. Perhaps we should set our own policy for a vote on a release candidate? See http://httpd.apache.org/dev/guidelines.html. If this is a majority vote, then the polls are closed and 3.2.7 is the winner. :) (And I didn't even use a calulator this time. ;) ) We usually wait for 72 hours or until all the voters vote, since some times it only takes one discovered failure to cause everyone else to change their votes. Roy
Re: mod_python 3.2.7 available for testing
Nicolas Lehuen wrote .. OK so my core group vote is +1 for this release. It has been tested on a wide array of OSes, both threaded and forked MPMs, Python 2.2, 2.3 and 2.4, so I guess it's okay. A threaded test on MacOSX and Solaris would have been great but maybe the recommended MPM on those platform is the forked one, so we don't have to worry about those. My vote is redundant again, but I can add one of the configurations that Nicolas wanted to see: +1 MacOSX 10.3.9 PPC, Apache-2.0.55-worker, Python-2.3 I'll also say +1 as core group vote. This means all 4 have voted as +1 and no need to wait 72 hours now to see if I would veto it. I'm too busy anyway, finding new features/improvements to add to JIRA, to look at 3.2.7 in particular to find bugs. ;-) Graham Regards, Nicolas 2006/2/7, Jim Gallacher [EMAIL PROTECTED]: Gregory (Grisha) Trubetskoy wrote: I think we have enough +1's. (If someone could tally them up in a single e-mail, that'd be great.) Should we start a core-group vote, or wait some more? On the bash issue - I think we can leave it as is, the affected distros will just have to maintain a patch in their build systems. Let's vote. Here is the test summary: +1 Debian (sid), Apache 2.0.55-prefork, Python 2.3.5 +1 Debian (sarge), Apache 2.0.54-worker, Python 2.3.5 +1 Debian (sarge), Apache 2.0.54-prefork, Python 2.3.5 +1 Debian (testing, aka, etch), Apache 2.0.55-worker, Python 2.3.5 +1 Fedora Core 4, Linux 2.6.15, Apache 2.0.54, Python 2.4.1 +1 FreeBSD 4.9 , Apache 2.0.50 (prefork), Python 2.3.4 +1 FreeBSD 4.9 , Apache 2.0.55 (prefork), Python 2.4.2 +1 MacOSX 10.4.4 PPC, Apache-2.0.55-prefork, Python-2.4.2 +1 Slackware 10.1, Apache 2.0.55 (mpm-prefork), Python 2.4 +1 Solaris 10 Sparc, Apache-2.0.55-prefork, Python-2.4.2 +1 Ubuntu 5.10 Breezy (amd64), Apache 2.0.54-worker, Python 2.4.2 +1 Windows 2000 SP4, Apache/2.0.55 + Python/2.2.3 +1 Windows 2000 SP4, Apache/2.0.55 + ActivePython/2.3.5 +1 Windows XP SP2, Apache/2.0.55 + ActivePython/2.4.2 With configure fixed manually to deal with bash bug: +1 Gentoo 2005.1 (amd64), Apache 2.0.55-prefork, Python 2.4.2 Plus we have the following tests from the svn revision which corresponds to 3.2.7: +1 trunk rev 374709 FreeBSD 6.0 Apache 2.0.55-prefork, Python 2.4.2 Jim
Re: mod_python 3.2.7 available for testing
On Sun, Feb 05, 2006 at 09:10:15PM -0500, Jim Gallacher wrote: Mod_python 3.2.7 tarball is available for test. Here's hoping this will be to final time we need your help testing before the official release. 3.2.7 adds a fix for the connection read issue that was causing problems on FreeBSD. Here are the rules: In order for a file to be officially announced, it has to be tested by developers on the dev list. Anyone subscribed to this list can (and should feel obligated to :-) ) test it, and provide feedback *to _this_ list*! (Not the [EMAIL PROTECTED] list, and preferably not me personally). +1 FreeBSD 4.9 , Apache 2.0.50 (prefork), Python 2.3.4 +1 FreeBSD 4.9 , Apache 2.0.55 (prefork), Python 2.4.2
Re: mod_python 3.2.7 available for testing
+1 Fedora Core 4, Linux 2.6.15, Apache 2.0.54, Python 2.4.1 Jim Gallacher wrote: Mod_python 3.2.7 tarball is available for test. Here's hoping this will be to final time we need your help testing before the official release. 3.2.7 adds a fix for the connection read issue that was causing problems on FreeBSD. Here are the rules: In order for a file to be officially announced, it has to be tested by developers on the dev list. Anyone subscribed to this list can (and should feel obligated to :-) ) test it, and provide feedback *to _this_ list*! (Not the [EMAIL PROTECTED] list, and preferably not me personally). The files are (temporarily) available here: http://www.modpython.org/dist/ Please download it, then do the usual $ ./configure --with-apxs=/wherever/it/is $ make $ (su) # make install Then (as non-root user!) $ cd test $ python test.py And see if any tests fail. If they pass, send a +1 to the list, if they fail, send the details (the versions of OS, Python and Apache, the test output, and suggestions, if any). Thank you for your assistance, Jim Gallacher
Re: mod_python 3.2.7 available for testing
Hi,
I hate to be the first one to report an issue with 3.2.7 tarball...
It might be related to my lack of knowledge (just joined the dev list
a few days ago), but here it is:
It is failing during the configure process...
[EMAIL PROTECTED] ~/mod_python-3.2.7 $ ./configure --with-apxs=/usr/
sbin/apxs2
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for ar... ar
checking for a BSD-compatible install... /usr/bin/install -c
checking whether make sets $(MAKE)... yes
checking for main in -lm... yes
checking for an ANSI C-conforming const... yes
checking your blood pressure... a bit high, but we can proceed
configure: checking whether apxs is available...
checking for --with-apxs... /usr/sbin/apxs2 executable, good
checking Apache version... 2.0.55
checking for Apache libexec directory... /usr/lib64/apache2/modules
checking for Apache include directory... -I/usr/include/apache2
checking for --with-python... no
checking for python... /usr/bin/python
checking Python version... 2.4
checking Python install prefix... /usr
checking checking where python libraries are installed... /usr/lib64/
python2.4
checking for Py_NewInterpreter in -lpython2.4... yes
checking what libraries Python was linked with... -lpython2.4 -
lpthread -ldl -lutil -lm
checking linker flags used to link Python...
checking where Python include files are... -I/usr/include/python2.4
./configure: line 3427: syntax error near unexpected token `('
./configure: line 3427: ` as_lineno_3=`(expr $as_lineno_1 + 1) 2/
dev/null`'
System is an Opteron 170 running Gentoo in 64 bit mode (2005.1 profile):
uname -a
Linux andromeda 2.6.14-gentoo-r5 #1 SMP Sun Jan 15 21:46:56 CST 2006
x86_64 Dual Core AMD Opteron(tm) Processor 170 AuthenticAMD GNU/Linux
/usr/sbin/apache2 -v
Server version: Apache/2.0.55
Server built: Jan 19 2006 15:46:57
/usr/sbin/apache2 -l
Compiled in modules:
core.c
prefork.c
http_core.c
mod_so.c
Python is 2.4.2
FYI, mod_python 3.1.4 configures, compiles and runs fine on the same
system.
Please let me know if you need anymore info.
Thanks,
Sébastien
On Feb 5, 2006, at 8:10 PM, Jim Gallacher wrote:
Mod_python 3.2.7 tarball is available for test. Here's hoping this
will be to final time we need your help testing before the official
release.
3.2.7 adds a fix for the connection read issue that was causing
problems on FreeBSD.
Here are the rules:
In order for a file to be officially announced, it has to be tested by
developers on the dev list. Anyone subscribed to this list can (and
should feel obligated to :-) ) test it, and provide feedback *to
_this_
list*! (Not the [EMAIL PROTECTED] list, and preferably not me
personally).
The files are (temporarily) available here:
http://www.modpython.org/dist/
Please download it, then do the usual
$ ./configure --with-apxs=/wherever/it/is
$ make
$ (su)
# make install
Then (as non-root user!)
$ cd test
$ python test.py
And see if any tests fail. If they pass, send a +1 to the list, if
they
fail, send the details (the versions of OS, Python and Apache, the
test
output, and suggestions, if any).
Thank you for your assistance,
Jim Gallacher
PGP.sig
Description: This is a digitally signed message part
Re: mod_python 3.2.7 available for testing
Hi Graham,
I am using:
[EMAIL PROTECTED] ~/mod_python-3.2.7 $ bash --version
GNU bash, version 3.1.7(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
I will look at if I can find later the BASH bug you are referring to.
I had the feeling that it was not directly mod_python causing the
issue, but that I ought to report the issue, since the problem was
not existent when I compiled the latest official release of
mod_python (3.1.4)
Thanks,
Sébastien
On Feb 6, 2006, at 2:06 PM, Graham Dumpleton wrote:
What version of BASH shell are you using? Can't remember the
version, but a
particular patch level revision of BASH released recently has a bug
in it
which causes configure to error. Ie., it is a BASH bug and not
mod_python.
Have to run now, so more later.
Graham
On 07/02/2006, at 6:46 AM, Sébastien Arnaud wrote:
Hi,
I hate to be the first one to report an issue with 3.2.7
tarball... It might be related to my lack of knowledge (just
joined the dev list a few days ago), but here it is:
It is failing during the configure process...
[EMAIL PROTECTED] ~/mod_python-3.2.7 $ ./configure --with-apxs=/
usr/sbin/apxs2
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for ar... ar
checking for a BSD-compatible install... /usr/bin/install -c
checking whether make sets $(MAKE)... yes
checking for main in -lm... yes
checking for an ANSI C-conforming const... yes
checking your blood pressure... a bit high, but we can proceed
configure: checking whether apxs is available...
checking for --with-apxs... /usr/sbin/apxs2 executable, good
checking Apache version... 2.0.55
checking for Apache libexec directory... /usr/lib64/apache2/modules
checking for Apache include directory... -I/usr/include/apache2
checking for --with-python... no
checking for python... /usr/bin/python
checking Python version... 2.4
checking Python install prefix... /usr
checking checking where python libraries are installed... /usr/
lib64/python2.4
checking for Py_NewInterpreter in -lpython2.4... yes
checking what libraries Python was linked with... -lpython2.4 -
lpthread -ldl -lutil -lm
checking linker flags used to link Python...
checking where Python include files are... -I/usr/include/python2.4
./configure: line 3427: syntax error near unexpected token `('
./configure: line 3427: ` as_lineno_3=`(expr $as_lineno_1 + 1) 2/
dev/null`'
System is an Opteron 170 running Gentoo in 64 bit mode (2005.1
profile):
uname -a
Linux andromeda 2.6.14-gentoo-r5 #1 SMP Sun Jan 15 21:46:56 CST
2006 x86_64 Dual Core AMD Opteron(tm) Processor 170 AuthenticAMD
GNU/Linux
/usr/sbin/apache2 -v
Server version: Apache/2.0.55
Server built: Jan 19 2006 15:46:57
/usr/sbin/apache2 -l
Compiled in modules:
core.c
prefork.c
http_core.c
mod_so.c
Python is 2.4.2
FYI, mod_python 3.1.4 configures, compiles and runs fine on the
same system.
Please let me know if you need anymore info.
Thanks,
Sébastien
On Feb 5, 2006, at 8:10 PM, Jim Gallacher wrote:
Mod_python 3.2.7 tarball is available for test. Here's hoping
this will be to final time we need your help testing before the
official release.
3.2.7 adds a fix for the connection read issue that was causing
problems on FreeBSD.
Here are the rules:
In order for a file to be officially announced, it has to be
tested by
developers on the dev list. Anyone subscribed to this list can (and
should feel obligated to :-) ) test it, and provide feedback *to
_this_
list*! (Not the [EMAIL PROTECTED] list, and preferably
not me
personally).
The files are (temporarily) available here:
http://www.modpython.org/dist/
Please download it, then do the usual
$ ./configure --with-apxs=/wherever/it/is
$ make
$ (su)
# make install
Then (as non-root user!)
$ cd test
$ python test.py
And see if any tests fail. If they pass, send a +1 to the list,
if they
fail, send the details (the versions of OS, Python and Apache,
the test
output, and suggestions, if any).
Thank you for your assistance,
Jim Gallacher
PGP.sig
Description: This is a digitally signed message part
bash bug (was Re: mod_python 3.2.7 available for testing)
A couple of thoughts on this issue.
According to the gentoo bug report quoted below, the problem in
configure.in is the double backslash escape sequence in the line:
MP_VERSION=`echo $MP_VERSION | sed s/\\//g`
Changing this to:
MP_VERSION=`echo $MP_VERSION | sed s/\//g`
fixes it for bash 3.1. I wonder why we are using \\ since the gentoo
fix seems to work ok with bash 3.0 (and GNU sed) on my system just as
well. Is it there to support other shells, other sed versions, older
bash versions... ??
I suggest we either adopt the gentoo fix, or avoid the problem
altogether by using tr. eg.
MP_VERSION=`echo $MP_VERSION | tr -d ''`
I'm assuming tr is always available on UNIX-like systems.
Jim
Jim Gallacher wrote:
The bash 3.1.x bug is the likely culprit.
For more info see:
http://www.modpython.org/pipermail/mod_python/2006-January/019965.html
http://www.modpython.org/pipermail/mod_python/2006-January/019969.html
http://bugs.gentoo.org/show_bug.cgi?id=118948
Jim
Sébastien Arnaud wrote:
Hi Graham,
I am using:
[EMAIL PROTECTED] ~/mod_python-3.2.7 $ bash --version
GNU bash, version 3.1.7(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
I will look at if I can find later the BASH bug you are referring to.
I had the feeling that it was not directly mod_python causing the
issue, but that I ought to report the issue, since the problem was
not existent when I compiled the latest official release of
mod_python (3.1.4)
Thanks,
Sébastien
On Feb 6, 2006, at 2:06 PM, Graham Dumpleton wrote:
What version of BASH shell are you using? Can't remember the
version, but a
particular patch level revision of BASH released recently has a bug
in it
which causes configure to error. Ie., it is a BASH bug and not
mod_python.
Have to run now, so more later.
Graham
On 07/02/2006, at 6:46 AM, Sébastien Arnaud wrote:
Hi,
I hate to be the first one to report an issue with 3.2.7 tarball...
It might be related to my lack of knowledge (just joined the dev
list a few days ago), but here it is:
It is failing during the configure process...
[EMAIL PROTECTED] ~/mod_python-3.2.7 $ ./configure --with-apxs=/
usr/sbin/apxs2
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for ar... ar
checking for a BSD-compatible install... /usr/bin/install -c
checking whether make sets $(MAKE)... yes
checking for main in -lm... yes
checking for an ANSI C-conforming const... yes
checking your blood pressure... a bit high, but we can proceed
configure: checking whether apxs is available...
checking for --with-apxs... /usr/sbin/apxs2 executable, good
checking Apache version... 2.0.55
checking for Apache libexec directory... /usr/lib64/apache2/modules
checking for Apache include directory... -I/usr/include/apache2
checking for --with-python... no
checking for python... /usr/bin/python
checking Python version... 2.4
checking Python install prefix... /usr
checking checking where python libraries are installed... /usr/
lib64/python2.4
checking for Py_NewInterpreter in -lpython2.4... yes
checking what libraries Python was linked with... -lpython2.4 -
lpthread -ldl -lutil -lm
checking linker flags used to link Python...
checking where Python include files are... -I/usr/include/python2.4
./configure: line 3427: syntax error near unexpected token `('
./configure: line 3427: ` as_lineno_3=`(expr $as_lineno_1 + 1) 2/
dev/null`'
System is an Opteron 170 running Gentoo in 64 bit mode (2005.1
profile):
uname -a
Linux andromeda 2.6.14-gentoo-r5 #1 SMP Sun Jan 15 21:46:56 CST
2006 x86_64 Dual Core AMD Opteron(tm) Processor 170 AuthenticAMD
GNU/Linux
/usr/sbin/apache2 -v
Server version: Apache/2.0.55
Server built: Jan 19 2006 15:46:57
/usr/sbin/apache2 -l
Compiled in modules:
core.c
prefork.c
http_core.c
mod_so.c
Python is 2.4.2
FYI, mod_python 3.1.4 configures, compiles and runs fine on the
same system.
Please let me know if you need anymore info.
Thanks,
Sébastien
On Feb 5, 2006, at 8:10 PM, Jim Gallacher wrote:
Mod_python 3.2.7 tarball is available for test. Here's hoping this
will be to final time we need your help testing before the
official release.
3.2.7 adds a fix for the connection read issue that was causing
problems on FreeBSD.
Here are the rules:
In order for a file to be officially announced, it has to be
tested by
developers on the dev list. Anyone subscribed to this list can (and
should feel obligated to :-) ) test it, and provide feedback *to
_this_
list*! (Not the [EMAIL PROTECTED] list, and preferably not me
personally).
The files are (temporarily)
Re: bash bug (was Re: mod_python 3.2.7 available for testing)
On 2/6/06, Jim Gallacher [EMAIL PROTECTED] wrote: A couple of thoughts on this issue. According to the gentoo bug report quoted below, the problem in configure.in is the double backslash escape sequence in the line: MP_VERSION=`echo $MP_VERSION | sed s/\\//g` Changing this to: MP_VERSION=`echo $MP_VERSION | sed s/\//g` fixes it for bash 3.1. I wonder why we are using \\ since the gentoo fix seems to work ok with bash 3.0 (and GNU sed) on my system just as well. Is it there to support other shells, other sed versions, older bash versions... ?? I suggest we either adopt the gentoo fix, or avoid the problem altogether by using tr. eg. MP_VERSION=`echo $MP_VERSION | tr -d ''` I'm assuming tr is always available on UNIX-like systems. Personally I prefer tr because it's more readable. But I don't know it's availability outside Unix. You can try single-quoting the sed expression and eliminationg the backslashes altogether: MP_VERSION=`echo $MP_VERSION | sed 's///g' ` If there is also some problem with a sed treating as a special character, you can always use character classes: MP_VERSION=`echo $MP_VERSION | sed 's/[]//g' ` I generally find that avoid backslashes at all cost improves portability of scripts across broken shells/seds. -- Deron Meranda
Re: mod_python 3.2.7 available for testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 Ubuntu 5.10 Breezy (amd64), Apache 2.0.54-worker, Python 2.4.2 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFD5/mTv4zJ7LQ+i84RAofQAKCb4ptmhPQa5QKRV/2sga60Xz4oAACcDygf IB8UDE0zlcUr+I16DWbQ09U= =WrUY -END PGP SIGNATURE-
Re: bash bug (was Re: mod_python 3.2.7 available for testing)
Hi, I would like to report: +1 Gentoo 2005.1 (amd64), Apache 2.0.55-prefork, Python 2.4.2 After replacing the troubling line (line 3038, configure): from: MP_VERSION=`echo $MP_VERSION | sed s/\\//g` to (Deron's 1st suggestion): MP_VERSION=`echo $MP_VERSION | sed 's///g' ` I guess now it's up to you to decide if you want to integrate the patch or if you want to leave it as is for this release ;) Thanks, Sébastien On Feb 6, 2006, at 4:13 PM, Deron Meranda wrote: On 2/6/06, Jim Gallacher [EMAIL PROTECTED] wrote: A couple of thoughts on this issue. According to the gentoo bug report quoted below, the problem in configure.in is the double backslash escape sequence in the line: MP_VERSION=`echo $MP_VERSION | sed s/\\//g` Changing this to: MP_VERSION=`echo $MP_VERSION | sed s/\//g` fixes it for bash 3.1. I wonder why we are using \\ since the gentoo fix seems to work ok with bash 3.0 (and GNU sed) on my system just as well. Is it there to support other shells, other sed versions, older bash versions... ?? I suggest we either adopt the gentoo fix, or avoid the problem altogether by using tr. eg. MP_VERSION=`echo $MP_VERSION | tr -d ''` I'm assuming tr is always available on UNIX-like systems. Personally I prefer tr because it's more readable. But I don't know it's availability outside Unix. You can try single-quoting the sed expression and eliminationg the backslashes altogether: MP_VERSION=`echo $MP_VERSION | sed 's///g' ` If there is also some problem with a sed treating as a special character, you can always use character classes: MP_VERSION=`echo $MP_VERSION | sed 's/[]//g' ` I generally find that avoid backslashes at all cost improves portability of scripts across broken shells/seds. -- Deron Meranda PGP.sig Description: This is a digitally signed message part
mod_python 3.2.7 available for testing
Mod_python 3.2.7 tarball is available for test. Here's hoping this will be to final time we need your help testing before the official release. 3.2.7 adds a fix for the connection read issue that was causing problems on FreeBSD. Here are the rules: In order for a file to be officially announced, it has to be tested by developers on the dev list. Anyone subscribed to this list can (and should feel obligated to :-) ) test it, and provide feedback *to _this_ list*! (Not the [EMAIL PROTECTED] list, and preferably not me personally). The files are (temporarily) available here: http://www.modpython.org/dist/ Please download it, then do the usual $ ./configure --with-apxs=/wherever/it/is $ make $ (su) # make install Then (as non-root user!) $ cd test $ python test.py And see if any tests fail. If they pass, send a +1 to the list, if they fail, send the details (the versions of OS, Python and Apache, the test output, and suggestions, if any). Thank you for your assistance, Jim Gallacher
Re: mod_python 3.2.7 available for testing
+1 Debian (sid), Apache 2.0.55-prefork, Python 2.3.5 +1 Debian (sarge), Apache 2.0.54-worker, Python 2.3.5 +1 Debian (sarge), Apache 2.0.54-prefork, Python 2.3.5 Jim Jim Gallacher wrote: Mod_python 3.2.7 tarball is available for test. Here's hoping this will be to final time we need your help testing before the official release. 3.2.7 adds a fix for the connection read issue that was causing problems on FreeBSD. Here are the rules: In order for a file to be officially announced, it has to be tested by developers on the dev list. Anyone subscribed to this list can (and should feel obligated to :-) ) test it, and provide feedback *to _this_ list*! (Not the [EMAIL PROTECTED] list, and preferably not me personally). The files are (temporarily) available here: http://www.modpython.org/dist/ Please download it, then do the usual $ ./configure --with-apxs=/wherever/it/is $ make $ (su) # make install Then (as non-root user!) $ cd test $ python test.py And see if any tests fail. If they pass, send a +1 to the list, if they fail, send the details (the versions of OS, Python and Apache, the test output, and suggestions, if any). Thank you for your assistance, Jim Gallacher
