Apache Mod-Python - Getting ready for 3.2 beta 2

Author

Getting ready for 3.2 beta 2

Jim Gallacher

2005-08-26, 7:46 am

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

Jim Gallacher

2005-08-26, 7:46 am

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

Gregory (Grisha) Trubetskoy

2005-08-26, 5:46 pm

On Thu, 25 Aug 2005, 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?

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

Gregory (Grisha) Trubetskoy

2005-08-26, 5:46 pm

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

Nicolas Lehuen

2005-08-27, 5:46 pm

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
>
>
>
>

Jim Gallacher

2005-08-31, 5:52 pm

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

Graham Dumpleton

2005-08-31, 5:52 pm

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

Gregory (Grisha) Trubetskoy

2005-09-01, 5:50 pm

On Wed, 31 Aug 2005, Jim Gallacher wrote:

>
> Not Done. I decided to defer this for reasons I won't go into just now. It
> 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

Gregory (Grisha) Trubetskoy

2005-09-01, 5:50 pm

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:

>
> 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 because
> it makes the build process look a bit on the bizzare side on Unix.
>
> Grisha
>

Jim Gallacher

2005-09-01, 5:50 pm

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:
>
>

Nicolas Lehuen

2005-09-01, 5:50 pm

Well I for one am happy woth MODPYTHON-73, I've integrated Graham's patch
and made unit test to check if everything was OK. Graham should be happy too

.

Regards,
Nicolas

2005/9/1, Jim Gallacher <jg.lists@sympatico.ca>:
>
> 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:
> environments.
>
>

Graham Dumpleton

2005-09-01, 5:50 pm

Nicolas Lehuen wrote ..
> Well I for one am happy woth MODPYTHON-73, I've integrated Graham's patch
> and made unit test to check if everything was OK. Graham should be happy
> too
>

.

As troublesome as I am, even I am happy at this point. :-)

Unfortunately, probably will not be able to do any last build checks on
MacOSX. I think I'll get killed tonight if I start working on the
computer tonight since I fly off quite early tomorrow morning. If I am
lucky I'll get just enough time to sync from the svn repository and then
I'll play with it on the plane. I'll then be off the Internet for about
4-5 days so if there are any problems you will not hear about them in
time anyway.

Graham

Gregory (Grisha) Trubetskoy

2005-09-06, 5:51 pm

I've been away this weekend - just got back, but I'm too busy to try to
read all the multiple-interpreter related comments. I guess my question is
- can someone provide a quick summary of how far we are from 3.2.1b test
tarbal?

Thanks!

Grisha

On Thu, 1 Sep 2005, Graham Dumpleton wrote:

> Nicolas Lehuen wrote ..
>
> As troublesome as I am, even I am happy at this point. :-)
>
> Unfortunately, probably will not be able to do any last build checks on
> MacOSX. I think I'll get killed tonight if I start working on the
> computer tonight since I fly off quite early tomorrow morning. If I am
> lucky I'll get just enough time to sync from the svn repository and then
> I'll play with it on the plane. I'll then be off the Internet for about
> 4-5 days so if there are any problems you will not hear about them in
> time anyway.
>
> Graham
>

Nicolas Lehuen

2005-09-06, 5:51 pm

Well, if I've understood Jim's mail, apart from the new MODPYTHON-77, we're
all set.

Regards,
Nicolas

2005/9/6, Gregory (Grisha) Trubetskoy <grisha@apache.org>:
>
>
> I've been away this weekend - just got back, but I'm too busy to try to
> read all the multiple-interpreter related comments. I guess my question is
> - can someone provide a quick summary of how far we are from 3.2.1b test
> tarbal?
>
> Thanks!
>
> Grisha
>
> On Thu, 1 Sep 2005, Graham Dumpleton wrote:
>
> patch
> happy
>

Jim Gallacher

2005-09-06, 5:51 pm

Gregory (Grisha) Trubetskoy wrote:
>
> I've been away this weekend - just got back, but I'm too busy to try to
> read all the multiple-interpreter related comments. I guess my question
> is - can someone provide a quick summary of how far we are from 3.2.1b
> test tarbal?

I've also been away for the weekend. The patch for MODPYTHON-77 from
last Thursday was causing apache to segfault and I have not had a chance
to try the lastest changes from Boyan.

As Graham stated on the weekend, "the use of thread states can be very
tricky". I think we should proceed with the 3.2.1b without the fix. That
way we can take the time to make sure we understand the issues and fix
it in 3.3.

If that seems reasonable, I'll make the tarball today.

Jim

> Thanks!
>
> Grisha
>
> On Thu, 1 Sep 2005, Graham Dumpleton wrote:
>
>

Gregory (Grisha) Trubetskoy

2005-09-06, 5:51 pm

On Tue, 6 Sep 2005, Jim Gallacher wrote:

> As Graham stated on the weekend, "the use of thread states can be very
> tricky". I think we should proceed with the 3.2.1b without the fix. That way
> we can take the time to make sure we understand the issues and fix it in 3.3.
>
> If that seems reasonable, I'll make the tarball today.

+1

Grisha

Graham Dumpleton

2005-09-08, 5:47 pm

Jim Gallacher wrote ..
> Gregory (Grisha) Trubetskoy wrote:
> to
>
> I've also been away for the weekend. The patch for MODPYTHON-77 from
> last Thursday was causing apache to segfault and I have not had a chance
> to try the lastest changes from Boyan.
>
> As Graham stated on the weekend, "the use of thread states can be very
> tricky". I think we should proceed with the 3.2.1b without the fix. That
> way we can take the time to make sure we understand the issues and fix
> it in 3.3.

If we feel that 3.3 could be a while in coming, I'm tending to think that this
change to support use of extensions using the simplified GIL interface
should be incorporated into 3.2. This would depend though on how many
more beta snapshots we think we might go through.

Graham

Nicolas Lehuen

2005-09-08, 5:47 pm

Well, why not keep our plan of releasing 3.2 ASAP and save this
problem for a later 3.2.x as a bug fix ?

Making subsequent bug-fix releases should be fast and easy. We cannot
afford to repeat the long hiatus between 3.1.3 and 3.2, with a long
period of time without any official bug fix.

I agree that 3.3 may come later, but we definitely should be able to
release 3.2 bugfixes version as often as possible. This will save us
and our users a lot of time, allowing us to stop writing "yeah, we
know this bug, it's already fixed in SVN but you'll have to wait an
undefinite time for the fix to go public".

Releasing often may need a bit of work on the web site side, however.
I feel that updating the web site is the current bottleneck, since
only Grisha can do it. Could it be possible to make the web site
writable by the commiters ? Maybe have a "web" directory in
subversion, so that we can edit the site and make update on the web
server side when we want to release new content ?

Regards,
Nicolas

2005/9/8, Graham Dumpleton <grahamd@dscpl.com.au>:
> Jim Gallacher wrote ..
on[vbcol=seagreen]
b[vbcol=seagreen]
e[vbcol=seagreen]
t[vbcol=seagreen]
>=20
> If we feel that 3.3 could be a while in coming, I'm tending to think that=
this
> change to support use of extensions using the simplified GIL interface
> should be incorporated into 3.2. This would depend though on how many
> more beta snapshots we think we might go through.
>=20
> Graham
>

Gregory (Grisha) Trubetskoy

2005-09-08, 5:47 pm

On Thu, 8 Sep 2005, Nicolas Lehuen wrote:

> Releasing often may need a bit of work on the web site side, however.

with respect to modpython.org, no, not at all. with httpd.apache.org -
it's a little bit of work, but not more than 15 minutes.

> I feel that updating the web site is the current bottleneck, since
> only Grisha can do it. Could it be possible to make the web site
> writable by the commiters ?

the httpd.apache.org website _is_ writable by committers.

the plan is to move the modpython.org website to the apache infrastructure
eventually, it's just been low priority and it would entail some work (the
mailing list migration being the most complex task), but it will happen,
eventually.

grisha

Jim Gallacher

2005-09-08, 5:47 pm

Nicolas Lehuen wrote:
> Well, why not keep our plan of releasing 3.2 ASAP and save this
> problem for a later 3.2.x as a bug fix ?
> Making subsequent bug-fix releases should be fast and easy. We cannot
> afford to repeat the long hiatus between 3.1.3 and 3.2, with a long
> period of time without any official bug fix.
>
> I agree that 3.3 may come later, but we definitely should be able to
> release 3.2 bugfixes version as often as possible. This will save us
> and our users a lot of time, allowing us to stop writing "yeah, we
> know this bug, it's already fixed in SVN but you'll have to wait an
> undefinite time for the fix to go public".

+1

It's always tempting to make one last change, fix one more bug, but then
the release never happens. I think everyone has the will to move
mod_python forward, we just need a little more discipline. There are
lots of things we can do in 3.3, but I for one am not motivated to work
on these until 3.2 is out. Lets get this puppy out the door and then
have a discussion on plans and priorities for 3.3 with a view to
reducing the time between bug fixes and major releases.

Jim

> Releasing often may need a bit of work on the web site side, however.
> I feel that updating the web site is the current bottleneck, since
> only Grisha can do it. Could it be possible to make the web site
> writable by the commiters ? Maybe have a "web" directory in
> subversion, so that we can edit the site and make update on the web
> server side when we want to release new content ?
>
> Regards,
> Nicolas
>
> 2005/9/8, Graham Dumpleton <grahamd@dscpl.com.au>:
>
>
>

Jorey Bump

2005-09-08, 5:47 pm

Jim Gallacher wrote:
> Nicolas Lehuen wrote:
>
>
>
> +1
>
> It's always tempting to make one last change, fix one more bug, but then
> the release never happens. I think everyone has the will to move
> mod_python forward, we just need a little more discipline. There are
> lots of things we can do in 3.3, but I for one am not motivated to work
> on these until 3.2 is out. Lets get this puppy out the door and then
> have a discussion on plans and priorities for 3.3 with a view to
> reducing the time between bug fixes and major releases.

Would it help to adopt a naming convention where odd minor versions are
for development, and even minor versions are stable/bug-fix-only? This
would be a convenient time to adopt it. In some environments, this gives
developers a place to add new features (3.3.x) while the first stable
release (3.2.0) is getting bug squashed. As a user, it makes things a
lot clearer that a certain version is still in development when you lust
after a new feature it offers.

Just a thought...

Nicolas Lehuen

2005-09-08, 5:47 pm

2005/9/8, Jorey Bump <list@joreybump.com>:
> Jim Gallacher wrote:
n[vbcol=seagreen]
>=20
> Would it help to adopt a naming convention where odd minor versions are
> for development, and even minor versions are stable/bug-fix-only? This
> would be a convenient time to adopt it. In some environments, this gives
> developers a place to add new features (3.3.x) while the first stable
> release (3.2.0) is getting bug squashed. As a user, it makes things a
> lot clearer that a certain version is still in development when you lust
> after a new feature it offers.
>=20
> Just a thought...
>=20

Yeah, why not.

In any case, we should maintain a separate 3.2 branch with only bug
fixes while developing the 3.3 version on the trunk (and merge the
bugfixes from the 3.2 version into the 3.3 trunk, of course).

We haven't done this for the 3.1 and 3.2 version, so everybody will
need to upgrade to 3.2 even if they want a single bugfix. This is not
a really bad thing this time, but next time, if we start to "fool
around" and break some compatibility (think "new import system" here

, we should make sure we don't force our users to upgrade just to
get one bugfix.

Regards,
Nicolas

Jim Gallacher

2005-09-08, 8:45 pm

Nicolas Lehuen wrote:
> 2005/9/8, Jorey Bump <list@joreybump.com>:
>
>
>
> Yeah, why not.
>
> In any case, we should maintain a separate 3.2 branch with only bug
> fixes while developing the 3.3 version on the trunk (and merge the
> bugfixes from the 3.2 version into the 3.3 trunk, of course).
>
> We haven't done this for the 3.1 and 3.2 version, so everybody will
> need to upgrade to 3.2 even if they want a single bugfix. This is not
> a really bad thing this time, but next time, if we start to "fool
> around" and break some compatibility (think "new import system" here
>

, we should make sure we don't force our users to upgrade just to
> get one bugfix.
>

As Jorey points out, this is a good time to discuss this.

I'm not opposed to the even/odd numbering, but I'm not sure it's really
necessary. Does anyone really envisage making development snapshots
available as tarballs? I'm a big fan of subversion. If anyone wants to
play around with the development branch it's just as easy to grab a copy
of mod_python/trunk with svn as it is to download a tarball. If we are
not making development releases then we don't need to number them.

Beyond that, I agree we should have a 3.2 branch for bugfixes, and I
think we need it now. It's just too tempting to mess around with code in
mod_python/trunk which could screw up our close-to-golden 3.2 release.
I'd like to suggest "branches/release-3.2" as the name. (Note the lack
of a patch level in the name). Any further beta's and the final release
would be generated from this branch, with mod_python/tags reserved for
snapshots.

As far as some future version breaking compatibility, I favour a bigger
jump in the major number: 3.2 -> 4.0. This is server software after all,
and some people may prefer to maintain an older version for a longer
period, foregoing new features in favour of the tried and true.
Incrementing the major number makes it more obvious that an upgrade may
cause some problems. But I guess that discussion is sometime *way* in
the future.

Jim

Graham Dumpleton

2005-09-09, 2:46 am

On 09/09/2005, at 10:02 AM, Jim Gallacher wrote:
> As far as some future version breaking compatibility, I favour a
> bigger jump in the major number: 3.2 -> 4.0. This is server software
> after all, and some people may prefer to maintain an older version for
> a longer period, foregoing new features in favour of the tried and
> true. Incrementing the major number makes it more obvious that an
> upgrade may cause some problems. But I guess that discussion is
> sometime *way* in the future.

I also have been thinking that a jump to version 4.0 would be better
for what is being speculated on for the next release.

Graham

Gregory (Grisha) Trubetskoy

2005-09-09, 5:46 pm

Don't know about versions, but I'd _really_ like to see a FreeBSD +1 at
this point :-) Graham - don't you have FreeBSD access somewhere?

On the versioning discussion - I don't like 4.0, I think 3.3 should be the
next version after 3.2.x. As far as even/odd stable/unstable - the Linux
kernel folks have abandoned it because it didn't work for them. The
fallacy is that you cannot know ahead of time what is stable and what is
not.

My preference is to just follow versions incrementally, and making it
known which version is stable or not independently of the version number,
which is what the HTTPD folks have been doing.

Grisha

On Fri, 9 Sep 2005, Graham Dumpleton wrote:

>
> On 09/09/2005, at 10:02 AM, Jim Gallacher wrote:
>
> I also have been thinking that a jump to version 4.0 would be better
> for what is being speculated on for the next release.
>
> Graham
>

Jim Gallacher

2005-09-09, 5:46 pm

Gregory (Grisha) Trubetskoy wrote:
>
> Don't know about versions, but I'd _really_ like to see a FreeBSD +1 at
> this point :-) Graham - don't you have FreeBSD access somewhere?

If Graham can't help out maybe we could recruit a volunteer on the
mod_python list?

>
> On the versioning discussion - I don't like 4.0, I think 3.3 should be
> the next version after 3.2.x. As far as even/odd stable/unstable - the
> Linux kernel folks have abandoned it because it didn't work for them.
> The fallacy is that you cannot know ahead of time what is stable and
> what is not.
>
> My preference is to just follow versions incrementally, and making it
> known which version is stable or not independently of the version
> number, which is what the HTTPD folks have been doing.

I can't get worked up one way or another wrt to a version numbering
scheme, as long as we release *something*. ;)

Regards,
Jim

Gregory (Grisha) Trubetskoy

2005-09-09, 5:46 pm

Just tried compiling it on minotaur and I get the same error. minotaur is
FreeBSD 5.4, so it looks like we have a -1. I don't know how much time
I'll have this weekend, so I might or might not look into the cause of
this - but anyone else with access to a FreeBSD box, you're more than
welcome to dig in... :-)

Grisha

On Fri, 9 Sep 2005, Jim Gallacher wrote:

> Gregory (Grisha) Trubetskoy wrote:
>
> If Graham can't help out maybe we could recruit a volunteer on the mod_python
> list?
>
>
> I can't get worked up one way or another wrt to a version numbering scheme,
> as long as we release *something*. ;)
>
> Regards,
> Jim
>

Nicolas Lehuen

2005-09-09, 5:46 pm

I tried to build it under minotaur as well, but "./configure" only
finds a 1.3.33 version of Apache, so I can't go further. I can't help
much here since I'm not used to FreeBSD...

Regards,
Nicolas

2005/9/9, Gregory (Grisha) Trubetskoy <grisha@apache.org>:
>=20
> Just tried compiling it on minotaur and I get the same error. minotaur is
> FreeBSD 5.4, so it looks like we have a -1. I don't know how much time
> I'll have this weekend, so I might or might not look into the cause of
> this - but anyone else with access to a FreeBSD box, you're more than
> welcome to dig in... :-)
>=20
> Grisha
>=20
>=20
> On Fri, 9 Sep 2005, Jim Gallacher wrote:
>=20
t[vbcol=seagreen]
python[vbcol=seagreen]
the[vbcol=seagreen]
ux[vbcol=seagreen]
is[vbcol=seagreen]
er,[vbcol=seagreen]
eme,[vbcol=seagreen]
>

Nicolas Lehuen

2005-09-09, 5:46 pm

OK, with the help of Grisha, I could get the same error as Jim and
Graham on minotaur

. Looks like something is missing from APXS.
Unfortunately I'll stop there because I'm pretty much clueless about
FreeBSD.

Regards,
Nicolas

2005/9/9, Nicolas Lehuen <nicolas.lehuen@gmail.com>:
> I tried to build it under minotaur as well, but "./configure" only
> finds a 1.3.33 version of Apache, so I can't go further. I can't help
> much here since I'm not used to FreeBSD...
>=20
> Regards,
> Nicolas
>=20
> 2005/9/9, Gregory (Grisha) Trubetskoy <grisha@apache.org>:
is[vbcol=seagreen]
at[vbcol=seagreen]
d_python[vbcol=seagreen]
be the[vbcol=seagreen]
inux[vbcol=seagreen]
t is[vbcol=seagreen]
t[vbcol=seagreen]
mber,[vbcol=seagreen]
cheme,[vbcol=seagreen]
>

Jim Gallacher

2005-09-09, 8:45 pm

I thought I'd it a shot on minotaur as well.

Poking around a bit reveals that the default apache is indeed 1.3. It
looks like there might be a viable apache2 hiding in
/usr/local/apache2-install/www.apache.org/current.

eg ./configure
--with-apxs=/usr/local/apache2-install/www.apache.org/current/apxs

Unfortunately, I'm getting the same errors as Grisha reported starting with:
mod_python.c:34: error: syntax error before '*' token

Regards,
Jim

Nicolas Lehuen wrote:
> I tried to build it under minotaur as well, but "./configure" only
> finds a 1.3.33 version of Apache, so I can't go further. I can't help
> much here since I'm not used to FreeBSD...
>
> Regards,
> Nicolas
>
> 2005/9/9, Gregory (Grisha) Trubetskoy <grisha@apache.org>:
>
>

Nicolas Lehuen

2005-09-10, 7:45 am

I've tried to build 3.1.4 from the tarball on minotaur and of course
it works. Could it be possible that the recent changes in the
configure script cause the problem ?

Regards,

Nicolas

2005/9/10, Jim Gallacher <jg.lists@sympatico.ca>:
> I thought I'd it a shot on minotaur as well.
>=20
> Poking around a bit reveals that the default apache is indeed 1.3. It
> looks like there might be a viable apache2 hiding in
> /usr/local/apache2-install/www.apache.org/current.
>=20
> eg ./configure
> --with-apxs=3D/usr/local/apache2-install/www.apache.org/current/apxs
>=20
> Unfortunately, I'm getting the same errors as Grisha reported starting wi=
th:
> mod_python.c:34: error: syntax error before '*' token
>=20
> Regards,
> Jim
>=20
> Nicolas Lehuen wrote:
is[vbcol=seagreen]
at[vbcol=seagreen]
_python[vbcol=seagreen]
e the[vbcol=seagreen]
nux[vbcol=seagreen]
is[vbcol=seagreen]
ber,[vbcol=seagreen]
heme,[vbcol=seagreen]
>=20
>

Graham Dumpleton

2005-09-15, 2:46 am

On 10/09/2005, at 2:08 AM, Gregory (Grisha) Trubetskoy wrote:

>
> Don't know about versions, but I'd _really_ like to see a FreeBSD +1
> at this point :-) Graham - don't you have FreeBSD access somewhere?

Sorry, don't have access to FreeBSD anymore. Any comments I make about
FreeBSD are from experiences with battling with mod_python 2.7 under
Apache 1.3 on my old web hosting provider. Now that I am with the much
superior OpenHosting (which I am sure Grisha will agree), don't have
FreeBSD access.

Graham