timely, since 3.2.6 is (so far) going to be a
final/stable release.
I propose that for starters those people are:
me (I'm also in the Apache HTTP Server PMC)
Jim Gallacher
Nicolas Lehuen
Graham Dumpleton
+1 here, but since the build process and typical MPM differs among
platforms, could we
Hi Barry,
I finally got mod_python working on a qemu image of FreeBSD 6.0 and I
can't reproduce your problem. All the tests pass for 3.2.6.
I did find that mod_python.so wasn't linking python2.4.so or
libpthread.so. Being a BSD noob I'm not sure if I've messed up my
configuration or if
Graham Dumpleton wrote:
Thus, trade off of speed versus correctness is probably reasonable as it
will
not cause a failure. In general I tend towards robustness and unexpected
surprises and that is why the code was written as it was.
Personally I tend towards robustness and *away* from
It seems like any 3.2.6 testing that is going to be done, has been done.
How long do we wait before making a decision for an official release.
If we don't get cracking on 3.3 soon Graham's gonna fill another couple
of pages on JIRA and we'll never catch up. :)
Jim
Gregory (Grisha) Trubetskoy wrote:
On Thu, 26 Jan 2006, Jim Gallacher wrote:
It seems like any 3.2.6 testing that is going to be done, has been done.
I've been kinda swamped with unrelated things past two weeks, so I
wasn't paying much attention. Perhaps an e-mail summarizing the +1's so
Gregory (Grisha) Trubetskoy wrote:
On Thu, 26 Jan 2006, Jim Gallacher wrote:
It seems like any 3.2.6 testing that is going to be done, has been done.
I've been kinda swamped with unrelated things past two weeks, so I
wasn't paying much attention. Perhaps an e-mail summarizing the +1's so
Volodya wrote:
On Fri, Jan 27, 2006 at 10:28:24AM -0500, Gregory (Grisha) Trubetskoy wrote:
OK, and I see Ron sent a Solaris 10 +1, which is good. I think we need a
FreeBSD +1 - perhaps not necessarily 6.0, but something...
FreeBSD 4.9
In my case PythonConnectionHandler test fails.
Graham Dumpleton wrote:
On 29/01/2006, at 1:29 AM, Jim Gallacher wrote:
Volodya wrote:
On Fri, Jan 27, 2006 at 10:28:24AM -0500, Gregory (Grisha)
Trubetskoy wrote:
OK, and I see Ron sent a Solaris 10 +1, which is good. I think we
need a FreeBSD +1 - perhaps not necessarily 6.0
Gregory (Grisha) Trubetskoy wrote:
On Sun, 29 Jan 2006, Graham Dumpleton wrote:
buffer += bufsize;
On a second thought - yes, you're right :-)
And if he's not then there is a bug in filter_read since that is what it
does and it is very similar to _conn_read.
Jim
Jim Gallacher wrote:
Graham Dumpleton wrote:
What I might speculate is that if the test in mod_python for the
connection handler is setup to run on a secondary listener port,
but with the primary still active, that it may trigger the problem
on other systems like Linux. Jim, you might want
Volodya wrote:
On Mon, Jan 30, 2006 at 09:40:39PM -0500, Graham Dumpleton wrote:
Graham Dumpleton wrote ..
Extending the above code as:
Py_BEGIN_ALLOW_THREADS;
rc = ap_get_brigade(c-input_filters, bb, mode, APR_BLOCK_READ, bufsize);
Py_END_ALLOW_THREADS;
if (!
Jim Gallacher wrote:
Volodya wrote:
On Mon, Jan 30, 2006 at 09:40:39PM -0500, Graham Dumpleton wrote:
Graham Dumpleton wrote ..
Extending the above code as:
Py_BEGIN_ALLOW_THREADS;
rc = ap_get_brigade(c-input_filters, bb, mode, APR_BLOCK_READ,
bufsize);
Py_END_ALLOW_THREADS
I assume we will be doing a 3.2.7 release if Graham's fix for the
ConnectionHandler / MODPYTHON-102 problem works?
If that is the case I wonder if we should roll in the changes to support
apache 2.2. I scanned mod_python for deprecated or removed apr calls and
can find only one
, Jim Gallacher [EMAIL PROTECTED]:
I assume we will be doing a 3.2.7 release if Graham's fix for the
ConnectionHandler / MODPYTHON-102 problem works?
If that is the case I wonder if we should roll in the changes to support
apache 2.2. I scanned mod_python for deprecated or removed apr calls and
can
Deron Meranda wrote:
On 1/31/06, Jim Gallacher [EMAIL PROTECTED] wrote:
apache 2.2. I scanned mod_python for deprecated or removed apr calls and
can find only one (apr_sockaddr_port_get), plus the missing
APR_STATUS_IS_SUCCESS macro.
The apr_sockaddr_port_get() call was introduced by me
later.
Thus, as much as I would prefer to see as much as possible fixed, I
think we just have defer further changes to next version.
Graham
Jim Gallacher wrote ..
Nicolas Lehuen wrote:
OK, so shall we schedule the 3.2.x release for 2007, then ?
As for the Apache 2.2 version, what if we roll
Graham Dumpleton wrote:
On 01/02/2006, at 9:10 PM, Nicolas Lehuen wrote:
Hi,
I've just checked in some changes to the Python source code in order
to support Python 2.2. Now the test suite runs successfully on Python
2.2.3 on Windows 2000. I've checked that no regressions were
introduced in
Daniel J. Popowich wrote:
Nicolas Lehuen writes:
I've just checked in some changes to the Python source code in order
to support Python 2.2. Now the test suite runs successfully on Python
2.2.3 on Windows 2000. I've checked that no regressions were
introduced in later Python versions, too.
I'm getting a unit test failure.
FAIL: test_publisher_cache (__main__.PerRequestTestCase)
--
Traceback (most recent call last):
File test.py, line 1836, in test_publisher_cache
self.fail(
File
Jim Gallacher wrote:
Graham Dumpleton wrote:
Jim Gallacher wrote ..
I'm getting a unit test failure.
FAIL: test_publisher_cache (__main__.PerRequestTestCase)
--
Traceback (most recent call last):
File test.py, line 1836
Graham Dumpleton wrote:
Jim Gallacher wrote ..
It is because you probably have a prefork/worker MPM.
The test as written will only reliably work for winnt MPM.
Doh! Prefork bites us in the a** yet again. :)
On UNIX boxes
the subsequent requests could be handled by a different child
Nicolas Lehuen wrote:
2006/2/4, Graham Dumpleton [EMAIL PROTECTED]:
Jim, Nicolas
Would it make sense to change test_Session_Session_conf() function in
unit tests to something like:
def test_Session_Session_conf(self):
import tempfile
tempdir = tempfile.gettempdir()
of OS, Python and Apache, the test
output, and suggestions, if any).
Thank you for your assistance,
Jim Gallacher
+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
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
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
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
Hi Grisha,
The mod_python information on modules.apache.org is badly out of date.
It would be a good idea to update this for 3.2.7
http://modules.apache.org/search?id=220
Jim
is available at:
http://httpd.apache.org/modules/
Many thanks to Jim Gallacher, Graham Dumpleton, Nicolas Lehuen and
everyone else who contributed to and helped test this release, without
your help it would not be possible!
Regards,
Grisha Trubetskoy
such as a 3.3 experimental
module import branch should start with an alpha character so the stable
3.x.x branches don't get lost in the noise. eg.
experimental-3.3
but not:
3.3-experimental
Jim
Gregory (Grisha) Trubetskoy wrote:
On Thu, 9 Feb 2006, Jim Gallacher wrote:
Looks good. As soon
Nicolas Lehuen wrote:
Hi,
There is something I'd like to do for the 3.3 version : it is to
refactor the test suite. It's more a chore than real development, but
the current test suite is slowly becoming big and quite difficult to
maintain.
Also, I think the size and complexity may be
Justin Erenkrantz wrote:
On 2/11/06, Jim Gallacher [EMAIL PROTECTED] wrote:
The underlying html from httdp.apache.org makes heavy use of tables for
layout and formating. If we end up using this layout I'd want to rewrite
it in css. Tables are just so last century. :)
You realize
The download page under the Apache Mod_python 3.2.7 is now available
heading states:
It will also work with HTTP Server 2.2, but this support should be
considered experimental at this point.
This is not correct. We made the decision to not support Apache 2.2 in
this release. There is a
Graham Dumpleton wrote:
snip
Thus we come to my actual idea that I want some feedback on.
The idea is to provide a new directive in mod_python that allows you to
mark
an arbitrary point in the directory hierarchy as a context point or
base directory
from which files can then be addressed
Graham Dumpleton wrote:
On 12/02/2006, at 2:40 PM, Jim Gallacher wrote:
Graham Dumpleton wrote:
get_directories could have several meanings in the context of a
request. Would req.get_module_directories() be a better alternative?
Does that capture the concept that you are trying
Justin Erenkrantz wrote:
On 2/11/06, Jim Gallacher [EMAIL PROTECTED] wrote:
No, I was not aware that it is auto-generated, but I'm hardly suprised.
:) The point was mostly to kick off a discussion.
The point is that you needn't muck with HTML directly and can focus on
the content instead
Mike Looijmans wrote:
Oh and if we are refactoring the tests, I want a make tests rule. I'm
tired of doing: ./configure; make; sudo make install; make tests; DOH!
cd test; python test.py. :)
Make that make check (like autotools), to not confuse old-skool
autoconfers like myself.
That
Graham Dumpleton wrote:
As Jim pointed out a while back, we need to get going on mod_python 3.3
before I fill up JIRA with another page of bug reports or suggestions.
I think you already *have* filled another page since I made that comment. ;)
That said, how do we want to proceed on this? Do
Nicolas Lehuen wrote:
Based on today's traffic on the mailing lists, I think that we should
go for a short-term 3.2.8 release of mod_python, with certified Apache
2.2 support on multiple platforms. The code is only there but I
suppose we'll need a lot of testing, so maybe we could expect to
Nicolas Lehuen wrote:
Hi,
I've built Apache 2.2 and tested mod_python SVN trunk with it.
The two register_cleanup tests fail. Apparently it's because the test
code registers a cleanup function giving the current request as
parameter. Of course when the cleanup function is called, the request
Nicolas Lehuen wrote:
2006/2/15, Jim Gallacher [EMAIL PROTECTED]:
Nicolas Lehuen wrote:
Hi,
I've built Apache 2.2 and tested mod_python SVN trunk with it.
The two register_cleanup tests fail. Apparently it's because the test
code registers a cleanup function giving the current request
I just noticed that write is declared twice in request_methods[] .
What's up with that??
src/requestobject.c
static PyMethodDef request_methods[] = {
...
... line 1075
{write, (PyCFunction) req_write, METH_VARARGS},
...
... line 1087
{write, (PyCFunction)
Graham,
I don't think it's necessary to add an additional JIRA comment when you
commit some code. JIRA will pickup the svn commit as long as the issue
number is mentioned in the svn commit message. People can subscribe to
python-cvs if they want notification of the commits.
This should save
Yes, this test seems to be broken. I'll create a JIRA issue for it.
We need unit tests for the unit tests. :)
Jim
For my WTF moment, have a look at test_req_get_basic_auth_pw in the
test suite. I guess it is supposed to be test req.get_basic_auth_pw (), but
that function isn't even mentioned
Now that 3.2.7 is out, should we be changing the status resolved issues
to closed in JIRA.
Jim
Jim Gallacher wrote:
Now that 3.2.7 is out, should we be changing the status resolved issues
to closed in JIRA.
Other JIRA thoughts:
Should we have a unit test component for bugs in the actual unit test
code?
Since we plan on having 3.2.x bugfix releases, should create new JIRA
versions
+1 Debian sid, apache 2.0.55 mpm-prefork, python 2.3.5
Graham Dumpleton wrote:
Jim Gallacher wrote ..
Jim Gallacher wrote:
Now that 3.2.7 is out, should we be changing the status resolved issues
to closed in JIRA.
If that is what closed implies. Is there somewhere which states what we
should interprete the different status as meaning? I don't
Graham Dumpleton wrote:
Jim Gallacher wrote ..
Graham,
I don't think it's necessary to add an additional JIRA comment when you
commit some code. JIRA will pickup the svn commit as long as the issue
number is mentioned in the svn commit message. People can subscribe to
python-cvs if they want
Graham Dumpleton wrote:
Jim Gallacher wrote ..
All very interesting, except that JIRA does record the svn commit info,
and with great detail. It just doesn't treat the commit as a comment.
For example:
http://issues.apache.org/jira/browse/MODPYTHON-124?page=all
Personally I think
Hi Oden,
The Apache 2.2 support will likely go into the 3.2.9 bugfix release. We
just wanted to get the security problem out of the way first.
Jim
Oden Eriksson wrote:
+1 Mandriva Linux Cooker (x86_64), apache 2.2.0 mpm-prefork, python-2.4.2
Note that I applied this change:
+ Apache/2.0.55 + Python/2.2.3 + Windows 2000 SP4
+1 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.3.5 + Windows
2000 SP4
+1 mod_python 3.2.8 + Apache/2.0.55 + ActivePython/2.4.2 + Windows XP SP2
Barry Pederson [EMAIL PROTECTED]
+1 FreeBSD 6.0, apache 2.0.55 mpm-prefork, python 2.4.2
Jim
Graham Dumpleton wrote:
On 21/02/2006, at 7:08 AM, Jim Gallacher wrote:
The Apache 2.2 support will likely go into the 3.2.9 bugfix release.
We just wanted to get the security problem out of the way first.
Jim, if we are again going to aim for a bug rollup release for 3.2.9 do I
need
Nice summary.
+1 for the change.
Jim
Graham Dumpleton wrote:
Jim Gallacher wrote ..
I don't have alot more to say on these last 2 emails. I think you are on
the right path here.
Okay, I think I have a good plan now.
To summarise the whole issue, the way Apache treats multiple handlers
Justin Erenkrantz wrote:
On 2/19/06, Jim Gallacher [EMAIL PROTECTED] wrote:
I just notice that a few files still say that mod_python uses Apache
License 1.1 (eg htdocs/tests.py, src/psp_string.c). Can I assume this is
an error and that *everything* should be version 2.0?
Yes. -- justin
Oh crap.
I changed the License information in htdocs/tests.py and thought, Gee
this is a simple change. No need to run the unit tests before I commit
the changes. Wrong. As it happens one of the unit tests looks at the
first line of htdocs/tests.py, which of course is now different. I've
Looks good. (with Jorey's correction).
Jim
Jorey Bump wrote:
Gregory (Grisha) Trubetskoy wrote:
If you see any problems with this text, let me know.
-- Forwarded message --
Date: Sat, 12 Feb 2005 22:00:56 -0500 (EST)
From: Gregory (Grisha) Trubetskoy [EMAIL PROTECTED]
To:
Now that JIRA is responding again I thought I'd update the status of
some issues.
I've created a new JIRA version for 3.2.8.
Version 3.2 is still shown as unreleased. I assume the proper action is
to rename it to 3.2.7 and mark it as released. Can someone confirm that
this is the correct
Graham,
The patch is faulty with the 3rd hunk getting rejected. It looks like
you generated it from an earlier revision, but one of the lines in the
hunk #3 was included in your commit for r380087. The offending line is:
+ python_filter: Can't get/create interpreter.);
Graham Dumpleton wrote:
One of the problems when I am looking at making changes to mod_python
is knowing that there is some consensus that changes are a good thing, or
at least that there is no objection.
I feel the same way. Let's establish some policy. I'll start a separate
thread for that
Graham Dumpleton wrote:
On 04/03/2006, at 4:59 AM, Jim Gallacher wrote:
More in the way of a general observation rather than on these
specific issues, but I wouldn't necessarily mark things as resolved
just on the basis of the fix being committed. For the big changes at
least, I think
Gregory (Grisha) Trubetskoy wrote:
I don't understand this enough to have an opinion on it, seems like
another way to skin a cat,
Yes, but perhaps just for small cats. ;)
Quoting from http://httpd.apache.org/docs/1.3/howto/ssi.html
SSI is certainly not a replacement for CGI, or other
I figured it was a mistake to do this late at night. :(
Graham Dumpleton (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-131?page=comments#action_12369959 ]
Graham Dumpleton commented on MODPYTHON-131:
In respect of:
Graham Dumpleton wrote:
This bit is going to change anyway when I add the PythonOption
mod_python.mutex_directory support. I have the changes ready, but I
think I'll review them in the morning rather than committing now.
I decide to do this stuff in 2 steps:
1. configure option
2.
Graham Dumpleton wrote:
Grisha wrote ..
On Mon, 13 Mar 2006, Graham Dumpleton wrote:
Thus I want a documented convention that if a handler is going to use
util.FieldStorage, that it should before doing so, first check whether
an existing instance resides as req.form and use that instead.
Graham Dumpleton wrote:
Jim Gallacher wrote ..
The idea of something like req.get_session() is to give users an obvious
way to grab a session object without the deadlock concerns. How many
times have we seen this kind of problem-code on the mailing list?
def index(req):
sess
Gregory (Grisha) Trubetskoy wrote:
On Mon, 13 Mar 2006, Jim Gallacher wrote:
The idea of something like req.get_session() is to give users an
obvious way to grab a session object without the deadlock concerns.
How many times have we seen this kind of problem-code on the mailing
list?
def
Debian Sid (httpd and python2.3 are stock debian):
$ /usr/bin/apxs2 -q CPPFLAGS
$ grep _FILE_OFFSET_BITS /usr/include/python2.3/pyconfig.h
#define _FILE_OFFSET_BITS 64
Jim
Gregory (Grisha) Trubetskoy wrote:
Could folks with access to different OS's try the following:
Compare output of apxs
+1
Commit it. The point of the snapshot is encourage testing to catch
problems earlier in the development cylce.
Jim
Graham Dumpleton wrote:
On 14/03/2006, at 12:23 PM, Jim Gallacher wrote:
I find I work more effectively when I have deadlines to worry about
(being a procrastinator
Graham Dumpleton wrote:
Now that I have some time, I'll explain why I want your reasoning. I
didn't have the time when I sent original email.
The only reason I can think of for Session not to generate a cookie is
because the SID is being extracted from the URL or is being passed by
some
Firat KUCUK wrote:
Graham Dumpleton yazmış:
Firat KUCUK wrote ..
Hi,
i have a little problem about Directory Index.
this is our .htaccess file:
Allow from All
AddHandler mod_python .py
PythonHandlerwepy.handler
PythonDebug On
DirectoryIndex index.htm index.html
, if any).
Thank you for your assistance,
Jim Gallacher
+1 Linux Debian Sid, apache 2.0.55 mpm-prefork, python 2.3.5
+1 Linux Debian Sid, apache 2.2.0 mpm-prefork, python 2.4.2
New Importer:
+1 Linux Debian Sid, apache 2.0.55 mpm-prefork, python 2.3.5
+1 Linux Debian Sid, apache 2.2.0 mpm-prefork, python 2.4.2
Jim Gallacher wrote:
mod_python-3.3.0
Hi Graham,
+1 auto update req.finfo when req.filename changed.
Is there a use case where the user might change filename but not want
finfo to change? I can't think of one, so let's save the user some work
and make their code more robust to boot.
A point I'd like to address is your concern
Nicolas Lehuen wrote:
Hi,
Just FYI, here are the results of my latest build tests with mod_python
SVN revision 387864 :
+1 ActivePython 2.4.2.10 / Apache 2.0.55 / Windows XP SP2 / old importer
+1 ActivePython 2.4.2.10 / Apache 2.0.55 / Windows XP SP2 / new importer
+1 ActivePython 2.3.5.? /
Graham Dumpleton wrote:
Nicolas
Are you okay with:
http://issues.apache.org/jira/browse/MODPYTHON-81
Pickling/unpickling top-level functions defined in published
module no longer works in mod_python 3.2
being resolved as Won't Fix and then closed?
As I describe in:
Graham Dumpleton wrote:
In:
http://issues.apache.org/jira/browse/MODPYTHON-117
I describe the idea of having a means of using PythonImport to define a
module to be imported into any interpreter that may be created. For some
cases where there are a lot of virtual hosts, this may be simpler
I'll take a look at the code tonight.
Jim
Graham Dumpleton wrote:
With FieldStorage being discussed on main user mailing list, came across
this old post of the mailing list:
http://www.modpython.org/pipermail/mod_python/2001-November/012256.html
What it is saying is that some HTTP clients
Graham Dumpleton wrote:
Graham Dumpleton wrote ..
Jim Gallacher wrote ..
WRT to 3.2.9, I've been bogged down with other stuff and will likely
be
fairly busy this week as well. How be we aim for a release somewhere
around April 22? I'd like to sort out why the apache 2.2 auth test fails
Jim Gallacher wrote:
I'm not sure about the most elegant way to handle this situation.
Perhaps something like:
#if !AP_MODULE_MAGIC_AT_LEAST(20050127,0)
#ifndef(AP_REG_EXTENDED)
typedef regex_t ap_regex_t;
#define AP_REG_EXTENDED REG_EXTENDED
#define AP_REG_ICASE REG_ICASE
#endif
#endif
We are slowly acquiring a number of reserved PythonOption keywords
which should likely be collected in one place so we don't end up with
any name collisions. Does the PythonOption page in section 5.4.10 seem
most appropriate? eg.
This seems like a good plan. I'll make the changes to the code and docs
- I don't want you to do all the work Graham. ;)
Jim
Graham Dumpleton (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MODPYTHON-127?page=comments#action_12376137 ]
Graham Dumpleton commented on MODPYTHON-127:
Graham Dumpleton (JIRA) wrote:
The actual function in Apache which can be used to normalise paths and which
outputs the POSIX style path required is apr_filepath_merge(). The question is,
should this be exposed in some way so that it is useable from mod_python, or
for the req.filename case,
I used pylint to assist in cleaning up the indentation mess in util.py.
I ended up checking all our lib/python/mod_python/*.py code, and
needless to say the results were edifying. The output is rather
extensive, with a lot noise regarding missing docstrings and the like,
but I suspect
Jim Gallacher wrote:
Laurent Blanquet wrote:
Hello,
I'm using MOD_APACHE 3.2.8 (from binary dist). with Apache 2.0.55
under Windows XP Pro.
I encounter memory leaks (~ 16 Ko per request) with a very basic
handler like :
import mod_python
from mod_python import util
def handler(req):
F
Jim Gallacher wrote:
Laurent Blanquet wrote:
Hello,
I'm using MOD_APACHE 3.2.8 (from binary dist). with Apache 2.0.55
under Windows XP Pro.
I encounter memory leaks (~ 16 Ko per request) with a very basic
handler like :
import mod_python
from mod_python import util
def handler(req):
F
Laurent,
Could you run a couple of more tests?
test1.py
from mod_python import apache, util
def handler(req):
pqs = util.parse_qsl('foo=abar=b')
req.content_type = 'text/plain'
req.write('mod_python.util.parse_qsl')
return apache.OK
test2.py
from mod_python
Max Bowsher wrote:
MODPYTHON-93, r387693, backported in r393781, changes the API of
mod_python.util.Field().
I think that it would be a very bad thing to change an API in an
incompatible way in a patch release - whilst people are likely to
understand that things may break going from 3.2.x to
looks good, I'll tag it svn and create a 3.2.9 final
tarball.
Thank you for your assistance,
Jim Gallacher
, if any).
If this tarball looks good, I'll tag it svn and create a 3.2.9 final
tarball.
Thank you for your assistance,
Jim Gallacher
Max Bowsher wrote:
Jim Gallacher wrote:
The mod_python 3.2.9-rc2 tarball is available for testing.
Something about the mod_python.util changes has either exposed a bug in
Trac, or introduced a bug into mod_python - I'm not sure which yet.
3.2.x r416547 with r393781 reverted works fine
Max Bowsher wrote:
Jim Gallacher wrote:
Max Bowsher wrote:
Jim Gallacher wrote:
The mod_python 3.2.9-rc2 tarball is available for testing.
Something about the mod_python.util changes has either exposed a bug in
Trac, or introduced a bug into mod_python - I'm not sure which yet.
3.2.x
for your assistance,
Jim Gallacher
+1 Linux Debian Sid, apache 2.0.55, python 2.3.5
Jim Gallacher wrote:
The mod_python 3.2.9-rc3 tarball is available for testing. This release
adds support for apache 2.2 as well as some other useful backports from
the development branch. For information on the changes from 3.2.8 take a
look
Mike Looijmans wrote:
Having written most of the issue 93 code, here's my opinion:
* How much non-compatibility is acceptable in a patch release?
None.
Though it hurts my personal feelings that my patch did manage to break
something (who imagined anyone trying to hack data into the FS
Here are the test results for 3.2.9 release candidate 3.
+1 FreeBSD 6.1 / Apache 2.2 / Python 2.4.3
+1 Linux Debian Sid, apache 2.0.55, python 2.3.5
Linux (Fedora Core 4) on Intel x86, Apache 2.0.58, Python 2.4.3
+1 Linux Slackware 10.1, Apache 2.0.55, Python 2.4.1
+1 Linux Slackware 10.2, Apache
. There is no need to include the
mod_python version in this string as that information is available in
the email subject. Who knows, one day I may actually write a script to
extract this information automatically. :)
Thank you for your assistance,
Jim Gallacher
+1 Linux Debian Sid, Apache 2.0.55 (mpm-worker), Python 2.3.5
Jim Gallacher wrote:
The mod_python 3.2.9 tarball is available for testing.
This tarball is unchanged from 3.2.9-rc3, but should be retested anyway
- just in case something went pair-shaped in the process of tagging and
packaging
Hi Harold,
I just wanted to let you know you are not being ignored. I just need
some free time to dive into this - hopefully this weekend.
Jim
Harold Ship (JIRA) wrote:
[
http://issues.apache.org/jira/browse/MODPYTHON-172?page=comments#action_12419728
]
Harold Ship commented on
Graham Dumpleton wrote:
On first look I would agree there is possibly a problem. There also
would appear to be
similar issues in other parts of mod_python. For example in
cfgtree_walk() of util.c it has:
PyObject *t = Py_BuildValue((s, s), dir-directive, dir-args);
if (!t)
101 - 200 of 328 matches
Mail list logo
