I think we should aim for the second beta release in the next couple of
days. I have a few questions and a list of outstanding issues.

Name of tarball: mod_python-3.2.1b.tgz?
Also, I assume a new branch called tags/release-3.2.1-BETA will be
created in subversion, correct?

Outstanding issues:

1. flex
Fix is ready to commit pending some feedback on the warning message
generated by configure.

2. MacOS compile
Fixed in svn trunk.

3. Eliminate creation of mod_python_so.so in non-windows environments.
Fix is ready to commit.

4. Fix segfault + memory leaks detailed in:
http://issues.apache.org/jira/browse/MODPYTHON-75
http://issues.apache.org/jira/browse/MODPYTHON-60
Boyan's patch detailed in MODPYTHON-75 seems to fix both of these.
Fix is ready to commit.

5. http://issues.apache.org/jira/browse/MODPYTHON-72
Fix still required.

6. Publisher bug in 3.2 BETA, detailed by Graham in python-dev message
posted 2005-08-21.
Fix still required.

I haven't looked at the code involved in items 5 and 6, but hopefully
the fixes will be fairly trivial.

Regards,
Jim

[ Post a follow-up to this message ]

Nicolas Lehuen wrote:
> Hi Jim,
>
> The fix for MODPYTHON-72
> <http://issues.apache.org/jira/browse/MODPYTHON-72> should be easy,
> unfortunately I'm quite busy right now, since my first daughter was born
> three days ago...

Congratulations Nicolas!

I'll do my best to have a look at it, but if someone
> feels like doing it, I'll understand.

I have nothing planned for this weekend, so don't worry if you don't
have the time. I should be able to handle it.

Best Regards,
Jim

[ Post a follow-up to this message ]

On Thu, 25 Aug 2005, Jim Gallacher wrote:

> I think we should aim for the second beta release in the next couple of da
ys.
> I have a few questions and a list of outstanding issues.
>
> Name of tarball: mod_python-3.2.1b.tgz?

yep, 3.2.1b

> Also, I assume a new branch called tags/release-3.2.1-BETA will be created
 in
> subversion, correct?

yup

> Regards,
> Jim

Thanks Jim!

Grisha

[ Post a follow-up to this message ]

On Fri, 26 Aug 2005, Nicolas Lehuen wrote:

> unfortunately I'm quite busy right now, since my first daughter was born
> three days ago...

Wow! Congratulations!!!! Is this a first child? Does she have a name?

Anyway, scratch that word "unfortunately", you didn't mean it! :-)

Grisha

[ Post a follow-up to this message ]

It's my first child (but the second for my wife), and her name is Violette. 
And I totally crazy of her ! The problem for you guys is that I've been 
preparing my house for her coming back (she came a bit earlier than expected
 
so I had to hurry things a little bit), so I had no time to work on 
mod_python. I feel quite bad about this since it looks like some problem are
 
found about the publisher. I'll try to give it a shot in the next few days.

Regards,
Nicolas

2005/8/26, Gregory (Grisha) Trubetskoy <grisha@modpython.org>:
> 
> 
> On Fri, 26 Aug 2005, Nicolas Lehuen wrote:
>  
> 
> Wow! Congratulations!!!! Is this a first child? Does she have a name?
> 
> Anyway, scratch that word "unfortunately", you didn't mean it! :-)
> 
> Grisha
> 
> 
> 
>

[ Post a follow-up to this message ]

Hey Gang,

I think we are ready for the 3.2.1b release. If there are no objections
in the next 24 hours I'll create the package and make the announcement
on python-dev.

Jim Gallacher wrote:
> I think we should aim for the second beta release in the next couple of
> days. I have a few questions and a list of outstanding issues.
>
> Name of tarball: mod_python-3.2.1b.tgz?
> Also, I assume a new branch called tags/release-3.2.1-BETA will be
> created in subversion, correct?
>
> Outstanding issues:
>
> 1. flex
>    Fix is ready to commit pending some feedback on the warning message
> generated by configure.

Done

> 2. MacOS compile
>    Fixed in svn trunk.

Done

> 3. Eliminate creation of mod_python_so.so in non-windows environments.
>    Fix is ready to commit.

Not Done. I decided to defer this for reasons I won't go into just
now. It is not a show stopper anyway.

> 4. Fix segfault + memory leaks detailed in:
>   http://issues.apache.org/jira/browse/MODPYTHON-75
>   http://issues.apache.org/jira/browse/MODPYTHON-60
>   Boyan's patch detailed in MODPYTHON-75 seems to fix both of these. Fix
> is ready to commit.

Done. These can be marked as fixed in JIRA.

> 5. http://issues.apache.org/jira/browse/MODPYTHON-72
>    Fix still required.

Done

> 6. Publisher bug in 3.2 BETA, detailed by Graham in python-dev message
> posted 2005-08-21.
>    Fix still required.

Done (fix for item 5 fixed this as well).

Regards,
Jim

[ Post a follow-up to this message ]

On 01/09/2005, at 6:19 AM, Jim Gallacher wrote:

> Hey Gang,
>
> I think we are ready for the 3.2.1b release. If there are no
> objections in the next 24 hours I'll create the package and make
> the announcement on python-dev.

Sounds good.

I'll always be hoping to sneak in just one more change (eg.
MODPYTHON-73),
but realities are that I have to stop at some point. :-)

BTW, I will be traveling for a few weeks from this weekend and at times
will be disconnected from the Internet and at other times will only have
basic dial-up access, so you might not hear from me too much during
that period.

Maybe I'll use the time to dream about writing a book. ;-)

Graham

[ Post a follow-up to this message ]

On Wed, 31 Aug 2005, Jim Gallacher wrote:
 
>
>  Not Done. I decided to defer this for reasons I won't go into just now. I
t
> is not a show stopper anyway.

Isn't the fix basically just placing the ModPyModule and setup() with
ModPyModule inside the "if winbuild" block and then having another set()
without the ModPyModule in the else clause?

Unless there is some good reason for it, I think it is a show stopper
because it makes the build process look a bit on the bizzare side on Unix.

Grisha

[ Post a follow-up to this message ]

Or speaking in diff (not tested):

--- setup.py.in.orig    2005-09-01 11:42:09.082202944 -0400
+++ setup.py.in 2005-09-01 11:44:35.969872624 -0400
@@ -140,18 +140,24 @@
# this is a hack to prevent build_ext from trying to append "initmod_python"
 to the export symbols
self.export_symbols = finallist(self.export_symbols)

-ModPyModule = ModPyExtension(getmp_srcdir(), [getmp_includedir(), getap
ache_includedir()], [getapache_libdir()])

if winbuild:
+
+    # build mod_python.so
+    ModPyModule = ModPyExtension(getmp_srcdir(), [getmp_includedir(), g
etapache_includedir()], [getapache_libdir()])
+
scripts = ["win32_postinstall.py"]
# put the mod_python.so file in the Python root ...
# win32_postinstall.py will pick it up from there...
# data_files = [("", [(os.path.join(getmp_srcdir(), 'Release', 'mod_
python.so'))])]
data_files = []
+    ext_modules = [ModPyModule, PSPModule]
+
else:
-    # mpso = "../src/mod_python.so"
+
scripts = []
data_files = []
+    ext_modules = [PSPModule]

import string
from distutils import sysconfig
@@ -174,7 +180,7 @@
package_dir={'mod_python': os.path.join(getmp_rootdir(), 'lib', 'python
', 'mod_python')},
scripts=scripts,
data_files=data_files,
-      ext_modules=[ModPyModule, PSPModule])
+      ext_modules=ext_modules)

# makes emacs go into Python mode
### Local Variables:



On Thu, 1 Sep 2005, Gregory (Grisha) Trubetskoy wrote:

>
> On Wed, 31 Aug 2005, Jim Gallacher wrote:
> 
>
> Isn't the fix basically just placing the ModPyModule and setup() with
> ModPyModule inside the "if winbuild" block and then having another set()
> without the ModPyModule in the else clause?
>
> Unless there is some good reason for it, I think it is a show stopper beca
use
> it makes the build process look a bit on the bizzare side on Unix.
>
> Grisha
>

[ Post a follow-up to this message ]

I've tested this patch and checked it into svn. Should probably be
tested for winbuild and MacOS X.

I think we are good to go if Graham and Nicolas are happy with their
MODPYTHON-73 changes.

Jim

Gregory (Grisha) Trubetskoy wrote:
>
> Or speaking in diff (not tested):
>
> --- setup.py.in.orig    2005-09-01 11:42:09.082202944 -0400
> +++ setup.py.in 2005-09-01 11:44:35.969872624 -0400
> @@ -140,18 +140,24 @@
>          # this is a hack to prevent build_ext from trying to append
> "initmod_python" to the export symbols
>          self.export_symbols = finallist(self.export_symbols)
>
> -ModPyModule = ModPyExtension(getmp_srcdir(), [getmp_includedir(),
> getapache_includedir()], [getapache_libdir()])
>
>  if winbuild:
> +
> +    # build mod_python.so
> +    ModPyModule = ModPyExtension(getmp_srcdir(), [getmp_includedir(),
> getapache_includedir()], [getapache_libdir()])
> +
>      scripts = ["win32_postinstall.py"]
>      # put the mod_python.so file in the Python root ...
>      # win32_postinstall.py will pick it up from there...
>      # data_files = [("", [(os.path.join(getmp_srcdir(), 'Release'
,
> 'mod_python.so'))])]
>      data_files = []
> +    ext_modules = [ModPyModule, PSPModule]
> +
>  else:
> -    # mpso = "../src/mod_python.so"
> +
>      scripts = []
>      data_files = []
> +    ext_modules = [PSPModule]
>
>  import string
>  from distutils import sysconfig
> @@ -174,7 +180,7 @@
>        package_dir={'mod_python': os.path.join(getmp_rootdir(), 'lib'
,
> 'python', 'mod_python')},
>        scripts=scripts,
>        data_files=data_files,
> -      ext_modules=[ModPyModule, PSPModule])
> +      ext_modules=ext_modules)
>
>  # makes emacs go into Python mode
>  ### Local Variables:
>
>
>
> On Thu, 1 Sep 2005, Gregory (Grisha) Trubetskoy wrote:
> 
>

[ Post a follow-up to this message ]