Date: Wed, 2 Aug 2006 11:50:01 -0400 From: Isaac Levy <ike@lesmuug.org> To: beno <zope@2012.vi> Cc: freebsd-python@freebsd.org Subject: Re: Reinstalling Python with mod_python Problem Message-ID: <4D080271-1930-4346-A6E9-9BEC67F5CF32@lesmuug.org> In-Reply-To: <44D0C6AE.9050704@2012.vi> References: <44CFF018.3030706@2012.vi> <AED67FDE-02EA-471C-82EA-8359F22DF0A6@lesmuug.org> <44D0C6AE.9050704@2012.vi>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Beno, On Aug 2, 2006, at 11:37 AM, beno wrote: > Isaac Levy wrote: >> Suggestion: >> >> If this is all new to you, and debugging cross-incompatibilities >> is not what you want to be doing, I'd suggest you do: >> >> First, make sure your system is up to date, and for Zope, make >> certain you have up-to-date Zlib and Expat installed (easiest from >> ports). > Afraid to do this. The last guy built a *very* sophisticated > shopping cart that depends on an older version of Zope. Don't want > to break it until I'm sure I can fix it ;) Gotcha- then this is a case where you *want* to isolate python, and even Zlib and Expat, all in a directory with the Zope software. Just use '--prefix=/path/to/new_isolated/ZopeSw' with each of the builds, and you'll be in great shape. If you are proxying Zope with Apache (mod_rewrite or other such common Zope-ish convention), you can build an Apache in there too, just for zope... Keeping it all contained and separate from your mod_python setup. The somewhat nice part about this strategy is that you can rebuild these softwares, including Zope itself, and test it all before you take down the old Zope system! Your Zope instance will only need config file tweaks- and you can test it all on different network ports... >> >> Compile one python and let it all live in /usr/local (default when >> NOT specifying --prefix during the install), track down and see if >> any other Python installs exist on the machine. >> You shouldn't need to toss ANY flags at the Python build for that >> matter, it will work AOK with mod_python and Zope. > Well, I just went to compile python and got this in the make test: > > test test_asynchat produced unexpected output: > ********************************************************************** > *** mismatch between line 3 of expected output and line 3 of actual > output: > - Received: 'hello world' > + error: uncaptured python exception, closing channel > <test.test_asynchat.echo_client connected at 0x848e10c> > (socket.error:(61, 'Connection refused') [/usr/local/zope/py243/Lib/ > asynchat.py|handle_read|89] [/usr/local/zope/py243/Lib/asyncore.py| > recv|343]) > ********************************************************************** > What do I do about that? Well, just check to see that your predecessor didn't use asynchat in any of his/her code, and if not, ignore it and move on... Troubleshooting why this isn't working could prove time consuming, insomuch as for some reason the socket isn't working to make the asynchat server run? (i.e. this could be your network config, packet filtering, some barfing lib which asyncore is based on, etc...) If your not using it, and don't plan to, don't worry about it. > TIA, > beno > Rocket, .ike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D080271-1930-4346-A6E9-9BEC67F5CF32>