configure failure with bash-3.1 - fixed in SVN, but not in any release

Attempting to configure mod_python on a current Debian 'etch' system, or any other using bash-3.1, fails, with the shell error: syntax error near unexpected token `(' This has already been fixed in mod_python SVN for 4 months (r376555, MODPYTHON-122), and backported to 3.2.x (r383362), but has n

Re: configure failure with bash-3.1 - fixed in SVN, but not in any release

Jim Gallacher wrote: > Rob Sanderson wrote: >> +1 >> >> Seconded. We have a kludge in our install script to replace sh with >> ksh, but it would be nice to be able to remove this. >> >> Thanks! > > Is anyone aware of any issues fixed in trunk that still need to be > backported to 3.2.x? I'll chec

3.2.9 release blocker? API breakage for mod_python.util.Field()

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 3.3.x, they are quite li

Re: 3.2.9 release blocker? API breakage for mod_python.util.Field()

Jim Gallacher wrote: > 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

Re: mod_python 3.2.9-rc2 available for testing

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 for me 3.2.x r416548 seems t

Re: mod_python 3.2.9-rc2 available for testing

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

Re: 3.2.9-rc2 FieldStorage Problems (was Re: mod_python 3.2.9-rc2 available for testing)

Jim Gallacher wrote: > Max Bowsher wrote: >> The root of the problem is that Trac wants to be able to add extra >> fields to a FieldStorage itself, and has been jumping through all sorts >> of crazy hoops in the internals of FieldStorage to make this happen. > > W

Re: Trac and FieldStorage

Graham Dumpleton wrote: > The outcome of incompatibilities between Trac and changes made to > FieldStorage in mod_python 3.2.9 resulted in us reversing out the > changes. The thought I expressed at the time was that we keep what > would be incompatible code for mod_python 3.3 on the basis that n

Re: Need confirmation of memory leak using Apache 2.2.2.

Graham Dumpleton wrote: > Okay, found the source of the memory leak. The problem goes right back > to 3.1.4 which also has the problem when tested. ... > Now what do we do about 3.2.10? Given that this thing leaks really badly > when triggered shows that no one must be using multiple handler phases

Re: The mod_python wiki has materialized!

Graham Dumpleton wrote: > > On 13/09/2006, at 8:45 AM, Jim Gallacher wrote: > >> Woot Woot Woot! We have our wiki! >> >> http://wiki.apache.org/mod_python/ >> >> Now comes the hard part... what the heck are we going to do with it? :) > > Ahhh, more work. :-( > > Obviously the FAQ stuff can go o

Re: TLP Name

Gregory (Grisha) Trubetskoy wrote: > > > So far PyPache seems to be the winner. Terranium is second, Quetzalcoatl > thrid. > > Let's say this vote closes on Wednesday, and please send in +1's for one > name - statements like "I like both and " are hard to > account for. I'd like to vote for Qu