From zope-coders@zope.org  Tue Oct  1 08:14:00 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 01 Oct 2002 03:14:00 -0400
Subject: [ZCM] [ZC] 595/ 8 Comment "html-unquoted title in manage_page_header"
Message-ID: <E17wHEG-0004p0-00@mail.python.org>

Issue #595 Update (Comment) "html-unquoted title in manage_page_header"
 ** Security Related ** (Public)
 Status Accepted, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/595

==============================================================
= Comment - Entry #8 by htrd on Oct 1, 2002 3:13 am

The attacker doesnt necessarily need access to the ZMI to set the title. Im sure there are plenty of products that let untrusted users supply an arbitrary 'title' property (this Collector, perhaps?) because it a reasonable thing to do.

The attack is launched when the victim looks at the ZMI. Only the victim needs ZMI access.

+1 on regarding this as a security issue.
________________________________________
= Comment - Entry #7 by mj on Sep 30, 2002 4:49 pm

Once a user has access to ZMI pages to set such titles, all bets are off, and there are simpler ways of introducing malicious code. A Corss-Site scripting hole usually exploits bugs without requiring a login first. ;)
________________________________________
= Comment - Entry #6 by efge on Sep 30, 2002 4:23 pm

Not all dangerous user input comes directly from REQUEST.

With the example given by the submitter, any Member can create
a document with arbitrary title containing javascript, and
then provoke someone to go to a ZMI page whose manage_page_header
with <dtml-var title> will provide the necessary injection vector.

This *is* a XSS vulnerability, and security-related.

________________________________________
= Unrestrict_accepted - Entry #5 by mj on Sep 30, 2002 3:41 pm

THis is not security related as my taint-code preventrs cross-scripting code to be inserted there.
________________________________________
= Restrict_accepted - Entry #4 by efge on Sep 29, 2002 1:48 pm

 Triggered by security_related toggle.
________________________________________
= Edit - Entry #3 by efge on Sep 29, 2002 1:48 pm

 Changes: submitter email, edited transcript, security_related set, importance (low => critical), new comment

Requalifying as security-related as this is a cross-site scripting (XSS)
vulnerability.
________________________________________
= Accept - Entry #2 by efge on Sep 29, 2002 1:44 pm

 Status: Pending => Accepted

 Supporters added: efge

Accepted.
Actually there are *lots* of missing html_quote in the dtml code.
I'm preparing a patch to fix most of them.

________________________________________
= Request - Entry #1 by mjablonski on Sep 27, 2002 11:52 pm

App/dtml/manage_page_header.dtml 

<title><dtml-if title><dtml-var title></dtml-if></title>

should be:

<title><dtml-if title><dtml-var title html_quote></dtml-if></title>

Mozilla 1.1 doesn't show any content at all, if some of your content-managers give your pages titles like:

a<b

then they can't edit this page anymore...
==============================================================



From zope-coders@zope.org  Tue Oct  1 12:05:11 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 01 Oct 2002 07:05:11 -0400
Subject: [ZCM] [ZC] 598/ 1 Request "diacriticals in ZMI"
Message-ID: <E17wKpz-0003Ss-00@mail.python.org>

Issue #598 Update (Request) "diacriticals in ZMI"
 Status Pending, Zope/bug+solution low
To followup, visit:
  http://collector.zope.org/Zope/598

==============================================================
= Request - Entry #1 by Anonymous User on Oct 1, 2002 7:05 am

PLease take look at 

http://www.zope.org/Members/lukesh/diacriticals/

Somebody from mail correspondence reccomend me to put this problem here, so I put:

On Qui 19 Set 2002 01:20, Jaroslav Lukesh wrote:
| I have same problem with MSIE in czech language. Try to define codepage in
| zope system files as suggested by me in my previous reply (look for that!).
| I need to define windows-1250 codepage (czech lang) like that:
|
| <meta http-equiv="Content-Type" content="text/html; charset=windows-1250">
| <meta http-equiv="Content-Language" content="cz">
|
| add these lines to <head> tag.

A suggestion: this could be put on the collector with a suggestion to create a 
way to make this configurable without needing to modify the zope source by 
hand, eg: providing these values as an environment variable, or trying to 
guess them from the -L <locale> option of z2.py.

[]'s

-- 
Sidnei da Silva (dreamcatcher) <sidnei@x3ng.com.br>

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



From zope-coders@zope.org  Tue Oct  1 13:26:35 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 01 Oct 2002 08:26:35 -0400
Subject: [ZCM] [ZC] 517/ 3 Resolve "Unicode encoding trouble with "Umlauts" and Zope 2.6 alpha 1"
Message-ID: <E17wM6l-0003Z2-00@mail.python.org>

Issue #517 Update (Resolve) "Unicode encoding trouble with "Umlauts" and Zope 2.6 alpha 1"
 Status Resolved, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/517

==============================================================
= Resolve - Entry #3 by htrd on Oct 1, 2002 8:26 am

 Status: Accepted => Resolved

resolved in the trunk and Zope-2_6-branch
________________________________________
= Assign - Entry #2 by ajung on Aug 14, 2002 11:25 am

 Status: Pending => Accepted

 Supporters added: htrd


________________________________________
= Request - Entry #1 by bavarian on Aug 14, 2002 11:23 am

The unicode support in Zope 2.6 alpha 1 is partly broken. This is what happens:

If you use German "Umlauts" in German versions of IE 6.0, saving the propertysheet screen will sometimes end up in an UTF-8 encoding error.

Sometimes storing the Umlauts works, but the characters that are displayed after saving are different from the characters that were entered.

Sometimes IE does not display the page (blank page, but the code is there, if you look at the source code of the page).

Mozilla does also display the wrong characters, but does not have the "blank screen" issue.

To sum it up: There seem to be some really bad issues with Unicode and Umlauts. I think this is all about the browser not telling the Server what encoding it uses. Stephan Richter talked about that before ...
==============================================================



From zope-coders@zope.org  Tue Oct  1 16:55:00 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 01 Oct 2002 11:55:00 -0400
Subject: [ZCM] [ZC] 539/ 2 Resolve "ZPT: tal:on-error renders tal-tags"
Message-ID: <E17wPMS-000601-00@mail.python.org>

Issue #539 Update (Resolve) "ZPT: tal:on-error renders tal-tags"
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/539

==============================================================
= Resolve - Entry #2 by evan on Oct 1, 2002 11:54 am

 Status: Pending => Resolved

Fixed in trunk and 2.6 branch of CVS
________________________________________
= Request - Entry #1 by d.maurer on Aug 26, 2002 6:10 am

In tags of the form

<tal:XXX ... tal:on-error="string: something" />

the result is:

  <tal:XXX>something</tal:XXX>

in case of an error.

When no error occurs, the "tal:XXX" tag is not
generated because it is in the "tal" namespace.

This calls at least for documentation.
==============================================================



From zope-coders@zope.org  Tue Oct  1 18:41:57 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 01 Oct 2002 13:41:57 -0400
Subject: [ZCM] [ZC] 595/ 9 Comment "html-unquoted title in manage_page_header"
Message-ID: <E17wR1x-0002tu-00@mail.python.org>

Issue #595 Update (Comment) "html-unquoted title in manage_page_header"
 ** Security Related ** (Public)
 Status Accepted, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/595

==============================================================
= Comment - Entry #9 by mj on Oct 1, 2002 1:41 pm

OK, but you'll have your work cut out for you if you want to close all of the possible holes, without loosing functionality. Some DTML is designed to take HTML.

Also note that if a DTML method is used to process a form-based request to change the title, a TaintedString will eventually cause an exception to be raised when storage in the ZODB is attempted.

Understand that I agree this must be fixed, I just want to make sure we don't overreact by labeling this as a security issue.
________________________________________
= Comment - Entry #8 by htrd on Oct 1, 2002 3:13 am

The attacker doesnt necessarily need access to the ZMI to set the title. Im sure there are plenty of products that let untrusted users supply an arbitrary 'title' property (this Collector, perhaps?) because it a reasonable thing to do.

The attack is launched when the victim looks at the ZMI. Only the victim needs ZMI access.

+1 on regarding this as a security issue.
________________________________________
= Comment - Entry #7 by mj on Sep 30, 2002 4:49 pm

Once a user has access to ZMI pages to set such titles, all bets are off, and there are simpler ways of introducing malicious code. A Corss-Site scripting hole usually exploits bugs without requiring a login first. ;)
________________________________________
= Comment - Entry #6 by efge on Sep 30, 2002 4:23 pm

Not all dangerous user input comes directly from REQUEST.

With the example given by the submitter, any Member can create
a document with arbitrary title containing javascript, and
then provoke someone to go to a ZMI page whose manage_page_header
with <dtml-var title> will provide the necessary injection vector.

This *is* a XSS vulnerability, and security-related.

________________________________________
= Unrestrict_accepted - Entry #5 by mj on Sep 30, 2002 3:41 pm

THis is not security related as my taint-code preventrs cross-scripting code to be inserted there.
________________________________________
= Restrict_accepted - Entry #4 by efge on Sep 29, 2002 1:48 pm

 Triggered by security_related toggle.
________________________________________
= Edit - Entry #3 by efge on Sep 29, 2002 1:48 pm

 Changes: submitter email, edited transcript, security_related set, importance (low => critical), new comment

Requalifying as security-related as this is a cross-site scripting (XSS)
vulnerability.
________________________________________
= Accept - Entry #2 by efge on Sep 29, 2002 1:44 pm

 Status: Pending => Accepted

 Supporters added: efge

Accepted.
Actually there are *lots* of missing html_quote in the dtml code.
I'm preparing a patch to fix most of them.

________________________________________
= Request - Entry #1 by mjablonski on Sep 27, 2002 11:52 pm

App/dtml/manage_page_header.dtml 

<title><dtml-if title><dtml-var title></dtml-if></title>

should be:

<title><dtml-if title><dtml-var title html_quote></dtml-if></title>

Mozilla 1.1 doesn't show any content at all, if some of your content-managers give your pages titles like:

a<b

then they can't edit this page anymore...
==============================================================



From zope-coders@zope.org  Tue Oct  1 20:22:39 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 01 Oct 2002 15:22:39 -0400
Subject: [ZCM] [ZC] 599/ 1 Request "inst/compilezpy.py supresses error messages written to sys.stdout "
Message-ID: <E17wSbP-0006K5-00@mail.python.org>

Issue #599 Update (Request) "inst/compilezpy.py supresses error messages written to sys.stdout "
 Status Pending, Zope/bug+solution low
To followup, visit:
  http://collector.zope.org/Zope/599

==============================================================
= Request - Entry #1 by camil7 on Oct 1, 2002 3:22 pm

when compiling zope from source via the "./wo_pcgi.py" script, the called "inst/compilezpy.py" first redirects sys.stdout to nowhere before recursively calls "compileall.py" for all relevant subdirectories.

 Unfortunately "compileall.py" creates the error
message like:

     print 'Sorry:', exc_type_name + ':',
     print sys.exc_value
     success = 0

i.e. it writes them to sys.stdout. If a problem occures while compiling the python sources, one only 
gets the error message "There were errors during 
Python module compilation.", but no clue where the
problem is.

 Ok, this _should_ not happen. However for obscure reasons one of my files was considered to contain
binary (result of NFS confusion) after a CVS update,
thus it happened to me.

 Thus I ask, if one could at least print something to 
sys.stderr, if the compilation within a directory 
failes, thus one can rerun the compileall manually
to check for the error message.
 Not a big issue, but I do not see that the few 
additional statements hurt something.

I try to upload a patch that could be used for that purpose.

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



From zope-coders@zope.org  Tue Oct  1 20:24:19 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 01 Oct 2002 15:24:19 -0400
Subject: [ZCM] [ZC] 599/ 2 Comment "inst/compilezpy.py supresses error messages written to sys.stdout "
Message-ID: <E17wSd1-00075w-00@mail.python.org>

Issue #599 Update (Comment) "inst/compilezpy.py supresses error messages written to sys.stdout "
 Status Pending, Zope/bug+solution low
To followup, visit:
  http://collector.zope.org/Zope/599

==============================================================
= Comment - Entry #2 by camil7 on Oct 1, 2002 3:24 pm


Uploaded:  "compilezpy.patch"
 - http://collector.zope.org/Zope/599/compilezpy.patch/view

________________________________________
= Request - Entry #1 by camil7 on Oct 1, 2002 3:22 pm

when compiling zope from source via the "./wo_pcgi.py" script, the called "inst/compilezpy.py" first redirects sys.stdout to nowhere before recursively calls "compileall.py" for all relevant subdirectories.

 Unfortunately "compileall.py" creates the error
message like:

     print 'Sorry:', exc_type_name + ':',
     print sys.exc_value
     success = 0

i.e. it writes them to sys.stdout. If a problem occures while compiling the python sources, one only 
gets the error message "There were errors during 
Python module compilation.", but no clue where the
problem is.

 Ok, this _should_ not happen. However for obscure reasons one of my files was considered to contain
binary (result of NFS confusion) after a CVS update,
thus it happened to me.

 Thus I ask, if one could at least print something to 
sys.stderr, if the compilation within a directory 
failes, thus one can rerun the compileall manually
to check for the error message.
 Not a big issue, but I do not see that the few 
additional statements hurt something.

I try to upload a patch that could be used for that purpose.

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



From zope-coders@zope.org  Wed Oct  2 16:35:53 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Wed, 02 Oct 2002 11:35:53 -0400
Subject: [ZCM] [ZC] 600/ 1 Request "sort_on breaks results if sorted attribute is missing"
Message-ID: <E17wlXV-00064C-00@mail.python.org>

Issue #600 Update (Request) "sort_on breaks results if sorted attribute is missing"
 Status Pending, Catalog/bug medium
To followup, visit:
  http://collector.zope.org/Zope/600

==============================================================
= Request - Entry #1 by chrisw on Oct 2, 2002 11:35 am

Okay, take a ZCatalog which has a FieldIndex called dateofpublication and some others.

Search it so that it returns some objects. Some of these objects have dateofpublication attributes, some dont, but all match the search criteria.

Now, add sort_on='dateofpublication' to your search terms.

I'd expect the objects without dateofpublication to be up the top of the results list.

What appears to happen is that they're dropped from the results completely, which really strikes me as a bug.


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



From zope-coders@zope.org  Thu Oct  3 10:27:08 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Thu, 03 Oct 2002 05:27:08 -0400
Subject: [ZCM] [ZC] 601/ 1 Request "DateTime Object - Days in month"
Message-ID: <E17x2GC-0002rL-00@mail.python.org>

Issue #601 Update (Request) "DateTime Object - Days in month"
 Status Pending, Zope/feature low
To followup, visit:
  http://collector.zope.org/Zope/601

==============================================================
= Request - Entry #1 by Anonymous User on Oct 3, 2002 5:27 am

I'd be glad if there could be a method in a DateTime object which would return a number of days in a specified month.

Example:

DateTime(2002,10,3).daysInMonth()

would return integer 31.

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



From zope-coders@zope.org  Thu Oct  3 14:12:00 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Thu, 03 Oct 2002 09:12:00 -0400
Subject: [ZCM] [ZC] 449/ 5 Resolve "PathIndex doesn't index last part of path"
Message-ID: <E17x5lo-0007Qf-00@mail.python.org>

Issue #449 Update (Resolve) "PathIndex doesn't index last part of path"
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/449

==============================================================
= Resolve - Entry #5 by ajung on Oct 3, 2002 9:11 am

 Status: Accepted => Resolved

This now fixed in the trunk and 2.6 branch.

-aj
________________________________________
= Accept - Entry #4 by tseaver on Sep 11, 2002 9:53 am

 Status: Rejected => Accepted

 Supporters added: tseaver


________________________________________
= Comment - Entry #3 by tseaver on Sep 11, 2002 9:51 am

> = Reject - Entry #2 by ajung on Jul 19, 2002 7:53 pm
> 
>  Status: Pending => Rejected
> 
> This behaviour is intenional.

It is *not* part of the original proposal for PathIndexes, and
in fact makes it impossible to use them as designed.

> A change might break 
> existing code.

Please indicate a use case which would break here;  the
only tradeoff I can see is that the index which works as the
submitter proposes will be larger.

> ________________________________________
> = Request - Entry #1 by djay on Jun 29, 2002 10:41 pm
> 
> The plugin ZCatalog index PathIndex doesn't index the last part of the
>   path. The reason is the following code
> 
> <pre>
>         if obj.meta_type != 'Folder':
>             comps = comps[:-1]
> </pre>
> I don't really see the sense in this code and it certainly doesn't make
>   the index a generalized one. Unless there is a good reason this should be
>   removed.
> 
> 
________________________________________
= Reject - Entry #2 by ajung on Jul 19, 2002 7:53 pm

 Status: Pending => Rejected

This behaviour is intenional. A change might break 
existing code.

-aj

________________________________________
= Request - Entry #1 by djay on Jun 29, 2002 10:41 pm

The plugin ZCatalog index PathIndex doesn't index the last part of the path. The reason is the following code

<pre>
        if obj.meta_type != 'Folder':
            comps = comps[:-1]
</pre>
I don't really see the sense in this code and it certainly doesn't make the index a generalized one. Unless there is a good reason this should be removed.


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



From zope-coders@zope.org  Thu Oct  3 19:42:56 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Thu, 03 Oct 2002 14:42:56 -0400
Subject: [ZCM] [ZC] 602/ 1 Request "XMLRPC does not allow HTTP Basic Authorization"
Message-ID: <E17xAw4-0005vO-00@mail.python.org>

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

==============================================================
= 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: <ProtocolError for localhost:8080/: 401 Unauthorized>"
 
in the event of a authentication failure.
==============================================================



From zope-coders@zope.org  Thu Oct  3 22:15:05 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Thu, 03 Oct 2002 17:15:05 -0400
Subject: [ZCM] [ZC] 603/ 1 Request "Das ZTUtils.SimpleTree Überbug"
Message-ID: <E17xDJJ-0004X2-00@mail.python.org>

Issue #603 Update (Request) "Das ZTUtils.SimpleTree Überbug"
 Status Pending, Zope/bug+solution low
To followup, visit:
  http://collector.zope.org/Zope/603

==============================================================
= Request - Entry #1 by Anonymous User on Oct 3, 2002 5:14 pm

In ZTUtils.py on line 194 the '.' character is used to denote the depth of the following node in the encoded expansion.  An obscure bug occurs when the node's id as obtained by Tree.getId() has its first 6 bits set, this will cause the b2a function to encode a node id which starts with a '.' due to the translation rules. (the base64 string will start with a '/' which is translated into '.')  Unfortunately expansion items that being with a '.' have special significance to the decoding routine, as we see on line 212 of the same file.  A valid node will be treated as a depth encoding, this will probably hose the tree.

The solution I'm using in the ExpansionTree product is to use '_' instead of '.'; this is safe because a depth encoding can never appear at the beginning of an expansion encoding (assuring they are safe for use in URLs, should somebody want to extend the code to do so), additionally a node id encoded with b2a can never begin with '_' because '_' is the translated character '=' from a base64 string, and '=' only appears at the *end* of base64 strings as padding.

example:
>>> from string import maketrans, translate
>>> from binascii import b2a_base64
>>> a2u_map = maketrans("+/=", "-._")
>>> def b2a(b):
...     "Encode 'b' into a string safe for use in cookies, queries, and URLs."
...     return translate(b2a_base64(str(b))[:-1], a2u_map)
... 
>>> b2a('überbug!')
'.GJlcmJ1ZyE_'

Line numbers mentioned are from Zope CVS as of a few days ago.
==============================================================



From zope-coders@zope.org  Thu Oct  3 22:41:50 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Thu, 03 Oct 2002 17:41:50 -0400
Subject: [ZCM] [ZC] 603/ 2 Accept "Das ZTUtils.SimpleTree Überbug"
Message-ID: <E17xDjC-0002wc-00@mail.python.org>

Issue #603 Update (Accept) "Das ZTUtils.SimpleTree Überbug"
 Status Accepted, Zope/bug+solution low
To followup, visit:
  http://collector.zope.org/Zope/603

==============================================================
= Accept - Entry #2 by mj on Oct 3, 2002 5:41 pm

 Status: Pending => Accepted

 Supporters added: mj

Excellent diagnosis! Like the example too :)

I'll check in a fix, as I am kneedeep into ZTUtils.Tree right now anyway.
________________________________________
= Request - Entry #1 by Anonymous User on Oct 3, 2002 5:14 pm

In ZTUtils.py on line 194 the '.' character is used to denote the depth of the following node in the encoded expansion.  An obscure bug occurs when the node's id as obtained by Tree.getId() has its first 6 bits set, this will cause the b2a function to encode a node id which starts with a '.' due to the translation rules. (the base64 string will start with a '/' which is translated into '.')  Unfortunately expansion items that being with a '.' have special significance to the decoding routine, as we see on line 212 of the same file.  A valid node will be treated as a depth encoding, this will probably hose the tree.

The solution I'm using in the ExpansionTree product is to use '_' instead of '.'; this is safe because a depth encoding can never appear at the beginning of an expansion encoding (assuring they are safe for use in URLs, should somebody want to extend the code to do so), additionally a node id encoded with b2a can never begin with '_' because '_' is the translated character '=' from a base64 string, and '=' only appears at the *end* of base64 strings as padding.

example:
>>> from string import maketrans, translate
>>> from binascii import b2a_base64
>>> a2u_map = maketrans("+/=", "-._")
>>> def b2a(b):
...     "Encode 'b' into a string safe for use in cookies, queries, and URLs."
...     return translate(b2a_base64(str(b))[:-1], a2u_map)
... 
>>> b2a('überbug!')
'.GJlcmJ1ZyE_'

Line numbers mentioned are from Zope CVS as of a few days ago.
==============================================================



From zope-coders@zope.org  Thu Oct  3 22:51:05 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Thu, 03 Oct 2002 17:51:05 -0400
Subject: [ZCM] [ZC] 603/ 3 Resolve "Das ZTUtils.SimpleTree Überbug"
Message-ID: <E17xDs9-0006na-00@mail.python.org>

Issue #603 Update (Resolve) "Das ZTUtils.SimpleTree Überbug"
 Status Resolved, Zope/bug+solution low
To followup, visit:
  http://collector.zope.org/Zope/603

==============================================================
= Resolve - Entry #3 by mj on Oct 3, 2002 5:51 pm

 Status: Accepted => Resolved

Checked into CVS for 2.6. Thanks!
________________________________________
= Accept - Entry #2 by mj on Oct 3, 2002 5:41 pm

 Status: Pending => Accepted

 Supporters added: mj

Excellent diagnosis! Like the example too :)

I'll check in a fix, as I am kneedeep into ZTUtils.Tree right now anyway.
________________________________________
= Request - Entry #1 by Anonymous User on Oct 3, 2002 5:14 pm

In ZTUtils.py on line 194 the '.' character is used to denote the depth of the following node in the encoded expansion.  An obscure bug occurs when the node's id as obtained by Tree.getId() has its first 6 bits set, this will cause the b2a function to encode a node id which starts with a '.' due to the translation rules. (the base64 string will start with a '/' which is translated into '.')  Unfortunately expansion items that being with a '.' have special significance to the decoding routine, as we see on line 212 of the same file.  A valid node will be treated as a depth encoding, this will probably hose the tree.

The solution I'm using in the ExpansionTree product is to use '_' instead of '.'; this is safe because a depth encoding can never appear at the beginning of an expansion encoding (assuring they are safe for use in URLs, should somebody want to extend the code to do so), additionally a node id encoded with b2a can never begin with '_' because '_' is the translated character '=' from a base64 string, and '=' only appears at the *end* of base64 strings as padding.

example:
>>> from string import maketrans, translate
>>> from binascii import b2a_base64
>>> a2u_map = maketrans("+/=", "-._")
>>> def b2a(b):
...     "Encode 'b' into a string safe for use in cookies, queries, and URLs."
...     return translate(b2a_base64(str(b))[:-1], a2u_map)
... 
>>> b2a('überbug!')
'.GJlcmJ1ZyE_'

Line numbers mentioned are from Zope CVS as of a few days ago.
==============================================================



From zope-coders@zope.org  Fri Oct  4 03:32:39 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Thu, 03 Oct 2002 22:32:39 -0400
Subject: [ZCM] [ZC] 606/ 2 Resolve "unlimited header length == trivial DoS"
Message-ID: <E17xIGd-0000YI-00@mail.python.org>

Issue #606 Update (Resolve) "unlimited header length == trivial DoS"
 ** Security Related ** (Public)
 Status Resolved, ZServer/bug critical
To followup, visit:
  http://collector.zope.org/Zope/606

==============================================================
= Resolve - Entry #2 by Brian on Oct 3, 2002 10:32 pm

 Status: Pending => Resolved

Thanks - I've fixed this for the 2.6 release and the next 
2.5 bug fix release.

-Brian
________________________________________
= Request - Entry #1 by Anonymous User on Oct 3, 2002 6:44 pm

In short, here's the cheesiest example ever:

$ yes | telnet myzopehost.example.com zopeport

Now go watch the process size on myzopehost.example.com.
ZServer should enforce a header length limit, not doing so leads to deep deep hurting.

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



From zope-coders@zope.org  Fri Oct  4 07:45:02 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Fri, 04 Oct 2002 02:45:02 -0400
Subject: [ZCM] [ZC] 607/ 1 Request "pcgi returns (103) unable to verify if process is running "
Message-ID: <E17xMCs-0007Uh-00@mail.python.org>

Issue #607 Update (Request) "pcgi returns (103) unable to verify if process is running "
 Status Pending, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/607

==============================================================
= Request - Entry #1 by djay on Oct 4, 2002 2:44 am

Until recently this setup was working fine (for several months) and now pcgi-wrapper.exe is returning "(103) unable to verify if process is running". The zope server is directly accessable via http. The PCGI port is being listened to by the zope process. The configuration file is correct and a similar setup is working on another server. The process id in the PID file is correct.

Rebooting the machine fixes the problem temporarily but soon after the problem kicks in again. Just restarting zope seems to make no difference. 

We're at a loss as to what can be the cause of this or how to fix this, hense this trouble ticket. We have integrated with IIS authentication so direct zope http serving is not an option. Currently our intranet site has been unavailable for serveral days while we try to work this out. Any help or fixes in this area would be greatly appreciated. Here is the pcgi file

 #!C:\Program Files\Zope\2.5.1\pcgi\win32\pcgi-wrapper.exe
 #
 # This PCGI info file was generated automatically by
 # the Zope installer. See the file doc/WEBSERVER.txt
 # for more information on setting up PCGI support.

 PCGI_NAME=Zope
 PCGI_PORT=8090
 PCGI_MODULE_PATH=C:\Program Files\Zope\2.5.1\lib\python\Zope
 PCGI_PUBLISHER=C:\Program Files\Zope\2.5.1\pcgi\pcgi_publisher.py
 PCGI_EXE=C:\Program Files\Zope\2.5.1\bin\python.exe
 PCGI_SOCKET_FILE=C:\Program Files\Zope\2.5.1\var\pcgi.soc
 PCGI_PID_FILE=C:\Program Files\Zope\2.5.1\var\pcgi.pid
 PCGI_ERROR_LOG=C:\Program Files\Zope\2.5.1\var\pcgi.log
 PCGI_DISPLAY_ERRORS=1
 BOBO_REALM=Zope
 BOBO_DEBUG_MODE=1
 INSTANCE_HOME=C:\Program Files\Zope\2.5.1

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



From zope-coders@zope.org  Fri Oct  4 07:55:17 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Fri, 04 Oct 2002 02:55:17 -0400
Subject: [ZCM] [ZC] 606/ 3 Comment "unlimited header length == trivial DoS"
Message-ID: <E17xMMn-0003ti-00@mail.python.org>

Issue #606 Update (Comment) "unlimited header length == trivial DoS"
 ** Security Related ** (Public)
 Status Resolved, ZServer/bug critical
To followup, visit:
  http://collector.zope.org/Zope/606

==============================================================
= Comment - Entry #3 by htrd on Oct 4, 2002 2:55 am

Brian has resolved this particular case, but it is worth pointing out that medusa has numerous other denial of service vulnerabilities. Essentially, it appears that medusa was not designed to guard against this type of abuse.

If you want to protect your zope against similar abuses today then the only option today is use a front-end proxy to sanitize the http conversation. Squid works well for me, others have reported success with Apache.mod_proxy

________________________________________
= Resolve - Entry #2 by Brian on Oct 3, 2002 10:32 pm

 Status: Pending => Resolved

Thanks - I've fixed this for the 2.6 release and the next 
2.5 bug fix release.

-Brian
________________________________________
= Request - Entry #1 by Anonymous User on Oct 3, 2002 6:44 pm

In short, here's the cheesiest example ever:

$ yes | telnet myzopehost.example.com zopeport

Now go watch the process size on myzopehost.example.com.
ZServer should enforce a header length limit, not doing so leads to deep deep hurting.

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



From zope-coders@zope.org  Fri Oct  4 08:44:28 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Fri, 04 Oct 2002 03:44:28 -0400
Subject: [ZCM] [ZC] 608/ 1 Request "VHM and ZCatalog absolute paths"
Message-ID: <E17xN8O-0003pJ-00@mail.python.org>

Issue #608 Update (Request) "VHM and ZCatalog absolute paths"
 Status Pending, Catalog/bug medium
To followup, visit:
  http://collector.zope.org/Zope/608

==============================================================
= Request - Entry #1 by Anonymous User on Oct 4, 2002 3:44 am

CatalogPathAware works very well for ZClasses under Virtual Host Monster. Object paths do not include the folder that VHM points to, if <dtml-call reindex_object> is used when creating the ZClass instance. Also when changing ZClass instance properties and running <dtml-call reindex_object>, object paths are ok.

But when ZMI is used to mass-catalog (Find Objects tab, Advanced/Update Catalog tab), the folder is always added. Objects in the catalog have ABSOLUTE paths, i.e. paths which include the container folder which should be hidden by VHM. This is IMHO incorrect.
==============================================================



From zope-coders@zope.org  Fri Oct  4 16:02:43 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Fri, 04 Oct 2002 11:02:43 -0400
Subject: [ZCM] [ZC] 605/ 3 Resolve "potential DoS in ZTUtils' Tree code"
Message-ID: <E17xTyV-0002Oz-00@mail.python.org>

Issue #605 Update (Resolve) "potential DoS in ZTUtils' Tree code"
 ** Security Related ** (Public)
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/605

==============================================================
= Resolve - Entry #3 by mj on Oct 4, 2002 11:02 am

 Status: Accepted => Resolved

Fix checked into 2.5 and 2.6 branches, and the trunk.
________________________________________
= Accept_confidential - Entry #2 by mj on Oct 4, 2002 10:28 am

 Status: Pending => Accepted

 Supporters added: mj

Okay, I'll put in a hard limit for the string length.

As the ZTUtils trees are always dynamic, and we cannot expect people to go and tell it the number of nodes the tree may have, we can only limit the length of the string to decode.

We'll set the limit to 8K for now. A fully expanded tree with an average depth of 10 will still allow some 340 expansion ids in the string, which would make a pretty big tree. This kind of state encoding could only be passed in through a POST anyway. If you need to encode the state of a larger tree, you'll have to resort to using a SESSION, where encoding the expansion state wouldn't even be needed.
________________________________________
= Request - Entry #1 by Anonymous User on Oct 3, 2002 6:38 pm

Keeping with the theme of my last tree-related DoS attack, we now try to exploit the ZTUtils code.  (Truth be known I found this one first, but its not quite as bad as its much easier to fix.)

ZTUtils/Tree.py encodes expansions in ':' delimited sequences.  The decoding process is relatively in-expensive involving only a dictionary and a list, and a few references, but by handing really long expansion encodings to the decoder you can nickel & dime your machine to death.  For example consider the "encoding" as offered with:

$ w3m -cookie "tree-state="`perl -e 'print "A:"x50000;'`"A" http://example.com/page/with/zt-tree

Luckily this bug is largely mitigated by a few external factors.  1) most web servers limit the header length on incoming requests (apache uses 4k by default IIRC)
2) zlib compression isn't supported in zlib so you can't send a zip bomb.

Unfortunately ZServer isn't in the category of "most" web servers. (thats my next bug, *sigh*)  So people using ZServer on a bare wire to the net, and the ZTUtils tree code are quite vulnerable to attack.

The workaround I developed for the ExpansionTree Product was to enforce limits on the expasion encoding content, specifically on the number of what I term "expansion ids".  An expansion id is an element of an expansion encoding which may either be a node id or a depth encoding of the following node.  I count() the number of ':' characters in the expansion encoding and raise an exception if they are over a user supplied limit.  Reasonable limits for static trees are easy to calculate using the worst-case scenario tree consisting solely of a root node and N children. (I define worst-case as a tree with the most possible depth expansion ids per node ids.) The equation is simply 2N-2 (and I tend to let a slop of 1 roll around in my conditional so people who expand a tree out all the way can actually close it again, but I digress).
Dynamic trees aren't quite as easy, you basically have to just define an upper growth limit that you know won't swamp your machine with the calculations.  Anyway attack strings over the limit will be caught this way before the costly data structures are built in the decoding process, effectively eliminating the attack vector.

Limits are poorly documented in my ExpansionTree product because I wanted to give ZC a chance to fix the the ZTUtils code before I explained why they existed in  my code in depth.  Anyone who thinks about web security on a regular basis though is gonna be able to figure it out should they read my docs (which lets face it, is unlikely).

Anyhow, thats my workaround, if you have other ideas I'd be happy to know about them.
==============================================================



From zope-coders@zope.org  Sat Oct  5 12:28:00 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Sat, 05 Oct 2002 07:28:00 -0400
Subject: [ZCM] [ZC] 609/ 1 Request "Possible leak detected"
Message-ID: <E17xn6G-0001xX-00@mail.python.org>

Issue #609 Update (Request) "Possible leak detected"
 Status Pending, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/609

==============================================================
= Request - Entry #1 by ctheune on Oct 5, 2002 7:27 am

Hi. One of our Zope Servers which is mainly spoken to
via XML-RPC seems to leak. We are only using standard Zope, with ZMySQLDA as the only addtion . The server mainly does conversion of data from the SQL server to some apps that ask him via XMLRPC.

The leak looks like this: After an uptime of 10 hours
we have about 240.000 Acquisition.ImplicitAcquirerWrapper
and 25.000 of each of those (the relation of 10:1 seems to be stable): 

- Products.StandardCacheManagers.RAMCacheManager.CacheEntry
- ZServer.HTTPResponse.ZServerHTTPResponse
- ZPublisher.xmlrpc.Response

I can currently only image two different reasons:

a) We have turned on heavy caching of the Z SQL Methods
b) XMLRPC leaks

I have no idea how to debug this, so i can't provide you further information for now.

Cheers
Christian

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



From zope-coders@zope.org  Mon Oct  7 22:46:13 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Mon, 07 Oct 2002 17:46:13 -0400
Subject: [ZCM] [ZC] 542/ 2 Comment "manage.addDocument creates methods"
Message-ID: <E17yfhd-0007hf-00@mail.python.org>

Issue #542 Update (Comment) "manage.addDocument creates methods"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/542

==============================================================
= Comment - Entry #2 by gregn on Oct 7, 2002 5:46 pm

This also happens when the function is called from a method, i.e.:

<dtml-call "manage_addDocument('hi2','display a greeting','Hello world!')">

adds a document. Attempts to assign properties to the new object fail.

It appears to be a long-running bug, as I've encountered it in 
Zope 2.4.3 running on Solaris.


________________________________________
= Request - Entry #1 by Anonymous User on Aug 27, 2002 6:36 pm

The manage.addDocument function when called from a python script creates a DTML Method instead of a DTML Document. I have not tested the function from other types of documents. The manage.addDTMLMethod also adds a method.
==============================================================



From zope-coders@zope.org  Tue Oct  8 02:59:42 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Mon, 07 Oct 2002 21:59:42 -0400
Subject: [ZCM] [ZC] 542/ 3 Reject "manage.addDocument creates methods"
Message-ID: <E17yjew-0004Sh-00@mail.python.org>

Issue #542 Update (Reject) "manage.addDocument creates methods"
 Status Rejected, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/542

==============================================================
= Reject - Entry #3 by Caseman on Oct 7, 2002 9:59 pm

 Status: Pending => Rejected

manage_addDocument is a deprecated api, which existed before there even were DTML documents. It is there only for backward compatibility.

Instead use manage_addDTMLDocument
________________________________________
= Comment - Entry #2 by gregn on Oct 7, 2002 5:46 pm

This also happens when the function is called from a method, i.e.:

<dtml-call "manage_addDocument('hi2','display a greeting','Hello world!')">

adds a document. Attempts to assign properties to the new object fail.

It appears to be a long-running bug, as I've encountered it in 
Zope 2.4.3 running on Solaris.


________________________________________
= Request - Entry #1 by Anonymous User on Aug 27, 2002 6:36 pm

The manage.addDocument function when called from a python script creates a DTML Method instead of a DTML Document. I have not tested the function from other types of documents. The manage.addDTMLMethod also adds a method.
==============================================================



From zope-coders@zope.org  Tue Oct  8 15:42:55 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 08 Oct 2002 10:42:55 -0400
Subject: [ZCM] [ZC] 542/ 4 Comment "manage.addDocument creates methods"
Message-ID: <E17yvZX-00036F-00@mail.python.org>

Issue #542 Update (Comment) "manage.addDocument creates methods"
 Status Rejected, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/542

==============================================================
= Comment - Entry #4 by gregn on Oct 8, 2002 10:42 am

You're right that it's deprecated, and that we should all use addDTMLDocument. But if it's truly deprecated, it should simply fail; it shouldn't have counterintuitive functionality. There is a problem in ~/lib/python/Products/OFSP/__init__.py at line 50:

49:   legacy=(
50:       ('manage_addDocument', OFS.DTMLMethod.addDTMLMethod),
51:       ('manage_addDTMLMethod', OFS.DTMLMethod.addDTMLMethod),
52:          )

This is where addDocument is aliased to addDTMLMethod rather than to addDTMLDocument, and what's causing all the problems. It would seem to make sense to either delete this, so addDocument fails gracefully, or to correct this so it works right.

Can we reactivate this issue?  Thanks.
________________________________________
= Reject - Entry #3 by Caseman on Oct 7, 2002 9:59 pm

 Status: Pending => Rejected

manage_addDocument is a deprecated api, which existed before there even were DTML documents. It is there only for backward compatibility.

Instead use manage_addDTMLDocument
________________________________________
= Comment - Entry #2 by gregn on Oct 7, 2002 5:46 pm

This also happens when the function is called from a method, i.e.:

<dtml-call "manage_addDocument('hi2','display a greeting','Hello world!')">

adds a document. Attempts to assign properties to the new object fail.

It appears to be a long-running bug, as I've encountered it in 
Zope 2.4.3 running on Solaris.


________________________________________
= Request - Entry #1 by Anonymous User on Aug 27, 2002 6:36 pm

The manage.addDocument function when called from a python script creates a DTML Method instead of a DTML Document. I have not tested the function from other types of documents. The manage.addDTMLMethod also adds a method.
==============================================================



From zope-coders@zope.org  Tue Oct  8 17:06:19 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 08 Oct 2002 12:06:19 -0400
Subject: [ZCM] [ZC] 610/ 1 Request "HTTP_TRACEBACK_STYLE not documented"
Message-ID: <E17ywsF-0004dI-00@mail.python.org>

Issue #610 Update (Request) "HTTP_TRACEBACK_STYLE not documented"
 Status Pending, Zope/doc request medium
To followup, visit:
  http://collector.zope.org/Zope/610

==============================================================
= Request - Entry #1 by efge on Oct 8, 2002 12:06 pm

HTTP_TRACEBACK_STYLE should be documented in doc/ENVIRONMENT.txt

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



From zope-coders@zope.org  Tue Oct  8 17:46:44 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 08 Oct 2002 12:46:44 -0400
Subject: [ZCM] [ZC] 598/ 2 Comment "diacriticals in ZMI"
Message-ID: <E17yxVM-0008Gy-00@mail.python.org>

Issue #598 Update (Comment) "diacriticals in ZMI"
 Status Pending, Zope/bug+solution low
To followup, visit:
  http://collector.zope.org/Zope/598

==============================================================
= Comment - Entry #2 by efge on Oct 8, 2002 12:46 pm

Please state what the problem is, before providing a solution
(which is a huge .tgz)...

Also be aware that most diacritical/Unicode problems should be
fixed in Zope 2.6b1.

________________________________________
= Request - Entry #1 by Anonymous User on Oct 1, 2002 7:05 am

PLease take look at 

http://www.zope.org/Members/lukesh/diacriticals/

Somebody from mail correspondence reccomend me to put this problem here, so I put:

On Qui 19 Set 2002 01:20, Jaroslav Lukesh wrote:
| I have same problem with MSIE in czech language. Try to define codepage in
| zope system files as suggested by me in my previous reply (look for that!).
| I need to define windows-1250 codepage (czech lang) like that:
|
| <meta http-equiv="Content-Type" content="text/html; charset=windows-1250">
| <meta http-equiv="Content-Language" content="cz">
|
| add these lines to <head> tag.

A suggestion: this could be put on the collector with a suggestion to create a 
way to make this configurable without needing to modify the zope source by 
hand, eg: providing these values as an environment variable, or trying to 
guess them from the -L <locale> option of z2.py.

[]'s

-- 
Sidnei da Silva (dreamcatcher) <sidnei@x3ng.com.br>

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



From zope-coders@zope.org  Tue Oct  8 23:27:46 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 08 Oct 2002 18:27:46 -0400
Subject: [ZCM] [ZC] 292/ 4 Resolve "PythonScript WebDAV PUT & Namespace Binding Bug"
Message-ID: <E17z2pO-0002tE-00@mail.python.org>

Issue #292 Update (Resolve) "PythonScript WebDAV PUT & Namespace Binding Bug"
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/292

==============================================================
= Resolve - Entry #4 by evan on Oct 8, 2002 6:26 pm

 Status: Accepted => Resolved

This should be fixed in the trunk and 2.6 branch of CVS
________________________________________
= Comment - Entry #3 by chrisw on Sep 17, 2002 5:34 am

I create it with a PUT_Factory just like I wrong for Paul at:
http://www.zope.org/Members/glpb/dwhowto

Sorry for the lack of response up til now, I didn't get notification that you had responded :-(

Chris
________________________________________
= Assign - Entry #2 by ajung on Mar 27, 2002 12:43 pm

 Status: Pending => Accepted

 Supporters added: ajung, andreasjung

PUTing a  file 'xx.py' through WebDAV creates a File object
inside Zope for me. How do you create a PyScript through WebDAV?

-aj
________________________________________
= Request - Entry #1 by chrisw on Mar 13, 2002 1:14 pm

When I create a Script(Python) via a WebDAV PUT,
The namespace does not get bound, regardless of the appropriate comments being included.

The only way to actually bind the namespace is to go to the ZMI bindings tab and bind it there.

Please fix :-)
==============================================================



From zope-coders@zope.org  Tue Oct  8 23:45:21 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 08 Oct 2002 18:45:21 -0400
Subject: [ZCM] [ZC] 323/ 2 Resolve "underscore in request var seems to cause problems in ZPT"
Message-ID: <E17z36P-0000Zs-00@mail.python.org>

Issue #323 Update (Resolve) "underscore in request var seems to cause problems in ZPT"
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/323

==============================================================
= Resolve - Entry #2 by evan on Oct 8, 2002 6:45 pm

 Status: Pending => Resolved

Fixed in trunk and 2.6 branch of CVS
________________________________________
= Request - Entry #1 by djay on Mar 30, 2002 12:07 am

This doesn't work

tal:attributes="value request/__ac_name|default">

but this does

tal:attributes="value python:request.has_key('__ac_name') and request['__ac_name'] or default"

which is a pity because the later is much less elegant and it is fustrating since the former is supposed to work (as far as I know).


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



From zope-coders@zope.org  Wed Oct  9 15:29:58 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Wed, 09 Oct 2002 10:29:58 -0400
Subject: [ZCM] [ZC] 611/ 1 Request "Spelling error in undo.dtml"
Message-ID: <E17zHqY-00011p-00@mail.python.org>

Issue #611 Update (Request) "Spelling error in undo.dtml"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/611

==============================================================
= Request - Entry #1 by Anonymous User on Oct 9, 2002 10:29 am

Zope/lib/python/App/dtml/undo.dtml, line 10-11:
"You can revert the application 
to a &quot;snapshot&quot; of it's state at a previous point in time."

Should be "its state" unless you mean "it is state"

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



From zope-coders@zope.org  Wed Oct  9 15:41:07 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Wed, 09 Oct 2002 10:41:07 -0400
Subject: [ZCM] [ZC] 372/ 2 Resolve "tal:attributes fails with error in image tag"
Message-ID: <E17zI1L-0002Op-00@mail.python.org>

Issue #372 Update (Resolve) "tal:attributes fails with error in image tag"
 Status Resolved, Zope/bug low
To followup, visit:
  http://collector.zope.org/Zope/372

==============================================================
= Resolve - Entry #2 by evan on Oct 9, 2002 10:40 am

 Status: Pending => Resolved

Fixed in trunk and 2.6 branch of CVS
________________________________________
= Request - Entry #1 by Anonymous User on May 1, 2002 6:35 pm

<img tal:replace="structure container/images/image.gif" tal:attributes="border string:1">

i get the following error when i load the page

Error Type: AttributeError
Error Value: Context instance has no attribute 'getCompilerError'

i've been using the tag method as a work around, but people have told me that this tag *should* work as is, hence this bug report.
==============================================================



From zope-coders@zope.org  Wed Oct  9 18:35:07 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Wed, 09 Oct 2002 13:35:07 -0400
Subject: [ZCM] [ZC] 577/ 2 Resolve "Make ZTUtils Iterator support simple iterator classes"
Message-ID: <E17zKjj-0002D4-00@mail.python.org>

Issue #577 Update (Resolve) "Make ZTUtils Iterator support simple iterator classes"
 Status Resolved, Zope/feature+solution medium
To followup, visit:
  http://collector.zope.org/Zope/577

==============================================================
= Resolve - Entry #2 by evan on Oct 9, 2002 1:34 pm

 Status: Pending => Resolved

Fixed in CVS trunk, for 2.7 release
________________________________________
= Request - Entry #1 by stevea on Sep 20, 2002 10:17 am


Uploaded:  "diff.txt"
 - http://collector.zope.org/Zope/577/diff.txt/view
See also bug http://collector.zope.org/Zope/573

I propose to improve Iterator.py so that it can handle simple classes that define an __iter__ generator, such as:

  from __future__ import generators

  class Foo:
    def __iter__(self):
      for i in 1,2,3,4:
        yield i

Currently, when running Zope on Python 2.2, instances of this class cannot be used in a tal:repeat.

My patch fixes this. However, I'm not sure of a good way to write a test that works for Python2.1 and Python2.2 because of needing to use the "yeild" syntax. Perhaps use an eval or something.

I've uploaded the patch.
==============================================================



From zope-coders@zope.org  Wed Oct  9 18:39:10 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Wed, 09 Oct 2002 13:39:10 -0400
Subject: [ZCM] [ZC] 436/ 2 Resolve "aq_parent is not Available in ZPT when Content-Type is not text/html"
Message-ID: <E17zKne-0002vY-00@mail.python.org>

Issue #436 Update (Resolve) "aq_parent is not Available in ZPT when Content-Type is not text/html"
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/436

==============================================================
= Resolve - Entry #2 by evan on Oct 9, 2002 1:39 pm

 Status: Pending => Resolved

Fixed in trunk and 2.6 branch of CVS
________________________________________
= Request - Entry #1 by Anonymous User on Jun 17, 2002 7:07 pm

To replicate the error create Folder. inside it create a Page Template with a text:
------------------------------------
<test xmlns:tal="http://xml.zope.org/namespaces/tal">
  <parent tal:content="here/aq_parent"
   tal:on-error="error">parent</parent>
</test>
------------------------------------
If Content-Type is set to "text/html" the code will work. If Content-Type is set to "text/xml" (or anything besides text/html) the error: "aq_parent not found in u'here/aq_parent'" will be displayed.
------------------------------------
Note: if "here/aq_parent" is replaced with "python:here.aq_parent" the code works fine for any Contnet-Type. 
==============================================================



From zope-coders@zope.org  Thu Oct 10 00:00:58 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Wed, 09 Oct 2002 19:00:58 -0400
Subject: [ZCM] [ZC] 529/ 2 Comment "Using ecryption with User Folder damages accounts"
Message-ID: <E17zPp4-000618-00@mail.python.org>

Issue #529 Update (Comment) "Using ecryption with User Folder damages accounts"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/529

==============================================================
= Comment - Entry #2 by chrisw on Oct 9, 2002 7:00 pm

I've observed this too. Anyone got any ideas?
________________________________________
= Request - Entry #1 by Anonymous User on Aug 20, 2002 5:59 pm

The root user folder defaults to clear text password store. Under Properties, there is a checkbox to switch to encrypted storage. Click it, then save. Then click on Update Existing Passwords. The operation completes and you are logged out which is fine.

You will not be able to log back in however. All the user passwords are trashed, including admin. You will need to resort to the emergency user to get things back up and running.

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



From zope-coders@zope.org  Thu Oct 10 13:47:17 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Thu, 10 Oct 2002 08:47:17 -0400
Subject: [ZCM] [ZC] 200/ 6 Comment "2.5.0 on py 2.2 crashes repeatedly"
Message-ID: <E17zcij-0005aW-00@mail.python.org>

Issue #200 Update (Comment) "2.5.0 on py 2.2 crashes repeatedly"
 Status Deferred, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/200

==============================================================
= Comment - Entry #6 by gvanrossum on Oct 10, 2002 8:46 am

I expect this is fixed in Python 2.2.2.  Can you try this with the 2.2.2b1 release?
________________________________________
= Comment - Entry #5 by zigg on May 30, 2002 9:22 am

On 2.2.1, on Solaris:

> (gdb) bt
> #0  initializeBaseExtensionClass (self=0x0)
>     at ../Components/ExtensionClass/src/ExtensionClass.c:1504
> #1  0xfe5c6e30 in export_type (dict=0x378668, name=0x378628 "", typ=0x0)
>     at ../Components/ExtensionClass/src/ExtensionClass.c:3488
> #2  0x285e4 in type_call (type=0xfe5c6e18, args=0x378628, kwds=0x0)
>     at Objects/typeobject.c:174
> #3  0x83920 in PyObject_Call (func=0xfe5c6e18, arg=0x378628, kw=0x0)
>     at Objects/abstract.c:1684
> #4  0x4a0dc in PyEval_CallObjectWithKeywords (func=0xdfa3c, arg=0x378628, 
>     kw=0x0) at Python/ceval.c:3049
> #5  0x82c34 in PyObject_CallFunction (callable=0xdfa3c, format=0x378628 "")
>     at Objects/abstract.c:1725
> #6  0x4b224 in build_class (methods=0x378130, bases=0x3780a0, name=0x374e70)
>     at Python/ceval.c:3603
> #7  0x46d3c in eval_frame (f=0x1add50) at Python/ceval.c:1522
> #8  0x494bc in PyEval_EvalCodeEx (co=0x372568, globals=0x3757a8, 
>     locals=0xed538, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
>     defcount=0, closure=0x0) at Python/ceval.c:2585
> #9  0x4bdb4 in PyEval_EvalCode (co=0x372568, globals=0x372388, locals=0x372388)
>     at Python/ceval.c:483

(don't know how much more of this is important, will try 2.3 when I get a chance)

________________________________________
= Comment - Entry #4 by gvanrossum on May 29, 2002 11:15 pm

Have you tried this on Linux?  If it doesn't occur
on Linux, but does occur on Solaris and *BSD, I
strongly expect it's writing a malloc'ed block out
of bounds -- I know BSD's malloc is much more
picky.  Could you try with 2.2.1?  It fixes some
bugs.

More work, but perhaps leading to the cause, could
you try with "2.3" (== current CVS), pymalloc
enabled (which it is by default in 2.3), in debug
mode, and with the symbol PYMALLOC_DEBUG defined
manually?  That enables heavy malloc debugging
which often points to the culprit.

Tim Peters can provide much better info on
how to enable.  Alternatively, the comments in
obmalloc.c may lead the way.

(It may not work in debug mode, but you can use
PYMALLOC_DEBUG even outside debug mode.  I vaguely
remember that I couldn't get 3rd party extension
linkage working in debug mode, but I'm not sure
about this.)

________________________________________
= Comment - Entry #3 by zigg on Feb 6, 2002 2:29 pm


Uploaded:  "do_py_better.patch"
 - http://collector.zope.org/Zope/200/do_py_better.patch/view
Here's a better do_py.patch; the first one might have used the wrong python to build... :-)

> Zope is NOT supported on Python 2.2 at this time; so caveat emptor.

Aw, you're no fun. :-)

> You probably built python 2.2 with pymalloc installed; turn it off -- it
>   causes problems with extensionclass.

No dice.  Tried --without-pymalloc and it's still crashing.

> Your gdb trace also shows that your core file doesn't match the
>   executable you used; so it's not necessarily valid.

gdb lies like a dog. :-)  In any event, this wasn't the case, as I pointed it to 'python' instead of 'python2.2' and got the same issue.

Anyway, defer away.  Looks like OpenBSD 3.1 is going to have to ship with two versions of python :-/
________________________________________
= Defer - Entry #2 by matt on Feb 6, 2002 2:04 pm

 Status: Pending => Deferred

Zope is NOT supported on Python 2.2 at this time; so caveat emptor.

You probably built python 2.2 with pymalloc installed; turn it off -- it causes problems with extensionclass.

Your gdb trace also shows that your core file doesn't match the executable you used; so it's not necessarily valid.
________________________________________
= Request - Entry #1 by zigg on Feb 6, 2002 1:53 pm


Uploaded:  "do_py.patch"
 - http://collector.zope.org/Zope/200/do_py.patch/view
I get this on both Solaris 2.8 and OpenBSD 3.0-current, although Solaris 2.8 gives slightly more detailed gdb information.  z2.py appears to be crashing when executing 'import PersistentMapping', and zdaemon will restart it over, and over, and over again...

Attached is a little patch I made up that will convert Setup files to distutils setup.py's on the fly, so that you can compile Zope 2.5.0 with Python 2.2.  (Incidentally, yes I did try it with the 'Makefile.pre.in' trick advertised elsewhere, and got the same results.)

Here's the gdb backtrace.  Let me know if you want more info, I can certainly get more:

> Script started on Wed Feb 06 13:47:09 2002
> $ gdb ../bin/python2.2 core

> GNU gdb 5.0

> Copyright 2000 Free Software Foundation, Inc.

> GDB is free software, covered by the GNU General Public License, and you are

> welcome to change it and/or distribute copies of it under certain conditions.

> Type "show copying" to see the conditions.

> There is absolutely no warranty for GDB. Type "show warranty" for details.

> This GDB was configured as "sparc-sun-solaris2.8"...

> 

> warning: core file may not match specified executable file.

> Core was generated by `/export/home/b14741/tmp/Zope-2.5.0-src/../bin/python /export/home/b14741/tmp/Zo'.

> Program terminated with signal 9, Killed.

> Reading symbols from /usr/lib/libsocket.so.1...done.

> Loaded symbols for /usr/lib/libsocket.so.1

> Reading symbols from /usr/lib/libnsl.so.1...done.

> Loaded symbols for /usr/lib/libnsl.so.1

> Reading symbols from /usr/lib/libdl.so.1...done.

> Loaded symbols for /usr/lib/libdl.so.1

> Reading symbols from /usr/lib/libpthread.so.1...done.

> Loaded symbols for /usr/lib/libpthread.so.1

> Reading symbols from /usr/lib/libthread.so.1...done.

> Loaded symbols for /usr/lib/libthread.so.1

> Reading symbols from /usr/lib/libm.so.1...done.

> Loaded symbols for /usr/lib/libm.so.1

> Reading symbols from /usr/lib/libc.so.1...done.

> Loaded symbols for /usr/lib/libc.so.1

> Reading symbols from /usr/lib/libmp.so.2...done.

> Loaded symbols for /usr/lib/libmp.so.2

> Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...done.

> Loaded symbols for /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1

> Reading symbols from /export/home/b14741/tmp/lib/python2.2/lib-dynload/strop.so...done.

> Loaded symbols for /export/home/b14741/tmp/lib/python2.2/lib-dynload/strop.so

> Reading symbols from /export/home/b14741/tmp/lib/python2.2/lib-dynload/fcntl.so...done.

> Loaded symbols for /export/home/b14741/tmp/lib/python2.2/lib-dynload/fcntl.so

> Reading symbols from /export/home/b14741/tmp/lib/python2.2/lib-dynload/select.so...done.

> Loaded symbols for /export/home/b14741/tmp/lib/python2.2/lib-dynload/select.so

> Reading symbols from /export/home/b14741/tmp/lib/python2.2/lib-dynload/_socket.so...done.

> Loaded symbols for /export/home/b14741/tmp/lib/python2.2/lib-dynload/_socket.so

> Reading symbols from /usr/lib/libssl.so.0.9.6...done.

> Loaded symbols for /usr/lib/libssl.so.0.9.6

> Reading symbols from /usr/lib/libcrypto.so.0.9.6...done.

> Loaded symbols for /usr/lib/libcrypto.so.0.9.6

> Reading symbols from /export/home/b14741/tmp/lib/python2.2/lib-dynload/errno.so...done.

> Loaded symbols for /export/home/b14741/tmp/lib/python2.2/lib-dynload/errno.so

> Reading symbols from /export/home/b14741/tmp/lib/python2.2/lib-dynload/time.so...done.

> Loaded symbols for /export/home/b14741/tmp/lib/python2.2/lib-dynload/time.so

> Reading symbols from /export/home/b14741/tmp/lib/python2.2/lib-dynload/cStringIO.so...done.

> Loaded symbols for /export/home/b14741/tmp/lib/python2.2/lib-dynload/cStringIO.so

> Reading symbols from /export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ExtensionClass.so...done.

> Loaded symbols for /export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ExtensionClass.so

> Reading symbols from /export/home/b14741/tmp/Zope-2.5.0-src/lib/python/zlib.so...done.

> Loaded symbols for /export/home/b14741/tmp/Zope-2.5.0-src/lib/python/zlib.so

> Reading symbols from /export/home/b14741/tmp/lib/python2.2/lib-dynload/binascii.so...done.

> Loaded symbols for /export/home/b14741/tmp/lib/python2.2/lib-dynload/binascii.so

> Reading symbols from /export/home/b14741/tmp/lib/python2.2/lib-dynload/md5.so...done.

> Loaded symbols for /export/home/b14741/tmp/lib/python2.2/lib-dynload/md5.so

> Reading symbols from /export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB/TimeStamp.so...done.

> Loaded symbols for /export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB/TimeStamp.so

> Reading symbols from /export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB/cPersistence.so...done.

> Loaded symbols for /export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB/cPersistence.so

> Reading symbols from /export/home/b14741/tmp/lib/python2.2/lib-dynload/cPickle.so...done.

> Loaded symbols for /export/home/b14741/tmp/lib/python2.2/lib-dynload/cPickle.so

> #0 initializeBaseExtensionClass (self=0x0)

> at ../Components/ExtensionClass/src/ExtensionClass.c:1504

> 1504 abstract=self->tp_basicsize == sizeof(PyPureMixinObject);

> (gdb) bt

> #0 initializeBaseExtensionClass (self=0x0)

> at ../Components/ExtensionClass/src/ExtensionClass.c:1504

> #1 0xfe61f4b4 in export_type (dict=0x33c7e8, name=0x33c7a8 "", typ=0x0)

> at ../Components/ExtensionClass/src/ExtensionClass.c:3488

> #2 0x2857c in type_call (type=0xfe61f49c, args=0x33c7a8, kwds=0x0)

> at Objects/typeobject.c:158

> #3 0x835a8 in PyObject_Call (func=0xfe61f49c, arg=0x33c7a8, kw=0x0)

> at Objects/abstract.c:1665

> #4 0x49ed4 in PyEval_CallObjectWithKeywords (func=0xdefcc, arg=0x33c7a8, 

> kw=0x0) at Python/ceval.c:3038

> #5 0x828bc in PyObject_CallFunction (callable=0xdefcc, format=0x33c7a8 "")

> at Objects/abstract.c:1706

> #6 0x4b01c in build_class (methods=0x33c2c0, bases=0x33c230, name=0x337f60)

> at Python/ceval.c:3592

> #7 0x46ab4 in eval_frame (f=0x175bb8) at Python/ceval.c:1511

> #8 0x492b4 in PyEval_EvalCodeEx (co=0x3390f0, globals=0x1e7140, 

> locals=0xed258, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 

> defcount=0, closure=0x0) at Python/ceval.c:2574

> #9 0x4bbac in PyEval_EvalCode (co=0x3390f0, globals=0x3391d0, locals=0x3391d0)

> at Python/ceval.c:483

> #10 0x6084c in PyImport_ExecCodeModuleEx (

> name=0xffbebd78 "ZODB.PersistentMapping", co=0x3390f0, 

> pathname=0xffbeb398 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB/PersistentMapping.pyc") at Python/import.c:506

> #11 0x60da0 in load_source_module (name=0xffbebd78 "ZODB.PersistentMapping", 

> pathname=0xffbeb398 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB/PersistentMapping.pyc", fp=0xebc40) at Python/import.c:776

> #12 0x6159c in load_module (name=0xffbebd78 "ZODB.PersistentMapping", 

> fp=0xebc40, 

> buf=0xffbeb888 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB/PersistentMapping.py", type=1) at Python/import.c:1360

> #13 0x62550 in import_submodule (mod=0x1ad360, 

> subname=0xffbebd7d "PersistentMapping", 

> fullname=0xffbebd78 "ZODB.PersistentMapping") at Python/import.c:1899

> #14 0x62050 in load_next (mod=0x1ad360, altmod=0xcf360, p_name=0xffbebd7d, 

> buf=0xffbebd78 "ZODB.PersistentMapping", p_buflen=0xffbebd74)

> at Python/import.c:1755

> #15 0x61b14 in import_module_ex (name=0x0, globals=0x336e00, locals=0x336e00, 

> fromlist=0xcf360) at Python/import.c:1606

> #16 0x61d58 in PyImport_ImportModuleEx (name=0x337f74 "PersistentMapping", 

> globals=0x336e00, locals=0x336e00, fromlist=0xcf360)

> at Python/import.c:1647

> #17 0xab9e4 in builtin___import__ (self=0x0, args=0x3222d0)

> at Python/bltinmodule.c:44

> #18 0xa7954 in PyCFunction_Call (func=0xee200, arg=0x3222d0, kw=0x0)

> at Objects/methodobject.c:101

> #19 0x835a8 in PyObject_Call (func=0xee200, arg=0x3222d0, kw=0xab998)

> at Objects/abstract.c:1665

> #20 0x49ed4 in PyEval_CallObjectWithKeywords (func=0xee200, arg=0x3222d0, 

> kw=0x0) at Python/ceval.c:3038

> #21 0x47620 in eval_frame (f=0x1c0ab8) at Python/ceval.c:1828

> #22 0x492b4 in PyEval_EvalCodeEx (co=0x337e68, globals=0x337b34, 

> locals=0xed258, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 

> defcount=0, closure=0x0) at Python/ceval.c:2574

> #23 0x4bbac in PyEval_EvalCode (co=0x337e68, globals=0x336e00, locals=0x336e00)

> at Python/ceval.c:483

> #24 0x6084c in PyImport_ExecCodeModuleEx (name=0xffbed51d "ZODB", co=0x337e68, 

> pathname=0xffbec648 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB/__init__.pyc") at Python/import.c:506

> #25 0x60da0 in load_source_module (name=0xffbed51d "ZODB", 

> pathname=0xffbec648 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB/__init__.pyc", fp=0xebc30) at Python/import.c:776

> #26 0x6159c in load_module (name=0xffbed51d "ZODB", fp=0xebc30, 

> buf=0xffbecb38 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB/__init__.py", type=1) at Python/import.c:1360

> #27 0x60f18 in load_package (name=0xffbed51d "ZODB", pathname=0x3379e0 "")

> at Python/import.c:833

> #28 0x615e0 in load_module (name=0xffbed51d "ZODB", fp=0x0, 

> buf=0xffbed028 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB", 

> type=5) at Python/import.c:1383

> #29 0x62550 in import_submodule (mod=0xcf360, subname=0xffbed51d "ZODB", 

> fullname=0xffbed51d "ZODB") at Python/import.c:1899

> ---Type <return> to continue, or q <return> to quit---

> #30 0x620a4 in load_next (mod=0x1ad4c8, altmod=0xcf360, p_name=0xffbed51d, 

> buf=0xffbed518 "Zope.ZODB", p_buflen=0xffbed514) at Python/import.c:1759

> #31 0x61b14 in import_module_ex (name=0x0, globals=0x3304f8, locals=0x3304f8, 

> fromlist=0xcf360) at Python/import.c:1606

> #32 0x61d58 in PyImport_ImportModuleEx (name=0x328afc "ZODB", 

> globals=0x3304f8, locals=0x3304f8, fromlist=0xcf360)

> at Python/import.c:1647

> #33 0xab9e4 in builtin___import__ (self=0x0, args=0x115900)

> at Python/bltinmodule.c:44

> #34 0xa7954 in PyCFunction_Call (func=0xee200, arg=0x115900, kw=0x0)

> at Objects/methodobject.c:101

> #35 0x835a8 in PyObject_Call (func=0xee200, arg=0x115900, kw=0xab998)

> at Objects/abstract.c:1665

> #36 0x49ed4 in PyEval_CallObjectWithKeywords (func=0xee200, arg=0x115900, 

> kw=0x0) at Python/ceval.c:3038

> #37 0x47620 in eval_frame (f=0x11c9b8) at Python/ceval.c:1828

> #38 0x492b4 in PyEval_EvalCodeEx (co=0x1d8098, globals=0x3305ec, 

> locals=0xed258, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 

> defcount=0, closure=0x0) at Python/ceval.c:2574

> #39 0x4bbac in PyEval_EvalCode (co=0x1d8098, globals=0x3304f8, locals=0x3304f8)

> at Python/ceval.c:483

> #40 0x6084c in PyImport_ExecCodeModuleEx (name=0xffbeecb8 "Zope", co=0x1d8098, 

> pathname=0xffbedde8 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/Zope/__init__.pyc") at Python/import.c:506

> #41 0x60da0 in load_source_module (name=0xffbeecb8 "Zope", 

> pathname=0xffbedde8 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/Zope/__init__.pyc", fp=0xebc20) at Python/import.c:776

> #42 0x6159c in load_module (name=0xffbeecb8 "Zope", fp=0xebc20, 

> buf=0xffbee2d8 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/Zope/__init__.py", type=1) at Python/import.c:1360

> #43 0x60f18 in load_package (name=0xffbeecb8 "Zope", pathname=0x32a660 "")

> at Python/import.c:833

> #44 0x615e0 in load_module (name=0xffbeecb8 "Zope", fp=0x0, 

> buf=0xffbee7c8 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/Zope", 

> type=5) at Python/import.c:1383

> #45 0x62550 in import_submodule (mod=0xcf360, subname=0xffbeecb8 "Zope", 

> fullname=0xffbeecb8 "Zope") at Python/import.c:1899

> #46 0x62050 in load_next (mod=0xcf360, altmod=0xcf360, p_name=0xffbeecb8, 

> buf=0xffbeecb8 "Zope", p_buflen=0xffbeecb4) at Python/import.c:1755

> #47 0x61b14 in import_module_ex (name=0x0, globals=0x1070d8, locals=0x1070d8, 

> fromlist=0xcf360) at Python/import.c:1606

> #48 0x61d58 in PyImport_ImportModuleEx (name=0x13728c "Zope", 

> globals=0x1070d8, locals=0x1070d8, fromlist=0xcf360)

> at Python/import.c:1647

> #49 0xab9e4 in builtin___import__ (self=0x0, args=0xf6400)

> at Python/bltinmodule.c:44

> #50 0xa7954 in PyCFunction_Call (func=0xee200, arg=0xf6400, kw=0x0)

> at Objects/methodobject.c:101

> #51 0x835a8 in PyObject_Call (func=0xee200, arg=0xf6400, kw=0xab998)

> at Objects/abstract.c:1665

> #52 0x49ed4 in PyEval_CallObjectWithKeywords (func=0xee200, arg=0xf6400, 

> kw=0x0) at Python/ceval.c:3038

> #53 0x47620 in eval_frame (f=0x329660) at Python/ceval.c:1828

> #54 0x492b4 in PyEval_EvalCodeEx (co=0x32d9d0, globals=0x3304d0, 

> locals=0xed258, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 

> defcount=0, closure=0x0) at Python/ceval.c:2574

> #55 0x4bbac in PyEval_EvalCode (co=0x32d9d0, globals=0x1070d8, locals=0x1070d8)

> at Python/ceval.c:483

> #56 0x6b6ac in run_node (n=0xec358, filename=0x32d9d0 "", globals=0x1070d8, 

> locals=0x1070d8, flags=0x0) at Python/pythonrun.c:1083

> #57 0x6b658 in run_err_node (n=0xec358, filename=0x32d9d0 "", 

> globals=0x1070d8, locals=0x1070d8, flags=0x0) at Python/pythonrun.c:1070

> #58 0x6b0e0 in PyRun_String (str=0x32802c "import Zope", start=257, 

> globals=0x1070d8, locals=0x1070d8) at Python/pythonrun.c:1012

> #59 0x4b498 in exec_statement (f=0x142738, prog=0x328018, globals=0x1070d8, 

> locals=0x1070d8) at Python/ceval.c:3672

> #60 0x46864 in eval_frame (f=0x142738) at Python/ceval.c:1467

> #61 0x492b4 in PyEval_EvalCodeEx (co=0x1368d0, globals=0x1aec67, 

> locals=0xed258, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 

> defcount=0, closure=0x0) at Python/ceval.c:2574

> #62 0x4bbac in PyEval_EvalCode (co=0x1368d0, globals=0xfd4e8, locals=0xfd4e8)

> at Python/ceval.c:483

> ---Type <return> to continue, or q <return> to quit---

> #63 0x6b6ac in run_node (n=0xec1d8, filename=0x1368d0 "", globals=0xfd4e8, 

> locals=0xfd4e8, flags=0xffbefae4) at Python/pythonrun.c:1083

> #64 0x6b658 in run_err_node (n=0xec1d8, filename=0x1368d0 "", globals=0xfd4e8, 

> locals=0xfd4e8, flags=0xffbefae4) at Python/pythonrun.c:1070

> #65 0x6b228 in PyRun_FileExFlags (fp=0xebc20, 

> filename=0xffbefce9 "/export/home/b14741/tmp/Zope-2.5.0-src/z2.py", 

> start=1037544, globals=0xfd4e8, locals=0xfd4e8, closeit=1, 

> flags=0xffbefae4) at Python/pythonrun.c:1061

> #66 0x69b9c in PyRun_SimpleFileExFlags (fp=0xebc20, 

> filename=0xffbefce9 "/export/home/b14741/tmp/Zope-2.5.0-src/z2.py", 

> closeit=1, flags=0xffbefae4) at Python/pythonrun.c:689

> #67 0x6ad60 in PyRun_AnyFileExFlags (fp=0xebc20, 

> filename=0xffbefce9 "/export/home/b14741/tmp/Zope-2.5.0-src/z2.py", 

> closeit=1, flags=0xffbefae4) at Python/pythonrun.c:499

> #68 0x1ae6c in Py_Main (argc=3, argv=0xffbefbcc) at Modules/main.c:369

> #69 0x1a69c in main (argc=3, argv=0xffbefbcc) at Modules/python.c:10

> (gdb) quit

> $ exit

> 
> script done on Wed Feb 06 13:47:23 2002

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



From zope-coders@zope.org  Thu Oct 10 14:47:52 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Thu, 10 Oct 2002 09:47:52 -0400
Subject: [ZCM] [ZC] 200/ 7 Resolve "2.5.0 on py 2.2 crashes repeatedly"
Message-ID: <E17zdfM-0003ro-00@mail.python.org>

Issue #200 Update (Resolve) "2.5.0 on py 2.2 crashes repeatedly"
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/200

==============================================================
= Resolve - Entry #7 by zigg on Oct 10, 2002 9:47 am

 Status: Deferred => Resolved

On Solaris, 2.5.1 no longer exhibits this problem with 2.2.2b1.  Yay!

I do not have access to an OpenBSD box I can try this on right now, but I'm going to take Guido's expectation + this result and resolve unless I find out differently.

________________________________________
= Comment - Entry #6 by gvanrossum on Oct 10, 2002 8:46 am

I expect this is fixed in Python 2.2.2.  Can you try this with the 2.2.2b1 release?
________________________________________
= Comment - Entry #5 by zigg on May 30, 2002 9:22 am

On 2.2.1, on Solaris:

> (gdb) bt
> #0  initializeBaseExtensionClass (self=0x0)
>     at ../Components/ExtensionClass/src/ExtensionClass.c:1504
> #1  0xfe5c6e30 in export_type (dict=0x378668, name=0x378628 "", typ=0x0)
>     at ../Components/ExtensionClass/src/ExtensionClass.c:3488
> #2  0x285e4 in type_call (type=0xfe5c6e18, args=0x378628, kwds=0x0)
>     at Objects/typeobject.c:174
> #3  0x83920 in PyObject_Call (func=0xfe5c6e18, arg=0x378628, kw=0x0)
>     at Objects/abstract.c:1684
> #4  0x4a0dc in PyEval_CallObjectWithKeywords (func=0xdfa3c, arg=0x378628, 
>     kw=0x0) at Python/ceval.c:3049
> #5  0x82c34 in PyObject_CallFunction (callable=0xdfa3c, format=0x378628 "")
>     at Objects/abstract.c:1725
> #6  0x4b224 in build_class (methods=0x378130, bases=0x3780a0, name=0x374e70)
>     at Python/ceval.c:3603
> #7  0x46d3c in eval_frame (f=0x1add50) at Python/ceval.c:1522
> #8  0x494bc in PyEval_EvalCodeEx (co=0x372568, globals=0x3757a8, 
>     locals=0xed538, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 
>     defcount=0, closure=0x0) at Python/ceval.c:2585
> #9  0x4bdb4 in PyEval_EvalCode (co=0x372568, globals=0x372388, locals=0x372388)
>     at Python/ceval.c:483

(don't know how much more of this is important, will try 2.3 when I get a chance)

________________________________________
= Comment - Entry #4 by gvanrossum on May 29, 2002 11:15 pm

Have you tried this on Linux?  If it doesn't occur
on Linux, but does occur on Solaris and *BSD, I
strongly expect it's writing a malloc'ed block out
of bounds -- I know BSD's malloc is much more
picky.  Could you try with 2.2.1?  It fixes some
bugs.

More work, but perhaps leading to the cause, could
you try with "2.3" (== current CVS), pymalloc
enabled (which it is by default in 2.3), in debug
mode, and with the symbol PYMALLOC_DEBUG defined
manually?  That enables heavy malloc debugging
which often points to the culprit.

Tim Peters can provide much better info on
how to enable.  Alternatively, the comments in
obmalloc.c may lead the way.

(It may not work in debug mode, but you can use
PYMALLOC_DEBUG even outside debug mode.  I vaguely
remember that I couldn't get 3rd party extension
linkage working in debug mode, but I'm not sure
about this.)

________________________________________
= Comment - Entry #3 by zigg on Feb 6, 2002 2:29 pm


Uploaded:  "do_py_better.patch"
 - http://collector.zope.org/Zope/200/do_py_better.patch/view
Here's a better do_py.patch; the first one might have used the wrong python to build... :-)

> Zope is NOT supported on Python 2.2 at this time; so caveat emptor.

Aw, you're no fun. :-)

> You probably built python 2.2 with pymalloc installed; turn it off -- it
>   causes problems with extensionclass.

No dice.  Tried --without-pymalloc and it's still crashing.

> Your gdb trace also shows that your core file doesn't match the
>   executable you used; so it's not necessarily valid.

gdb lies like a dog. :-)  In any event, this wasn't the case, as I pointed it to 'python' instead of 'python2.2' and got the same issue.

Anyway, defer away.  Looks like OpenBSD 3.1 is going to have to ship with two versions of python :-/
________________________________________
= Defer - Entry #2 by matt on Feb 6, 2002 2:04 pm

 Status: Pending => Deferred

Zope is NOT supported on Python 2.2 at this time; so caveat emptor.

You probably built python 2.2 with pymalloc installed; turn it off -- it causes problems with extensionclass.

Your gdb trace also shows that your core file doesn't match the executable you used; so it's not necessarily valid.
________________________________________
= Request - Entry #1 by zigg on Feb 6, 2002 1:53 pm


Uploaded:  "do_py.patch"
 - http://collector.zope.org/Zope/200/do_py.patch/view
I get this on both Solaris 2.8 and OpenBSD 3.0-current, although Solaris 2.8 gives slightly more detailed gdb information.  z2.py appears to be crashing when executing 'import PersistentMapping', and zdaemon will restart it over, and over, and over again...

Attached is a little patch I made up that will convert Setup files to distutils setup.py's on the fly, so that you can compile Zope 2.5.0 with Python 2.2.  (Incidentally, yes I did try it with the 'Makefile.pre.in' trick advertised elsewhere, and got the same results.)

Here's the gdb backtrace.  Let me know if you want more info, I can certainly get more:

> Script started on Wed Feb 06 13:47:09 2002
> $ gdb ../bin/python2.2 core

> GNU gdb 5.0

> Copyright 2000 Free Software Foundation, Inc.

> GDB is free software, covered by the GNU General Public License, and you are

> welcome to change it and/or distribute copies of it under certain conditions.

> Type "show copying" to see the conditions.

> There is absolutely no warranty for GDB. Type "show warranty" for details.

> This GDB was configured as "sparc-sun-solaris2.8"...

> 

> warning: core file may not match specified executable file.

> Core was generated by `/export/home/b14741/tmp/Zope-2.5.0-src/../bin/python /export/home/b14741/tmp/Zo'.

> Program terminated with signal 9, Killed.

> Reading symbols from /usr/lib/libsocket.so.1...done.

> Loaded symbols for /usr/lib/libsocket.so.1

> Reading symbols from /usr/lib/libnsl.so.1...done.

> Loaded symbols for /usr/lib/libnsl.so.1

> Reading symbols from /usr/lib/libdl.so.1...done.

> Loaded symbols for /usr/lib/libdl.so.1

> Reading symbols from /usr/lib/libpthread.so.1...done.

> Loaded symbols for /usr/lib/libpthread.so.1

> Reading symbols from /usr/lib/libthread.so.1...done.

> Loaded symbols for /usr/lib/libthread.so.1

> Reading symbols from /usr/lib/libm.so.1...done.

> Loaded symbols for /usr/lib/libm.so.1

> Reading symbols from /usr/lib/libc.so.1...done.

> Loaded symbols for /usr/lib/libc.so.1

> Reading symbols from /usr/lib/libmp.so.2...done.

> Loaded symbols for /usr/lib/libmp.so.2

> Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...done.

> Loaded symbols for /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1

> Reading symbols from /export/home/b14741/tmp/lib/python2.2/lib-dynload/strop.so...done.

> Loaded symbols for /export/home/b14741/tmp/lib/python2.2/lib-dynload/strop.so

> Reading symbols from /export/home/b14741/tmp/lib/python2.2/lib-dynload/fcntl.so...done.

> Loaded symbols for /export/home/b14741/tmp/lib/python2.2/lib-dynload/fcntl.so

> Reading symbols from /export/home/b14741/tmp/lib/python2.2/lib-dynload/select.so...done.

> Loaded symbols for /export/home/b14741/tmp/lib/python2.2/lib-dynload/select.so

> Reading symbols from /export/home/b14741/tmp/lib/python2.2/lib-dynload/_socket.so...done.

> Loaded symbols for /export/home/b14741/tmp/lib/python2.2/lib-dynload/_socket.so

> Reading symbols from /usr/lib/libssl.so.0.9.6...done.

> Loaded symbols for /usr/lib/libssl.so.0.9.6

> Reading symbols from /usr/lib/libcrypto.so.0.9.6...done.

> Loaded symbols for /usr/lib/libcrypto.so.0.9.6

> Reading symbols from /export/home/b14741/tmp/lib/python2.2/lib-dynload/errno.so...done.

> Loaded symbols for /export/home/b14741/tmp/lib/python2.2/lib-dynload/errno.so

> Reading symbols from /export/home/b14741/tmp/lib/python2.2/lib-dynload/time.so...done.

> Loaded symbols for /export/home/b14741/tmp/lib/python2.2/lib-dynload/time.so

> Reading symbols from /export/home/b14741/tmp/lib/python2.2/lib-dynload/cStringIO.so...done.

> Loaded symbols for /export/home/b14741/tmp/lib/python2.2/lib-dynload/cStringIO.so

> Reading symbols from /export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ExtensionClass.so...done.

> Loaded symbols for /export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ExtensionClass.so

> Reading symbols from /export/home/b14741/tmp/Zope-2.5.0-src/lib/python/zlib.so...done.

> Loaded symbols for /export/home/b14741/tmp/Zope-2.5.0-src/lib/python/zlib.so

> Reading symbols from /export/home/b14741/tmp/lib/python2.2/lib-dynload/binascii.so...done.

> Loaded symbols for /export/home/b14741/tmp/lib/python2.2/lib-dynload/binascii.so

> Reading symbols from /export/home/b14741/tmp/lib/python2.2/lib-dynload/md5.so...done.

> Loaded symbols for /export/home/b14741/tmp/lib/python2.2/lib-dynload/md5.so

> Reading symbols from /export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB/TimeStamp.so...done.

> Loaded symbols for /export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB/TimeStamp.so

> Reading symbols from /export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB/cPersistence.so...done.

> Loaded symbols for /export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB/cPersistence.so

> Reading symbols from /export/home/b14741/tmp/lib/python2.2/lib-dynload/cPickle.so...done.

> Loaded symbols for /export/home/b14741/tmp/lib/python2.2/lib-dynload/cPickle.so

> #0 initializeBaseExtensionClass (self=0x0)

> at ../Components/ExtensionClass/src/ExtensionClass.c:1504

> 1504 abstract=self->tp_basicsize == sizeof(PyPureMixinObject);

> (gdb) bt

> #0 initializeBaseExtensionClass (self=0x0)

> at ../Components/ExtensionClass/src/ExtensionClass.c:1504

> #1 0xfe61f4b4 in export_type (dict=0x33c7e8, name=0x33c7a8 "", typ=0x0)

> at ../Components/ExtensionClass/src/ExtensionClass.c:3488

> #2 0x2857c in type_call (type=0xfe61f49c, args=0x33c7a8, kwds=0x0)

> at Objects/typeobject.c:158

> #3 0x835a8 in PyObject_Call (func=0xfe61f49c, arg=0x33c7a8, kw=0x0)

> at Objects/abstract.c:1665

> #4 0x49ed4 in PyEval_CallObjectWithKeywords (func=0xdefcc, arg=0x33c7a8, 

> kw=0x0) at Python/ceval.c:3038

> #5 0x828bc in PyObject_CallFunction (callable=0xdefcc, format=0x33c7a8 "")

> at Objects/abstract.c:1706

> #6 0x4b01c in build_class (methods=0x33c2c0, bases=0x33c230, name=0x337f60)

> at Python/ceval.c:3592

> #7 0x46ab4 in eval_frame (f=0x175bb8) at Python/ceval.c:1511

> #8 0x492b4 in PyEval_EvalCodeEx (co=0x3390f0, globals=0x1e7140, 

> locals=0xed258, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 

> defcount=0, closure=0x0) at Python/ceval.c:2574

> #9 0x4bbac in PyEval_EvalCode (co=0x3390f0, globals=0x3391d0, locals=0x3391d0)

> at Python/ceval.c:483

> #10 0x6084c in PyImport_ExecCodeModuleEx (

> name=0xffbebd78 "ZODB.PersistentMapping", co=0x3390f0, 

> pathname=0xffbeb398 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB/PersistentMapping.pyc") at Python/import.c:506

> #11 0x60da0 in load_source_module (name=0xffbebd78 "ZODB.PersistentMapping", 

> pathname=0xffbeb398 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB/PersistentMapping.pyc", fp=0xebc40) at Python/import.c:776

> #12 0x6159c in load_module (name=0xffbebd78 "ZODB.PersistentMapping", 

> fp=0xebc40, 

> buf=0xffbeb888 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB/PersistentMapping.py", type=1) at Python/import.c:1360

> #13 0x62550 in import_submodule (mod=0x1ad360, 

> subname=0xffbebd7d "PersistentMapping", 

> fullname=0xffbebd78 "ZODB.PersistentMapping") at Python/import.c:1899

> #14 0x62050 in load_next (mod=0x1ad360, altmod=0xcf360, p_name=0xffbebd7d, 

> buf=0xffbebd78 "ZODB.PersistentMapping", p_buflen=0xffbebd74)

> at Python/import.c:1755

> #15 0x61b14 in import_module_ex (name=0x0, globals=0x336e00, locals=0x336e00, 

> fromlist=0xcf360) at Python/import.c:1606

> #16 0x61d58 in PyImport_ImportModuleEx (name=0x337f74 "PersistentMapping", 

> globals=0x336e00, locals=0x336e00, fromlist=0xcf360)

> at Python/import.c:1647

> #17 0xab9e4 in builtin___import__ (self=0x0, args=0x3222d0)

> at Python/bltinmodule.c:44

> #18 0xa7954 in PyCFunction_Call (func=0xee200, arg=0x3222d0, kw=0x0)

> at Objects/methodobject.c:101

> #19 0x835a8 in PyObject_Call (func=0xee200, arg=0x3222d0, kw=0xab998)

> at Objects/abstract.c:1665

> #20 0x49ed4 in PyEval_CallObjectWithKeywords (func=0xee200, arg=0x3222d0, 

> kw=0x0) at Python/ceval.c:3038

> #21 0x47620 in eval_frame (f=0x1c0ab8) at Python/ceval.c:1828

> #22 0x492b4 in PyEval_EvalCodeEx (co=0x337e68, globals=0x337b34, 

> locals=0xed258, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 

> defcount=0, closure=0x0) at Python/ceval.c:2574

> #23 0x4bbac in PyEval_EvalCode (co=0x337e68, globals=0x336e00, locals=0x336e00)

> at Python/ceval.c:483

> #24 0x6084c in PyImport_ExecCodeModuleEx (name=0xffbed51d "ZODB", co=0x337e68, 

> pathname=0xffbec648 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB/__init__.pyc") at Python/import.c:506

> #25 0x60da0 in load_source_module (name=0xffbed51d "ZODB", 

> pathname=0xffbec648 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB/__init__.pyc", fp=0xebc30) at Python/import.c:776

> #26 0x6159c in load_module (name=0xffbed51d "ZODB", fp=0xebc30, 

> buf=0xffbecb38 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB/__init__.py", type=1) at Python/import.c:1360

> #27 0x60f18 in load_package (name=0xffbed51d "ZODB", pathname=0x3379e0 "")

> at Python/import.c:833

> #28 0x615e0 in load_module (name=0xffbed51d "ZODB", fp=0x0, 

> buf=0xffbed028 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/ZODB", 

> type=5) at Python/import.c:1383

> #29 0x62550 in import_submodule (mod=0xcf360, subname=0xffbed51d "ZODB", 

> fullname=0xffbed51d "ZODB") at Python/import.c:1899

> ---Type <return> to continue, or q <return> to quit---

> #30 0x620a4 in load_next (mod=0x1ad4c8, altmod=0xcf360, p_name=0xffbed51d, 

> buf=0xffbed518 "Zope.ZODB", p_buflen=0xffbed514) at Python/import.c:1759

> #31 0x61b14 in import_module_ex (name=0x0, globals=0x3304f8, locals=0x3304f8, 

> fromlist=0xcf360) at Python/import.c:1606

> #32 0x61d58 in PyImport_ImportModuleEx (name=0x328afc "ZODB", 

> globals=0x3304f8, locals=0x3304f8, fromlist=0xcf360)

> at Python/import.c:1647

> #33 0xab9e4 in builtin___import__ (self=0x0, args=0x115900)

> at Python/bltinmodule.c:44

> #34 0xa7954 in PyCFunction_Call (func=0xee200, arg=0x115900, kw=0x0)

> at Objects/methodobject.c:101

> #35 0x835a8 in PyObject_Call (func=0xee200, arg=0x115900, kw=0xab998)

> at Objects/abstract.c:1665

> #36 0x49ed4 in PyEval_CallObjectWithKeywords (func=0xee200, arg=0x115900, 

> kw=0x0) at Python/ceval.c:3038

> #37 0x47620 in eval_frame (f=0x11c9b8) at Python/ceval.c:1828

> #38 0x492b4 in PyEval_EvalCodeEx (co=0x1d8098, globals=0x3305ec, 

> locals=0xed258, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 

> defcount=0, closure=0x0) at Python/ceval.c:2574

> #39 0x4bbac in PyEval_EvalCode (co=0x1d8098, globals=0x3304f8, locals=0x3304f8)

> at Python/ceval.c:483

> #40 0x6084c in PyImport_ExecCodeModuleEx (name=0xffbeecb8 "Zope", co=0x1d8098, 

> pathname=0xffbedde8 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/Zope/__init__.pyc") at Python/import.c:506

> #41 0x60da0 in load_source_module (name=0xffbeecb8 "Zope", 

> pathname=0xffbedde8 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/Zope/__init__.pyc", fp=0xebc20) at Python/import.c:776

> #42 0x6159c in load_module (name=0xffbeecb8 "Zope", fp=0xebc20, 

> buf=0xffbee2d8 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/Zope/__init__.py", type=1) at Python/import.c:1360

> #43 0x60f18 in load_package (name=0xffbeecb8 "Zope", pathname=0x32a660 "")

> at Python/import.c:833

> #44 0x615e0 in load_module (name=0xffbeecb8 "Zope", fp=0x0, 

> buf=0xffbee7c8 "/export/home/b14741/tmp/Zope-2.5.0-src/lib/python/Zope", 

> type=5) at Python/import.c:1383

> #45 0x62550 in import_submodule (mod=0xcf360, subname=0xffbeecb8 "Zope", 

> fullname=0xffbeecb8 "Zope") at Python/import.c:1899

> #46 0x62050 in load_next (mod=0xcf360, altmod=0xcf360, p_name=0xffbeecb8, 

> buf=0xffbeecb8 "Zope", p_buflen=0xffbeecb4) at Python/import.c:1755

> #47 0x61b14 in import_module_ex (name=0x0, globals=0x1070d8, locals=0x1070d8, 

> fromlist=0xcf360) at Python/import.c:1606

> #48 0x61d58 in PyImport_ImportModuleEx (name=0x13728c "Zope", 

> globals=0x1070d8, locals=0x1070d8, fromlist=0xcf360)

> at Python/import.c:1647

> #49 0xab9e4 in builtin___import__ (self=0x0, args=0xf6400)

> at Python/bltinmodule.c:44

> #50 0xa7954 in PyCFunction_Call (func=0xee200, arg=0xf6400, kw=0x0)

> at Objects/methodobject.c:101

> #51 0x835a8 in PyObject_Call (func=0xee200, arg=0xf6400, kw=0xab998)

> at Objects/abstract.c:1665

> #52 0x49ed4 in PyEval_CallObjectWithKeywords (func=0xee200, arg=0xf6400, 

> kw=0x0) at Python/ceval.c:3038

> #53 0x47620 in eval_frame (f=0x329660) at Python/ceval.c:1828

> #54 0x492b4 in PyEval_EvalCodeEx (co=0x32d9d0, globals=0x3304d0, 

> locals=0xed258, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 

> defcount=0, closure=0x0) at Python/ceval.c:2574

> #55 0x4bbac in PyEval_EvalCode (co=0x32d9d0, globals=0x1070d8, locals=0x1070d8)

> at Python/ceval.c:483

> #56 0x6b6ac in run_node (n=0xec358, filename=0x32d9d0 "", globals=0x1070d8, 

> locals=0x1070d8, flags=0x0) at Python/pythonrun.c:1083

> #57 0x6b658 in run_err_node (n=0xec358, filename=0x32d9d0 "", 

> globals=0x1070d8, locals=0x1070d8, flags=0x0) at Python/pythonrun.c:1070

> #58 0x6b0e0 in PyRun_String (str=0x32802c "import Zope", start=257, 

> globals=0x1070d8, locals=0x1070d8) at Python/pythonrun.c:1012

> #59 0x4b498 in exec_statement (f=0x142738, prog=0x328018, globals=0x1070d8, 

> locals=0x1070d8) at Python/ceval.c:3672

> #60 0x46864 in eval_frame (f=0x142738) at Python/ceval.c:1467

> #61 0x492b4 in PyEval_EvalCodeEx (co=0x1368d0, globals=0x1aec67, 

> locals=0xed258, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, 

> defcount=0, closure=0x0) at Python/ceval.c:2574

> #62 0x4bbac in PyEval_EvalCode (co=0x1368d0, globals=0xfd4e8, locals=0xfd4e8)

> at Python/ceval.c:483

> ---Type <return> to continue, or q <return> to quit---

> #63 0x6b6ac in run_node (n=0xec1d8, filename=0x1368d0 "", globals=0xfd4e8, 

> locals=0xfd4e8, flags=0xffbefae4) at Python/pythonrun.c:1083

> #64 0x6b658 in run_err_node (n=0xec1d8, filename=0x1368d0 "", globals=0xfd4e8, 

> locals=0xfd4e8, flags=0xffbefae4) at Python/pythonrun.c:1070

> #65 0x6b228 in PyRun_FileExFlags (fp=0xebc20, 

> filename=0xffbefce9 "/export/home/b14741/tmp/Zope-2.5.0-src/z2.py", 

> start=1037544, globals=0xfd4e8, locals=0xfd4e8, closeit=1, 

> flags=0xffbefae4) at Python/pythonrun.c:1061

> #66 0x69b9c in PyRun_SimpleFileExFlags (fp=0xebc20, 

> filename=0xffbefce9 "/export/home/b14741/tmp/Zope-2.5.0-src/z2.py", 

> closeit=1, flags=0xffbefae4) at Python/pythonrun.c:689

> #67 0x6ad60 in PyRun_AnyFileExFlags (fp=0xebc20, 

> filename=0xffbefce9 "/export/home/b14741/tmp/Zope-2.5.0-src/z2.py", 

> closeit=1, flags=0xffbefae4) at Python/pythonrun.c:499

> #68 0x1ae6c in Py_Main (argc=3, argv=0xffbefbcc) at Modules/main.c:369

> #69 0x1a69c in main (argc=3, argv=0xffbefbcc) at Modules/python.c:10

> (gdb) quit

> $ exit

> 
> script done on Wed Feb 06 13:47:23 2002

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



From zope-coders@zope.org  Fri Oct 11 01:49:31 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Thu, 10 Oct 2002 20:49:31 -0400
Subject: [ZCM] [ZC] 612/ 1 Request "Can't add a "multiple selection"-property"
Message-ID: <E17znze-0000nl-00@mail.python.org>

Issue #612 Update (Request) "Can't add a "multiple selection"-property"
 Status Pending, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/612

==============================================================
= Request - Entry #1 by mjablonski on Oct 10, 2002 8:49 pm

Add a lines-property with name='foo'. Then adding a "multiple selection"-property with name='foobar' and value='foo' results in an error: 

Error Type: Bad Request
Error Value: No select variable ['reference']

If I comment out line 160 of ZPublisher/Converters.py

#    'multiple selection': field2lines,

all works fine. Interesting note: There's no entry for 'selection' in the type_converters, so they work without problems...

type_converters = {
    'float':              field2float,
    'int':                field2int,
    'long':               field2long,
    'string':             field2string,
    'date':               field2date,
    'required':           field2required,
    'tokens':             field2tokens,
    'lines':              field2lines,
    'text':               field2text,
    'boolean':            field2boolean,
    'multiple selection': field2lines,
    'ustring':            field2ustring,
    'utokens':            field2utokens,
    'ulines':             field2ulines,
    'utext':              field2utext,
    }

cheers, maik

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



From zope-coders@zope.org  Fri Oct 11 01:51:10 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Thu, 10 Oct 2002 20:51:10 -0400
Subject: [ZCM] [ZC] 613/ 1 Request "Can't add a "multiple selection"-property"
Message-ID: <E17zo1G-0001Sf-00@mail.python.org>

Issue #613 Update (Request) "Can't add a "multiple selection"-property"
 Status Pending, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/613

==============================================================
= Request - Entry #1 by mjablonski on Oct 10, 2002 8:50 pm

Add a lines-property with name='foo'. Then adding a "multiple selection"-property with name='foobar' and value='foo' results in an error: 

Error Type: Bad Request
Error Value: No select variable ['foo']

If I comment out line 160 of ZPublisher/Converters.py

#    'multiple selection': field2lines,

all works fine. Interesting note: There's no entry for 'selection' in the type_converters, so they work without problems...

type_converters = {
    'float':              field2float,
    'int':                field2int,
    'long':               field2long,
    'string':             field2string,
    'date':               field2date,
    'required':           field2required,
    'tokens':             field2tokens,
    'lines':              field2lines,
    'text':               field2text,
    'boolean':            field2boolean,
    'multiple selection': field2lines,
    'ustring':            field2ustring,
    'utokens':            field2utokens,
    'ulines':             field2ulines,
    'utext':              field2utext,
    }

cheers, maik

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



From zope-coders@zope.org  Fri Oct 11 11:43:37 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Fri, 11 Oct 2002 06:43:37 -0400
Subject: [ZCM] [ZC] 613/ 2 Reject "Can't add a "multiple selection"-property"
Message-ID: <E17zxGb-0002lq-00@mail.python.org>

Issue #613 Update (Reject) "Can't add a "multiple selection"-property"
 Status Rejected, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/613

==============================================================
= Reject - Entry #2 by chrisw on Oct 11, 2002 6:43 am

 Status: Pending => Rejected

Duplicate
________________________________________
= Request - Entry #1 by mjablonski on Oct 10, 2002 8:50 pm

Add a lines-property with name='foo'. Then adding a "multiple selection"-property with name='foobar' and value='foo' results in an error: 

Error Type: Bad Request
Error Value: No select variable ['foo']

If I comment out line 160 of ZPublisher/Converters.py

#    'multiple selection': field2lines,

all works fine. Interesting note: There's no entry for 'selection' in the type_converters, so they work without problems...

type_converters = {
    'float':              field2float,
    'int':                field2int,
    'long':               field2long,
    'string':             field2string,
    'date':               field2date,
    'required':           field2required,
    'tokens':             field2tokens,
    'lines':              field2lines,
    'text':               field2text,
    'boolean':            field2boolean,
    'multiple selection': field2lines,
    'ustring':            field2ustring,
    'utokens':            field2utokens,
    'ulines':             field2ulines,
    'utext':              field2utext,
    }

cheers, maik

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



From zope-coders@zope.org  Fri Oct 11 11:45:32 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Fri, 11 Oct 2002 06:45:32 -0400
Subject: [ZCM] [ZC] 612/ 2 Comment "Can't add a "multiple selection"-property"
Message-ID: <E17zxIS-0003Qk-00@mail.python.org>

Issue #612 Update (Comment) "Can't add a "multiple selection"-property"
 Status Pending, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/612

==============================================================
= Comment - Entry #2 by chrisw on Oct 11, 2002 6:45 am

Arg. I added that line to solve a problem with empty multiple selection lists on CMF TypeInfo objects' Properties pages.

I'm not gonna 'accept' this, 'cos I don't know what's going on, btu I just wanted to note that the line in question was added for a verygood reason, so please don't delete it without finding out what's really going on...

________________________________________
= Request - Entry #1 by mjablonski on Oct 10, 2002 8:49 pm

Add a lines-property with name='foo'. Then adding a "multiple selection"-property with name='foobar' and value='foo' results in an error: 

Error Type: Bad Request
Error Value: No select variable ['reference']

If I comment out line 160 of ZPublisher/Converters.py

#    'multiple selection': field2lines,

all works fine. Interesting note: There's no entry for 'selection' in the type_converters, so they work without problems...

type_converters = {
    'float':              field2float,
    'int':                field2int,
    'long':               field2long,
    'string':             field2string,
    'date':               field2date,
    'required':           field2required,
    'tokens':             field2tokens,
    'lines':              field2lines,
    'text':               field2text,
    'boolean':            field2boolean,
    'multiple selection': field2lines,
    'ustring':            field2ustring,
    'utokens':            field2utokens,
    'ulines':             field2ulines,
    'utext':              field2utext,
    }

cheers, maik

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



From zope-coders@zope.org  Fri Oct 11 12:16:43 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Fri, 11 Oct 2002 07:16:43 -0400
Subject: [ZCM] [ZC] 614/ 1 Request "Image URL - Structured Text bug."
Message-ID: <E17zxmd-0006GV-00@mail.python.org>

Issue #614 Update (Request) "Image URL - Structured Text bug."
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/614

==============================================================
= Request - Entry #1 by dosil on Oct 11, 2002 7:16 am


Structured text fail to recognice image URLs with underscore characters "_"
The possible cause is that in DocumentWithImages class, when compiling regular expressions,
these regular expressions doesn't include the "_" underscore character. By now, I'll hack arround it
just adding the _ character to that regular expressions but I think there should be a way to recognize 
standad URL characters.

class DocumentWithImages(DocumentClass):
    """

    """


    text_types = [
       'doc_img',
       ] + DocumentClass.text_types


    def doc_img(
        self, s,
        expr1=re.compile('\"([ _a-zA-Z0-9*.:/;,\-\n\~]+)\":img:([a-zA-Z0-9\-.:/;,\n\~]+)').search,
        expr2=re.compile('\"([ _a-zA-Z0-9*.:/;,\-\n\~]+)\":img:([a-zA-Z0-9\-.:/;,\n\~]+):([a-zA-Z0-9\-.:/;,\n\~]+)').search
        ):

 .......

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



From zope-coders@zope.org  Fri Oct 11 12:25:12 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Fri, 11 Oct 2002 07:25:12 -0400
Subject: [ZCM] [ZC] 614/ 2 Accept "Image URL - Structured Text bug."
Message-ID: <E17zxuq-0007rA-00@mail.python.org>

Issue #614 Update (Accept) "Image URL - Structured Text bug."
 Status Accepted, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/614

==============================================================
= Accept - Entry #2 by ajung on Oct 11, 2002 7:25 am

 Status: Pending => Accepted

 Supporters added: ajung


________________________________________
= Request - Entry #1 by dosil on Oct 11, 2002 7:16 am


Structured text fail to recognice image URLs with underscore characters "_"
The possible cause is that in DocumentWithImages class, when compiling regular expressions,
these regular expressions doesn't include the "_" underscore character. By now, I'll hack arround it
just adding the _ character to that regular expressions but I think there should be a way to recognize 
standad URL characters.

class DocumentWithImages(DocumentClass):
    """

    """


    text_types = [
       'doc_img',
       ] + DocumentClass.text_types


    def doc_img(
        self, s,
        expr1=re.compile('\"([ _a-zA-Z0-9*.:/;,\-\n\~]+)\":img:([a-zA-Z0-9\-.:/;,\n\~]+)').search,
        expr2=re.compile('\"([ _a-zA-Z0-9*.:/;,\-\n\~]+)\":img:([a-zA-Z0-9\-.:/;,\n\~]+):([a-zA-Z0-9\-.:/;,\n\~]+)').search
        ):

 .......

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



From zope-coders@zope.org  Fri Oct 11 12:26:59 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Fri, 11 Oct 2002 07:26:59 -0400
Subject: [ZCM] [ZC] 614/ 3 Comment "Image URL - Structured Text bug."
Message-ID: <E17zxwZ-00083r-00@mail.python.org>

Issue #614 Update (Comment) "Image URL - Structured Text bug."
 Status Accepted, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/614

==============================================================
= Comment - Entry #3 by dosil on Oct 11, 2002 7:26 am

Forgot to put an example. In structured text something like this wouldn't work:

"Image":img:http://www.somewhere.com/any_image.jpg

________________________________________
= Accept - Entry #2 by ajung on Oct 11, 2002 7:25 am

 Status: Pending => Accepted

 Supporters added: ajung


________________________________________
= Request - Entry #1 by dosil on Oct 11, 2002 7:16 am


Structured text fail to recognice image URLs with underscore characters "_"
The possible cause is that in DocumentWithImages class, when compiling regular expressions,
these regular expressions doesn't include the "_" underscore character. By now, I'll hack arround it
just adding the _ character to that regular expressions but I think there should be a way to recognize 
standad URL characters.

class DocumentWithImages(DocumentClass):
    """

    """


    text_types = [
       'doc_img',
       ] + DocumentClass.text_types


    def doc_img(
        self, s,
        expr1=re.compile('\"([ _a-zA-Z0-9*.:/;,\-\n\~]+)\":img:([a-zA-Z0-9\-.:/;,\n\~]+)').search,
        expr2=re.compile('\"([ _a-zA-Z0-9*.:/;,\-\n\~]+)\":img:([a-zA-Z0-9\-.:/;,\n\~]+):([a-zA-Z0-9\-.:/;,\n\~]+)').search
        ):

 .......

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



From zope-coders@zope.org  Sat Oct 12 00:05:10 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Fri, 11 Oct 2002 19:05:10 -0400
Subject: [ZCM] [ZC] 616/ 1 Request "File object requires file"
Message-ID: <E1808qE-0002bh-00@mail.python.org>

Issue #616 Update (Request) "File object requires file"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/616

==============================================================
= Request - Entry #1 by Anonymous User on Oct 11, 2002 7:05 pm

The File object under 2.6b1 no longer lets me create a File object without specifying a file to upload. This is different from 2.5.1. In addition, the "File" attribute in the Add window is in italics, implying it should be optional.

I consider this a bug, and an annoying one at that. Please consider making File not require an upload file.

While you're at it, consider adding a MIME type to the Add pane for File object :-)


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



From zope-coders@zope.org  Mon Oct 14 15:52:39 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Mon, 14 Oct 2002 10:52:39 -0400
Subject: [ZCM] [ZC] 590/ 2 Resolve "lib/python/initgroups.so missing in Zope-2.6.0b1-linux2-x86.tgz"
Message-ID: <E1816aF-0005qT-00@mail.python.org>

Issue #590 Update (Resolve) "lib/python/initgroups.so missing in Zope-2.6.0b1-linux2-x86.tgz"
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/590

==============================================================
= Resolve - Entry #2 by matt on Oct 14, 2002 10:52 am

 Status: Pending => Resolved

This should be fixed in the buildout scripts and beta 2 should have the requisite module.
________________________________________
= Request - Entry #1 by Anonymous User on Sep 26, 2002 4:28 am

Title says all, doesn't it? ;-)
==============================================================



From zope-coders@zope.org  Mon Oct 14 16:06:53 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Mon, 14 Oct 2002 11:06:53 -0400
Subject: [ZCM] [ZC] 612/ 3 Accept "Can't add a "multiple selection"-property"
Message-ID: <E1816o1-00016V-00@mail.python.org>

Issue #612 Update (Accept) "Can't add a "multiple selection"-property"
 Status Accepted, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/612

==============================================================
= Accept - Entry #3 by Brian on Oct 14, 2002 11:06 am

 Status: Pending => Accepted

 Supporters added: Brian

Chris - I've had to back out your change for 2.6 b2, as it 
broke all ability to add multiple select properties. I don't 
know the details of the CMF bug you are referring to, but I 
don't believe the *value* of a multiple select property as 
it comes in in a request should ever be a sequence - it should 
always be a string referring to the existing property from 
which to draw the values of the multiple select.

Your change made it so that the value was always converted to 
a 1-item list, which is what broke things.

I don't know the right answer for the CMF issue, but the 
value of the multiple select needs to remain a string to 
work properly.

-Brian
________________________________________
= Comment - Entry #2 by chrisw on Oct 11, 2002 6:45 am

Arg. I added that line to solve a problem with empty multiple selection lists on CMF TypeInfo objects' Properties pages.

I'm not gonna 'accept' this, 'cos I don't know what's going on, btu I just wanted to note that the line in question was added for a verygood reason, so please don't delete it without finding out what's really going on...

________________________________________
= Request - Entry #1 by mjablonski on Oct 10, 2002 8:49 pm

Add a lines-property with name='foo'. Then adding a "multiple selection"-property with name='foobar' and value='foo' results in an error: 

Error Type: Bad Request
Error Value: No select variable ['reference']

If I comment out line 160 of ZPublisher/Converters.py

#    'multiple selection': field2lines,

all works fine. Interesting note: There's no entry for 'selection' in the type_converters, so they work without problems...

type_converters = {
    'float':              field2float,
    'int':                field2int,
    'long':               field2long,
    'string':             field2string,
    'date':               field2date,
    'required':           field2required,
    'tokens':             field2tokens,
    'lines':              field2lines,
    'text':               field2text,
    'boolean':            field2boolean,
    'multiple selection': field2lines,
    'ustring':            field2ustring,
    'utokens':            field2utokens,
    'ulines':             field2ulines,
    'utext':              field2utext,
    }

cheers, maik

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



From zope-coders@zope.org  Mon Oct 14 16:31:10 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Mon, 14 Oct 2002 11:31:10 -0400
Subject: [ZCM] [ZC] 411/ 2 Accept "DateTime.rfc822 is not rfc822 compliant"
Message-ID: <E1817BW-0000pr-00@mail.python.org>

Issue #411 Update (Accept) "DateTime.rfc822 is not rfc822 compliant"
 Status Accepted, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/411

==============================================================
= Accept - Entry #2 by regebro on Oct 14, 2002 11:31 am

 Status: Pending => Accepted

 Supporters added: regebro

You are correct. MailHost now adds a Date header if it is missing, so dtml-sendmail will now include the mail. Fixing DateTime.rfc822() is more complex though, so I haven't fixed that yet. 

One ugly possibility is to set the zone to -0000, which will make it compliant, but loose the time zone information...
________________________________________
= Request - Entry #1 by Anonymous User on May 31, 2002 12:04 pm

It produces (for example): Fri, 31 May 2002 17:00:05 GMT+1
Whereas it should be: Fri, 31 May 2002 17:00:05 +0100
In the time zone you can have letters (e.g. GMT) or numbers (e.g. +0100) but not both, and the numbers must be in the sign-and-4-digit format.
The numbers-only format is preferable, as that what most e-mail messages have.
I notice the <dtml-sendmail> example conveniently misses out the date.

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



From zope-coders@zope.org  Mon Oct 14 21:22:44 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Mon, 14 Oct 2002 16:22:44 -0400
Subject: [ZCM] [ZC] 616/ 1 Request "ZPT: "python: CONTEXTS" gives NameError"
Message-ID: <E181Bjg-00053O-00@mail.python.org>

Issue #616 Update (Request) "ZPT: "python: CONTEXTS" gives NameError"
 Status Pending, Zope/bug low
To followup, visit:
  http://collector.zope.org/Zope/616

==============================================================
= Request - Entry #1 by wilm on Oct 14, 2002 4:22 pm

In page templates, the built-in variable 'CONTEXTS' is not accessible inside python expressions:

  <div tal:replace="python: CONTEXTS" />
  -> NameError on global name 'CONTEXTS'

while it works fine outside python expressions:

  <div tal:replace="CONTEXTS" />

and the other built-in variables work fine, too:

  <div tal:replace="python: attrs" />

The TALES documentation mentioning CONTEXTS is at:
 <http://www.zope.org/Wikis/DevSite/Projects/ZPT/TALES%20Specification%201.3>

 

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



From zope-coders@zope.org  Tue Oct 15 07:25:03 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 15 Oct 2002 02:25:03 -0400
Subject: [ZCM] [ZC] 617/ 1 Request "Zope-2.5.1 restart failed"
Message-ID: <E181L8Z-0005Bk-00@mail.python.org>

Issue #617 Update (Request) "Zope-2.5.1 restart failed"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/617

==============================================================
= Request - Entry #1 by Anonymous User on Oct 15, 2002 2:25 am

Hi all,

i have a problem restarting my Zope-2.5.1 TTW.
If i hit the Restart-button in the Control_Panel
Zope seems to restart, but if i click on Root-Folder
in the menu i got 
ValueError: I/O operation on closed file

The stupid-log say the following

2002-10-15T06:15:21 INFO(0) ApplicationManager Restart requested by "andre"
------
2002-10-15T06:16:52 ERROR(200) ZODB A storage error occured during object abort This shouldn't happen. 
Traceback (innermost last):
  File /usr/share/zope/lib/python/ZODB/Transaction.py, line 302, in commit
  File /usr/share/zope/lib/python/ZODB/Connection.py, line 540, in tpc_abort
  File /usr/share/zope/lib/python/ZODB/BaseStorage.py, line 111, in tpc_abort
    (Object: /var/zope/var/Data.fs)
  File /usr/share/zope/lib/python/ZODB/FileStorage.py, line 871, in _abort
    (Object: /var/zope/var/Data.fs)
ValueError: I/O operation on closed file

It seems to me the Zope is not starting correctly, or i'am wrong with something ?

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



From zope-coders@zope.org  Tue Oct 15 14:00:36 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 15 Oct 2002 09:00:36 -0400
Subject: [ZCM] [ZC] 619/ 1 Request "Sendmail tag bug"
Message-ID: <E181RJM-0006QA-00@mail.python.org>

Issue #619 Update (Request) "Sendmail tag bug"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/619

==============================================================
= Request - Entry #1 by Anonymous User on Oct 15, 2002 9:00 am

The sendmail tag requires both a "TO:" and a "FROM:" in
order for it to work. This is undocumented. It also requires
that the mailhost be explicity named for it to work. Example
of working dtml:
<dtml-sendmail mailhost="MailHost">
To:rhires@earthlink.net
From:rhires@earthlink.net
Subject: big test

Yes it does...
</dtml-sendmail>

If I take out the "From:rhires@earthlink.net" part, I get an
error: Zope Error

Zope has encountered an error while publishing this resource. 

Error Type: TypeError
 Error Value: len() of unsized object

If I fail to specify the mailhost, I get this error:
Zope Error

Zope has encountered an error while publishing this resource. 

Error Type: UnboundLocalError
 Error Value: local variable 'mhost' referenced before assignment
 
This needs to be documented, or the sendmail tag needs
to be modified to allow for a default mailhost and not 
require the "FROM:" part. 
==============================================================



From zope-coders@zope.org  Tue Oct 15 15:49:28 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 15 Oct 2002 10:49:28 -0400
Subject: [ZCM] [ZC] 620/ 1 Request "PageTemplateFile doesn't set id"
Message-ID: <E181T0i-0006ti-00@mail.python.org>

Issue #620 Update (Request) "PageTemplateFile doesn't set id"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/620

==============================================================
= Request - Entry #1 by chrisw on Oct 15, 2002 10:49 am

PageTemplateFile never sets the id attribute on instantiation, so my_ptf.getId() returns and empty string.

It should returns the id that the PTF is accessible through.
==============================================================



From zope-coders@zope.org  Tue Oct 15 19:44:41 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 15 Oct 2002 14:44:41 -0400
Subject: [ZCM] [ZC] 411/ 3 Comment "DateTime.rfc822 is not rfc822 compliant"
Message-ID: <E181WgL-0007N8-00@mail.python.org>

Issue #411 Update (Comment) "DateTime.rfc822 is not rfc822 compliant"
 Status Accepted, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/411

==============================================================
= Comment - Entry #3 by Torped on Oct 15, 2002 2:44 pm

A fix is submitted and will be included in Zope 2.6. The correct time zone will be included when the timezone is the same as the server, and otherwise timezone information will not be included (marked by -0000).
________________________________________
= Accept - Entry #2 by regebro on Oct 14, 2002 11:31 am

 Status: Pending => Accepted

 Supporters added: regebro

You are correct. MailHost now adds a Date header if it is missing, so dtml-sendmail will now include the mail. Fixing DateTime.rfc822() is more complex though, so I haven't fixed that yet. 

One ugly possibility is to set the zone to -0000, which will make it compliant, but loose the time zone information...
________________________________________
= Request - Entry #1 by Anonymous User on May 31, 2002 12:04 pm

It produces (for example): Fri, 31 May 2002 17:00:05 GMT+1
Whereas it should be: Fri, 31 May 2002 17:00:05 +0100
In the time zone you can have letters (e.g. GMT) or numbers (e.g. +0100) but not both, and the numbers must be in the sign-and-4-digit format.
The numbers-only format is preferable, as that what most e-mail messages have.
I notice the <dtml-sendmail> example conveniently misses out the date.

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



From zope-coders@zope.org  Tue Oct 15 20:20:40 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 15 Oct 2002 15:20:40 -0400
Subject: [ZCM] [ZC] 621/ 1 Request "External methods require save before they can be called with xml-rpc"
Message-ID: <E181XFA-0006SU-00@mail.python.org>

Issue #621 Update (Request) "External methods require save before they can be called with xml-rpc"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/621

==============================================================
= Request - Entry #1 by Anonymous User on Oct 15, 2002 3:20 pm

I am trying to call an external method via xml-rpc. After restarting the zope service, the following error occurs:

>>> srv.hello('Mark')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "xmlrpclib.py", line 547, in __call__
    return self.__send(self.__name, args)
  File "xmlrpclib.py", line 630, in __request
    request
  File "/home/mrroach/xmlrpcbasicauth.py", line 44, in request
    return self.parse_response(h.getfile()) 
  File "xmlrpclib.py", line 601, in parse_response
    return u.close()
  File "xmlrpclib.py", line 371, in close
    raise apply(Fault, (), self._stack[0])
xmlrpclib.Fault: <Fault -2: 'Unexpected Zope error value: <html><head><title>Zope</title></head><body bgcolor="#FFFFFF">\n\n\n<table border="0" width="100%">\n<tr valign="TOP">\n\n<td width="10%" align="center">\n<img src="http://uhgcitrix05:8080/p_/ZButton" alt="Zope">\n</td>\n\n<td width="90%">\n  <h2>Zope Error</h2>\n  <p>Zope has encountered an error while publishing this resource.</p>\n  \n  <p>\n  <strong>Error Type: TypeError</strong><br>\n  <strong>Error Value: too many arguments</strong><br> \n  </p>\n \n  <hr noshade>\n \n  <p>Troubleshooting Suggestions</p>\n\n  <ul>\n    <li>The URL may be incorrect.</li>\n  <li>The parameters passed to this resource may be incorrect.</li>\n  <li>A resource that this resource relies on may be encountering an error.</li>\n  </ul>\n\n  <p>For more detailed information about the error, please\n  refer to the HTML source for this page.\n  </p>\n\n  <p>If the error persists please contact the site maintainer.\n  Thank you for your patience.\n  </p>\n</td></tr>\n</table>\n\n\n<p><a href="http://www.zope.org/Credits" target="_top"><img src="http://uhgcitrix05:8080/p_/ZopeButton" width="115" height="50" border="0" alt="Powered by Zope" /></a></p></body></html>\n'>

If I open ZMI and do a "Save Changes" (no changes have actually occurred) then the call works fine:

>>> srv.hello('Mark')
'Hello Mark'

This is using the simplest possible test case with a parameter. 

def hello(myvar):
    return "Hello %s" % myvar
==============================================================



From zope-coders@zope.org  Tue Oct 15 20:23:04 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 15 Oct 2002 15:23:04 -0400
Subject: [ZCM] [ZC] 622/ 1 Request "External methods require save before they can be called with xml-rpc"
Message-ID: <E181XHU-0006tO-00@mail.python.org>

Issue #622 Update (Request) "External methods require save before they can be called with xml-rpc"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/622

==============================================================
= Request - Entry #1 by Anonymous User on Oct 15, 2002 3:23 pm

(Sorry for opening twice, accidentally submitted without email info)

I am trying to call an external method via xml-rpc. After restarting the zope service, the following error occurs:

>>> srv.hello('Mark')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "xmlrpclib.py", line 547, in __call__
    return self.__send(self.__name, args)
  File "xmlrpclib.py", line 630, in __request
    request
  File "/home/mrroach/xmlrpcbasicauth.py", line 44, in request
    return self.parse_response(h.getfile()) 
  File "xmlrpclib.py", line 601, in parse_response
    return u.close()
  File "xmlrpclib.py", line 371, in close
    raise apply(Fault, (), self._stack[0])
xmlrpclib.Fault: <Fault -2: 'Unexpected Zope error value: <html><head><title>Zope</title></head><body bgcolor="#FFFFFF">\n\n\n<table border="0" width="100%">\n<tr valign="TOP">\n\n<td width="10%" align="center">\n<img src="http://uhgcitrix05:8080/p_/ZButton" alt="Zope">\n</td>\n\n<td width="90%">\n  <h2>Zope Error</h2>\n  <p>Zope has encountered an error while publishing this resource.</p>\n  \n  <p>\n  <strong>Error Type: TypeError</strong><br>\n  <strong>Error Value: too many arguments</strong><br> \n  </p>\n \n  <hr noshade>\n \n  <p>Troubleshooting Suggestions</p>\n\n  <ul>\n    <li>The URL may be incorrect.</li>\n  <li>The parameters passed to this resource may be incorrect.</li>\n  <li>A resource that this resource relies on may be encountering an error.</li>\n  </ul>\n\n  <p>For more detailed information about the error, please\n  refer to the HTML source for this page.\n  </p>\n\n  <p>If the error persists please contact the site maintainer.\n  Thank you for your patience.\n  </p>\n</td></tr>\n</table>\n\n\n<p><a href="http://www.zope.org/Credits" target="_top"><img src="http://uhgcitrix05:8080/p_/ZopeButton" width="115" height="50" border="0" alt="Powered by Zope" /></a></p></body></html>\n'>

If I open ZMI and do a "Save Changes" (no changes have actually occurred) then the call works fine:

>>> srv.hello('Mark')
'Hello Mark'

This is using the simplest possible test case with a parameter. 

def hello(myvar):
    return "Hello %s" % myvar
==============================================================



From zope-coders@zope.org  Tue Oct 15 20:27:49 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 15 Oct 2002 15:27:49 -0400
Subject: [ZCM] [ZC] 622/ 2 Reject "External methods require save before they can be called with xml-rpc"
Message-ID: <E181XM5-0007jZ-00@mail.python.org>

Issue #622 Update (Reject) "External methods require save before they can be called with xml-rpc"
 Status Rejected, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/622

==============================================================
= Reject - Entry #2 by ajung on Oct 15, 2002 3:27 pm

 Status: Pending => Rejected

Duplicate (#621)
________________________________________
= Request - Entry #1 by Anonymous User on Oct 15, 2002 3:23 pm

(Sorry for opening twice, accidentally submitted without email info)

I am trying to call an external method via xml-rpc. After restarting the zope service, the following error occurs:

>>> srv.hello('Mark')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "xmlrpclib.py", line 547, in __call__
    return self.__send(self.__name, args)
  File "xmlrpclib.py", line 630, in __request
    request
  File "/home/mrroach/xmlrpcbasicauth.py", line 44, in request
    return self.parse_response(h.getfile()) 
  File "xmlrpclib.py", line 601, in parse_response
    return u.close()
  File "xmlrpclib.py", line 371, in close
    raise apply(Fault, (), self._stack[0])
xmlrpclib.Fault: <Fault -2: 'Unexpected Zope error value: <html><head><title>Zope</title></head><body bgcolor="#FFFFFF">\n\n\n<table border="0" width="100%">\n<tr valign="TOP">\n\n<td width="10%" align="center">\n<img src="http://uhgcitrix05:8080/p_/ZButton" alt="Zope">\n</td>\n\n<td width="90%">\n  <h2>Zope Error</h2>\n  <p>Zope has encountered an error while publishing this resource.</p>\n  \n  <p>\n  <strong>Error Type: TypeError</strong><br>\n  <strong>Error Value: too many arguments</strong><br> \n  </p>\n \n  <hr noshade>\n \n  <p>Troubleshooting Suggestions</p>\n\n  <ul>\n    <li>The URL may be incorrect.</li>\n  <li>The parameters passed to this resource may be incorrect.</li>\n  <li>A resource that this resource relies on may be encountering an error.</li>\n  </ul>\n\n  <p>For more detailed information about the error, please\n  refer to the HTML source for this page.\n  </p>\n\n  <p>If the error persists please contact the site maintainer.\n  Thank you for your patience.\n  </p>\n</td></tr>\n</table>\n\n\n<p><a href="http://www.zope.org/Credits" target="_top"><img src="http://uhgcitrix05:8080/p_/ZopeButton" width="115" height="50" border="0" alt="Powered by Zope" /></a></p></body></html>\n'>

If I open ZMI and do a "Save Changes" (no changes have actually occurred) then the call works fine:

>>> srv.hello('Mark')
'Hello Mark'

This is using the simplest possible test case with a parameter. 

def hello(myvar):
    return "Hello %s" % myvar
==============================================================



From zope-coders@zope.org  Tue Oct 15 20:29:19 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 15 Oct 2002 15:29:19 -0400
Subject: [ZCM] [ZC] 621/ 2 Comment "External methods require save before they can be called with xml-rpc"
Message-ID: <E181XNX-00089S-00@mail.python.org>

Issue #621 Update (Comment) "External methods require save before they can be called with xml-rpc"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/621

==============================================================
= Comment - Entry #2 by ajung on Oct 15, 2002 3:29 pm

can't reproduce the problem under Linux (Zope 2.5.1).

-aj
________________________________________
= Request - Entry #1 by Anonymous User on Oct 15, 2002 3:20 pm

I am trying to call an external method via xml-rpc. After restarting the zope service, the following error occurs:

>>> srv.hello('Mark')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "xmlrpclib.py", line 547, in __call__
    return self.__send(self.__name, args)
  File "xmlrpclib.py", line 630, in __request
    request
  File "/home/mrroach/xmlrpcbasicauth.py", line 44, in request
    return self.parse_response(h.getfile()) 
  File "xmlrpclib.py", line 601, in parse_response
    return u.close()
  File "xmlrpclib.py", line 371, in close
    raise apply(Fault, (), self._stack[0])
xmlrpclib.Fault: <Fault -2: 'Unexpected Zope error value: <html><head><title>Zope</title></head><body bgcolor="#FFFFFF">\n\n\n<table border="0" width="100%">\n<tr valign="TOP">\n\n<td width="10%" align="center">\n<img src="http://uhgcitrix05:8080/p_/ZButton" alt="Zope">\n</td>\n\n<td width="90%">\n  <h2>Zope Error</h2>\n  <p>Zope has encountered an error while publishing this resource.</p>\n  \n  <p>\n  <strong>Error Type: TypeError</strong><br>\n  <strong>Error Value: too many arguments</strong><br> \n  </p>\n \n  <hr noshade>\n \n  <p>Troubleshooting Suggestions</p>\n\n  <ul>\n    <li>The URL may be incorrect.</li>\n  <li>The parameters passed to this resource may be incorrect.</li>\n  <li>A resource that this resource relies on may be encountering an error.</li>\n  </ul>\n\n  <p>For more detailed information about the error, please\n  refer to the HTML source for this page.\n  </p>\n\n  <p>If the error persists please contact the site maintainer.\n  Thank you for your patience.\n  </p>\n</td></tr>\n</table>\n\n\n<p><a href="http://www.zope.org/Credits" target="_top"><img src="http://uhgcitrix05:8080/p_/ZopeButton" width="115" height="50" border="0" alt="Powered by Zope" /></a></p></body></html>\n'>

If I open ZMI and do a "Save Changes" (no changes have actually occurred) then the call works fine:

>>> srv.hello('Mark')
'Hello Mark'

This is using the simplest possible test case with a parameter. 

def hello(myvar):
    return "Hello %s" % myvar
==============================================================



From zope-coders@zope.org  Tue Oct 15 20:43:16 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 15 Oct 2002 15:43:16 -0400
Subject: [ZCM] [ZC] 614/ 4 Resolve "Image URL - Structured Text bug."
Message-ID: <E181Xb2-0002OK-00@mail.python.org>

Issue #614 Update (Resolve) "Image URL - Structured Text bug."
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/614

==============================================================
= Resolve - Entry #4 by ajung on Oct 15, 2002 3:43 pm

 Status: Accepted => Resolved

Fixed in 2.5 branch. 2.6 and HEAD already have the patch
(no idea why).

-aj
________________________________________
= Comment - Entry #3 by dosil on Oct 11, 2002 7:26 am

Forgot to put an example. In structured text something like this wouldn't work:

"Image":img:http://www.somewhere.com/any_image.jpg

________________________________________
= Accept - Entry #2 by ajung on Oct 11, 2002 7:25 am

 Status: Pending => Accepted

 Supporters added: ajung


________________________________________
= Request - Entry #1 by dosil on Oct 11, 2002 7:16 am


Structured text fail to recognice image URLs with underscore characters "_"
The possible cause is that in DocumentWithImages class, when compiling regular expressions,
these regular expressions doesn't include the "_" underscore character. By now, I'll hack arround it
just adding the _ character to that regular expressions but I think there should be a way to recognize 
standad URL characters.

class DocumentWithImages(DocumentClass):
    """

    """


    text_types = [
       'doc_img',
       ] + DocumentClass.text_types


    def doc_img(
        self, s,
        expr1=re.compile('\"([ _a-zA-Z0-9*.:/;,\-\n\~]+)\":img:([a-zA-Z0-9\-.:/;,\n\~]+)').search,
        expr2=re.compile('\"([ _a-zA-Z0-9*.:/;,\-\n\~]+)\":img:([a-zA-Z0-9\-.:/;,\n\~]+):([a-zA-Z0-9\-.:/;,\n\~]+)').search
        ):

 .......

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



From zope-coders@zope.org  Wed Oct 16 11:28:04 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Wed, 16 Oct 2002 06:28:04 -0400
Subject: [ZCM] [ZC] 623/ 1 Request "can't input non-latin-1 characters in any ZMI 'Properites' view"
Message-ID: <E181lPI-0007Ze-00@mail.python.org>

Issue #623 Update (Request) "can't input non-latin-1 characters in any ZMI 'Properites' view"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/623

==============================================================
= Request - Entry #1 by panjunyong on Oct 16, 2002 6:28 am

we can't input any Chinese in the ZMI's 'Properites' view, such as Folder's 'title' property. Zope will throw an error: 

Error Type: UnicodeError
Error Value: Latin-1 encoding error: ordinal not in range(256)

I browse the code and found 'latin1' is hard-coded as 'default' encoding in many files, such as: \ZPublisher\Converters.py (field2string), \Zpublisher\HTTPResquest.py(processInputs) and \ZPublisher\HTTPRespone.py. I think maybe this is the reason. I try to covert 'latin1' to 'uft_8' and it accepts my Chinese input correctly. But it still can't show the word in the 'ZMI Properties View' correctly. 
==============================================================



From zope-coders@zope.org  Wed Oct 16 11:57:18 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Wed, 16 Oct 2002 06:57:18 -0400
Subject: [ZCM] [ZC] 612/ 4 Comment "Can't add a "multiple selection"-property"
Message-ID: <E181lra-0005Pi-00@mail.python.org>

Issue #612 Update (Comment) "Can't add a "multiple selection"-property"
 Status Accepted, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/612

==============================================================
= Comment - Entry #4 by chrisw on Oct 16, 2002 6:57 am

TypesTool.py define a property of type information objects as:
        {'id':'allowed_content_types'
         , 'type': 'multiple selection'
         , 'mode':'w'
         , 'label':'Allowed content types'
         , 'select_variable':'listContentTypes'
         },

Now listContentTypes is a method that can return an empty list.
What happens when the thing specified in the select_variable returns an empty list?

I suspect I unearthed a bug but fixed it in the wrong place...

Ideas?

Chris
________________________________________
= Accept - Entry #3 by Brian on Oct 14, 2002 11:06 am

 Status: Pending => Accepted

 Supporters added: Brian

Chris - I've had to back out your change for 2.6 b2, as it 
broke all ability to add multiple select properties. I don't 
know the details of the CMF bug you are referring to, but I 
don't believe the *value* of a multiple select property as 
it comes in in a request should ever be a sequence - it should 
always be a string referring to the existing property from 
which to draw the values of the multiple select.

Your change made it so that the value was always converted to 
a 1-item list, which is what broke things.

I don't know the right answer for the CMF issue, but the 
value of the multiple select needs to remain a string to 
work properly.

-Brian
________________________________________
= Comment - Entry #2 by chrisw on Oct 11, 2002 6:45 am

Arg. I added that line to solve a problem with empty multiple selection lists on CMF TypeInfo objects' Properties pages.

I'm not gonna 'accept' this, 'cos I don't know what's going on, btu I just wanted to note that the line in question was added for a verygood reason, so please don't delete it without finding out what's really going on...

________________________________________
= Request - Entry #1 by mjablonski on Oct 10, 2002 8:49 pm

Add a lines-property with name='foo'. Then adding a "multiple selection"-property with name='foobar' and value='foo' results in an error: 

Error Type: Bad Request
Error Value: No select variable ['reference']

If I comment out line 160 of ZPublisher/Converters.py

#    'multiple selection': field2lines,

all works fine. Interesting note: There's no entry for 'selection' in the type_converters, so they work without problems...

type_converters = {
    'float':              field2float,
    'int':                field2int,
    'long':               field2long,
    'string':             field2string,
    'date':               field2date,
    'required':           field2required,
    'tokens':             field2tokens,
    'lines':              field2lines,
    'text':               field2text,
    'boolean':            field2boolean,
    'multiple selection': field2lines,
    'ustring':            field2ustring,
    'utokens':            field2utokens,
    'ulines':             field2ulines,
    'utext':              field2utext,
    }

cheers, maik

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



From zope-coders@zope.org  Thu Oct 17 09:33:00 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Thu, 17 Oct 2002 04:33:00 -0400
Subject: [ZCM] [ZC] 624/ 1 Request "Sybase DAv2 - loses connection & crashes zope"
Message-ID: <E18265U-000827-00@mail.python.org>

Issue #624 Update (Request) "Sybase DAv2 - loses connection & crashes zope"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/624

==============================================================
= Request - Entry #1 by Anonymous User on Oct 17, 2002 4:32 am

Zope in pcgi mode
---
Repeatedly refreshing a web page that queries a database crashes zope.

Zope started in single threaded mode (no -p flag)
---
The database connection is lost, time to lose connection varies between 1 minute and a couple hours. I've temporarily solved the problem by writing a python script that downloads a query web page every minute.

Here's the error Zope displays:
Error Type: Database Error
Error Value: SelectActiveKiosks is not connected to a database

(SelectActiveKiosks is a Z SQL Method.)

Also, once the connection is lost, editing the connection and clicking the "Open Connection" button produces the following error:

Invalid connection string: database: ZopeStats, password: ********, server: SYBASE, transactional: Y, user: sa

Restarting zope fixes all this??

Thanks
Raphael Faria





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



From zope-coders@zope.org  Thu Oct 17 10:24:23 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Thu, 17 Oct 2002 05:24:23 -0400
Subject: [ZCM] [ZC] 624/ 2 Reject "Sybase DAv2 - loses connection & crashes zope"
Message-ID: <E1826tD-0005NN-00@mail.python.org>

Issue #624 Update (Reject) "Sybase DAv2 - loses connection & crashes zope"
 Status Rejected, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/624

==============================================================
= Reject - Entry #2 by chrisw on Oct 17, 2002 5:24 am

 Status: Pending => Rejected

This looks like a Sybase DA issue.

This collector is not for Sybase DA issues ;-)

I'd suggest asking on zope@zope.org
________________________________________
= Request - Entry #1 by Anonymous User on Oct 17, 2002 4:32 am

Zope in pcgi mode
---
Repeatedly refreshing a web page that queries a database crashes zope.

Zope started in single threaded mode (no -p flag)
---
The database connection is lost, time to lose connection varies between 1 minute and a couple hours. I've temporarily solved the problem by writing a python script that downloads a query web page every minute.

Here's the error Zope displays:
Error Type: Database Error
Error Value: SelectActiveKiosks is not connected to a database

(SelectActiveKiosks is a Z SQL Method.)

Also, once the connection is lost, editing the connection and clicking the "Open Connection" button produces the following error:

Invalid connection string: database: ZopeStats, password: ********, server: SYBASE, transactional: Y, user: sa

Restarting zope fixes all this??

Thanks
Raphael Faria





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



From zope-coders@zope.org  Fri Oct 18 05:47:09 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Fri, 18 Oct 2002 00:47:09 -0400
Subject: [ZCM] [ZC] 610/ 2 Resolve "HTTP_TRACEBACK_STYLE not documented"
Message-ID: <E182P2T-00013V-00@mail.python.org>

Issue #610 Update (Resolve) "HTTP_TRACEBACK_STYLE not documented"
 Status Resolved, Zope/doc request medium
To followup, visit:
  http://collector.zope.org/Zope/610

==============================================================
= Resolve - Entry #2 by ajung on Oct 18, 2002 12:47 am

 Status: Pending => Resolved

fixed in the 2.5 branch.

-aj
________________________________________
= Request - Entry #1 by efge on Oct 8, 2002 12:06 pm

HTTP_TRACEBACK_STYLE should be documented in doc/ENVIRONMENT.txt

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



From zope-coders@zope.org  Fri Oct 18 08:03:44 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Fri, 18 Oct 2002 03:03:44 -0400
Subject: [ZCM] [ZC] 625/ 1 Request "dtml-in and tuples"
Message-ID: <E182RAe-0001cL-00@mail.python.org>

Issue #625 Update (Request) "dtml-in and tuples"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/625

==============================================================
= Request - Entry #1 by Anonymous User on Oct 18, 2002 3:03 am

If the sequence variable of a dtml-in tag yields a tuple of tuples and if one of these tuples contains  exactly two entries, "sequence-item" will not contain this tuple, but the second entry in this tuple.

For an example try this;

<dtml-in "(('a', 'b'),('c','d','e'))">
  <dtml-var sequence-item><br>
</dtml-in>

This prints like
b
('c','d','e')

and not (as expected)
('a', 'b')
('c','d','e')


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



From zope-coders@zope.org  Fri Oct 18 08:14:28 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Fri, 18 Oct 2002 03:14:28 -0400
Subject: [ZCM] [ZC] 625/ 2 Reject "dtml-in and tuples"
Message-ID: <E182RL2-00069W-00@mail.python.org>

Issue #625 Update (Reject) "dtml-in and tuples"
 Status Rejected, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/625

==============================================================
= Reject - Entry #2 by ajung on Oct 18, 2002 3:14 am

 Status: Pending => Rejected

This behaviour is intentional and documented:

 sequence-item
    The current item.
sequence-key
    The current key. When looping over tuples of the form (key,value), the in tag interprets them as (sequence-key, sequence-item).

-aj
________________________________________
= Request - Entry #1 by Anonymous User on Oct 18, 2002 3:03 am

If the sequence variable of a dtml-in tag yields a tuple of tuples and if one of these tuples contains  exactly two entries, "sequence-item" will not contain this tuple, but the second entry in this tuple.

For an example try this;

<dtml-in "(('a', 'b'),('c','d','e'))">
  <dtml-var sequence-item><br>
</dtml-in>

This prints like
b
('c','d','e')

and not (as expected)
('a', 'b')
('c','d','e')


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



From zope-coders@zope.org  Fri Oct 18 15:24:03 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Fri, 18 Oct 2002 10:24:03 -0400
Subject: [ZCM] [ZC] 560/ 3 Comment "frequent error code 10 or 11 zope crashes"
Message-ID: <E182Y2l-0004gc-00@mail.python.org>

Issue #560 Update (Comment) "frequent error code 10 or 11 zope crashes"
 Status Pending, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/560

==============================================================
= Comment - Entry #3 by pieterb on Oct 18, 2002 10:23 am

This bug is also discussed at <a href="http://www.zwiki.org/">zwiki</a>.

See also: <a href="http://zwiki.org/IssueNo0226">http://zwiki.org/IssueNo0226</a>

PieterB
________________________________________
= Comment - Entry #2 by simon on Sep 4, 2002 10:08 pm

This is on freebsd 4.3 and as far as I know it's the stock python.
________________________________________
= Request - Entry #1 by simon on Sep 4, 2002 10:00 pm

I can trigger this bug in different ways, typically by saving a certain zwiki page once it grows past a certain length. Splitting up the page stops the problem. Disabling catalog-indexing or switching to plain text mode does not seem to affect the problem.

I've also seen it when using a plone page template which had Iterator calls in it. Removing the Iterator calls stopped the problem.

This used to be rare but has become frequent enough to be a severe nuisance. My zope runs at around 50-100Mb resident memory usage.

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



From zope-coders@zope.org  Fri Oct 18 15:39:02 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Fri, 18 Oct 2002 10:39:02 -0400
Subject: [ZCM] [ZC] 560/ 4 Comment "frequent error code 10 or 11 zope crashes"
Message-ID: <E182YHF-0000pM-00@mail.python.org>

Issue #560 Update (Comment) "frequent error code 10 or 11 zope crashes"
 Status Pending, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/560

==============================================================
= Comment - Entry #4 by matt on Oct 18, 2002 10:38 am

This is either a bug with Python or FreeBSD -- depending on your favoritism.  The FreeBSD default thread stack size is very small -- 64K.  Python needs more than that to run Zope.

The attached patch has been successful for me in changing the default stack size on BSDs.

Regardless, it isn't a Zope problem, so I am closing this issue.

--- ../Python-2.1.3/Python/thread_pthread.h     Thu Jan 10 06:12:20 2002
+++ Python/thread_pthread.h     Thu Jan 17 11:54:21 2002
@@ -128,6 +128,10 @@
 {
        pthread_t th;
        int success;
+        pthread_attr_t pta;
+        pthread_attr_init(&pta);
+        pthread_attr_setstacksize(&pta, (1<<17));
+        
 #ifdef PTHREAD_SYSTEM_SCHED_SUPPORTED
        pthread_attr_t attrs;
 #endif
@@ -156,7 +160,7 @@
 #ifdef PTHREAD_SYSTEM_SCHED_SUPPORTED
                                 &attrs,
 #else
-                                (pthread_attr_t*)NULL,
+                                (pthread_attr_t*)&pta,
 #endif
                                 (void* (*)(void *))func,
                                 (void *)arg


________________________________________
= Comment - Entry #3 by pieterb on Oct 18, 2002 10:23 am

This bug is also discussed at <a href="http://www.zwiki.org/">zwiki</a>.

See also: <a href="http://zwiki.org/IssueNo0226">http://zwiki.org/IssueNo0226</a>

PieterB
________________________________________
= Comment - Entry #2 by simon on Sep 4, 2002 10:08 pm

This is on freebsd 4.3 and as far as I know it's the stock python.
________________________________________
= Request - Entry #1 by simon on Sep 4, 2002 10:00 pm

I can trigger this bug in different ways, typically by saving a certain zwiki page once it grows past a certain length. Splitting up the page stops the problem. Disabling catalog-indexing or switching to plain text mode does not seem to affect the problem.

I've also seen it when using a plone page template which had Iterator calls in it. Removing the Iterator calls stopped the problem.

This used to be rare but has become frequent enough to be a severe nuisance. My zope runs at around 50-100Mb resident memory usage.

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



From zope-coders@zope.org  Fri Oct 18 15:39:11 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Fri, 18 Oct 2002 10:39:11 -0400
Subject: [ZCM] [ZC] 560/ 5 Resolve "frequent error code 10 or 11 zope crashes"
Message-ID: <E182YHP-0000qM-00@mail.python.org>

Issue #560 Update (Resolve) "frequent error code 10 or 11 zope crashes"
 Status Resolved, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/560

==============================================================
= Resolve - Entry #5 by matt on Oct 18, 2002 10:39 am

 Status: Pending => Resolved


________________________________________
= Comment - Entry #4 by matt on Oct 18, 2002 10:38 am

This is either a bug with Python or FreeBSD -- depending on your favoritism.  The FreeBSD default thread stack size is very small -- 64K.  Python needs more than that to run Zope.

The attached patch has been successful for me in changing the default stack size on BSDs.

Regardless, it isn't a Zope problem, so I am closing this issue.

--- ../Python-2.1.3/Python/thread_pthread.h     Thu Jan 10 06:12:20 2002
+++ Python/thread_pthread.h     Thu Jan 17 11:54:21 2002
@@ -128,6 +128,10 @@
 {
        pthread_t th;
        int success;
+        pthread_attr_t pta;
+        pthread_attr_init(&pta);
+        pthread_attr_setstacksize(&pta, (1<<17));
+        
 #ifdef PTHREAD_SYSTEM_SCHED_SUPPORTED
        pthread_attr_t attrs;
 #endif
@@ -156,7 +160,7 @@
 #ifdef PTHREAD_SYSTEM_SCHED_SUPPORTED
                                 &attrs,
 #else
-                                (pthread_attr_t*)NULL,
+                                (pthread_attr_t*)&pta,
 #endif
                                 (void* (*)(void *))func,
                                 (void *)arg


________________________________________
= Comment - Entry #3 by pieterb on Oct 18, 2002 10:23 am

This bug is also discussed at <a href="http://www.zwiki.org/">zwiki</a>.

See also: <a href="http://zwiki.org/IssueNo0226">http://zwiki.org/IssueNo0226</a>

PieterB
________________________________________
= Comment - Entry #2 by simon on Sep 4, 2002 10:08 pm

This is on freebsd 4.3 and as far as I know it's the stock python.
________________________________________
= Request - Entry #1 by simon on Sep 4, 2002 10:00 pm

I can trigger this bug in different ways, typically by saving a certain zwiki page once it grows past a certain length. Splitting up the page stops the problem. Disabling catalog-indexing or switching to plain text mode does not seem to affect the problem.

I've also seen it when using a plone page template which had Iterator calls in it. Removing the Iterator calls stopped the problem.

This used to be rare but has become frequent enough to be a severe nuisance. My zope runs at around 50-100Mb resident memory usage.

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



From zope-coders@zope.org  Sat Oct 19 07:11:09 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Sat, 19 Oct 2002 02:11:09 -0400
Subject: [ZCM] [ZC] 626/ 1 Request "localzone DateTime bug?"
Message-ID: <E182mpJ-00084Y-00@mail.python.org>

Issue #626 Update (Request) "localzone DateTime bug?"
 Status Pending, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/626

==============================================================
= Request - Entry #1 by Anonymous User on Oct 19, 2002 2:11 am

create a dtml method with dtml-sendmail.  view the page
we'll get:
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 OFS.DTMLMethod, line 126, in __call__ 
Module DocumentTemplate.DT_String, line 474, in __call__ 
Module Products.MailHost.SendMailTag, line 115, in render 
Module Products.MailHost.MailHost, line 123, in send 
Module Products.MailHost.MailHost, line 208, in _mungeHeaders 
Module DateTime.DateTime, line 1441, in rfc822 
NameError: global name 'localzone' is not defined 


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



From zope-coders@zope.org  Sun Oct 20 08:52:33 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Sun, 20 Oct 2002 03:52:33 -0400
Subject: [ZCM] [ZC] 627/ 1 Request "Editbox"
Message-ID: <E183Asz-0000m6-00@mail.python.org>

Issue #627 Update (Request) "Editbox"
 Status Pending, Zope/bug+solution low
To followup, visit:
  http://collector.zope.org/Zope/627

==============================================================
= Request - Entry #1 by Anonymous User on Oct 20, 2002 3:52 am


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



From zope-coders@zope.org  Sun Oct 20 09:08:44 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Sun, 20 Oct 2002 04:08:44 -0400
Subject: [ZCM] [ZC] 627/ 2 Reject "Editbox"
Message-ID: <E183B8e-00043k-00@mail.python.org>

Issue #627 Update (Reject) "Editbox"
 Status Rejected, Zope/bug+solution low
To followup, visit:
  http://collector.zope.org/Zope/627

==============================================================
= Reject - Entry #2 by ctheune on Oct 20, 2002 4:08 am

 Status: Pending => Rejected

empty request
________________________________________
= Request - Entry #1 by Anonymous User on Oct 20, 2002 3:52 am


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



From zope-coders@zope.org  Sun Oct 20 09:10:09 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Sun, 20 Oct 2002 04:10:09 -0400
Subject: [ZCM] [ZC] 628/ 1 Request "Textarea resize problem in edit view"
Message-ID: <E183BA1-0004KU-00@mail.python.org>

Issue #628 Update (Request) "Textarea resize problem in edit view"
 Status Pending, Zope/bug+solution low
To followup, visit:
  http://collector.zope.org/Zope/628

==============================================================
= Request - Entry #1 by Anonymous User on Oct 20, 2002 4:10 am

 Problems is in bad handling of textarea dimensions
 expressed as percentages.

 1.
 ZopePageTemplate.py has error in pt_changePrefs.
 The line:
     elif type(width) is StringType 
        and dtpref_cols.endswith('%'):
 sholud read:
     elif type(dtpref_cols) is StringType 
        and dtpref_cols.endswith('%'):

 2.
 PythonScript.py has simmilar error in
 ZPythonScriptHTML_changePrefs.
 It should use the code from fixed pt_changePrefs,
 but it should keep the last line:
   return apply(
      self.manage_main,
      (self, REQUEST),
      REQUEST.form)
 This change helps to the extent that errors don't
 happen. But still, the page resizes only vertically
 and not horizontally.

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



From zope-coders@zope.org  Sun Oct 20 09:25:08 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Sun, 20 Oct 2002 04:25:08 -0400
Subject: [ZCM] [ZC] 629/ 1 Request "Cannot run WebDAV Lock Manager from Control Panel"
Message-ID: <E183BOW-00086m-00@mail.python.org>

Issue #629 Update (Request) "Cannot run WebDAV Lock Manager from Control Panel"
 Status Pending, Zope/bug low
To followup, visit:
  http://collector.zope.org/Zope/629

==============================================================
= Request - Entry #1 by Anonymous User on Oct 20, 2002 4:25 am

 When I try to start WebDAV Lock Manager from Control panel an error happens. Here is the log of that error:

 Request URL:
http://localhost:8080/Control_Panel/DavLocks/manage_main 

 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_Let, line 75, in render
  Module DocumentTemplate.DT_Util, line 201, in eval
   - __traceback_info__: REQUEST
  Module <string>, line 0, in ?
 TypeError: has_key() takes exactly 1 argument (2 given)


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



From zope-coders@zope.org  Sun Oct 20 09:39:01 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Sun, 20 Oct 2002 04:39:01 -0400
Subject: [ZCM] [ZC] 630/ 1 Request "Runtime error while modifying bobobase_modification_time with a python script"
Message-ID: <E183Bbx-0003oW-00@mail.python.org>

Issue #630 Update (Request) "Runtime error while modifying bobobase_modification_time with a python script"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/630

==============================================================
= Request - Entry #1 by Anonymous User on Oct 20, 2002 4:38 am

I'm not sure if this is a bug or a new feature but it never happened to me with Zope 2.5.1. When I try to use any method of the DateTime object bobobase_modification_time from inside a Page Template or a Python Script, the server complains with this error:

Zope has encountered an error while publishing this resource.

Error Type: RuntimeError
Error Value: function attributes not accessible in restricted mode

I'm not sure what this could means, but I think is a bug.
==============================================================



From zope-coders@zope.org  Mon Oct 21 05:39:37 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Mon, 21 Oct 2002 00:39:37 -0400
Subject: [ZCM] [ZC] 631/ 1 Request "Images in structured text"
Message-ID: <E183ULp-0003Gf-00@mail.python.org>

Issue #631 Update (Request) "Images in structured text"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/631

==============================================================
= Request - Entry #1 by Anonymous User on Oct 21, 2002 12:39 am

Inserting images in structured text works incorrectly when http port specified in URL:

"picture":img:http://mysite:8080/path/image.gif

produces this output:

<a name="mysite"></a>
<img src="8080/path/image.gif" alt="picture">
<p><b>Figure mysite</b> picture</p>

while specifying URL without "8080" gives the right output:

"picture":img:http://mysite/path/image.gif

gives

<img src="http://mysite/path/image.gif" alt="picture"> 



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



From zope-coders@zope.org  Mon Oct 21 05:48:14 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Mon, 21 Oct 2002 00:48:14 -0400
Subject: [ZCM] [ZC] 631/ 2 Accept "Images in structured text"
Message-ID: <E183UUA-0005Su-00@mail.python.org>

Issue #631 Update (Accept) "Images in structured text"
 Status Accepted, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/631

==============================================================
= Accept - Entry #2 by ajung on Oct 21, 2002 12:48 am

 Status: Pending => Accepted

 Supporters added: ajung


________________________________________
= Request - Entry #1 by Anonymous User on Oct 21, 2002 12:39 am

Inserting images in structured text works incorrectly when http port specified in URL:

"picture":img:http://mysite:8080/path/image.gif

produces this output:

<a name="mysite"></a>
<img src="8080/path/image.gif" alt="picture">
<p><b>Figure mysite</b> picture</p>

while specifying URL without "8080" gives the right output:

"picture":img:http://mysite/path/image.gif

gives

<img src="http://mysite/path/image.gif" alt="picture"> 



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



From zope-coders@zope.org  Mon Oct 21 09:26:05 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Mon, 21 Oct 2002 04:26:05 -0400
Subject: [ZCM] [ZC] 632/ 1 Request ""exception no set" error"
Message-ID: <E183Xsz-0000EV-00@mail.python.org>

Issue #632 Update (Request) ""exception no set" error"
 Status Pending, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/632

==============================================================
= Request - Entry #1 by ajung on Oct 21, 2002 4:25 am

The following PyScript is used to jump directly
to a collector issue inside a CMFCollector instance
by the issue number.

##parameters=ticketnumber
# Jump to a ticket given by its ticketnumbers

ticket = getattr(context, ticketnumber,None)
url = ticket.absolute_url()

if ticket:
    context.REQUEST.RESPONSE.redirect(url)
else:
    raise ValueError, "No such ticket: %s" % ticketnumber

In some case I get the following traceback:


Exception traceback
Time 2002/10/21 10:19:26.278 GMT+2
User Name (User Id) admin (admin)
Request URL http://localhost:20080/tracker/sd/jump_to_ticket
Exception Type SystemError
Exception Value error return without exception set

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 Products.CMFCore.FSPythonScript, line 90, in __call__
    * Module Shared.DC.Scripts.Bindings, line 252, in __call__
    * Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec
    * Module Products.CMFCore.FSPythonScript, line 124, in _exec
      __traceback_info__: ({'script': <FSPythonScript at /tracker/jump_to_ticket used for /tracker/sd>, 'context': <Collector 'sd' (2 issues) at 0x8cd0580>, 'container': <CMFSite instance at 8bd8120>, 'traverse_subpath': []}, ('1',), {}, None)
    * Module Script (Python), line 6, in jump_to_ticket

SystemError: error return without exception set

Display traceback as text
REQUEST
form
ticketnumber '1'
cookies
lazy items
SESSION <bound method SessionDataManager.getSessionData of <SessionDataManager instance at 8bd6d88>>
other
AUTHENTICATION_PATH 'tracker'
TraversalRequestNameStack []
ticketnumber '1'
URL 'http://localhost:20080/tracker/sd/jump_to_ticket'
PUBLISHED <FSPythonScript at /tracker/jump_to_ticket used for /tracker/sd>
SERVER_URL 'http://localhost:20080'
AUTHENTICATED_USER admin
traverse_subpath []
URL0 http://localhost:20080/tracker/sd/jump_to_ticket
URL1 http://localhost:20080/tracker/sd
URL2 http://localhost:20080/tracker
URL3 http://localhost:20080
BASE0 http://localhost:20080
BASE1 http://localhost:20080
BASE2 http://localhost:20080/tracker
BASE3 http://localhost:20080/tracker/sd
BASE4 http://localhost:20080/tracker/sd/jump_to_ticket
environ
SCRIPT_NAME ''
HTTP_ACCEPT_ENCODING 'gzip, deflate, compress;q=0.9'
CONTENT_LENGTH '14'
SERVER_PORT '20080'
PATH_TRANSLATED '/tracker/sd/jump_to_ticket'
HTTP_ACCEPT 'text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1'
GATEWAY_INTERFACE 'CGI/1.1'
CONTENT_TYPE 'application/x-www-form-urlencoded'
HTTP_ACCEPT_LANGUAGE 'en-us, en;q=0.50'
REMOTE_ADDR '127.0.0.1'
SERVER_NAME 'sb1.sb.haufe.de'
HTTP_USER_AGENT 'Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016'
HTTP_ACCEPT_CHARSET 'ISO-8859-1, utf-8;q=0.66, *;q=0.66'
CONNECTION_TYPE 'keep-alive'
channel.creation_time 1035188271
SERVER_PROTOCOL 'HTTP/1.1'
HTTP_KEEP_ALIVE '300'
HTTP_HOST 'localhost:20080'
REQUEST_METHOD 'POST'
PATH_INFO '/tracker/sd/jump_to_ticket'
SERVER_SOFTWARE 'Zope/(unreleased version, python 2.1.3, linux2) ZServer/1.1b1'
HTTP_CACHE_CONTROL 'no-cache'
HTTP_REFERER 'http://localhost:20080/tracker/sd/collector_contents'
HTTP_PRAGMA 'no-cache'

I encoutered a similiar problem when I was using
getattr() with the CMFCollector instance. 

-aj

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



From zope-coders@zope.org  Mon Oct 21 15:39:17 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Mon, 21 Oct 2002 10:39:17 -0400
Subject: [ZCM] [ZC] 633/ 1 Request "Can not mix-in unicode and non-latin1 charactor in DTML"
Message-ID: <E183di9-0003wh-00@mail.python.org>

Issue #633 Update (Request) "Can not mix-in unicode and non-latin1 charactor in DTML"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/633

==============================================================
= Request - Entry #1 by Anonymous User on Oct 21, 2002 10:39 am

I can't input mix-in unicode and non-latin1(CJK) charactor in DTML.

example:

<dtml-in "u'Japanese String','Japanese String'">

run this code then raise  UnicodeError.

I found join_unicode function in cDocumentTemplate.c.
this function will decode non-ascii string to latin-1,
but string is not latin-1, error occur.

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



From zope-coders@zope.org  Mon Oct 21 15:55:09 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Mon, 21 Oct 2002 10:55:09 -0400
Subject: [ZCM] [ZC] 634/ 1 Request "Image objects return img element with deprecated border attribute"
Message-ID: <E183dxV-0000Ky-00@mail.python.org>

Issue #634 Update (Request) "Image objects return img element with deprecated border attribute"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/634

==============================================================
= Request - Entry #1 by tfarrell on Oct 21, 2002 10:55 am

When calling a Zope Image object, the object returns a string.  This string is an html img element in the form of the following:

<img src="picture.jpg" width="1" height="1" alt="A picture" border="0" />

This element represents an ugly hybrid.  The border attribute is deprecated in HTML 4.01, tolerated in XHTML 1.0 Transitional and not allowed in XHTML 1.0 Strict.  The / at the end of the element is an attempt at XML validity (presumably to allow us to use the element in XHTML pages.)

The offending border attribute is added in lines 766 and 767 of /lib/python/OFS/Image.py(http://cvs.zope.org/~checkout~/Zope/lib/python/OFS/Image.py?rev=1.141.2.2&content-type=text/plain)

if not 'border' in [ x.lower() for x in  args.keys()]:
  result = '%s border="0"' % result

It was suggested by Casey that we allow the border attribute to be omited by calling the method with a special parameter.  Below is his email:

Please file a collector issue for this.

The border is there by default because most browsers put a border around images when they are inside an anchor tag. Since most of the time people did not want this, they requested this feature.

A couple of fixes come to mind, like adding a "no_border" argument, or allow "border=''" to mean omit that attribute. Some other thoughts include adding a new "xtag" method that generates XHTML strict or a configuration option that tells Zope to generate strict code.

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



From zope-coders@zope.org  Mon Oct 21 16:01:04 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Mon, 21 Oct 2002 11:01:04 -0400
Subject: [ZCM] [ZC] 634/ 2 Comment "Image objects return img element with deprecated border attribute"
Message-ID: <E183e3E-0001Gl-00@mail.python.org>

Issue #634 Update (Comment) "Image objects return img element with deprecated border attribute"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/634

==============================================================
= Comment - Entry #2 by tfarrell on Oct 21, 2002 11:01 am

Please read the associated thread on the zope@zope.org mailing list:
http://lists.zope.org/pipermail/zope/2002-October/125010.html
________________________________________
= Request - Entry #1 by tfarrell on Oct 21, 2002 10:55 am

When calling a Zope Image object, the object returns a string.  This string is an html img element in the form of the following:

<img src="picture.jpg" width="1" height="1" alt="A picture" border="0" />

This element represents an ugly hybrid.  The border attribute is deprecated in HTML 4.01, tolerated in XHTML 1.0 Transitional and not allowed in XHTML 1.0 Strict.  The / at the end of the element is an attempt at XML validity (presumably to allow us to use the element in XHTML pages.)

The offending border attribute is added in lines 766 and 767 of /lib/python/OFS/Image.py(http://cvs.zope.org/~checkout~/Zope/lib/python/OFS/Image.py?rev=1.141.2.2&content-type=text/plain)

if not 'border' in [ x.lower() for x in  args.keys()]:
  result = '%s border="0"' % result

It was suggested by Casey that we allow the border attribute to be omited by calling the method with a special parameter.  Below is his email:

Please file a collector issue for this.

The border is there by default because most browsers put a border around images when they are inside an anchor tag. Since most of the time people did not want this, they requested this feature.

A couple of fixes come to mind, like adding a "no_border" argument, or allow "border=''" to mean omit that attribute. Some other thoughts include adding a new "xtag" method that generates XHTML strict or a configuration option that tells Zope to generate strict code.

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



From zope-coders@zope.org  Tue Oct 22 08:45:10 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 22 Oct 2002 03:45:10 -0400
Subject: [ZCM] [ZC] 633/ 2 Accept "Can not mix-in unicode and non-latin1 charactor in DTML"
Message-ID: <E183tiw-0007j3-00@mail.python.org>

Issue #633 Update (Accept) "Can not mix-in unicode and non-latin1 charactor in DTML"
 Status Accepted, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/633

==============================================================
= Accept - Entry #2 by ajung on Oct 22, 2002 3:45 am

 Status: Pending => Accepted

 Supporters added: ajung

def join_unicode(rendered):
    """join a list of plain strings into a single plain string,
    a list of unicode strings into a single unicode strings,
    or a list containing a mix into a single unicode string with
    the plain strings converted from latin-1
    """
    try:
        return ''.join(rendered)
    except UnicodeError:
        # A mix of unicode string and non-ascii plain strings.
        # Fix up the list, treating normal strings as latin-1
        rendered = list(rendered)
        for i in range(len(rendered)):
            if type(rendered[i]) is StringType:
                rendered[i] = unicode(rendered[i],'latin-1')
        return u''.join(rendered)

Wouldn't it be better to use sys.getdefaultencoding()
instead of "latin-1". This would allow users to specify
their encoding site-wide. Using 'latin-1' is definitely
a bad choice.

-aj

________________________________________
= Request - Entry #1 by Anonymous User on Oct 21, 2002 10:39 am

I can't input mix-in unicode and non-latin1(CJK) charactor in DTML.

example:

<dtml-in "u'Japanese String','Japanese String'">

run this code then raise  UnicodeError.

I found join_unicode function in cDocumentTemplate.c.
this function will decode non-ascii string to latin-1,
but string is not latin-1, error occur.

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



From zope-coders@zope.org  Tue Oct 22 08:45:38 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 22 Oct 2002 03:45:38 -0400
Subject: [ZCM] [ZC] 633/ 3 Assign "Can not mix-in unicode and non-latin1 charactor in DTML"
Message-ID: <E183tjO-0008Gk-00@mail.python.org>

Issue #633 Update (Assign) "Can not mix-in unicode and non-latin1 charactor in DTML"
 Status Accepted, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/633

==============================================================
= Assign - Entry #3 by ajung on Oct 22, 2002 3:45 am

 Supporters added: htrd


________________________________________
= Accept - Entry #2 by ajung on Oct 22, 2002 3:45 am

 Status: Pending => Accepted

 Supporters added: ajung

def join_unicode(rendered):
    """join a list of plain strings into a single plain string,
    a list of unicode strings into a single unicode strings,
    or a list containing a mix into a single unicode string with
    the plain strings converted from latin-1
    """
    try:
        return ''.join(rendered)
    except UnicodeError:
        # A mix of unicode string and non-ascii plain strings.
        # Fix up the list, treating normal strings as latin-1
        rendered = list(rendered)
        for i in range(len(rendered)):
            if type(rendered[i]) is StringType:
                rendered[i] = unicode(rendered[i],'latin-1')
        return u''.join(rendered)

Wouldn't it be better to use sys.getdefaultencoding()
instead of "latin-1". This would allow users to specify
their encoding site-wide. Using 'latin-1' is definitely
a bad choice.

-aj

________________________________________
= Request - Entry #1 by Anonymous User on Oct 21, 2002 10:39 am

I can't input mix-in unicode and non-latin1(CJK) charactor in DTML.

example:

<dtml-in "u'Japanese String','Japanese String'">

run this code then raise  UnicodeError.

I found join_unicode function in cDocumentTemplate.c.
this function will decode non-ascii string to latin-1,
but string is not latin-1, error occur.

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



From zope-coders@zope.org  Tue Oct 22 10:51:02 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 22 Oct 2002 05:51:02 -0400
Subject: [ZCM] [ZC] 633/ 4 Comment "Can not mix-in unicode and non-latin1 charactor in DTML"
Message-ID: <E183vgk-0004Jt-00@mail.python.org>

Issue #633 Update (Comment) "Can not mix-in unicode and non-latin1 charactor in DTML"
 Status Accepted, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/633

==============================================================
= Comment - Entry #4 by htrd on Oct 22, 2002 5:50 am

The current behaviour is by design. I thought the documentation changes had been merged, but I cant find anything online right now. The best refereces I have are:
http://www.zope.org/Members/htrd/howto/unicode-zdg-changes
http://www.zope.org/Members/htrd/howto/unicode

> Wouldn't it be better to use sys.getdefaultencoding()

sys.getdefaultencoding (and its converse, setdefaultencoding) is not designed for application use. This is a hacking tool added during Python's early unicode development, and is likely to disappear in a future python revision.

As for some other configuration parameter, no. The current design rule was to provide a consistent behaviour when combining these different string representations in dtml. This is essential for writing robust Products.

(Imagine what would happen if 1+"hello" sometimes had a different behaviour, depending on some global configuration parameter. That would be no better than programming in C ;-)

The answer to the original poster's problem is that he should explicity encode the unicode string into the approporiate character encoding. DTML will happily combine 8-bit strings the same way it always has done, provided it does not encounter a unicode string in the same page.

<dtml-var "'japanese string'">
<dtml-var "u'japanese string'.encode('japanese encoding')">

Alternatively, if you want to work entirely in unicode:

<dtml-var "unicode('japanese string','japanese encoding')">
<dtml-var "u'japanese string'">

Essentially, you cant mix pre-encoded strings and unicode string objects inside the same dtml.

This is covered in
http://www.zope.org/Members/htrd/howto/unicode
"Pages That Do Not Expect Unicode"

This behaviour changed between zope 2.5 and 2.6. In 2.5, the dtml posted by the original poster would have raised a UnicodeError exception. For this reason, this change in 2.6 is not judged to be dangerously incompatible.

________________________________________
= Assign - Entry #3 by ajung on Oct 22, 2002 3:45 am

 Supporters added: htrd


________________________________________
= Accept - Entry #2 by ajung on Oct 22, 2002 3:45 am

 Status: Pending => Accepted

 Supporters added: ajung

def join_unicode(rendered):
    """join a list of plain strings into a single plain string,
    a list of unicode strings into a single unicode strings,
    or a list containing a mix into a single unicode string with
    the plain strings converted from latin-1
    """
    try:
        return ''.join(rendered)
    except UnicodeError:
        # A mix of unicode string and non-ascii plain strings.
        # Fix up the list, treating normal strings as latin-1
        rendered = list(rendered)
        for i in range(len(rendered)):
            if type(rendered[i]) is StringType:
                rendered[i] = unicode(rendered[i],'latin-1')
        return u''.join(rendered)

Wouldn't it be better to use sys.getdefaultencoding()
instead of "latin-1". This would allow users to specify
their encoding site-wide. Using 'latin-1' is definitely
a bad choice.

-aj

________________________________________
= Request - Entry #1 by Anonymous User on Oct 21, 2002 10:39 am

I can't input mix-in unicode and non-latin1(CJK) charactor in DTML.

example:

<dtml-in "u'Japanese String','Japanese String'">

run this code then raise  UnicodeError.

I found join_unicode function in cDocumentTemplate.c.
this function will decode non-ascii string to latin-1,
but string is not latin-1, error occur.

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



From zope-coders@zope.org  Tue Oct 22 10:59:01 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 22 Oct 2002 05:59:01 -0400
Subject: [ZCM] [ZC] 633/ 5 Reject "Can not mix-in unicode and non-latin1 charactor in DTML"
Message-ID: <E183voT-0005uE-00@mail.python.org>

Issue #633 Update (Reject) "Can not mix-in unicode and non-latin1 charactor in DTML"
 Status Rejected, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/633

==============================================================
= Reject - Entry #5 by ajung on Oct 22, 2002 5:58 am

 Status: Accepted => Rejected

very good description.
can we add this to the documentation somewhere in the doc folder
of zope?

-aj
________________________________________
= Comment - Entry #4 by htrd on Oct 22, 2002 5:50 am

The current behaviour is by design. I thought the documentation changes had been merged, but I cant find anything online right now. The best refereces I have are:
http://www.zope.org/Members/htrd/howto/unicode-zdg-changes
http://www.zope.org/Members/htrd/howto/unicode

> Wouldn't it be better to use sys.getdefaultencoding()

sys.getdefaultencoding (and its converse, setdefaultencoding) is not designed for application use. This is a hacking tool added during Python's early unicode development, and is likely to disappear in a future python revision.

As for some other configuration parameter, no. The current design rule was to provide a consistent behaviour when combining these different string representations in dtml. This is essential for writing robust Products.

(Imagine what would happen if 1+"hello" sometimes had a different behaviour, depending on some global configuration parameter. That would be no better than programming in C ;-)

The answer to the original poster's problem is that he should explicity encode the unicode string into the approporiate character encoding. DTML will happily combine 8-bit strings the same way it always has done, provided it does not encounter a unicode string in the same page.

<dtml-var "'japanese string'">
<dtml-var "u'japanese string'.encode('japanese encoding')">

Alternatively, if you want to work entirely in unicode:

<dtml-var "unicode('japanese string','japanese encoding')">
<dtml-var "u'japanese string'">

Essentially, you cant mix pre-encoded strings and unicode string objects inside the same dtml.

This is covered in
http://www.zope.org/Members/htrd/howto/unicode
"Pages That Do Not Expect Unicode"

This behaviour changed between zope 2.5 and 2.6. In 2.5, the dtml posted by the original poster would have raised a UnicodeError exception. For this reason, this change in 2.6 is not judged to be dangerously incompatible.

________________________________________
= Assign - Entry #3 by ajung on Oct 22, 2002 3:45 am

 Supporters added: htrd


________________________________________
= Accept - Entry #2 by ajung on Oct 22, 2002 3:45 am

 Status: Pending => Accepted

 Supporters added: ajung

def join_unicode(rendered):
    """join a list of plain strings into a single plain string,
    a list of unicode strings into a single unicode strings,
    or a list containing a mix into a single unicode string with
    the plain strings converted from latin-1
    """
    try:
        return ''.join(rendered)
    except UnicodeError:
        # A mix of unicode string and non-ascii plain strings.
        # Fix up the list, treating normal strings as latin-1
        rendered = list(rendered)
        for i in range(len(rendered)):
            if type(rendered[i]) is StringType:
                rendered[i] = unicode(rendered[i],'latin-1')
        return u''.join(rendered)

Wouldn't it be better to use sys.getdefaultencoding()
instead of "latin-1". This would allow users to specify
their encoding site-wide. Using 'latin-1' is definitely
a bad choice.

-aj

________________________________________
= Request - Entry #1 by Anonymous User on Oct 21, 2002 10:39 am

I can't input mix-in unicode and non-latin1(CJK) charactor in DTML.

example:

<dtml-in "u'Japanese String','Japanese String'">

run this code then raise  UnicodeError.

I found join_unicode function in cDocumentTemplate.c.
this function will decode non-ascii string to latin-1,
but string is not latin-1, error occur.

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



From zope-coders@zope.org  Tue Oct 22 13:29:29 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 22 Oct 2002 08:29:29 -0400
Subject: [ZCM] [ZC] 635/ 1 Request "Binary compatibility"
Message-ID: <E183yA5-00027p-00@mail.python.org>

Issue #635 Update (Request) "Binary compatibility"
 Status Pending, Zope/doc request low
To followup, visit:
  http://collector.zope.org/Zope/635

==============================================================
= Request - Entry #1 by Anonymous User on Oct 22, 2002 8:29 am

When I move out data.fs from v2.5.1, install 2.6.0 and move data.fs back will everything ok?

When I create application in 2.6.0 and then ditribute this binary to machines with 2.5.1 will everything be ok?

Thanks
==============================================================



From zope-coders@zope.org  Tue Oct 22 13:35:30 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 22 Oct 2002 08:35:30 -0400
Subject: [ZCM] [ZC] 635/ 2 Reject "Binary compatibility"
Message-ID: <E183yFu-00032i-00@mail.python.org>

Issue #635 Update (Reject) "Binary compatibility"
 Status Rejected, Zope/doc request low
To followup, visit:
  http://collector.zope.org/Zope/635

==============================================================
= Reject - Entry #2 by ajung on Oct 22, 2002 8:35 am

 Status: Pending => Rejected

Use the Zope mailinglists for general questions.
The collector is for bugtracking only.

Thanks,
-aj
________________________________________
= Request - Entry #1 by Anonymous User on Oct 22, 2002 8:29 am

When I move out data.fs from v2.5.1, install 2.6.0 and move data.fs back will everything ok?

When I create application in 2.6.0 and then ditribute this binary to machines with 2.5.1 will everything be ok?

Thanks
==============================================================



From zope-coders@zope.org  Tue Oct 22 13:39:33 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 22 Oct 2002 08:39:33 -0400
Subject: [ZCM] [ZC] 636/ 1 Request "ZMI: sortable search results"
Message-ID: <E183yJp-0003JS-00@mail.python.org>

Issue #636 Update (Request) "ZMI: sortable search results"
 Status Pending, Zope/feature medium
To followup, visit:
  http://collector.zope.org/Zope/636

==============================================================
= Request - Entry #1 by to_be on Oct 22, 2002 8:39 am

Search results view (manage_findResult):
* should allow the sorting of results like the normal folder view (and thus display size and datetime as well, but using more width for the path/id)

* For very long paths, line breaks should be enabled, e.g. by inserting blanks

* For objects in subfolders, a link to the containing object would be useful
==============================================================



From zope-coders@zope.org  Tue Oct 22 16:00:42 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 22 Oct 2002 11:00:42 -0400
Subject: [ZCM] [ZC] 561/ 6 Comment "Setting unicode headers or cookies breaks ZServer"
Message-ID: <E1840WQ-0000cf-00@mail.python.org>

Issue #561 Update (Comment) "Setting unicode headers or cookies breaks ZServer"
 Status Accepted, ZServer/bug medium
To followup, visit:
  http://collector.zope.org/Zope/561

==============================================================
= Comment - Entry #6 by lalo on Oct 22, 2002 11:00 am

Updated the patch to Zope 2.6, it now applies correctly and leaves no methods behind.
________________________________________
= Accept - Entry #5 by efge on Sep 27, 2002 12:14 pm

 Status: Pending => Accepted

 Supporters added: efge

Accepted.
________________________________________
= Comment - Entry #4 by efge on Sep 27, 2002 12:12 pm

Ok, I agree with you.

________________________________________
= Comment - Entry #3 by lalo on Sep 16, 2002 4:31 pm

> = Comment - Entry #2 by efge on Sep 16, 2002 4:24 pm
> 
> Why try the conversions when the user code is clearly
> at fault?

I do not share this opinion. What if at some time in the future we decide that TALES will return unicode instead of strings (as should be)? Then suddenly all existing page templates are at fault?

I am of opinion that the simplest case (valid ascii, but that for some reason is in an unicode object) should work transparently, and the really b0rked case - non-ascii unicode stuff - should raise an exception that actually shows where the error is, instead of silently killing a zope thread as it currently does.

(I could even argue that giving anyone with permission to write a PythonScript a chance to kill a zope thread is a security problem... hmm... hey, perhaps it is.)
________________________________________
= Comment - Entry #2 by efge on Sep 16, 2002 4:24 pm

I'd rather have something like

  if isinstance(name, UnicodeType) or isinstance(value, UnicodeType):
    raise ValueError, "Invalid unicode value in setCookie"

at the beginning of setCookie.

Why try the conversions when the user code is clearly
at fault?

________________________________________
= Request - Entry #1 by lalo on Sep 5, 2002 3:02 pm


Uploaded:  "HTTPResponse.no-unicode.diff"
 - http://collector.zope.org/Zope/561/HTTPResponse.no-unicode.diff/view
If you set an unicode header or cookie (either in name or value), this breaks ZServer, even if the contents of the unicode are valid 7-bit ascii.

(To get the breakage you need to have something in the body that is not ascii.)

This happens because ZServer.HTTPRresponse.__str__() tries to join all headers and body, and str + unicode = unicode by the coerce rules. ZPublisher will already have encoded the body back into a string to avoid that, but headers and cookies pose a vulnerability.

I looked a bit and have been told that HTTP headers should be plain ascii. In this case, the attached (very simple) patch will move the breakage from ZServer to ZPublisher (setHeader, setCookie, etc) which allows the programmer to realize the error of his/her ways and repent, I mean, fix his/her code.

If this is not deemed acceptable, something with::

  if type(foo) is UnicodeType:
    foo = foo.encode(sys.getdefaultencoding(), 'replace')

can be used. But IMHO that is worse, as it hides the problem under the carpet.
==============================================================



From zope-coders@zope.org  Wed Oct 23 08:53:50 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Wed, 23 Oct 2002 03:53:50 -0400
Subject: [ZCM] [ZC] 637/ 1 Request "ZPT: modules/sequence raises Unauthorized exception"
Message-ID: <E184GKs-0003nv-00@mail.python.org>

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

==============================================================
= 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@zope.org  Wed Oct 23 08:58:01 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Wed, 23 Oct 2002 03:58:01 -0400
Subject: [ZCM] [ZC] 637/ 2 Accept "ZPT: modules/sequence raises Unauthorized exception"
Message-ID: <E184GOv-0004Ls-00@mail.python.org>

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

==============================================================
= 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@zope.org  Wed Oct 23 22:06:45 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Wed, 23 Oct 2002 17:06:45 -0400
Subject: [ZCM] [ZC] 638/ 1 Request "DTML doc/meth: allow omission of "id" if file uploaded"
Message-ID: <E184SiD-0008Rb-00@mail.python.org>

Issue #638 Update (Request) "DTML doc/meth: allow omission of "id" if file uploaded"
 Status Pending, Zope/feature+solution medium
To followup, visit:
  http://collector.zope.org/Zope/638

==============================================================
= Request - Entry #1 by wilm on Oct 23, 2002 5:06 pm


Uploaded:  "diff.txt"
 - http://collector.zope.org/Zope/638/diff.txt/view
This fixes a usability issue: when adding a DTML Method or Document using "upload", currently the "id" field must be filled in.

When uploading a bunch of files, I often want to have the new object to have the same id as the uploaded file name. It's boring and a waste of time to have to manually copy/paste that.

After this diff is applied: if 'id' is not filled in but a file is uploaded, the filename of the uploaded file will be used as id of the DTML Method or Document.

(The checks for id not starting with an underscore etc. still happen later on, of course.)
==============================================================



From zope-coders@zope.org  Thu Oct 24 00:43:26 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Wed, 23 Oct 2002 19:43:26 -0400
Subject: [ZCM] [ZC] 639/ 1 Request "Problem with CDATA in minidom with given python"
Message-ID: <E184V9q-0005Tp-00@mail.python.org>

Issue #639 Update (Request) "Problem with CDATA in minidom with given python"
 Status Pending, Zope/bug+solution low
To followup, visit:
  http://collector.zope.org/Zope/639

==============================================================
= Request - Entry #1 by Anonymous User on Oct 23, 2002 7:43 pm

Problem with python version given with the Zope in :
xml.dom.minidom class CDATASection :
_write_data("<![CDATA[%s]]>" ...

should be replaced by :
writer.write("<![CDATA[%s]]>" ...

Don't know if it comes from official 2.1 python  hence I use 2.2 elsewhere, and it is OK.
==============================================================



From zope-coders@zope.org  Thu Oct 24 11:35:55 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Thu, 24 Oct 2002 06:35:55 -0400
Subject: [ZCM] [ZC] 640/ 1 Request "bad declareProtected() call in ZCTextIndex "
Message-ID: <E184fLH-0006tD-00@mail.python.org>

Issue #640 Update (Request) "bad declareProtected() call in ZCTextIndex "
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/640

==============================================================
= Request - Entry #1 by Anonymous User on Oct 24, 2002 6:35 am

On line 133 of ZCTextIndex.py the declareProtected() call
got the arguments backwards.

security.declareProtected('query', search_zcatalog)

should be

security.declareProtected(search_zcatalog, 'query')


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



From zope-coders@zope.org  Thu Oct 24 14:49:00 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Thu, 24 Oct 2002 09:49:00 -0400
Subject: [ZCM] [ZC] 640/ 2 Resolve "bad declareProtected() call in ZCTextIndex "
Message-ID: <E184iM8-0002EC-00@mail.python.org>

Issue #640 Update (Resolve) "bad declareProtected() call in ZCTextIndex "
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/640

==============================================================
= Resolve - Entry #2 by Caseman on Oct 24, 2002 9:48 am

 Status: Pending => Resolved

Fixed on HEAD and 2.6 branch.

Thank you!
________________________________________
= Request - Entry #1 by Anonymous User on Oct 24, 2002 6:35 am

On line 133 of ZCTextIndex.py the declareProtected() call
got the arguments backwards.

security.declareProtected('query', search_zcatalog)

should be

security.declareProtected(search_zcatalog, 'query')


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



From zope-coders@zope.org  Fri Oct 25 11:19:20 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Fri, 25 Oct 2002 06:19:20 -0400
Subject: [ZCM] [ZC] 641/ 1 Request "BeforeTraverse: bad acquisition"
Message-ID: <E1851Ym-0003KA-00@mail.python.org>

Issue #641 Update (Request) "BeforeTraverse: bad acquisition"
 Status Pending, Zope/bug+solution medium
To followup, visit:
  http://collector.zope.org/Zope/641

==============================================================
= Request - Entry #1 by d.maurer on Oct 25, 2002 6:19 am


Uploaded:  "BeforeTraverse.pat"
 - http://collector.zope.org/Zope/641/BeforeTraverse.pat/view
ZPublisher.BeforeTraverse.NameCaller.__call__
can wrongly acquire "func_code".

This happens, e.g. for URLs of the form

	.../DTMLMethod/.../CMFPortal/...

The result is a 

2002-10-25T09:42:09 ERROR(200) BeforeTraverse Error while invoking hook: "cookie_authentication"
Traceback (innermost last):
  File /home/dieter/Haufe/src/Zope/lib/python/ZPublisher/BeforeTraverse.py, line 127, in __call__
TypeError: __call__() takes exactly 3 arguments (4 given)

The reason is "getattr(meth,'func_code',None)"
acquires the "func_code" of the DTMLMethod.
Therefore, the number of arguments is faulty.
==============================================================



From zope-coders@zope.org  Fri Oct 25 23:26:32 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Fri, 25 Oct 2002 18:26:32 -0400
Subject: [ZCM] [ZC] 642/ 1 Request "installation problem Win98"
Message-ID: <E185CuW-0005cl-00@mail.python.org>

Issue #642 Update (Request) "installation problem Win98"
 Status Pending, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/642

==============================================================
= Request - Entry #1 by Anonymous User on Oct 25, 2002 6:26 pm

I had installed a previous version of Zope.
All was fine.
Then I unstalled it.
Then I installed a 2.5 and now a 2.6 version:
I do not get the icon on the office,
neither an entry in the Program list and
trying to run the Zope start.bat by cliking, It hangs
(this is normal: start.bat waits for parameters!)
Note that I have a 2.1 stand alone Python installed.
Can someone help me?
Many thanks, I need Zope !!!
Patrice.

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



From zope-coders@zope.org  Fri Oct 25 23:28:51 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Fri, 25 Oct 2002 18:28:51 -0400
Subject: [ZCM] [ZC] 643/ 1 Request "Object Manager Settings Tab not present"
Message-ID: <E185Cwl-00060X-00@mail.python.org>

Issue #643 Update (Request) "Object Manager Settings Tab not present"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/643

==============================================================
= Request - Entry #1 by andym on Oct 25, 2002 6:28 pm

This bit of the changes.txt is incorrect:

"A ZMI configurable browser_default implementation has been added to ObjectManager. You can configure browser_default for OMs via a new "settings" management tab."

No such tab has been added to 2.6.
==============================================================



From zope-coders@zope.org  Sun Oct 27 16:04:12 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Sun, 27 Oct 2002 11:04:12 -0500
Subject: [ZCM] [ZC] 644/ 1 Request "initial ZODB root 'index_html' is broken HTML"
Message-ID: <E185ptc-0005Qy-00@mail.python.org>

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

==============================================================
= 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
  <head>, while the std_header puts only a title there.)

Description:
  The source of index_html:

  <dtml-var standard_html_header>
  <dtml-var zope_quick_start>
  <dtml-var standard_html_footer>

This gives, when viewed:

  <html><head>
  <base href="http://localhost:8081/" />
  <title>Zope</title></head><body bgcolor="#FFFFFF">
  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
  <html>
  <head>
  <title>Zope QuickStart</title>

  ...<snip body>...

  </body>
  </html>
  <p><a href="http://www.zope.org/Credits" target="_top">
  <img src="http://localhost:8081/p_/ZopeButton" width="115" height="50" border="0" alt="Powered by Zope" /></a></p>
  </body></html>

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



From zope-coders@zope.org  Mon Oct 28 15:08:35 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Mon, 28 Oct 2002 10:08:35 -0500
Subject: [ZCM] [ZC] 645/ 2 Reject "HEAD by  Anonymous User"
Message-ID: <E186BVL-0001fQ-00@mail.python.org>

Issue #645 Update (Reject) "HEAD by  Anonymous User"
 ** Security Related ** (Public)
 Status Rejected, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/645

==============================================================
= Reject - Entry #2 by Caseman on Oct 28, 2002 10:08 am

 Status: Pending => Rejected

This has already been fixed in cvs for 2.5, 2.6 and the HEAD. Upgrade your lib/python/webdav/Resource.py to the latest version in cvs to correct this problem.
________________________________________
= Request - Entry #1 by Anonymous User on Oct 28, 2002 7:18 am

I just discovered that the undo-log shows transactions like:
".../HEAD by  Anonymous User "
but no changes can be found in the document or the history of the document. And a document "HEAD" doesn't exist. Also there is no acl_user called "Anonymous User". But on the other hand no errors where raised.
where do these transactions come from? is there a security hole in zope that script kiddies try to exploit or what else could be the reason for these transactions?
Thanks in advance for your efforts.
Martin Fuchs, Germany
==============================================================



From zope-coders@zope.org  Mon Oct 28 18:27:34 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Mon, 28 Oct 2002 13:27:34 -0500
Subject: [ZCM] [ZC] 646/ 1 Request "metal:slot broken"
Message-ID: <E186Ebu-000430-00@mail.python.org>

Issue #646 Update (Request) "metal:slot broken"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/646

==============================================================
= Request - Entry #1 by Anonymous User on Oct 28, 2002 1:27 pm

The TAL parser doesn't recognize metal:slot anymore as a valid metal attribute. This causes templates to fail to compile. I'm not sure if this change is on purpose or not, but I think that it's a bug. At least the test suite seems to indicate this.

The fix is to add "slot" to the list of KNOWN_METAL_ATTRIBUTES on line 38 of TAL/TALDefs.py

-Amos
==============================================================



From zope-coders@zope.org  Mon Oct 28 20:47:09 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Mon, 28 Oct 2002 15:47:09 -0500
Subject: [ZCM] [ZC] 646/ 2 Resolve "metal:slot broken"
Message-ID: <E186Gmz-0000an-00@mail.python.org>

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

==============================================================
= Resolve - Entry #2 by evan on Oct 28, 2002 3:47 pm

 Status: Pending => Resolved

Fixed in trunk and 2.6 branch of CVS.  Looks like this was dropped during the i18n merge.
________________________________________
= Request - Entry #1 by Anonymous User on Oct 28, 2002 1:27 pm

The TAL parser doesn't recognize metal:slot anymore as a valid metal attribute. This causes templates to fail to compile. I'm not sure if this change is on purpose or not, but I think that it's a bug. At least the test suite seems to indicate this.

The fix is to add "slot" to the list of KNOWN_METAL_ATTRIBUTES on line 38 of TAL/TALDefs.py

-Amos
==============================================================



From zope-coders@zope.org  Tue Oct 29 06:36:40 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 29 Oct 2002 01:36:40 -0500
Subject: [ZCM] [ZC] 647/ 1 Request "page template textarea resize broken"
Message-ID: <E186PzU-0000Iv-00@mail.python.org>

Issue #647 Update (Request) "page template textarea resize broken"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/647

==============================================================
= Request - Entry #1 by Anonymous User on Oct 29, 2002 1:36 am

Attempts to resize a pagetemplate edit area by height fail.  Something about calling int("100%"). Unfortunately, I do not understand what the intentions are in the pt_changePrefs method so I cannot submit a patch.

Why is this capability implemented seperately in ZopePageTemplate and DTMLMethod?
==============================================================



From zope-coders@zope.org  Tue Oct 29 10:16:28 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 29 Oct 2002 05:16:28 -0500
Subject: [ZCM] [ZC] 626/ 2 Comment "localzone DateTime bug?"
Message-ID: <E186TQC-0005Q0-00@mail.python.org>

Issue #626 Update (Comment) "localzone DateTime bug?"
 Status Pending, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/626

==============================================================
= Comment - Entry #2 by chrisw on Oct 29, 2002 5:16 am

I think Lennart knows about this...
________________________________________
= Request - Entry #1 by Anonymous User on Oct 19, 2002 2:11 am

create a dtml method with dtml-sendmail.  view the page
we'll get:
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 OFS.DTMLMethod, line 126, in __call__ 
Module DocumentTemplate.DT_String, line 474, in __call__ 
Module Products.MailHost.SendMailTag, line 115, in render 
Module Products.MailHost.MailHost, line 123, in send 
Module Products.MailHost.MailHost, line 208, in _mungeHeaders 
Module DateTime.DateTime, line 1441, in rfc822 
NameError: global name 'localzone' is not defined 


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



From zope-coders@zope.org  Tue Oct 29 10:16:50 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 29 Oct 2002 05:16:50 -0500
Subject: [ZCM] [ZC] 626/ 3 Assign "localzone DateTime bug?"
Message-ID: <E186TQY-0005QF-00@mail.python.org>

Issue #626 Update (Assign) "localzone DateTime bug?"
 Status Accepted, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/626

==============================================================
= Assign - Entry #3 by chrisw on Oct 29, 2002 5:16 am

 Status: Pending => Accepted

 Supporters added: regebro

I think Lennart knows about this...
________________________________________
= Comment - Entry #2 by chrisw on Oct 29, 2002 5:16 am

I think Lennart knows about this...
________________________________________
= Request - Entry #1 by Anonymous User on Oct 19, 2002 2:11 am

create a dtml method with dtml-sendmail.  view the page
we'll get:
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 OFS.DTMLMethod, line 126, in __call__ 
Module DocumentTemplate.DT_String, line 474, in __call__ 
Module Products.MailHost.SendMailTag, line 115, in render 
Module Products.MailHost.MailHost, line 123, in send 
Module Products.MailHost.MailHost, line 208, in _mungeHeaders 
Module DateTime.DateTime, line 1441, in rfc822 
NameError: global name 'localzone' is not defined 


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



From zope-coders@zope.org  Tue Oct 29 10:29:15 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 29 Oct 2002 05:29:15 -0500
Subject: [ZCM] [ZC] 626/ 4 Resolve "localzone DateTime bug?"
Message-ID: <E186TcZ-0008RI-00@mail.python.org>

Issue #626 Update (Resolve) "localzone DateTime bug?"
 Status Resolved, Zope/bug critical
To followup, visit:
  http://collector.zope.org/Zope/626

==============================================================
= Resolve - Entry #4 by regebro on Oct 29, 2002 5:29 am

 Status: Accepted => Resolved

This is already fixed in the CVS. A bugfix can be found at http://www.zope.org/Members/regebro/datetime_260_fix and the fix will be included in the next release.
________________________________________
= Assign - Entry #3 by chrisw on Oct 29, 2002 5:16 am

 Status: Pending => Accepted

 Supporters added: regebro

I think Lennart knows about this...
________________________________________
= Comment - Entry #2 by chrisw on Oct 29, 2002 5:16 am

I think Lennart knows about this...
________________________________________
= Request - Entry #1 by Anonymous User on Oct 19, 2002 2:11 am

create a dtml method with dtml-sendmail.  view the page
we'll get:
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 OFS.DTMLMethod, line 126, in __call__ 
Module DocumentTemplate.DT_String, line 474, in __call__ 
Module Products.MailHost.SendMailTag, line 115, in render 
Module Products.MailHost.MailHost, line 123, in send 
Module Products.MailHost.MailHost, line 208, in _mungeHeaders 
Module DateTime.DateTime, line 1441, in rfc822 
NameError: global name 'localzone' is not defined 


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



From zope-coders@zope.org  Tue Oct 29 10:30:02 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 29 Oct 2002 05:30:02 -0500
Subject: [ZCM] [ZC] 411/ 4 Resolve "DateTime.rfc822 is not rfc822 compliant"
Message-ID: <E186TdK-000083-00@mail.python.org>

Issue #411 Update (Resolve) "DateTime.rfc822 is not rfc822 compliant"
 Status Resolved, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/411

==============================================================
= Resolve - Entry #4 by regebro on Oct 29, 2002 5:29 am

 Status: Accepted => Resolved

Fixed
________________________________________
= Comment - Entry #3 by Torped on Oct 15, 2002 2:44 pm

A fix is submitted and will be included in Zope 2.6. The correct time zone will be included when the timezone is the same as the server, and otherwise timezone information will not be included (marked by -0000).
________________________________________
= Accept - Entry #2 by regebro on Oct 14, 2002 11:31 am

 Status: Pending => Accepted

 Supporters added: regebro

You are correct. MailHost now adds a Date header if it is missing, so dtml-sendmail will now include the mail. Fixing DateTime.rfc822() is more complex though, so I haven't fixed that yet. 

One ugly possibility is to set the zone to -0000, which will make it compliant, but loose the time zone information...
________________________________________
= Request - Entry #1 by Anonymous User on May 31, 2002 12:04 pm

It produces (for example): Fri, 31 May 2002 17:00:05 GMT+1
Whereas it should be: Fri, 31 May 2002 17:00:05 +0100
In the time zone you can have letters (e.g. GMT) or numbers (e.g. +0100) but not both, and the numbers must be in the sign-and-4-digit format.
The numbers-only format is preferable, as that what most e-mail messages have.
I notice the <dtml-sendmail> example conveniently misses out the date.

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



From zope-coders@zope.org  Tue Oct 29 16:40:40 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 29 Oct 2002 11:40:40 -0500
Subject: [ZCM] [ZC] 597/ 2 Comment "ZCTextIndex doesn't use LOCALE for splitting text"
Message-ID: <E186ZQ0-0008EW-00@mail.python.org>

Issue #597 Update (Comment) "ZCTextIndex doesn't use LOCALE for splitting text"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/597

==============================================================
= Comment - Entry #2 by dedalu on Oct 29, 2002 11:40 am

This patch works fine here. If we want TextIndex deprecated, it must be included on next release.

Ty, mjablonski
________________________________________
= Request - Entry #1 by mjablonski on Sep 30, 2002 2:12 am

ZCTextIndex doesn't use the LOCALE-Flag in regexps for splitting words. Problem for all users who need more than ASCII-Splitting... for example all the german ones...;-)

Patches:

::HTMLSplitter.py:

::line 24

def process(self, text, wordpat=r"(?L)\w+"):

::line 31

return self.process(text, r"(?L)\w+[\w*?]*") # see Lexicon.globToWordIds()

::Lexicon.py:

::line 159

rx = re.compile(r"(?L)\w+")

::line 160

rxGlob = re.compile(r"(?L)\w+[\w*?]*") # See globToWordIds() above

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



From zope-coders@zope.org  Tue Oct 29 16:50:49 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 29 Oct 2002 11:50:49 -0500
Subject: [ZCM] [ZC] 648/ 1 Request "Contained ZClass can't be selected as Subobjects"
Message-ID: <E186ZZp-0001Eq-00@mail.python.org>

Issue #648 Update (Request) "Contained ZClass can't be selected as Subobjects"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/648

==============================================================
= Request - Entry #1 by to_be on Oct 29, 2002 11:50 am

We have a product (Zope 2.5.1) which contains ZClasses which contain other ZClasses; e. g. the ourGallery class contains an ourImage class. The only object type to be added to an ourGallery is an ourImage. This way every ourImage is contained in an ourGallery.

Since I couldn't import the class, I tried to re-implement it in Zope 2.6.0. Unfortunately it doesn't seem to be possible to select the Image class in the Subobjects tab of the Gallery class; it is simply not there.
==============================================================



From zope-coders@zope.org  Tue Oct 29 17:08:34 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 29 Oct 2002 12:08:34 -0500
Subject: [ZCM] [ZC] 649/ 1 Request "Problem with structured text and unicode accented chars"
Message-ID: <E186Zr0-0005Wj-00@mail.python.org>

Issue #649 Update (Request) "Problem with structured text and unicode accented chars"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/649

==============================================================
= Request - Entry #1 by Anonymous User on Oct 29, 2002 12:08 pm

Since version 2.6.0 STX format are broken by accented chars with unicode text even if zope is launched with the -L "fr_FR.UTF-8" flag (the locale is generated of course).

Note that I used to launch zope 2.5.1 with -L "fr_FR.ISO-8859-1" wich worked correctly.
The pages are correctly seen of any browser (IEx on Mac + PC, Mozilla, Netscape 4x) with the UTF-8 encoding, so I'm pretty sure that the text is unicode encoded.

What did I wrong ?  
==============================================================



From zope-coders@zope.org  Tue Oct 29 17:13:23 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 29 Oct 2002 12:13:23 -0500
Subject: [ZCM] [ZC] 649/ 2 Comment "Problem with structured text and unicode accented chars"
Message-ID: <E186Zvf-0006Mh-00@mail.python.org>

Issue #649 Update (Comment) "Problem with structured text and unicode accented chars"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/649

==============================================================
= Comment - Entry #2 by ajung on Oct 29, 2002 12:13 pm

STXNG does not handle unicode or utf-8 encoded text.
It is very unlikely that this will be fixed.

-aj

________________________________________
= Request - Entry #1 by Anonymous User on Oct 29, 2002 12:08 pm

Since version 2.6.0 STX format are broken by accented chars with unicode text even if zope is launched with the -L "fr_FR.UTF-8" flag (the locale is generated of course).

Note that I used to launch zope 2.5.1 with -L "fr_FR.ISO-8859-1" wich worked correctly.
The pages are correctly seen of any browser (IEx on Mac + PC, Mozilla, Netscape 4x) with the UTF-8 encoding, so I'm pretty sure that the text is unicode encoded.

What did I wrong ?  
==============================================================



From zope-coders@zope.org  Tue Oct 29 17:28:08 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 29 Oct 2002 12:28:08 -0500
Subject: [ZCM] [ZC] 597/ 3 Comment "ZCTextIndex doesn't use LOCALE for splitting text"
Message-ID: <E186a9w-0000aN-00@mail.python.org>

Issue #597 Update (Comment) "ZCTextIndex doesn't use LOCALE for splitting text"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/597

==============================================================
= Comment - Entry #3 by Caseman on Oct 29, 2002 12:28 pm

I would suggest checking this in on the HEAD and 2.6 branch (assuming the tests still pass) and adding additional LOCALE unittests to exercise this functionality and demonstrate its correctness.
________________________________________
= Comment - Entry #2 by dedalu on Oct 29, 2002 11:40 am

This patch works fine here. If we want TextIndex deprecated, it must be included on next release.

Ty, mjablonski
________________________________________
= Request - Entry #1 by mjablonski on Sep 30, 2002 2:12 am

ZCTextIndex doesn't use the LOCALE-Flag in regexps for splitting words. Problem for all users who need more than ASCII-Splitting... for example all the german ones...;-)

Patches:

::HTMLSplitter.py:

::line 24

def process(self, text, wordpat=r"(?L)\w+"):

::line 31

return self.process(text, r"(?L)\w+[\w*?]*") # see Lexicon.globToWordIds()

::Lexicon.py:

::line 159

rx = re.compile(r"(?L)\w+")

::line 160

rxGlob = re.compile(r"(?L)\w+[\w*?]*") # See globToWordIds() above

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



From zope-coders@zope.org  Tue Oct 29 17:45:57 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 29 Oct 2002 12:45:57 -0500
Subject: [ZCM] [ZC] 648/ 2 Comment "Contained ZClass can't be selected as Subobjects"
Message-ID: <E186aRB-0005Rq-00@mail.python.org>

Issue #648 Update (Comment) "Contained ZClass can't be selected as Subobjects"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/648

==============================================================
= Comment - Entry #2 by stevea on Oct 29, 2002 12:45 pm

Don't define ZClasses nested within other ZClasses.

I'm sorry that this doesn't help you a whole lot. Your development will be much easier if you use ZClasses only for simple things, and use a filesystem-based Python product for more complex things.

________________________________________
= Request - Entry #1 by to_be on Oct 29, 2002 11:50 am

We have a product (Zope 2.5.1) which contains ZClasses which contain other ZClasses; e. g. the ourGallery class contains an ourImage class. The only object type to be added to an ourGallery is an ourImage. This way every ourImage is contained in an ourGallery.

Since I couldn't import the class, I tried to re-implement it in Zope 2.6.0. Unfortunately it doesn't seem to be possible to select the Image class in the Subobjects tab of the Gallery class; it is simply not there.
==============================================================



From zope-coders@zope.org  Tue Oct 29 17:53:04 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 29 Oct 2002 12:53:04 -0500
Subject: [ZCM] [ZC] 648/ 3 Comment "Contained ZClass can't be selected as Subobjects"
Message-ID: <E186aY4-00084B-00@mail.python.org>

Issue #648 Update (Comment) "Contained ZClass can't be selected as Subobjects"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/648

==============================================================
= Comment - Entry #3 by stevea on Oct 29, 2002 12:53 pm

On re-reading, I think I misunderstood what you are reporting. My apologies.

You're saying that your ZClass (defined inside your product) is not appearing in subobjects lists of an ObjectManager-derived ZClass.


________________________________________
= Comment - Entry #2 by stevea on Oct 29, 2002 12:45 pm

Don't define ZClasses nested within other ZClasses.

I'm sorry that this doesn't help you a whole lot. Your development will be much easier if you use ZClasses only for simple things, and use a filesystem-based Python product for more complex things.

________________________________________
= Request - Entry #1 by to_be on Oct 29, 2002 11:50 am

We have a product (Zope 2.5.1) which contains ZClasses which contain other ZClasses; e. g. the ourGallery class contains an ourImage class. The only object type to be added to an ourGallery is an ourImage. This way every ourImage is contained in an ourGallery.

Since I couldn't import the class, I tried to re-implement it in Zope 2.6.0. Unfortunately it doesn't seem to be possible to select the Image class in the Subobjects tab of the Gallery class; it is simply not there.
==============================================================



From zope-coders@zope.org  Tue Oct 29 22:55:23 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Tue, 29 Oct 2002 17:55:23 -0500
Subject: [ZCM] [ZC] 650/ 1 Request "lists of tainted values in query string kill processInputs"
Message-ID: <E186fGd-0004dc-00@mail.python.org>

Issue #650 Update (Request) "lists of tainted values in query string kill processInputs"
 Status Pending, Zope/bug+solution medium
To followup, visit:
  http://collector.zope.org/Zope/650

==============================================================
= Request - Entry #1 by Anonymous User on Oct 29, 2002 5:55 pm

The issue: lists of tainted values in HTTP_QUERY_STRING won't survive. That is,
multiple parameters from the web with the same key value, thet contain '<'
symbols kill the parser so your script won't even get executed.
It generates an AttributeError on "append" with the following stack trace:
[//ZServer/medusa/asyncore.py|poll|94]
[//ZServer/medusa/asyncore.py|handle_read_event|395]
[//ZServer/UserListServer.py|handle_read|83]
[//ZServer/UserListServer.py|calc_reply|120]
[//lib/python/ZPublisher/Publish.py|publish|114]
[//lib/python/Zope/__init__.py|zpublisher_exception_hook|171]
[//lib/python/ZPublisher/Publish.py|publish|63]
[//lib/python/ZPublisher/HTTPRequest.py|processInputs|763]
[//lib/python/ZPublisher/TaintedString.py|__getattr__|89])

I digged around a bit in the source, and it seems the problem is in
processInputs. 'append' is called on a string, which should be a list, but is
initialized wrongly in another part of processInputs.
Following is a patch to fix the issue in lib/python/ZPublisher/HTTPRequest.py
--- HTTPRequest.py.old  2002-10-28 20:13:40.000000000 +0100
+++ HTTPRequest.py.new  2002-10-28 20:14:32.000000000 +0100
@@ -780,7 +780,7 @@
                     else:
                         mapping_object[key]=item
                         if tainted:
-                            taintedform[tainted_key] = tainted
+                            taintedform[tainted_key] = [tainted]
 
             #insert defaults into form dictionary
             if defaults:


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



From zope-coders@zope.org  Wed Oct 30 10:18:47 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Wed, 30 Oct 2002 05:18:47 -0500
Subject: [ZCM] [ZC] 648/ 4 Comment "Contained ZClass can't be selected as Subobjects"
Message-ID: <E186pvz-0002yb-00@mail.python.org>

Issue #648 Update (Comment) "Contained ZClass can't be selected as Subobjects"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/648

==============================================================
= Comment - Entry #4 by to_be on Oct 30, 2002 5:18 am

It's a problem of nested ZClasses. Ok, it would have been better to do it with a Python product, but to newbies ZClasses are easyer to create, and it's a bug anyway.

The structure:
Product
`--ourGallery
    `--ourImage

An instance of the ourGallery ZClass should contain ourImages only. Instances of the ourImage ZClass should turn up nowhere but in an ourGallery. Since ourGallery is derived from ZObjectManager, I get a Subobjects tab, but the ourImage ZClass does not appear in the list. This used to work in Zope 2.5.1 and doesn't work anymore in Zope 2.6.0.
________________________________________
= Comment - Entry #3 by stevea on Oct 29, 2002 12:53 pm

On re-reading, I think I misunderstood what you are reporting. My apologies.

You're saying that your ZClass (defined inside your product) is not appearing in subobjects lists of an ObjectManager-derived ZClass.


________________________________________
= Comment - Entry #2 by stevea on Oct 29, 2002 12:45 pm

Don't define ZClasses nested within other ZClasses.

I'm sorry that this doesn't help you a whole lot. Your development will be much easier if you use ZClasses only for simple things, and use a filesystem-based Python product for more complex things.

________________________________________
= Request - Entry #1 by to_be on Oct 29, 2002 11:50 am

We have a product (Zope 2.5.1) which contains ZClasses which contain other ZClasses; e. g. the ourGallery class contains an ourImage class. The only object type to be added to an ourGallery is an ourImage. This way every ourImage is contained in an ourGallery.

Since I couldn't import the class, I tried to re-implement it in Zope 2.6.0. Unfortunately it doesn't seem to be possible to select the Image class in the Subobjects tab of the Gallery class; it is simply not there.
==============================================================



From zope-coders@zope.org  Thu Oct 31 05:18:57 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Thu, 31 Oct 2002 00:18:57 -0500
Subject: [ZCM] [ZC] 651/ 1 Request "davLockManager.dtml error"
Message-ID: <E1877jN-0004Tv-00@mail.python.org>

Issue #651 Update (Request) "davLockManager.dtml error"
 Status Pending, Zope/bug+solution medium
To followup, visit:
  http://collector.zope.org/Zope/651

==============================================================
= Request - Entry #1 by Anonymous User on Oct 31, 2002 12:18 am

When in the management interface, going to the control panel and then clicking WebDAV Lock Manager will generate an error.

To fix, change the file /usr/local/Zope/lib/python/App/dtml/davLockManager.dtml.

Line 28 from:
<dtml-let lockedobjs="REQUEST.form.has_key('frompath','') and findLockedObjects(frompath=REQUEST.get('frompath','')) or []">

to:

<dtml-let lockedobjs="REQUEST.form.has_key('frompath') and findLockedObjects(frompath=REQUEST.get('frompath','')) or []">
==============================================================



From zope-coders@zope.org  Thu Oct 31 14:25:14 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Thu, 31 Oct 2002 09:25:14 -0500
Subject: [ZCM] [ZC] 651/ 2 Resolve "davLockManager.dtml error"
Message-ID: <E187GG2-0000JH-00@mail.python.org>

Issue #651 Update (Resolve) "davLockManager.dtml error"
 Status Resolved, Zope/bug+solution medium
To followup, visit:
  http://collector.zope.org/Zope/651

==============================================================
= Resolve - Entry #2 by chrisw on Oct 31, 2002 9:25 am

 Status: Pending => Resolved

Fixed in CVS HEAD and 2.6 branches.
________________________________________
= Request - Entry #1 by Anonymous User on Oct 31, 2002 12:18 am

When in the management interface, going to the control panel and then clicking WebDAV Lock Manager will generate an error.

To fix, change the file /usr/local/Zope/lib/python/App/dtml/davLockManager.dtml.

Line 28 from:
<dtml-let lockedobjs="REQUEST.form.has_key('frompath','') and findLockedObjects(frompath=REQUEST.get('frompath','')) or []">

to:

<dtml-let lockedobjs="REQUEST.form.has_key('frompath') and findLockedObjects(frompath=REQUEST.get('frompath','')) or []">
==============================================================



From zope-coders@zope.org  Thu Oct 31 18:28:28 2002
From: zope-coders@zope.org (Collector: Zope Bugs, Features, and Patches ...)
Date: Thu, 31 Oct 2002 13:28:28 -0500
Subject: [ZCM] [ZC] 652/ 1 Request "img id is copied to title during creation"
Message-ID: <E187K3Q-0000E0-00@mail.python.org>

Issue #652 Update (Request) "img id is copied to title during creation"
 Status Pending, Zope/bug low
To followup, visit:
  http://collector.zope.org/Zope/652

==============================================================
= Request - Entry #1 by to_be on Oct 31, 2002 1:28 pm

When an image is created through the ZMI and no title is specified, the id is copied to the title. This doesn't make sense. If the image is left unchanged, the tag method creates both an alt and a title attribute with the value of the id.

It doesn't make sense to create a default title. The title of images is displayed on mouseOver and should contain a description or nothing, but not the id. Instead, an (empty!) alt property should be created during image creation.
==============================================================