RE: [Zope] Error on starting and stopping Zope 2.8.2
From the Zope 2.8.2 announcement on this mailing list : Please also keep in mind that Zope 2.8.2 requires Python 2.3.5. Zope 2.8.2 is not certified for any Python 2.4.x versions. So using Python 2.4 is neither recommended nor supported and any related questions or problems are likely to be ignored until 2.4 is an officially supported Python version for Zope.
Pascal -----Original Message----- From: zope-bounces@zope.org [mailto:zope-bounces@zope.org] On Behalf Of Jens Vagelpohl Sent: 14 October 2005 17:12 To: Zope ML Subject: Re: [Zope] Error on starting and stopping Zope 2.8.2 On 14 Oct 2005, at 17:09, hpinson@indepthl.com wrote:
Hello. On starting and stopping Zope 2.8.2 (upgraded from 2.8.1, compiled with Python 2.4.2, running on Fedora Core 3) I get the following error. Performance does not seem to be affected. Resolution?
# service zopectl start /opt/python2.4.2/lib/python2.4/whrandom.py:38: DeprecationWarning: the whrandom module is deprecated; please use the random module DeprecationWarning) . daemon process started, pid=22829
# service zopectl stop /opt/python2.4.2/lib/python2.4/whrandom.py:38: DeprecationWarning: the whrandom module is deprecated; please use the random module DeprecationWarning) . daemon process stopped
If this was an error, it would say "error". This is a "warning". jens _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **********************************************************************
Pascal, Why does Zope lag the release of Python by so very long? The Python 2.4.X series includes language features and poerformance enhancements which ought to be available in Zope. For the most part, Python 2.3.5 is a subset of Python 2.4.X. Compatibility is a language and implementation design priority. Python 2.4 was released November 30, 2004, almost a year ago. Python 2.3.5 was released Feb 8, 2005 (after Python 2.4.0, released November 30, 2004, and shortly before Python 2.4.1 which was released March 30, 2005). Python 2.3 was released July 29, 2003. The current Python 2.4.2 was released just recently. My understanding is that the reason the Python 2.4.X is not the recommended Python is because a "security audit" has not been performed and not because of functionality issues. We have been using Python 2.4.1 in production without apparent problems; I am about to move to 2.4.2 which fixes some bugs we have not encountered. IMHO it would be wise to track the releases of Python a bit more closely. On Fri, 14 Oct 2005, Pascal Peregrina wrote:
From the Zope 2.8.2 announcement on this mailing list : Please also keep in mind that Zope 2.8.2 requires Python 2.3.5. Zope 2.8.2 is not certified for any Python 2.4.x versions. So using Python 2.4 is neither recommended nor supported and any related questions or problems are likely to be ignored until 2.4 is an officially supported Python version for Zope.
Pascal
--
On 16 Oct 2005, at 19:54, Dennis Allison wrote:
Why does Zope lag the release of Python by so very long?
Because someone has to spend considerable time to assess impacts on the Zope 2 security machinery. This has been mentioned on this and other Zope lists on various occasions.
My understanding is that the reason the Python 2.4.X is not the recommended Python is because a "security audit" has not been performed and not because of functionality issues. We have been using Python 2.4.1 in production without apparent problems; I am about to move to 2.4.2 which fixes some bugs we have not encountered.
The fact that it "seems to work" is a pretty weak argument. It's like driving with really old tires where the rubber is starting to crack. It could lead to sudden failure, even though the car seems to drive just fine today. jens
--On 16. Oktober 2005 11:54:18 -0700 Dennis Allison <allison@shasta.stanford.edu> wrote:
IMHO it would be wise to track the releases of Python a bit more closely.
Software components choosen for a framework have to be solid and approved. There is no reason to run after every new python version or whatever. Stability and performance is somewhat more important than hunting for new language features.. Some features of Python 2.4 are nice2have but we can perfectly live with Python 2.3.5. If you want Python 2.4, use it (at your own risk). As we already explained a bunch of times (sorry, this issue is bothering the more people ask about the same issue), a security audit has not happened yet. Why not? Because it takes time to do such an audit and the persons that can do such an audit likely had not time so far. So things are as they are and will change as they change. If you have the skills, resources and perhaps some money to fund the audit then raise your hand. Otherwise we have to wait until it will happen. -aj
Andreas, I understand both the importance of stability and the need for a security audit at some point. (I do wish we had the funds or I had the time to help move it forward, but I don't.) I also understand the need for a consistent framework for reporting and resolving bugs. It is reasonable to expect that all bugs be reported against the same framework to eliminate one significant possible variable. What does concern me is the way in which the recommendation to use (at the moment) Python 2.3.5 is explained. I may be willing to accept the risks of using a system which has not yet been audited in terms of security, but I want to know if there are any reported instabilities or incompatibilities which have been identified when, say, Python 2.4.X is used. I'd rather people say that the standard reference platform against which all bugs should be reported uses 2.3.5, and that use of other, later versions of Python is at your own risk. When using another Python that is known to cause problems, it would make sense to identify the problem so that users can make an informed decision. There are times when there are Python version related problems and these need to be identified and publicized. We certainly collect the incompatilities (if there are any) so they can be fixed as eventually the code base will move to later python systems. -d On Sun, 16 Oct 2005, Andreas Jung wrote:
--On 16. Oktober 2005 11:54:18 -0700 Dennis Allison <allison@shasta.stanford.edu> wrote:
IMHO it would be wise to track the releases of Python a bit more closely.
Software components choosen for a framework have to be solid and approved. There is no reason to run after every new python version or whatever. Stability and performance is somewhat more important than hunting for new language features.. Some features of Python 2.4 are nice2have but we can perfectly live with Python 2.3.5. If you want Python 2.4, use it (at your own risk).
As we already explained a bunch of times (sorry, this issue is bothering the more people ask about the same issue), a security audit has not happened yet. Why not? Because it takes time to do such an audit and the persons that can do such an audit likely had not time so far. So things are as they are and will change as they change. If you have the skills, resources and perhaps some money to fund the audit then raise your hand. Otherwise we have to wait until it will happen.
-aj
--
On Sun, 2005-10-16 at 12:29 -0700, Dennis Allison wrote:
What does concern me is the way in which the recommendation to use (at the moment) Python 2.3.5 is explained.
I may be willing to accept the risks of using a system which has not yet been audited in terms of security, but I want to know if there are any reported instabilities or incompatibilities which have been identified when, say, Python 2.4.X is used.
I'm sure there are, but a list of all such issues hasn't been created and likely won't be. I suspect that there just aren't a lot of folks who are willing to do the time-consuming labor of testing their application under both 2.3.5 and a later Python revision and reporting the issue in a structured way to make it easy for others to consume. To the extent that some people are willing to do this, the historical mechanism for reporting has been the Zope collector; these kinds of issues are thrown in to the bucket like any other kind of issue. A concentrated effort is usually organized every year or two to find and solve them. When this concentrated effort is undertaken, developers have time to go cull the collector for issues like this. This is also why it's only undertaken every year or so, because it's pretty labor-intensive and so usually requires some injection of cash (which has historically comes from Zope Corporation or one of their customers). Collector issues already have a metadata field that is supposed to be used as a field for reporting the Python version used. Unfortunately there is no user-visible searching mechanism in the collector to show only issues that have been reported against a particular Python version. - C
participants (5)
-
Andreas Jung -
Chris McDonough -
Dennis Allison -
Jens Vagelpohl -
Pascal Peregrina