title

Sighting goes here
", line 1>, (), [], {})
>>> compile_restricted_eval('range(1,4)')
(", line 1>, (), [], {'range': 1})
>>> compile_restricted_eval('[i for i in [1,2,3]]')

After the last statement, you'll get a HUGE traceback.

However, the last statement works just fine with Python 2.1.

I'm assigning this to Shane in the hopes that he will assign it to the appropriate person.

==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 13:36:52 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 13:36:56 2004
Subject: [ZCM] [ZC] 546/ 3 Reject "Form variable CONTENT_TYPE lost"
Message-ID: 

Issue #546 Update (Reject) "Form variable CONTENT_TYPE lost"
 Status Rejected, Zope/bug low
To followup, visit:
  http://collector.zope.org/Zope/546

==============================================================
= Reject - Entry #3 by Caseman on Apr 29, 2004 1:36 pm

 Status: Pending => Rejected

It is the current policy of the request processing code in Zope to ignore form variables that match CGI names. This will not be changed for Zope 2.
________________________________________
= Comment - Entry #2 by leper on Feb 14, 2003 3:20 am

This is ZPublisher's doing, it does the same thing for every key mentioned in the isCGI_NAME function (see the top of lib/python/ZPublisher/HTTPRequest.py).  I'm guessing it may be done in a misguided attempt to protect people from pulling a variable out of the form namespace which they thought would be coming from the environment.  Its been like this since version 1.1 of HTTPRequest.py though, I sort of doubt it will ever change, despite that it is clearly silly.
________________________________________
= Request - Entry #1 by peterb on Aug 28, 2002 9:38 am

The following DTML document illustrates the problem:


 
 

 &dtml.missing-CONTENT_TYPE;
 &dtml.missing-ref;

 
   CONTENT_TYPE: 
   
   ref:    
   

   
 

 

 


The form vars of the request object doesn't include the value of the submitted CONTENT_TYPE field, it is lost somewhere. OTOH the REQUEST object itself contains the content type of the submitted form which may be accessed using REQUEST.CONTENT_TYPE but this is not the value of the form variable.

Running the above will show how any entered 'ref' is displayed above and below (after submission) whereas the 'CONTENT_TYPE' form variable never is.
==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 13:41:15 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 13:41:17 2004
Subject: [ZCM] [ZC] 545/ 4 Resolve "Object id 'content_type' crashes folder
	view"
Message-ID: 

Issue #545 Update (Resolve) "Object id 'content_type' crashes folder view"
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/545

==============================================================
= Resolve - Entry #4 by Caseman on Apr 29, 2004 1:41 pm

 Status: Accepted => Resolved

Works for me on Zope 2.7
________________________________________
= Comment - Entry #3 by leper on Apr 27, 2004 5:17 pm

I'm unable to reproduce this at all.
________________________________________
= Accept - Entry #2 by mjablonski on Apr 26, 2004 3:36 am

 Status: Pending => Accepted

 Supporters added: mjablonski

Jamie Heilman wrote on zope-dev: 

"Accept, they are completely fixable.  I've probably already fixed those bugs in my fork, I'll hunt around and see if I can find the relevant files and post followups to the bugs."

Please note: This one is related to 

http://zope.org/Collectors/Zope/1217
________________________________________
= Request - Entry #1 by peterb on Aug 28, 2002 9:28 am

Create folder A, in A create an object with id 'content_type' and then try to list all items in A's parent. What you get is:

 Error Type: AttributeError
 Error Value: startswith

  File /opt/Appload/Zope-2.5.1-linux2-x86/lib/python/ZPublisher/Publish.py, line 150, in publish_module
  File /opt/Appload/Zope-2.5.1-linux2-x86/lib/python/ZPublisher/Publish.py, line 114, in publish
  File /opt/Appload/Zope-2.5.1-linux2-x86/lib/python/Zope/__init__.py, line 159, in zpublisher_exception_hook
    (Object: Peter)
  File /opt/Appload/Zope-2.5.1-linux2-x86/lib/python/ZPublisher/Publish.py, line 98, in publish
  File /opt/Appload/Zope-2.5.1-linux2-x86/lib/python/ZPublisher/mapply.py, line 88, in mapply
    (Object: manage_contents)
  File /opt/Appload/Zope-2.5.1-linux2-x86/lib/python/ZPublisher/Publish.py, line 39, in call_object
    (Object: manage_contents)
  File /opt/Appload/Zope-2.5.1-linux2-x86/lib/python/Shared/DC/Scripts/Bindings.py, line 252, in __call__
    (Object: manage_contents)
  File /opt/Appload/Zope-2.5.1-linux2-x86/lib/python/Shared/DC/Scripts/Bindings.py, line 283, in _bindAndExec
    (Object: manage_contents)
  File /opt/Appload/Zope-2.5.1-linux2-x86/lib/python/App/special_dtml.py, line 172, in _exec
    (Object: manage_contents)
  File /opt/Appload/Zope-2.5.1-linux2-x86/lib/python/DocumentTemplate/DT_In.py, line 695, in renderwob
    (Object: objectItems)
  File /opt/Appload/Zope-2.5.1-linux2-x86/lib/python/DocumentTemplate/DT_Let.py, line 76, in render
    (Object: explicit="_.getitem('sequence-item').aq_explicit")
  File /opt/Appload/Zope-2.5.1-linux2-x86/lib/python/DocumentTemplate/DT_Util.py, line 159, in eval
    (Object: _.hasattr(explicit, 'manage_FTPget')
                   or _.hasattr(explicit, 'read')
                   or _.getattr(explicit, 'content_type',
                   '').startswith('text/'))
    (Info: explicit)
  File , line 0, in ?



Probably because get_attr returns the 'content_type' object and not the content type attribute

==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 14:05:55 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 14:05:58 2004
Subject: [ZCM] [ZC] 1259/ 3 Unrestrict ""make uninstall" can delete system
	directories"
Message-ID: 

Issue #1259 Update (Unrestrict) ""make uninstall" can delete system directories"
 ** Security Related ** (Public)
 Status Pending, Zope/bug critical
To followup, visit:
  http://zope.org/Collectors/Zope/1259

==============================================================
= Unrestrict_pending - Entry #3 by tseaver on Apr 29, 2004 2:05 pm

Not a security hole.
________________________________________
= Comment - Entry #2 by ajung on Mar 23, 2004 6:56 am

The logical consequences are either to remove the uninstall target or to disallow the installation of Zope into
directories that already contain files.
________________________________________
= Request - Entry #1 by Anonymous User on Mar 16, 2004 6:29 am

The following commonly used sequence is able to destroy your system quite fast:

# ./configure --prefix=/usr
# make
# make uninstall

After "make uninstall" the makefile script starts deleting /usr, since it simply executes 

uninstall:
        ${RMRF} "${PREFIX}"

which results in "rm -rf /usr".
==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 15:03:23 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 15:03:26 2004
Subject: [ZCM] [ZC] 1300/ 2 Resolve "TreeTag no longer preserves state"
Message-ID: 

Issue #1300 Update (Resolve) "TreeTag no longer preserves state"
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/1300

==============================================================
= Resolve - Entry #2 by Caseman on Apr 29, 2004 3:03 pm

 Status: Pending => Resolved

Fixed on HEAD and 2.7 branch
________________________________________
= Request - Entry #1 by shh on Apr 25, 2004 9:02 am

The TreeTag does not properly encode/decode the tree state in recent versions of Zope. Since the introduction of the MiniUnpickler class (as part of the security audit, iirc) the tree state does not persist anymore.

The error is conveniently masked by an 'except IndexError:' around line 180 of TreeDisplay/TreeTag.py. Adding some logging at this point shows that NO tree-s cookie decodes without error.

To reproduce: in the ZMI in the left frame open a folder. Then open a second folder on the same level as the first. You will find the first folder is no longer expanded because the tree state could not be read from the cookie.

Known to work in Zope 2.6.2

==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 15:04:22 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 15:04:25 2004
Subject: [ZCM] [ZC] 1286/ 3 Comment "App.Management.Tabs.manage_workspace
	sucks! :-("
Message-ID: 

Issue #1286 Update (Comment) "App.Management.Tabs.manage_workspace sucks! :-("
 Status Pending, Zope/bug medium
To followup, visit:
  http://zope.org/Collectors/Zope/1286

==============================================================
= Comment - Entry #3 by tseaver on Apr 29, 2004 3:04 pm

> 1. manage_workspace is only protected by the Authenticated role, and that
>   is done directly, not even through a permission.

WONTFIX, this is *by design*.

> 2. self.filtered_manage_roles then limits the options of what can be
>   shown, which might end up being nothing. But, because the method is only
>   protected by 'Authenticated', no chance is given to specify other user
>   credentials (say, from a user folder higher up in the tree) which might
>   be able to see something.

NOTABUG.  *Nothing* in Zope behaves as you describe.  Once you are authenticated, your identity is fixed for the duration of the request.

> 3. There's a bare try/except which masks errors. From what I can see, it
>   should ONLY catch IndexError's. 

SHOULDFIX.  This part should be fixed by removing the 'try:...except:' altogether.  If the list returned by 'filtered_manage_options' is empty, then raise Unauthorized.

> 4. The "raise TypeError" could do with some explanation.

NOTABUG.  That check avoids a potential recursion loop.

> 5. The Unauthorized could raise a more helpful message "You are not
>   authorized to view an of this object's management itnerface"

Why expose more information?  Unauthorized says, "You tried to do something you aren't allowed;  please authenticate as someone else", which is all we want.
________________________________________
= Comment - Entry #2 by ajung on Apr 11, 2004 1:13 pm

Can you fix this?
________________________________________
= Request - Entry #1 by chrisw on Apr 2, 2004 5:08 am

1. manage_workspace is only protected by the Authenticated role, and that is done directly, not even through a permission.

2. self.filtered_manage_roles then limits the options of what can be shown, which might end up being nothing. But, because the method is only protected by 'Authenticated', no chance is given to specify other user credentials (say, from a user folder higher up in the tree) which might be able to see something.

3. There's a bare try/except which masks errors. From what I can see, it should ONLY catch IndexError's. 

4. The "raise TypeError" could do with some explanation.

5. The Unauthorized could raise a more helpful message "You are not authorized to view an of this object's management itnerface"
==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 15:39:00 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 15:39:03 2004
Subject: [ZCM] [ZC] 553/ 2 Resolve "sporadic Zope crashes"
Message-ID: 

Issue #553 Update (Resolve) "sporadic Zope crashes"
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/553

==============================================================
= Resolve - Entry #2 by Caseman on Apr 29, 2004 3:38 pm

 Status: Pending => Resolved

Much work has been done on BTrees since this report. If the problem still occurs, please reopen.
________________________________________
= Request - Entry #1 by Anonymous User on Aug 30, 2002 11:47 am

I'm doing stress tests of my Application from time to time to check for memory leaks and such. There it sometimes happens, that Zope crashes with an illegal memory access exception. Some debugging showed, that the problem is in BTrees/BucketTemplate.c in _bucket__p_resolveConflict:

>  _bucket__p_resolveConflict(PyObject *ob_type, PyObject *s[3])
>  {
>    PyObject *r=0, *a;
>    Bucket *b[3];
>    int i;
>
>    for (i=0; i < 3; i++)
>      {
>      ...
>      }
> here is where the exception occured, that should probably be a Py_XDECREF
>    Py_DECREF(r);

==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 15:49:12 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 15:49:15 2004
Subject: [ZCM] [ZC] 553/ 3 Resubmit "sporadic Zope crashes"
Message-ID: 

Issue #553 Update (Resubmit) "sporadic Zope crashes"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/553

==============================================================
= Resubmit - Entry #3 by tim_one on Apr 29, 2004 3:49 pm

 Status: Resolved => Pending

Reopened Wow!  Wish I had known about this one earlier.  This particular bug still exists, and Dieter Maurer rediscovered it this year (2004).  It can only happen when bucket conflict resolution is handed 3 empty buckets, which is darned hard to do.
________________________________________
= Resolve - Entry #2 by Caseman on Apr 29, 2004 3:38 pm

 Status: Pending => Resolved

Much work has been done on BTrees since this report. If the problem still occurs, please reopen.
________________________________________
= Request - Entry #1 by Anonymous User on Aug 30, 2002 11:47 am

I'm doing stress tests of my Application from time to time to check for memory leaks and such. There it sometimes happens, that Zope crashes with an illegal memory access exception. Some debugging showed, that the problem is in BTrees/BucketTemplate.c in _bucket__p_resolveConflict:

>  _bucket__p_resolveConflict(PyObject *ob_type, PyObject *s[3])
>  {
>    PyObject *r=0, *a;
>    Bucket *b[3];
>    int i;
>
>    for (i=0; i < 3; i++)
>      {
>      ...
>      }
> here is where the exception occured, that should probably be a Py_XDECREF
>    Py_DECREF(r);

==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 15:49:44 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 15:49:46 2004
Subject: [ZCM] [ZC] 553/ 4 Assign "sporadic Zope crashes"
Message-ID: 

Issue #553 Update (Assign) "sporadic Zope crashes"
 Status Accepted, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/553

==============================================================
= Assign - Entry #4 by tim_one on Apr 29, 2004 3:49 pm

 Status: Pending => Accepted

 Supporters added: tim_one

Assigned this one to me.
________________________________________
= Resubmit - Entry #3 by tim_one on Apr 29, 2004 3:49 pm

 Status: Resolved => Pending

Reopened Wow!  Wish I had known about this one earlier.  This particular bug still exists, and Dieter Maurer rediscovered it this year (2004).  It can only happen when bucket conflict resolution is handed 3 empty buckets, which is darned hard to do.
________________________________________
= Resolve - Entry #2 by Caseman on Apr 29, 2004 3:38 pm

 Status: Pending => Resolved

Much work has been done on BTrees since this report. If the problem still occurs, please reopen.
________________________________________
= Request - Entry #1 by Anonymous User on Aug 30, 2002 11:47 am

I'm doing stress tests of my Application from time to time to check for memory leaks and such. There it sometimes happens, that Zope crashes with an illegal memory access exception. Some debugging showed, that the problem is in BTrees/BucketTemplate.c in _bucket__p_resolveConflict:

>  _bucket__p_resolveConflict(PyObject *ob_type, PyObject *s[3])
>  {
>    PyObject *r=0, *a;
>    Bucket *b[3];
>    int i;
>
>    for (i=0; i < 3; i++)
>      {
>      ...
>      }
> here is where the exception occured, that should probably be a Py_XDECREF
>    Py_DECREF(r);

==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 16:02:45 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 16:02:47 2004
Subject: [ZCM] [ZC] 1298/ 3 Comment "Make ZSQLMethods useful in SiteErrorLog"
Message-ID: 

Issue #1298 Update (Comment) "Make ZSQLMethods useful in SiteErrorLog"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/1298

==============================================================
= Comment - Entry #3 by shh on Apr 29, 2004 4:02 pm

Applied the patch to HEAD and 2.7 branch. Please resolve.
________________________________________
= Comment - Entry #2 by ajung on Apr 17, 2004 11:35 am

Nice patch but it can not be applied to the 2.7 branch/HEAD (2nd hunk fails). Could you please correct the patch?

-aj
________________________________________
= Request - Entry #1 by anthony on Apr 16, 2004 2:35 am


Uploaded:  "zsql.patch"
 - http://collector.zope.org/Zope/1298/zsql.patch/view
Right now, ZSQLMethods are uselessly rendered in the SiteErrorLog. The following patch fixes 
this.

==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 16:09:39 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 16:09:41 2004
Subject: [ZCM] [ZC] 1231/ 2 Comment "ZODB ExportImport.exportFile: Error
	logging fails"
Message-ID: 

Issue #1231 Update (Comment) "ZODB ExportImport.exportFile: Error logging fails"
 Status Pending, Database/bug+solution medium
To followup, visit:
  http://zope.org/Collectors/Zope/1231

==============================================================
= Comment - Entry #2 by dunny on Apr 29, 2004 4:09 pm

Fixed in CVS on both HEAD and Zope-2_7-branch.
________________________________________
= Request - Entry #1 by Anonymous User on Feb 15, 2004 5:58 am

Line 51 references sys.exc_info() but sys is not imported.

Also zLOG.LOG does not expect "err=sys.exc_info()" but "error=sys.exc_info()"
==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 16:46:26 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 16:46:30 2004
Subject: [ZCM] [ZC] 1298/ 4 Resolve "Make ZSQLMethods useful in SiteErrorLog"
Message-ID: 

Issue #1298 Update (Resolve) "Make ZSQLMethods useful in SiteErrorLog"
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/1298

==============================================================
= Resolve - Entry #4 by Caseman on Apr 29, 2004 4:46 pm

 Status: Pending => Resolved


________________________________________
= Comment - Entry #3 by shh on Apr 29, 2004 4:02 pm

Applied the patch to HEAD and 2.7 branch. Please resolve.
________________________________________
= Comment - Entry #2 by ajung on Apr 17, 2004 11:35 am

Nice patch but it can not be applied to the 2.7 branch/HEAD (2nd hunk fails). Could you please correct the patch?

-aj
________________________________________
= Request - Entry #1 by anthony on Apr 16, 2004 2:35 am


Uploaded:  "zsql.patch"
 - http://collector.zope.org/Zope/1298/zsql.patch/view
Right now, ZSQLMethods are uselessly rendered in the SiteErrorLog. The following patch fixes 
this.

==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 16:47:36 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 16:47:41 2004
Subject: [ZCM] [ZC] 1231/ 3 Resolve "ZODB ExportImport.exportFile: Error
	logging fails"
Message-ID: 

Issue #1231 Update (Resolve) "ZODB ExportImport.exportFile: Error logging fails"
 Status Resolved, Database/bug+solution medium
To followup, visit:
  http://zope.org/Collectors/Zope/1231

==============================================================
= Resolve - Entry #3 by Caseman on Apr 29, 2004 4:47 pm

 Status: Pending => Resolved


________________________________________
= Comment - Entry #2 by dunny on Apr 29, 2004 4:09 pm

Fixed in CVS on both HEAD and Zope-2_7-branch.
________________________________________
= Request - Entry #1 by Anonymous User on Feb 15, 2004 5:58 am

Line 51 references sys.exc_info() but sys is not imported.

Also zLOG.LOG does not expect "err=sys.exc_info()" but "error=sys.exc_info()"
==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 17:09:13 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 17:09:18 2004
Subject: [ZCM] [ZC] 1305/ 1 Request "data in mounted databases cant be
	accessed on HEAD"
Message-ID: 

Issue #1305 Update (Request) "data in mounted databases cant be accessed on HEAD"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/1305

==============================================================
= Request - Entry #1 by mcdonc on Apr 29, 2004 5:09 pm

>From an email exchange on Zope-Dev...

> > This breaks any mounted databases (which breaks dbtab, which breaks
> > sessions, which breaks lots of other things).  Hopefully this is
> > simple to fix, I haven't looked yet.
> 
> I expect Shane will look at this in a week or two (when he settles down from
> moving) -- but can't know that.  There was some horrid patching going on in
> ZODBMountPoint.py, which reached into various ZODB internals and replaced
> them.  Jeremy refactored that, to make MountConnection a subclass of
> Connection, and MountConnection._getMountedConnection() is still there.

Right.  FWIW, the binding to DB.klass to allow the DB to use the
MountConnection happens too late as it stands.  But that doesn't matter
too much for reasons below.

> There's still horrid patching going on, in that ZODBMountPoint.py reaches
> into ZODB.DB.DB and forces it to create MountConnection connections instead
> of Connection connections.  Perhaps this isn't being done "soon enough" in
> whatever exactly it is you were trying.

Yes, I fixed this by making the binding happen earlier (during
startup).  Once I do that, Zope in its default configuration indeed
starts and appears to work.  But any time an attempt is made to access
or store an object in a mounted database (the default Zope sessioning
configuration makes use of a mounted database), it falls over.  The same
code works ok against objects in the main database.  You can probably
replicate the problem by using the Zope "Shopping Cart" example code
(accessible by viewing the Zope default home page without '/manage') 
For anyone who cares, here's a traceback demonstrating one variation of
the symptom:

2004-04-25T22:38:57 ERROR SiteError http://www.plope.com/logged_in
Traceback (most recent call last):
  File "/home/chrism/software/Trunk/lib/python/ZPublisher/Publish.py",
line 111, in publish
    request, bind=1)
  File "/home/chrism/software/Trunk/lib/python/ZPublisher/mapply.py",
line 88, in mapply
    if debug is not None: return debug(object,args,context)
  File "/home/chrism/software/Trunk/lib/python/ZPublisher/Publish.py",
line 40, in call_object
    result=apply(object,args) # Type s to step into published
object.
  File
"/home/chrism/var/zopemafia.org/Products/CMFCore/FSPythonScript.py",
line 107, in __call__
    return Script.__call__(self, *args, **kw)
  File
"/home/chrism/software/Trunk/lib/python/Shared/DC/Scripts/Bindings.py",
line 306, in __call__
    return self._bindAndExec(args, kw, None)
  File
"/home/chrism/software/Trunk/lib/python/Shared/DC/Scripts/Bindings.py",
line 343, in _bindAndExec
    return self._exec(bound_data, args, kw)
  File
"/home/chrism/var/zopemafia.org/Products/CMFCore/FSPythonScript.py",
line 162, in _exec
    result = f(*args, **kw)
  File "Script (Python)", line 22, in logged_in
  File
"/home/chrism/software/Trunk/lib/python/ZPublisher/HTTPRequest.py", line
1214, in __getattr__
    v = self.get(key, default, returnTaints=returnTaints)
  File
"/home/chrism/software/Trunk/lib/python/ZPublisher/HTTPRequest.py", line
1174, in get
    if callable(v): v = v()
  File
"/home/chrism/software/Trunk/lib/python/Products/Sessions/SessionDataManager.py", line 93, in getSessionData
    return self._getSessionDataObject(key)
  File
"/home/chrism/software/Trunk/lib/python/Products/Sessions/SessionDataManager.py", line 180, in _getSessionDataObject
    ob = container.new_or_existing(key)
  File
"/home/chrism/software/Trunk/lib/python/Products/Transience/Transience.py", line 176, in new_or_existing
    item  = self.get(key, notfound)
  File
"/home/chrism/software/Trunk/lib/python/Products/Transience/Transience.py", line 817, in get
    b = index.get(k, notfound)
  File "/home/chrism/software/Trunk/lib/python/ZODB/Connection.py", line
795, in setstate
    self._setstate(obj)
  File "/home/chrism/software/Trunk/lib/python/ZODB/Connection.py", line
849, in _setstate
    self._reader.setGhostState(obj, p)
  File "/home/chrism/software/Trunk/lib/python/ZODB/serialize.py", line
401, in setGhostState
    obj.__setstate__(state)
SystemError: new style getargs format but argument is not a tuple



==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 17:12:10 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 17:12:13 2004
Subject: [ZCM] [ZC] 532/ 2 Resolve "Python language warnings give I/O Errors"
Message-ID: 

Issue #532 Update (Resolve) "Python language warnings give I/O Errors"
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/532

==============================================================
= Resolve - Entry #2 by mcdonc on Apr 29, 2004 5:12 pm

 Status: Pending => Resolved

Oh my god is this old.  This is fixed now that we've made a more or less proper daemonizing system for Zope 2.7.
________________________________________
= Request - Entry #1 by ctheune on Aug 22, 2002 1:22 pm

I used a lambda function in a product, that triggered
the warning for the nested_scopes feature. Actually
zope was running as a daemon and therefore decoupled from the console.
It gave this error message during the import:

Traceback (innermost last):
  File /usr/lib/zope/lib/python/App/RefreshFuncs.py, line 183, in performSafeRef
resh
  File /usr/lib/zope/lib/python/App/RefreshFuncs.py, line 170, in performRefresh
  File /usr/lib/zope/lib/python/OFS/Application.py, line 758, in reimport_produc
t
  File /usr/lib/zope/lib/python/OFS/Application.py, line 531, in import_product
  File /usr/lib/zope/lib/python/Products/MetaIndex/__init__.py, line 18, in ?
  File /usr/lib/python2.1/warnings.py, line 92, in warn_explicit
  File /usr/lib/python2.1/warnings.py, line 98, in showwarning
IOError: [Errno 5] Input/output error


This shouldn't happen, as this is only a warning. Maybe you should try to catch this somehow and provide it with the zLOG facilities.


Cheers
Christian
==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 17:14:39 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 17:14:41 2004
Subject: [ZCM] [ZC] 562/ 2 Resolve "pDocumentTemplate is broken"
Message-ID: 

Issue #562 Update (Resolve) "pDocumentTemplate is broken"
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/562

==============================================================
= Resolve - Entry #2 by Caseman on Apr 29, 2004 5:14 pm

 Status: Pending => Resolved

pDocumentTemplate is no longer used for 2.7 or HEAD
________________________________________
= Request - Entry #1 by efge on Sep 9, 2002 7:20 pm

pDocumentTemplate doesn't work.

To reproduce, take a brand new Zope install, and make
it not use cDocumentTemplate, by doing for instance:

mv lib/python/DocumentTemplate/cDocumentTemplate.so \
lib/python/DocumentTemplate/cDocumentTemplate.so.removed

Then start Zope and go to http://localhost:8080/manage

On 2.5.1 for instance you get:

  File /home/fg/tmp/zope/251/lib/python/ZPublisher/Publish.py, line 150, in publish_module
  File /home/fg/tmp/zope/251/lib/python/ZPublisher/Publish.py, line 114, in publish
  File /home/fg/tmp/zope/251/lib/python/Zope/__init__.py, line 159, in zpublisher_exception_hook
    (Object: Zope)
  File /home/fg/tmp/zope/251/lib/python/ZPublisher/Publish.py, line 98, in publish
  File /home/fg/tmp/zope/251/lib/python/ZPublisher/mapply.py, line 88, in mapply
    (Object: manage_main)
  File /home/fg/tmp/zope/251/lib/python/ZPublisher/Publish.py, line 39, in call_object
    (Object: manage_main)
  File /home/fg/tmp/zope/251/lib/python/Shared/DC/Scripts/Bindings.py, line 252, in __call__
    (Object: manage_main)
  File /home/fg/tmp/zope/251/lib/python/Shared/DC/Scripts/Bindings.py, line 283, in _bindAndExec
    (Object: manage_main)
  File /home/fg/tmp/zope/251/lib/python/App/special_dtml.py, line 172, in _exec
    (Object: manage_main)
  File /home/fg/tmp/zope/251/lib/python/DocumentTemplate/pDocumentTemplate.py, line 209, in render_blocks
TypeError: object of type 'None' is not callable


But on occasions I also got "object of type 'list' is not callable".

==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 17:15:41 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 17:16:12 2004
Subject: [ZCM] [ZC] 1306/ 1 Request "Missing acqisition context on local
	roles screen "
Message-ID: 

Issue #1306 Update (Request) "Missing acqisition context on local roles screen "
 Status Pending, Zope/bug+solution medium
To followup, visit:
  http://collector.zope.org/Zope/1306

==============================================================
= Request - Entry #1 by shh on Apr 29, 2004 5:15 pm

RoleManager.get_valid_userids() calls user_names() on an unwrapped user folder. This make the local role screens unusable for e.g. database user folders that need to acquire their DB connector.

The following patch wraps user_names() before calling it. If there are no security implications I failed to spot, I'd like to check this is in.

 --- Role.py     Thu Jul 24 18:08:43 2003
 +++ Role.py     Thu Jul 24 18:08:49 2003
 @@ -314,11 +314,12 @@
                  if mlu < 0: raise OverflowError
                  un = getattr(aclu, 'user_names', _notfound)
                  if un is not _notfound:
 +                    un = aclu.__of__(item).user_names   # rewrap
                      unl = un()
                      # maxlistusers of 0 is list all
                      if len(unl) > mlu and mlu != 0:
                          raise OverflowError
 -                    for name in un():
 +                    for name in unl:
                          dict[name]=1
              item = getattr(item, 'aq_parent', _notfound)
              if item is _notfound:


==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 17:17:02 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 17:17:07 2004
Subject: [ZCM] [ZC] 1199/ 2 Comment "FileUpload not iterable"
Message-ID: 

Issue #1199 Update (Comment) "FileUpload not iterable"
 Status Pending, Zope/bug+solution medium
To followup, visit:
  http://zope.org/Collectors/Zope/1199

==============================================================
= Comment - Entry #2 by LRA on Apr 29, 2004 5:16 pm


Uploaded:  "bug-1199.diff"
 - http://zope.org/Collectors/Zope/1199/bug-1199.diff/view
here's a patch based on discussions at 2004-04-29 bugday

________________________________________
= Request - Entry #1 by LRA on Jan 20, 2004 11:57 pm

ZPublisher.HTTPRequest.FileUpload class does not implement the iterable interface regular files do, so it can't be used in places where a file object is assumed to be an iterable, like csv.reader(), for instance.

I think fixing this is as easy as implementing an __iter__ method that returns 'self' and a .next() method as an alias for .readline() in the FileUpload class
==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 17:17:48 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 17:17:52 2004
Subject: [ZCM] [ZC] 602/ 2 Resolve "XMLRPC does not allow HTTP Basic
	Authorization"
Message-ID: 

Issue #602 Update (Resolve) "XMLRPC does not allow HTTP Basic Authorization"
 Status Resolved, Zope/feature+solution medium
To followup, visit:
  http://collector.zope.org/Zope/602

==============================================================
= Resolve - Entry #2 by mcdonc on Apr 29, 2004 5:17 pm

 Status: Pending => Resolved

The newest xmlrpclib that ships with Python 2.3.3 (and probably before) supports basic auth.  Zope as of 2.7 no longer ships with its own version of xmlrpclib, so closing.
________________________________________
= Request - Entry #1 by dbasch on Oct 3, 2002 2:42 pm


Uploaded:  "xmlrpclib.py"
 - http://collector.zope.org/Zope/602/xmlrpclib.py/view
Zope/lib/python/xmlrpclib does not provide a Transport for basic http authentication. I used Amos BasicAuthTransport patch and modified it to be compatible with the latest xmlrpclib.py revision(Revision 1.10.6.1) and the latest xmlrpc.py revision(Revision 1.12.4.1) It should now return
"ProtocolError: "
 
in the event of a authentication failure.
==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 17:19:07 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 17:19:11 2004
Subject: [ZCM] [ZC] 875/10 Resolve "FileStorage packing bug: backpointer not
	resolved"
Message-ID: 

Issue #875 Update (Resolve) "FileStorage packing bug: backpointer not resolved"
 Status Resolved, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/875

==============================================================
= Resolve - Entry #10 by mcdonc on Apr 29, 2004 5:19 pm

 Status: Pending => Resolved

Manual testing during bug day on 4/29/2004 by Paul Winkler could not reproduce on HEAD or in 2.7 branch.  Closing.
________________________________________
= Comment - Entry #9 by ajung on Sep 29, 2003 8:42 am

is this bug still there?
________________________________________
= Comment - Entry #8 by jeremy on May 13, 2003 11:19 am

In a variety of small examples involving undo and pack, I can't reproduce this problem.  I know there are bugs involving 2.6.1 pack, but the description in the previous message doesn't contain enough information to see which bug is causing the problem.

________________________________________
= Comment - Entry #7 by mjablonski on May 12, 2003 2:19 am

rbreathe@brookes.ac.uk posted this description on zope@zope.org. I think it may be useful to track down the problem.

-------------------------------------------------

I believe we have found a bug in the 2.6.1 release (possibly more specifically in ZODB 3.1.1).

-----------
# Summary:
-----------

When an undo is the last transaction preceeding a "pack(days:float=0)", the FileStorage is corrupted.

------------
# To repeat:
------------

Start with a 'consistent' FileStorage, e.g. Data.fs that passes fstest.py without error:

    1368329: transaction tid 0x034cd1c220785077 #32
    1368792: transaction tid 0x034cd1dbeb647922 #33
    no errors detected

Change an object (e.g. its contents, rename or delete it.  whatever).
Immediately undo that change ("oops").
Pack the Database (days:float=0).
Your FileStorage should be corrupt:

    1368329: transaction tid 0x034cd1c220785077 #32
    1368792: transaction tid 0x034cd1e0caa0286e #33
    1369330 object serialno 0x034cd1e0caa0286e does not matchtransaction id 0x034cd1e11516ba55

Now try changing an object (perhaps the same one again).
In the event.log, you should have something like the following:

2003-05-09T17:18:56 INFO(0) ZODB conflict error at /VirtualHostBase/https/twww.brookes.ac.uk:8443/VirtualHostRoot/Brookes/www/manage_delObjects (1 conflicts since startup at 2003-05-09T17:16:34)
------
2003-05-09T17:18:57 INFO(0) ZODB conflict error at /VirtualHostBase/https/twww.brookes.ac.uk:8443/VirtualHostRoot/Brookes/www/manage_delObjects (2 conflicts since startup at 2003-05-09T17:16:34)
------
2003-05-09T17:18:58 INFO(0) ZODB conflict error at /VirtualHostBase/https/twww.brookes.ac.uk:8443/VirtualHostRoot/Brookes/www/manage_delObjects (3 conflicts since startup at 2003-05-09T17:16:34)
------
2003-05-09T17:19:01 INFO(0) ZODB conflict error at /VirtualHostBase/https/twww.brookes.ac.uk:8443/VirtualHostRoot/Brookes/www/manage_delObjects (4 conflicts since startup at 2003-05-09T17:16:34)

Without ZEO (2.0.1b1) this is only repeated once, and the operation seemingly succeeds (on top of the corrupted FileStorage), but with ZEO all transactions involving a write to the FileStorage fail, throwing the following error:

ZODB.POSException.ConflictError
Traceback (innermost last):
    * Module ZPublisher.Publish, line 150, in publish_module
    * Module ZPublisher.Publish, line 127, in publish
    * Module ZPublisher.Publish, line 127, in publish
    * Module ZPublisher.Publish, line 127, in publish
    * Module ZPublisher.Publish, line 122, in publish
    * Module Zope.App.startup, line 142, in zpublisher_exception_hook
    * Module ZPublisher.Publish, line 102, in publish
    * Module Zope.App.startup, line 200, in commit
    * Module ZODB.Transaction, line 246, in commit
    * Module ZODB.Connection, line 680, in tpc_vote
    * Module ZEO.ClientStorage, line 722, in tpc_vote
    * Module ZEO.ClientStorage, line 706, in _check_serials
ConflictError: database conflict error (oid 0000000000000af6, serial was 034cd1e0caa0286e, now 034cd1e11516ba55)

The site is useless until both ZEO and the Client Instance have been restarted, at which point it is possible to change the errant object, and pack again (assuming no undo), which then fixes the consistency.
However restarting your site whenever someone chooses to undo an operation just before your automated pack.

-------------
# Workaround:
-------------

Don't let an undo be the last transaction preceeding a pack (easier said than cleanly done with automation).

--------
# Notes:
--------

Machine:
SunOS lr1 5.9 Generic_112233-04 sun4u sparc SUNW,Ultra-Enterprise

Zope:
Primarily we tried the binary Solaris release of 2.6.1 and ZEO 2.0.1b1:

    Zope Version: (Zope 2.6.1 (binary release, python 2.1, solaris-2.8-sparc), python 2.1.3, sunos5)
    Python Version: 2.1.3 (#4, Sep 16 2002, 15:52:14) [GCC 2.95.3 20010315 (release)]
    System Platform: sunos5
    SOFTWARE_HOME: /app/zope/zope_2.6.1/lib/python
    ZOPE_HOME: /app/zope/zope_2.6.1
    INSTANCE_HOME: /data/zope/zope_2.6.1/test/client
    CLIENT_HOME: /data/zope/zope_2.6.1/test/client/var

We have also tried our own homegrown from CVS (Zope-2_6-branch) as of 2003/05/09 15:20, along with our own Python 2.1.3 and a snapshot of /ZEO from CVS (HEAD) (in various combinations):

    Zope Version: (unreleased version, python 2.1.3, sunos5)
    Python Version: 2.1.3 (#1, Mar 26 2003, 16:28:24) [GCC 3.2.2]
    System Platform: sunos5
    SOFTWARE_HOME: /app/zope/zope_2.6.1-cvs/lib/python
    ZOPE_HOME: /app/zope/zope_2.6.1-cvs
    INSTANCE_HOME: /data/zope/zope_2.6.1-cvs/test/client
    CLIENT_HOME: /data/zope/zope_2.6.1-cvs/test/client/var

Further we found that the fsrecover.py script packaged with 2.6.1 release is useless.  It always removes EVERYTHING from the Data.fs bar the magic number.  This was our primary incentive for trying Zope-2_6-branch since it includes jeremy's recently improved ZODB management scripts.  Note however that jeremy's recent fstest.py does not throw an error on inconsistencies of the type mentioned above (despite the fact they still seem to cause problems?).

Anything else I can say?  Rather a longwinded message for such an easily repeatable bug, but nevermind.
Obviously we'd be happy to help find a solution, be that by providing corrupt Data.fs, extra details, testing patches, etc.


________________________________________
= Comment - Entry #6 by mjablonski on May 6, 2003 3:12 pm

I've had another data lost after packing on 05/05/2003. I've packed the database on 05/04/2003, a day after a DTML-Document was gone without anyone has deleted it (no entry in undo-log etc.)

My config:
 - ZEO-2.0.1b1
 - Zope 2.6.x from CVS (recently updated)
 - Python 2.1.3

As workaround I turned of ZEO to check if the problem arises from the communication between backend and frontend-server. We will see...
________________________________________
= Comment - Entry #5 by jeremy on Apr 29, 2003 4:33 pm

A question about the patch.  It looks like the change means that back pointers are always resolved during pack.  Is that right?  If so, it means that when we're done there are no backpointers in the storage; every backpointer has been replaced by a copy of the actual data.

We need backpointers to get undo semantics right.  They also save space.

________________________________________
= Comment - Entry #4 by d.maurer on Apr 10, 2003 7:48 am


Uploaded:  "UndoPack.pat"
 - http://collector.zope.org/Zope/875/UndoPack.pat/view
Patch attached
________________________________________
= Comment - Entry #3 by d.maurer on Apr 10, 2003 5:11 am


Uploaded:  "testFileStorageUndoPack.py"
 - http://collector.zope.org/Zope/875/testFileStorageUndoPack.py/view
Unittests attached reproducing the bug.
The tests assumes to be located in "ZODB/tests".

The error occurs when an "Undo" record is copied
during pack's copy phase (rather than the packing phase).
________________________________________
= Comment - Entry #2 by mjablonski on Apr 9, 2003 8:55 am

I've had the same "object-were-mystical-gone-after-packing"-problem two times a few weeks ago with 2.6.1. I thought it was a ZEO-Syncing-Issue, but it seems that it is problem of the ZODB-packing.
________________________________________
= Request - Entry #1 by d.maurer on Apr 9, 2003 8:06 am

ATTENTION: data loss!

We lost an object (say "O") during packing.

Events: "delete O", "undo 'delete O'", pack
After the "pack", "O" is no longer accessible, it is lost.

Analysis of the FileStorage for "O"s parent record:
Before packing
                pos             serial                  prev                            plen
undo            634808031L     '\x03K\xa5\xe4\xcaLYw'   '\x00\x00\x00\x00%L\xeb\xa2'    0    
delete          625798050L     "\x03K\xa5\xc7\xb0';f"   '\x00\x00\x00\x00\x01F\xcd)'    168      
backpointer     21417257L      '\x03G\xd3)\x98\xc9\x043' 0                              254

After packing
                pos             serial                  prev                            plen
undo            437746018L      '\x03K\xa5\xe4\xcaLYw'  '\x00\x00\x00\x00\x19\x8d\xfe%' 0    
delete          428736037L
backpointer     428736037L      "\x03K\xa5\xc7\xb0';f"  '\x00\x00\x00\x00\x01<)\xdd'    168

As we see, the backpointer was not resolved
during packing and after packing, it points
to the "deleted" state.

I will try to reproduce this error in
a small test case and report back.

==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 17:26:39 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 17:26:41 2004
Subject: [ZCM] [ZC] 584/ 2 Reject "Auto-refresh External Methods"
Message-ID: 

Issue #584 Update (Reject) "Auto-refresh External Methods"
 Status Rejected, Zope/feature+solution medium
To followup, visit:
  http://collector.zope.org/Zope/584

==============================================================
= Reject - Entry #2 by mcdonc on Apr 29, 2004 5:26 pm

 Status: Pending => Rejected

Sorry, I'm going to reject this one because:

1.  No one has wanted to do this for two years.

2.  Refresh has given me grief in the past and I wouldn't
    want us to add more grief.




________________________________________
= Request - Entry #1 by Anonymous User on Sep 23, 2002 11:56 am

Could the small hack described at www.zope.org/Members/madcow/ExtMethodRefresh be incorporated into Zope? This allows one to set individual External Methods to refresh themselves automatically, which is helpful if you're in the process of developing them. (They currently do this when Zope is started debug mode, but this modification allows it to be set for individual methods, rather than all or nothing.)
==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 17:28:59 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 17:29:01 2004
Subject: [ZCM] [ZC] 654/ 2 Resolve "Carrying of Duplicate cPickle"
Message-ID: 

Issue #654 Update (Resolve) "Carrying of Duplicate cPickle"
 Status Resolved, Zope/bug low
To followup, visit:
  http://collector.zope.org/Zope/654

==============================================================
= Resolve - Entry #2 by mcdonc on Apr 29, 2004 5:28 pm

 Status: Pending => Resolved

Zope 2.7.0 no longer ships with cPickle.
________________________________________
= Request - Entry #1 by Anonymous User on Nov 2, 2002 9:12 pm

Since Zope 2.6.0 now requires Python 2.1, can we drop
the carrying of cPickle in Zope distributions?  Isn't
the version of cPickle in Python 2.1 good enough or is
there still Zope-specific mods to cPickle being used?

Removing unnecessary files makes maintaining release
packages such as RPMs easier.

==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 17:30:41 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 17:30:44 2004
Subject: [ZCM] [ZC] 678/ 6 Resolve "pyexpat.so missing in binary
	installation"
Message-ID: 

Issue #678 Update (Resolve) "pyexpat.so missing in binary installation"
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/678

==============================================================
= Resolve - Entry #6 by mcdonc on Apr 29, 2004 5:30 pm

 Status: Pending => Resolved

Zope Corp no longer builds binaries for releases after 2.7.0, so this is "resolved" (in a very cheap-shot kind of way, but still resolved ;-).
________________________________________
= Resubmit - Entry #5 by efge on Feb 17, 2003 12:05 pm

 Status: Rejected => Pending

> ZC does not bundle expat with its binary builds of python.

That's not an acceptable answer... Core Zope needs expat, as the
original poster of this bug remarked. Does this mean that any
user needing page templates in a non-HTML format will have to
build his own Zope?

- create a Page Template

- go edit it

- use  as content

- use text/xml as content-type

- try to save the resulting page template

You get the traceback:

    * Module ZPublisher.Publish, line 98, in publish
    * Module ZPublisher.mapply, line 88, in mapply
    * Module ZPublisher.Publish, line 39, in call_object
    * Module Products.PageTemplates.ZopePageTemplate, line 116, in pt_editAction
    * Module Products.PageTemplates.PageTemplate, line 60, in pt_edit
    * Module Products.PageTemplates.ZopePageTemplate, line 196, in write
    * Module Products.PageTemplates.PageTemplate, line 139, in write
    * Module Products.PageTemplates.PageTemplate, line 169, in _cook
    * Module TAL.TALParser, line 27, in __init__
    * Module TAL.XMLParser, line 48, in __init__
    * Module TAL.XMLParser, line 72, in createParser

ImportError: cannot import name expat


________________________________________
= Reject - Entry #4 by matt on Feb 3, 2003 9:32 am

 Status: Pending => Rejected

ZC does not bundle expat with its binary builds of python.  

The windows binaries are distributed unaltered -- the PythonLabs build of python for windows does include the expat library, but ZC has never included this as part of python for a linux binary release.

At one point in time, Zope did include an older version of expat, but this has since been removed.

Linux users needing expat should use a source release of Zope compiled against a local python.
________________________________________
= Comment - Entry #3 by efge on Jan 31, 2003 5:55 pm

This still happens with 2.6.1b2 binary release for Linux.

Another symptom is:

# ./bin/python 
Python 2.1.3 (#1, Sep 19 2002, 13:15:46) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> from xml.parsers import expat
Traceback (most recent call last):
  File "", line 1, in ?
  File "/home/zope/testzope261b2/lib/python2.1/xml/parsers/expat.py", line 4, in ?
    from pyexpat import *
ImportError: No module named pyexpat

________________________________________
= Comment - Entry #2 by efge on Dec 17, 2002 5:19 pm

Yes, this happened to me too.

Basically it means that you cannot use XML zpts using
a binary install.

I'm surprised the unit tests don't detect this.
Actually I'm not sure I ever ran the unit tests using a binary
install...
________________________________________
= Request - Entry #1 by j_lubcke on Nov 18, 2002 3:30 pm

Binary installation missing pyexpat.so

PageTemplates with non-standard content type ("text/vnd.wap.wml" for example) gives a Site Error with the traceback:

-- 8< --

 Traceback (innermost last):
   Module ZPublisher.Publish, line 98, in publish
   Module ZPublisher.mapply, line 88, in mapply
   Module ZPublisher.Publish, line 39, in call_object
   Module Shared.DC.Scripts.Bindings, line 252, in __call__
   Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec
   Module App.special_dtml, line 174, in _exec
   Module DocumentTemplate.DT_In, line 705, in renderwob
   Module Products.PageTemplates.ZopePageTemplate, line 279, in om_icons
   Module Products.PageTemplates.PageTemplate, line 169, in _cook
   Module TAL.TALParser, line 27, in __init__
   Module TAL.XMLParser, line 48, in __init__
   Module TAL.XMLParser, line 72, in createParser
 ImportError: cannot import name expat

-- 8< --

If pyexpat.so is copied from some other Python 2.1 installation the problem goes away.


==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 17:34:39 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 17:34:41 2004
Subject: [ZCM] [ZC] 800/ 2 Resolve "win32 upgrade 2.6 -> 2.6.1: swhome
	broken"
Message-ID: 

Issue #800 Update (Resolve) "win32 upgrade 2.6 -> 2.6.1: swhome broken"
 Status Resolved, Zope/doc request medium
To followup, visit:
  http://collector.zope.org/Zope/800

==============================================================
= Resolve - Entry #2 by mcdonc on Apr 29, 2004 5:34 pm

 Status: Pending => Resolved

This is water under the bridge at this point, so I am resovling.
________________________________________
= Request - Entry #1 by tarnold on Feb 9, 2003 9:16 am

When upgrading the win32 binary distribution for Zope 2.6 (Zope-2.6.0-win32-x86.exe) to 2.6.1 using Zope-2.6.x-to-2.6.1-win32-x86.tgz, the file z2.py (in Zope's root folder) is upgraded and the "required path hackery for the win32 binary distribution" on line 236 gets lost.
The visible result is that products using e.g. win32api are disabled.

To fix the problem re-change line 236 from

  swhome=r'INSERT_SOFTWARE_HOME'
  
to the path of the installation, e.g.

  swhome=r'C:\Program Files\Z26'  
  
As this is problem is probably not solvable in a .tgz upgrade, it should be described on http://www.zope.org/Documentation/Misc/InstallingZope.html .
==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 17:37:28 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 17:37:30 2004
Subject: [ZCM] [ZC] 811/ 2 Reject "Virtual Host Logging"
Message-ID: 

Issue #811 Update (Reject) "Virtual Host Logging"
 Status Rejected, ZServer/feature+solution medium
To followup, visit:
  http://collector.zope.org/Zope/811

==============================================================
= Reject - Entry #2 by mcdonc on Apr 29, 2004 5:37 pm

 Status: Pending => Rejected

Apologies, I don't think anyone is willing to commit this patch, as most people frontend Zope with Apache and use its vhosting facilities to do the same thing.  I am going to "reject" this as a result, as it appears that no one has been willing to step up to commit this since it was entered.
________________________________________
= Request - Entry #1 by SmileyChris on Feb 16, 2003 7:27 pm

I added the ability for medusa to split the logs based on the virtual host. (It only splits the HTTP server log on host, all others all go in the default log file)

I use it and I have had other emails thanking me for this, so maybe if noone can see any problem with it, it should be melded with the main code.

My solution:
http://www.zope.org/Members/SmileyChris/howto/virtual_host_file_logger
==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 17:38:29 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 17:38:31 2004
Subject: [ZCM] [ZC] 922/ 3 Comment "Version feature is broken in Zope"
Message-ID: 

Issue #922 Update (Comment) "Version feature is broken in Zope"
 Status Pending, Database/bug critical
To followup, visit:
  http://zope.org/Collectors/Zope/922

==============================================================
= Comment - Entry #3 by slinkp on Apr 29, 2004 5:38 pm

Cannot reproduce with Zope 2.7 CVS.

Tried to test with Zope 2 HEAD (2.8), but fsrecover.py seems badly broken there - gives about 900 invalid transaction lengths for a fresh Data.fs.
________________________________________
= Comment - Entry #2 by jeremy on Jan 17, 2004 4:33 pm

Can you confirm whether this bug exists with 2.6.3?  I vaguely recall fixing a bug in abortVersion that could have caused this behavior, but I can't find any evidence of it in the change logs.

________________________________________
= Request - Entry #1 by Anonymous User on May 22, 2003 11:04 am

Version feature is broken in Zope:

Working for some time with versions has caused two
times a corruption of Data.fs (Zope 2.5.1) in
our installation.

Test scenario description with a new (clean) Zope installation:
- Add Version to Root Folder: Id = "Test Version"
- Press Button: "Start Working in Test Version" in Test Version
- Add Line "Test" as 4th line to index.html
- Press Button "Quit Working in /Test Version" in Test Version
- call 'python /lib/python/ZODB/fsrecover.py /var/Data.fs /tmp/Data.fs'
Result:
Recovering /home/ndu/zope2.6/var/Data.fs into /tmp/Data.fs
. 1 . 2 . 3 . 4 . 5 . 6 . 7 . 8 . 9 .
ZODB.POSException.VersionLockError: ("'\\x00\\x00\\x00\\x00\\x00\\x00\\x00T'", '/Test Version')

0 . 1 . 2 . 3 . 4 . 5 . 6 . 7 . 8 . 9
319 bytes removed during recovery

I assume that this error leads after some time/changes
to a corruption of Data.fs

I get the above error for Zope 2.5.1 and Zope 2.6.2b1.
For Zope 2.5.1 the error can be resolved by packing the
Database. For Zope 2.6.2b1 the error persists.

==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 17:41:13 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 17:41:21 2004
Subject: [ZCM] [ZC] 571/ 2 Reject "Can't call methods on a ZPT object
	because of weird path traversal"
Message-ID: 

Issue #571 Update (Reject) "Can't call methods on a ZPT object because of weird path traversal"
 Status Rejected, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/571

==============================================================
= Reject - Entry #2 by Caseman on Apr 29, 2004 5:41 pm

 Status: Pending => Rejected

ZPT subclass the same script base class as Python scripts. This has a traversal hook that eats the subpath following the template. This is probably fixable, but the level of effort does not seem worthwhile IMO.
________________________________________
= Request - Entry #1 by djay on Sep 16, 2002 8:20 pm

If I have a python method M1 and a ZPT, Z1 and I use the url Z1/M1 I don't get the behaviour I expect. I think something about the path traversal code that ZPT uses to do things like the "source.html" functionality must screw up normal aquisition type method calling. I'm not sure how to get the traversal path when using a python script so I'm not sure how could use a url such as "M1/Z1" as an alternative, although even if I could it doesn't strike me as very nice way of doing it. Not very OO.
==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 17:43:01 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 17:43:04 2004
Subject: [ZCM] [ZC] 1042/ 4 Reject "Zope 2.7 port-base not calculating
	correctly"
Message-ID: 

Issue #1042 Update (Reject) "Zope 2.7 port-base not calculating correctly"
 Status Rejected, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/1042

==============================================================
= Reject - Entry #4 by mcdonc on Apr 29, 2004 5:43 pm

 Status: Pending => Rejected

Wont-fix... (sorry Limi!)
________________________________________
= Comment - Entry #3 by mcdonc on Oct 23, 2003 6:49 pm

I'd really prefer that port-base didn't exist at all.  If Jim weren't the one that wanted it, I'd just rip it out. ;-)

That said, here's how it works: the value you define as "port-base" will be added to the port number you define in each server section.  It defaults to 0.  If you've got a web server on 8080 and a port-base of 0, the web server will run on 8080.  If you've got a web server on 8080 and a port-base of 1, it will run on 8081.

I think Jim's reasoning was that he wanted to be able to change the port base from the command line.  Maybe we should just take it out of the default config file and make it "Jim's undocumented option". ;-)

Relatedly, I think the fact that a zope.conf doesn't need any servers defined but still starts an ftp and web server is wrong.  I thought it was right at one point, but I think I'm going to change it so that Zope will start no servers if none are defined. 
________________________________________
= Comment - Entry #2 by limi on Sep 8, 2003 8:56 pm

Hm, I see now that the behaviour has been changed, this is not a good way of doing it, IMHO.

Having to input negative offsets from the value 8000 makes no sense to get something running on port 80.

port-base 0

should give you web on 80, ftp on 21 etc. port-base -8000 seems a bit silly, why the magical connection to the number 8000?

In any case, this is certain to trip up a lot of current users of Zope in addition to the newbies. If there's a good reason to change it, I'm all ears :)

________________________________________
= Request - Entry #1 by limi on Sep 8, 2003 8:50 pm

The port-base directive in zope.conf seems to be a bit confused.

I set it up with the instruction:

port-base 40000

Which (according to the instructions, and to the way it's always worked in previous zope versions) should give me web on 40080, ftp on 40021 etc.

What it ends ut doing is adding the base to the 8080 that exists originally, so it ends up running on port 48080 instead.

==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 17:48:30 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 17:48:32 2004
Subject: [ZCM] [ZC] 637/ 5 Reject "ZPT: modules/sequence raises Unauthorized
	exception"
Message-ID: 

Issue #637 Update (Reject) "ZPT: modules/sequence raises Unauthorized exception"
 Status Rejected, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/637

==============================================================
= Reject - Entry #5 by Caseman on Apr 29, 2004 5:48 pm

 Status: Accepted => Rejected

NOTABUG
________________________________________
= Resubmit - Entry #4 by chrisw on Nov 5, 2003 3:40 am

 Status: Rejected => Accepted

Well, if that's the case, it seems that Andreas is describing an error in the Zope book.

Does the Zope book have a tracker?
________________________________________
= Reject - Entry #3 by evan on Nov 4, 2003 3:07 pm

 Status: Accepted => Rejected

There *is* no top-level sequence module.  It is, however, already available in the restricted Python builtins.  Try tal:define="seq python:sequence", for example.
________________________________________
= Accept - Entry #2 by ajung on Oct 23, 2002 3:58 am

 Status: Pending => Accepted

 Supporters added: ajung


________________________________________
= Request - Entry #1 by ajung on Oct 23, 2002 3:53 am

tal:define="seq modules/sequence" raises
an Unauthorized exception although it should be allowed to use this module as described in the Zope Book.

-aj
==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 17:49:22 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 17:49:24 2004
Subject: [ZCM] [ZC] 540/ 6 Resolve "Local roles don't work when name of user
	doesn't match id"
Message-ID: 

Issue #540 Update (Resolve) "Local roles don't work when name of user doesn't match id"
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/540

==============================================================
= Resolve - Entry #6 by mcdonc on Apr 29, 2004 5:49 pm

 Status: Pending => Resolved

The separation between getUserName vs. getId is fixed *almost* 100% in Zope 2.6.4 and Zope 2.7.0.  It is fixed 100% in (an as yet-unreleased) Zope 2.7.1.
________________________________________
= Comment - Entry #5 by djay on Aug 27, 2002 7:18 pm

No, it's not LDAPUserFolder. It's RemoteUserFolder which is one I wrote but have yet to make publicly available, for reasons such as finding these kind of bugs. I could patch the userfolder but I'm not sure that's the right thing to do since this seems to be a Zopebug.
________________________________________
= Comment - Entry #4 by jens on Aug 27, 2002 12:18 pm

djay,

if the user folder you use happens to be the LDAPUserFolder (which i know had this problem) then you should upgrade it to the latest version which has this specific "problem" fixed.

jens

________________________________________
= Comment - Entry #3 by jens on Aug 27, 2002 12:18 pm

djay,

if the user folder you use happens to be the LDAPUserFolder (which i know had this problem) then you should upgrade it to the latest version which has this specific "problem" fixed.

jens

________________________________________
= Comment - Entry #2 by jens on Aug 27, 2002 12:18 pm

djay,

if the user folder you use happens to be the LDAPUserFolder (which i know had this problem) then you should upgrade it to the latest version which has this specific "problem" fixed.

jens

________________________________________
= Request - Entry #1 by djay on Aug 27, 2002 3:45 am

The code in User.py tries to match user.getUserName() to the values stored in __ac_local_roles__, however user.getId() is what is added to the local roles (in fact user paths should be too but that's a different issue). In my case I'm using a UserFolder that has users where getUserName() returns a different value from getId(), which seams reasonable behaviour except for this inconsitency with local roles
==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 17:51:34 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 17:51:37 2004
Subject: [ZCM] [ZC] 658/ 3 Resolve "Fracture setup.py into components"
Message-ID: 

Issue #658 Update (Resolve) "Fracture setup.py into components"
 Status Resolved, Zope/bug+solution low
To followup, visit:
  http://collector.zope.org/Zope/658

==============================================================
= Resolve - Entry #3 by Caseman on Apr 29, 2004 5:51 pm

 Status: Pending => Resolved

Obsolete

________________________________________
= Comment - Entry #2 by mcdonc on Nov 2, 2002 9:40 pm

Jeff,

You may be interested in the "chrism-install-branch" of the Zope trunk.  It has an rpm builder ("make rpmdist").  Any suggestions for splitting the setup.py should probably be made in terms of this branch as it will be merged into the head soon.

- C

________________________________________
= Request - Entry #1 by Anonymous User on Nov 2, 2002 9:31 pm

Please break the global setup.py apart so that it is
easier to build selected Zope components, for
packaging.  A single, monolithic build process is not
developer friendly and makes assumptions of the use
and placement of build results.

Apparently the distutils functionality doesn't support
selected builds of subpackages, at least as far I can
can tell.  Something similar to "make subtarget".

==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 17:52:40 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 17:52:41 2004
Subject: [ZCM] [ZC] 1050/ 2 Reject "softwarehome points to wrong directory"
Message-ID: 

Issue #1050 Update (Reject) "softwarehome points to wrong directory"
 Status Rejected, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/1050

==============================================================
= Reject - Entry #2 by Caseman on Apr 29, 2004 5:52 pm

 Status: Pending => Rejected

Not enough specific detail provided. If this is still an issue please provide the exact configuration in question.
________________________________________
= Request - Entry #1 by ctheune on Sep 15, 2003 1:09 pm

I have an instance_home setup with this
Zope (some days before DBTabs checkin) and 
the softwarehome from the configuration registry
points to the instance home root, which screws
up the detection of a version.txt in App.version_txt.py

Dunno if it is fixed in newer versions, can't use them
currently because of the DBTab changes (this one really hurt over here ... but that's a different story.)
==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 17:56:09 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 17:56:12 2004
Subject: [ZCM] [ZC] 810/ 2 Resolve "zlib missing ?"
Message-ID: 

Issue #810 Update (Resolve) "zlib missing ?"
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/810

==============================================================
= Resolve - Entry #2 by mcdonc on Apr 29, 2004 5:56 pm

 Status: Pending => Resolved

Closing this issue as we no longer supply binary installation tarballs in the stable release (2.7+).  Errors like this will be detected on source install or by 3rd-party package management systems that have dependency checking.
________________________________________
= Request - Entry #1 by Anonymous User on Feb 16, 2003 10:51 am

Hi Collector Team,

I've have downloaded and installed the Zope 2.6.1 linux .tar.gz. On start of z2.py the library zlib from lib/Components/zlib pointed out as missing.

Is zlib no longer in the Zope dist ? If so where can I get zlib from ?

Regards,
Dirk
==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 17:57:55 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 17:57:57 2004
Subject: [ZCM] [ZC] 644/ 2 Resolve "initial ZODB root 'index_html' is broken
	HTML"
Message-ID: 

Issue #644 Update (Resolve) "initial ZODB root 'index_html' is broken HTML"
 Status Resolved, Zope/bug+solution medium
To followup, visit:
  http://collector.zope.org/Zope/644

==============================================================
= Resolve - Entry #2 by Caseman on Apr 29, 2004 5:57 pm

 Status: Pending => Resolved

Appears to be fixed in 2.7
________________________________________
= Request - Entry #1 by wilm on Oct 27, 2002 11:04 am

Problem:
  The 'index_html' in the root directory of the
  ZODB is invalid HTML.

Solution:
  Remove standard_hml_header and .._footer from
  index_html. (Removing the parts from zope_quick_start
  is a bit more difficult, as it puts styles in the
  , while the std_header puts only a title there.)

Description:
  The source of index_html:

  
  
  

This gives, when viewed:

  
  
  Zope
  
  
  
  Zope QuickStart

  ......

  
  
  
  
  

==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 18:06:58 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 18:07:02 2004
Subject: [ZCM] [ZC] 584/ 3 Comment "Auto-refresh External Methods"
Message-ID: 

Issue #584 Update (Comment) "Auto-refresh External Methods"
 Status Rejected, Zope/feature+solution medium
To followup, visit:
  http://collector.zope.org/Zope/584

==============================================================
= Comment - Entry #3 by Caseman on Apr 29, 2004 6:06 pm

Actually ext. methods already refresh on each request if you run Zope in debug mode.
________________________________________
= Reject - Entry #2 by mcdonc on Apr 29, 2004 5:26 pm

 Status: Pending => Rejected

Sorry, I'm going to reject this one because:

1.  No one has wanted to do this for two years.

2.  Refresh has given me grief in the past and I wouldn't
    want us to add more grief.




________________________________________
= Request - Entry #1 by Anonymous User on Sep 23, 2002 11:56 am

Could the small hack described at www.zope.org/Members/madcow/ExtMethodRefresh be incorporated into Zope? This allows one to set individual External Methods to refresh themselves automatically, which is helpful if you're in the process of developing them. (They currently do this when Zope is started debug mode, but this modification allows it to be set for individual methods, rather than all or nothing.)
==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 18:08:22 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 18:08:26 2004
Subject: [ZCM] [ZC] 553/ 5 Comment "sporadic Zope crashes"
Message-ID: 

Issue #553 Update (Comment) "sporadic Zope crashes"
 Status Accepted, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/553

==============================================================
= Comment - Entry #5 by tim_one on Apr 29, 2004 6:08 pm

This is fixed on Zope-2_7-branch now.

doc/CHANGES.txt rev 1.625.2.137
lib/python/BTrees/BucketTemplate.c rev 1.54.4.1
lib/python/BTrees/tests/testConflict.py rev 1.16.6.1

It's still broken in the 2.6 branch.  It's not broken on HEAD (it got fixed there a long time ago, as a happy side effect of backporting ZODB4 code to ZODB HEAD).
________________________________________
= Assign - Entry #4 by tim_one on Apr 29, 2004 3:49 pm

 Status: Pending => Accepted

 Supporters added: tim_one

Assigned this one to me.
________________________________________
= Resubmit - Entry #3 by tim_one on Apr 29, 2004 3:49 pm

 Status: Resolved => Pending

Reopened Wow!  Wish I had known about this one earlier.  This particular bug still exists, and Dieter Maurer rediscovered it this year (2004).  It can only happen when bucket conflict resolution is handed 3 empty buckets, which is darned hard to do.
________________________________________
= Resolve - Entry #2 by Caseman on Apr 29, 2004 3:38 pm

 Status: Pending => Resolved

Much work has been done on BTrees since this report. If the problem still occurs, please reopen.
________________________________________
= Request - Entry #1 by Anonymous User on Aug 30, 2002 11:47 am

I'm doing stress tests of my Application from time to time to check for memory leaks and such. There it sometimes happens, that Zope crashes with an illegal memory access exception. Some debugging showed, that the problem is in BTrees/BucketTemplate.c in _bucket__p_resolveConflict:

>  _bucket__p_resolveConflict(PyObject *ob_type, PyObject *s[3])
>  {
>    PyObject *r=0, *a;
>    Bucket *b[3];
>    int i;
>
>    for (i=0; i < 3; i++)
>      {
>      ...
>      }
> here is where the exception occured, that should probably be a Py_XDECREF
>    Py_DECREF(r);

==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 18:19:48 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 18:19:52 2004
Subject: [ZCM] [ZC] 1003/ 4 Reject "Overlong HTTP headers handled badly"
Message-ID: 

Issue #1003 Update (Reject) "Overlong HTTP headers handled badly"
 Status Rejected, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/1003

==============================================================
= Reject - Entry #4 by mcdonc on Apr 29, 2004 6:19 pm

 Status: Pending => Rejected

Rejecting, here's the rationale:

 slinkP: errr... if I follow Jamie's suggestion, he thinks there's no bug for 1003, right?
 i dont think it's a bug either.  if someone sends an 8000-character query string, it can only be a mistake or a DOS attempt, replying to them with a 500 just consumes more bandwidth and time.

Jamie, if you have a good argument to the contrary, please let me know and I will reopen.
________________________________________
= Comment - Entry #3 by leper on Dec 2, 2003 4:24 am

Upon further investigation this issue is actually more interesting than I initially thought.  The fix for 606 was rather naive, at the time I thought Brian had added a per-header 8KB limit like Apache's LimitRequestFieldsize, but thats not what he did.  The limit is 8K of data *total* prior to the CRLF CRLF sequence that delimits a request's headers and its body (if it has one).  That limit, while seemingly small, seems to be working OK for most folks or I'd imagine we'd be hearing a lot more complaints.  It also debunks my theory that ZServer stored unlimited headers in memory until it hit an rlimit, paradoxically making ZServer marginally safer than I'd initially given it credit for.  Go figure.  Nevertheless Andreas is right in that the handling of this error isn't very friendly.
________________________________________
= Comment - Entry #2 by leper on Aug 1, 2003 6:31 pm

Why is this critical?

I agree its a silly situation, but the simple truth is ZServer does
not offer an internet-quality HTTP service.  Requests handled by
ZServer must be sanitized by a proxy server first, for safety.  If
you ask me, its critical the lack of documentation about this be
addressed before 2.7 is released.

________________________________________
= Request - Entry #1 by ajung on Aug 1, 2003 6:46 am

Sending a GET request with a very long query string (several thousands characters) raises:


2003-08-01T12:41:33 ERROR(200) ZServer uncaptured python exception, closing channel  (exceptions.ValueError:HTTP headers invalid (too long) [/develop/sandboxes/bpe2-head/ZServer/medusa/asyncore.py|poll|94] [/develop/sandboxes/bpe2-head/ZServer/medusa/asyncore.py|handle_read_event|395] [/develop/sandboxes/bpe2-head/ZServer/medusa/asynchat.py|handle_read|142] [/develop/sandboxes/bpe2-head/ZServer/HTTPServer.py|collect_incoming_data|351])

Instead of replying with a proper HTTP return code (500 at least), Zope just closes the connection.



==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 18:35:49 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 18:35:52 2004
Subject: [ZCM] [ZC] 724/ 3 Resolve "Redirecting (etc.) pages are cached"
Message-ID: 

Issue #724 Update (Resolve) "Redirecting (etc.) pages are cached"
 Status Resolved, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/724

==============================================================
= Resolve - Entry #3 by mcdonc on Apr 29, 2004 6:35 pm

 Status: Pending => Resolved

This was fixed by Paul as an addition to the HurtSys documentation basically stating "don't do that". ;-)
________________________________________
= Comment - Entry #2 by astaubo on Dec 13, 2002 10:01 am

2.6.0-linux2-x86, sorry.
________________________________________
= Request - Entry #1 by astaubo on Dec 13, 2002 10:00 am

Pages which are associated with a RAM Cache Manager are cached even when they return a redirection header (301, 302) or an error header. This means that if you have a page like this:

El redirecto!
  

  page here


then the first cache miss will return to the user:

 HTTP/1.1 302 Moved Temporarily
 Date: Fri, 13 Dec 2002 14:49:53 GMT
 Location: ... 

 El redirecto!

and subsequent cache hits will return:

 HTTP/1.1 200 OK
 Date: Fri, 13 Dec 2002 14:49:53 GMT

 El redirecto!

In short, Zope's RAM Cache Manager should not cache pages that redirect or return errors.
==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 18:43:57 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 18:44:01 2004
Subject: [ZCM] [ZC] 789/ 4 Comment "Zope's transaction behaviour flawed"
Message-ID: 

Issue #789 Update (Comment) "Zope's transaction behaviour flawed"
 Status Pending, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/789

==============================================================
= Comment - Entry #4 by d.maurer on Apr 29, 2004 6:43 pm

Toby convinced me ("zope-dev" discussion) that the correct behaviour would be to abort the transaction after error handling
(thus doing error handling in the same transaction as the request).

Currently, at the start of error handling, "get_transaction().begin()" is called, effectivle aborting the transaction, the request has been running in. This is bad as people expecting to find information in the SESSION are mislead.

I do not understand why implementing the correct behaviour would break application that "clear ... data
themselves at transaction boundaries".

I can see that application will break that perform a commit in the error handling -- but that should be rare...
________________________________________
= Comment - Entry #3 by mcdonc on Apr 29, 2004 12:09 pm

Michael Dunstan also compiled some notes and fixes for this... see http://mail.zope.org/pipermail/zope-dev/2004-April/022727.html
________________________________________
= Comment - Entry #2 by stevea on Feb 2, 2003 12:14 pm

I'm currently implementing similar behaviour for zope 3.

However, introducing this behaviour in zope2 could break applications that themselves clear cached or computed data on transaction boundaries. This data would not be available for the error page.

I think ZPatterns applications sometimes rely on the current behaviour, so this change would break certain zpatterns applications.
________________________________________
= Request - Entry #1 by d.maurer on Feb 2, 2003 10:39 am

Zope's current transaction behaviour is essentially:


  ## request starts
  transaction.begin()
  try:
       object= REQUEST.traverse(...)
       mapply(object,...)
       transaction.commit()
  except:
       transaction.abort()
       handle_error()
  ## request ends


This is flawed as error handling is done outside of a transaction.

   Potential changes during the error handling spill over
   uncontrolled into another request and are there
   either committed or aborted as part of this request.

   Andrew Athan () has had lots
   of serious inconsistencies in Zope's session data.
   After extensive analysis, he found out that reading
   the session data during error handling led to these
   error conditions (reading session data causes writes to
   the administrative data).


I suggest, we let Zope perform error handling in its own
transaction after the original transaction had been aborted.
When error handling succeeds, its transaction is committed,
otherwise aborted.

The new behaviour would look something like this:

  ## request starts
  transaction.begin()
  try:
       object= REQUEST.traverse(...)
       mapply(object,...)
       transaction.commit()
  except:
       transaction.abort()
       transaction.begin()
       transaction.note('%s (application error handling)'
                        % '/'.join(object.getPhysicalPath)
			)
       try:
	   handle_error()
	   transaction.commit()
       except:
           default_handle_error() # Zope's default error handling
	                          # it should not have side effects
				  # and is executed inside the
				  # error handling transaction
	   transaction.abort()
  ## request ends


--- See discussion in "zope-dev".
==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 18:51:55 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 18:51:59 2004
Subject: [ZCM] [ZC] 1199/ 3 Comment "FileUpload not iterable"
Message-ID: 

Issue #1199 Update (Comment) "FileUpload not iterable"
 Status Pending, Zope/bug+solution medium
To followup, visit:
  http://zope.org/Collectors/Zope/1199

==============================================================
= Comment - Entry #3 by LRA on Apr 29, 2004 6:51 pm


Uploaded:  "bug-1199-wo-braindamage.diff"
 - http://zope.org/Collectors/Zope/1199/bug-1199-wo-braindamage.diff/view
previous patch had a hard to spot braindamage (missing comma between two strings. Even Python didn't complain because it's a valid string syntax)

________________________________________
= Comment - Entry #2 by LRA on Apr 29, 2004 5:16 pm


Uploaded:  "bug-1199.diff"
 - http://zope.org/Collectors/Zope/1199/bug-1199.diff/view
here's a patch based on discussions at 2004-04-29 bugday

________________________________________
= Request - Entry #1 by LRA on Jan 20, 2004 11:57 pm

ZPublisher.HTTPRequest.FileUpload class does not implement the iterable interface regular files do, so it can't be used in places where a file object is assumed to be an iterable, like csv.reader(), for instance.

I think fixing this is as easy as implementing an __iter__ method that returns 'self' and a .next() method as an alias for .readline() in the FileUpload class
==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 18:54:40 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 18:54:43 2004
Subject: [ZCM] [ZC] 553/ 6 Resolve "sporadic Zope crashes"
Message-ID: 

Issue #553 Update (Resolve) "sporadic Zope crashes"
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/553

==============================================================
= Resolve - Entry #6 by tim_one on Apr 29, 2004 6:54 pm

 Status: Accepted => Resolved

Also fixed on Zope-2_6-branch now, so closing as Resolved:

doc/CHANGES.txt rev 1.535.2.180
lib/python/BTrees/BucketTemplate.c rev 1.47.10.5
lib/python/BTrees/tests/testConflict.py rev 1.13.6.6

________________________________________
= Comment - Entry #5 by tim_one on Apr 29, 2004 6:08 pm

This is fixed on Zope-2_7-branch now.

doc/CHANGES.txt rev 1.625.2.137
lib/python/BTrees/BucketTemplate.c rev 1.54.4.1
lib/python/BTrees/tests/testConflict.py rev 1.16.6.1

It's still broken in the 2.6 branch.  It's not broken on HEAD (it got fixed there a long time ago, as a happy side effect of backporting ZODB4 code to ZODB HEAD).
________________________________________
= Assign - Entry #4 by tim_one on Apr 29, 2004 3:49 pm

 Status: Pending => Accepted

 Supporters added: tim_one

Assigned this one to me.
________________________________________
= Resubmit - Entry #3 by tim_one on Apr 29, 2004 3:49 pm

 Status: Resolved => Pending

Reopened Wow!  Wish I had known about this one earlier.  This particular bug still exists, and Dieter Maurer rediscovered it this year (2004).  It can only happen when bucket conflict resolution is handed 3 empty buckets, which is darned hard to do.
________________________________________
= Resolve - Entry #2 by Caseman on Apr 29, 2004 3:38 pm

 Status: Pending => Resolved

Much work has been done on BTrees since this report. If the problem still occurs, please reopen.
________________________________________
= Request - Entry #1 by Anonymous User on Aug 30, 2002 11:47 am

I'm doing stress tests of my Application from time to time to check for memory leaks and such. There it sometimes happens, that Zope crashes with an illegal memory access exception. Some debugging showed, that the problem is in BTrees/BucketTemplate.c in _bucket__p_resolveConflict:

>  _bucket__p_resolveConflict(PyObject *ob_type, PyObject *s[3])
>  {
>    PyObject *r=0, *a;
>    Bucket *b[3];
>    int i;
>
>    for (i=0; i < 3; i++)
>      {
>      ...
>      }
> here is where the exception occured, that should probably be a Py_XDECREF
>    Py_DECREF(r);

==============================================================


From zope-coders-admin at zope.org  Thu Apr 29 19:23:06 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Thu Apr 29 19:23:10 2004
Subject: [ZCM] [ZC] 1042/ 5 Comment "Zope 2.7 port-base not calculating
	correctly"
Message-ID: 

Issue #1042 Update (Comment) "Zope 2.7 port-base not calculating correctly"
 Status Rejected, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/1042

==============================================================
= Comment - Entry #5 by limi on Apr 29, 2004 7:23 pm

No problem, I have another parameter to use instead now, so even if it's still braindead, I can live with it. ;)
________________________________________
= Reject - Entry #4 by mcdonc on Apr 29, 2004 5:43 pm

 Status: Pending => Rejected

Wont-fix... (sorry Limi!)
________________________________________
= Comment - Entry #3 by mcdonc on Oct 23, 2003 6:49 pm

I'd really prefer that port-base didn't exist at all.  If Jim weren't the one that wanted it, I'd just rip it out. ;-)

That said, here's how it works: the value you define as "port-base" will be added to the port number you define in each server section.  It defaults to 0.  If you've got a web server on 8080 and a port-base of 0, the web server will run on 8080.  If you've got a web server on 8080 and a port-base of 1, it will run on 8081.

I think Jim's reasoning was that he wanted to be able to change the port base from the command line.  Maybe we should just take it out of the default config file and make it "Jim's undocumented option". ;-)

Relatedly, I think the fact that a zope.conf doesn't need any servers defined but still starts an ftp and web server is wrong.  I thought it was right at one point, but I think I'm going to change it so that Zope will start no servers if none are defined. 
________________________________________
= Comment - Entry #2 by limi on Sep 8, 2003 8:56 pm

Hm, I see now that the behaviour has been changed, this is not a good way of doing it, IMHO.

Having to input negative offsets from the value 8000 makes no sense to get something running on port 80.

port-base 0

should give you web on 80, ftp on 21 etc. port-base -8000 seems a bit silly, why the magical connection to the number 8000?

In any case, this is certain to trip up a lot of current users of Zope in addition to the newbies. If there's a good reason to change it, I'm all ears :)

________________________________________
= Request - Entry #1 by limi on Sep 8, 2003 8:50 pm

The port-base directive in zope.conf seems to be a bit confused.

I set it up with the instruction:

port-base 40000

Which (according to the instructions, and to the way it's always worked in previous zope versions) should give me web on 40080, ftp on 40021 etc.

What it ends ut doing is adding the base to the 8080 that exists originally, so it ends up running on port 48080 instead.

==============================================================


From zope-coders-admin at zope.org  Fri Apr 30 11:14:47 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Fri Apr 30 11:14:57 2004
Subject: [ZCM] [ZC] 1285/ 2 Assign "[Weakness] analysis of Zope startup
	problems"
Message-ID: 

Issue #1285 Update (Assign) "[Weakness] analysis of Zope startup problems"
 Status Accepted, Zope/bug medium
To followup, visit:
  http://dev.zope.org/Collectors/Zope/1285

==============================================================
= Assign - Entry #2 by fdrake on Apr 30, 2004 11:14 am

 Status: Pending => Accepted

 Supporters added: fdrake

Assigned to myself since I've had my hand in startup logging recently.
________________________________________
= Request - Entry #1 by d.maurer on Apr 2, 2004 3:32 am

Zope 2.7 delays access to log files until Zope is properly set up.
This means: log files cannot be used to analyse startup problems.

The official advice to analyse startup problems is to start
Zope in the foreground and interpret the console log messages.

However, this does *NOT* work when Zope is not running in
debug mode. "Zope.Startup.ZopeStarter.setupStartupHandler"
expressly suppresses messages to "stderr" when Zope
is not running in debug mode.

Apparently, we do not have an easy way to analyse startup problems
for Zope in production mode.
In my view, this is really bad.


Please provide a way to control how startup messages should
be handled. The best place would be a file (at least for
all installations that do not start Zope as root and later
switch the effective user).

I suggest to always use the standard log file unless
told otherwise by an explicit configuration option.

==============================================================


From zope-coders-admin at zope.org  Fri Apr 30 11:21:34 2004
From: zope-coders-admin at zope.org (Collector: Zope Bugs, Features,
	and Patches ...)
Date: Fri Apr 30 11:21:41 2004
Subject: [ZCM] [ZC] 505/ 4 Assign "ZCTextUndex should not hold a reference
	to a lexicon"
Message-ID: 

Issue #505 Update (Assign) "ZCTextUndex should not hold a reference to a lexicon"
 Status Accepted, Zope/bug medium
To followup, visit:
  http://dev.zope.org/Collectors/Zope/505

==============================================================
= Assign - Entry #4 by fdrake on Apr 30, 2004 11:21 am

 Supporters removed: bwarsaw, jeremy


________________________________________
= Assign - Entry #3 by fdrake on Nov 5, 2003 2:56 pm

 Supporters removed: gvanrossum

(Trying to remove Guido from the list of assignees.)
________________________________________
= Comment - Entry #2 by Caseman on Aug 14, 2002 5:45 pm

Partial fix in place. I still need to resolve the deeper reference held in the actual index object that ZCTextIndex delegates to (more fun and games).
________________________________________
= Request - Entry #1 by mj on Aug 6, 2002 1:51 pm

 Status: Pending => Accepted

 Supporters added: bwarsaw, Caseman, fdrake, gvanrossum, jeremy, tim_one

ZCTextIndex expects the ID for the lexicon to be used to be passed in on creation. It subsequently uses getattr to retrieve this lexicon and stores it in an attribute.

If I later on delete the Lexicon from its original place, and replace it with a new type with the same ID, all ZCTextIndexes will still use the old Lexicon they were told to use on creation.

Instead, the lexicon_id should be stored, and resolved every time it is needed. Checks such as interface compliance should be moved to this point as well, removing the dependency on the 'caller' attribute in the process.

==============================================================