Re: mod_python 3.2.6 (Final!) available for testing
2006/2/7, Nicolas Lehuen <[EMAIL PROTECTED]>: > 2006/1/21, Jim Gallacher <[EMAIL PROTECTED]>: > > I notice that we have slight differences in the apache and python > > versions. Could that be significant? More testing to follow. (Oh if only > > qemu wasn't so slow. Compiling Apache takes... a ... long ... time). > > > > Jim > > Oh joy, VMWare has made it VMWare GSX product free of charge : > > http://www.vmware.com/products/server/ > > Judging from how VMWare Workstation performs, it is great news. > Granted, it's not open source, but if it can save us hours of > compilation... I don't know if FreeBSD is supported, but Workstation > runs it without any problem. > > The only problem for me is that I'm a total FreeBSD newbie, meaning > that I could install Apache but something went wrong during the > mod_python configuration. Well, I'll try it another time soon. > > Regards, > Nicolas > Note that there are pre-built environment available here : http://www.vmware.com/vmtn/vm/community.html Amongst them, there is a FreeBSD 6.0 virtual machine. Regards, Nicolas
Re: mod_python 3.2.6 (Final!) available for testing
2006/1/21, Jim Gallacher <[EMAIL PROTECTED]>: > I notice that we have slight differences in the apache and python > versions. Could that be significant? More testing to follow. (Oh if only > qemu wasn't so slow. Compiling Apache takes... a ... long ... time). > > Jim Oh joy, VMWare has made it VMWare GSX product free of charge : http://www.vmware.com/products/server/ Judging from how VMWare Workstation performs, it is great news. Granted, it's not open source, but if it can save us hours of compilation... I don't know if FreeBSD is supported, but Workstation runs it without any problem. The only problem for me is that I'm a total FreeBSD newbie, meaning that I could install Apache but something went wrong during the mod_python configuration. Well, I'll try it another time soon. Regards, Nicolas
Re: Hooking handler with ap_hook_map_to_storage().
Graham Dumpleton wrote .. > Grisha > > I have a really obscure question for you. > > Was there a specific reason that mod_python did not allow a handler > to be hooked using ap_hook_map_to_storage()? > > I know that the reasons for wanting to do this would be very limited, > such as if you wanted to implement some sort of equivalent to mod_proxy > in Python, but curious all the same. > > Notionally the handler would have fit in as 2 1/2 in code fragment below. > > /* [2] filename-to-URI translation */ > ap_hook_translate_name(PythonTransHandler, >NULL, NULL, APR_HOOK_MIDDLE); > > /* [2 1/2] map filename to storage */ > ap_hook_translate_name(PythonStorageHandler, >NULL, NULL, APR_HOOK_MIDDLE); Whoops. Wrong function. /* [2 1/2] map filename to storage */ ap_hook_map_to_storage(PythonStorageHandler, NULL, NULL, APR_HOOK_MIDDLE); > /* [3] header parser */ > ap_hook_header_parser(PythonHeaderParserHandler, > NULL, NULL, APR_HOOK_MIDDLE); > Graham
Hooking handler with ap_hook_map_to_storage().
Grisha I have a really obscure question for you. Was there a specific reason that mod_python did not allow a handler to be hooked using ap_hook_map_to_storage()? I know that the reasons for wanting to do this would be very limited, such as if you wanted to implement some sort of equivalent to mod_proxy in Python, but curious all the same. Notionally the handler would have fit in as 2 1/2 in code fragment below. /* [2] filename-to-URI translation */ ap_hook_translate_name(PythonTransHandler, NULL, NULL, APR_HOOK_MIDDLE); /* [2 1/2] map filename to storage */ ap_hook_translate_name(PythonStorageHandler, NULL, NULL, APR_HOOK_MIDDLE); /* [3] header parser */ ap_hook_header_parser(PythonHeaderParserHandler, NULL, NULL, APR_HOOK_MIDDLE); Graham Graham
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
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)
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
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: mod_python 3.2.7 available for testing
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) 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 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
Re: mod_python 3.2.7 available for testing
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
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
+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
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
