[Zope-CMF] cmf-tests - OK: 2, UNKNOWN: 2
This is the summary for test reports received on the cmf-tests list between 2012-04-10 00:00:00 UTC and 2012-04-11 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received CMF-2.2 Zope-2.12 Python-2.6.6 : Linux CMF-2.2 Zope-2.13 Python-2.6.6 : Linux [1]FAILED (failures=1) : CMF-trunk Zope-2.13 Python-2.6.6 : Linux [2]FAILED (failures=1) : CMF-trunk Zope-trunk Python-2.6.6 : Linux Non-OK results -- [1]UNKNOWN FAILED (failures=1) : CMF-trunk Zope-2.13 Python-2.6.6 : Linux https://mail.zope.org/pipermail/cmf-tests/2012-April/016080.html [2]UNKNOWN FAILED (failures=1) : CMF-trunk Zope-trunk Python-2.6.6 : Linux https://mail.zope.org/pipermail/cmf-tests/2012-April/016081.html ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] cmf-tests - OK: 2, UNKNOWN: 2
Am 11.04.2012, 17:06 Uhr, schrieb Charlie Clark : I can't reproduce the other failures. Thanks for looking. I'll do clean checkout and buildout and see if that makes any difference. I can reproduce the errors on CMF trunk with Zope trunk on Mac OS, Debian and FreeBSD. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] cmf-tests - OK: 2, UNKNOWN: 2
Am 11.04.2012, 16:03 Uhr, schrieb yuppie : It wasn't a blank line. You removed whitespace in rev 125119: Modified: Products.CMFDefault/trunk/Products/CMFDefault/tests/test_utils.py === --- Products.CMFDefault/trunk/Products/CMFDefault/tests/test_utils.py 2012-04-09 16:16:46 UTC (rev 125118) +++ Products.CMFDefault/trunk/Products/CMFDefault/tests/test_utils.py 2012-04-09 16:30:40 UTC (rev 125119) @@ -27,7 +27,7 @@ MULTIPARAGRAPH_DESCRIPTION = \ '''Description: this description spans multiple lines. - + It includes a second paragraph''' Doh, it was my editor what done it! (Configured to remove my bête noire of trailing) whitespace). I added some whitespace back in. I can't make any sense from the RFC whether this should actually be supported but for our purposes we need to keep it. Do you any examples of where this behaviour is required? I can't reproduce the other failures. Thanks for looking. I'll do clean checkout and buildout and see if that makes any difference. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] cmf-tests - OK: 2, UNKNOWN: 2
Hi Charlie! Charlie Clark wrote: Am 11.04.2012, 03:00 Uhr, schrieb CMF tests summarizer : [1] UNKNOWN FAILED (failures=1) : CMF-trunk Zope-2.13 Python-2.6.6 : Linux https://mail.zope.org/pipermail/cmf-tests/2012-April/016076.html [2] UNKNOWN FAILED (failures=1) : CMF-trunk Zope-trunk Python-2.6.6 : Linux https://mail.zope.org/pipermail/cmf-tests/2012-April/016077.html I noticed this the other day but thought it might be related to my configuration. Even though I'm on Python 2.6.7 Failure in test test_parseHeadersBody_embedded_blank_line (Products.CMFDefault.tests.test_utils.DefaultUtilsTests) Traceback (most recent call last): File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 279, in run testMethod() File "/Users/charlieclark/Sites/CMF/src/Products.CMFDefault/Products/CMFDefault/tests/test_utils.py", line 85, in test_parseHeadersBody_embedded_blank_line self.assertEqual( desc_len, 3, desc_lines ) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 350, in failUnlessEqual (msg or '%r != %r' % (first, second)) AssertionError: ['this description spans multiple lines.'] This is weird because all of a sudden blank lines in headers are being treated as separators, as they should. Why wasn't the test failing earlier? It wasn't a blank line. You removed whitespace in rev 125119: Modified: Products.CMFDefault/trunk/Products/CMFDefault/tests/test_utils.py === --- Products.CMFDefault/trunk/Products/CMFDefault/tests/test_utils.py 2012-04-09 16:16:46 UTC (rev 125118) +++ Products.CMFDefault/trunk/Products/CMFDefault/tests/test_utils.py 2012-04-09 16:30:40 UTC (rev 125119) @@ -27,7 +27,7 @@ MULTIPARAGRAPH_DESCRIPTION = \ '''Description: this description spans multiple lines. - + It includes a second paragraph''' I can't reproduce the other failures. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] cmf-tests - OK: 2, UNKNOWN: 2
Am 11.04.2012, 03:00 Uhr, schrieb CMF tests summarizer : [1]UNKNOWN FAILED (failures=1) : CMF-trunk Zope-2.13 Python-2.6.6 : Linux https://mail.zope.org/pipermail/cmf-tests/2012-April/016076.html [2]UNKNOWN FAILED (failures=1) : CMF-trunk Zope-trunk Python-2.6.6 : Linux https://mail.zope.org/pipermail/cmf-tests/2012-April/016077.html I noticed this the other day but thought it might be related to my configuration. Even though I'm on Python 2.6.7 Failure in test test_parseHeadersBody_embedded_blank_line (Products.CMFDefault.tests.test_utils.DefaultUtilsTests) Traceback (most recent call last): File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 279, in run testMethod() File "/Users/charlieclark/Sites/CMF/src/Products.CMFDefault/Products/CMFDefault/tests/test_utils.py", line 85, in test_parseHeadersBody_embedded_blank_line self.assertEqual( desc_len, 3, desc_lines ) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 350, in failUnlessEqual (msg or '%r != %r' % (first, second)) AssertionError: ['this description spans multiple lines.'] This is weird because all of a sudden blank lines in headers are being treated as separators, as they should. Why wasn't the test failing earlier? Testing directly with the RFC822 module shows that blank lines indicate the end of the headers: Message.headers A list containing the entire set of header lines, in the order in which they were read (except that setitem calls may disturb this order). Each line contains a trailing newline. The blank line terminating the headers is not contained in the list rfc = rfc822.Message(msg) rfc.headers ['Author: Tres Seaver\n', 'Title: Test Products.CMFDefault.utils.parseHeadersBody\n', 'Description: this description spans multiple lines.\n', 'It includes a second paragraph\n', 'And a third\n'] From the docs: Message.headers A list containing the entire set of header lines, in the order in which they were read (except that setitem calls may disturb this order). Each line contains a trailing newline. The blank line terminating the headers is not contained in the list. I think the test has to be fixed to show that blank lines are not supported. Or, we go back to parsing the headers ourselves. A couple of questions: should the function be updated to use the Mail module? And should we drop the unused regex from the signature? *** I'm also getting local failures on the Discussions tests: Failure in test test_deletePropagation (Products.CMFDefault.tests.test_Discussions.DiscussionTests) Traceback (most recent call last): File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 279, in run testMethod() File "/Users/charlieclark/Sites/CMF/src/Products.CMFDefault/Products/CMFDefault/tests/test_Discussions.py", line 260, in test_deletePropagation self.assertEqual( len(ctool), 2 ) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 350, in failUnlessEqual (msg or '%r != %r' % (first, second)) AssertionError: 1 != 2 Failure in test test_deleteReplies (Products.CMFDefault.tests.test_Discussions.DiscussionTests) Traceback (most recent call last): File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 279, in run testMethod() File "/Users/charlieclark/Sites/CMF/src/Products.CMFDefault/Products/CMFDefault/tests/test_Discussions.py", line 299, in test_deleteReplies self.assertEqual(len(ctool), 7) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 350, in failUnlessEqual (msg or '%r != %r' % (first, second)) AssertionError: 6 != 7 Failure in test test_itemCataloguing (Products.CMFDefault.tests.test_Discussions.DiscussionTests) Traceback (most recent call last): File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 279, in run testMethod() File "/Users/charlieclark/Sites/CMF/src/Products.CMFDefault/Products/CMFDefault/tests/test_Discussions.py", line 185, in test_itemCataloguing self.assertEqual( len(ctool), 1 ) File "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 350, in failUnlessEqual (msg or '%r != %r' % (first, second)) AssertionError: 0 != 1 And finally the functional tests won't run: Running Products.CMFDefault.testing.FunctionalLayer tests: Tear down Products.CMFCore.testing.EventZCMLLayer in 0.000 seconds. Set up Products.CMFCore.testing.FunctionalZCMLLayer in 0.400 seconds. Set up Products.CMFDefault.testing.FunctionalLayer Traceback (most recent call last): File "/Users/charlieclark/Sites/CMF/eggs/zope.testrunner-4.0.4-py2.6.egg/zope/testrunne
Re: [Zope-CMF] 2.3
Am 11.04.2012, 10:16 Uhr, schrieb yuppie : Just a general remark: The last time we added a warning to getToolByName it had to be taken back out. The protest was too big. No one wanted to spend the time on all the third-party packages that still use that API. What's worse, back then even the CMF packages were not switched to a pure utility model and would emit these warnings as well. I think I remember. No warning then. We've still got a few instances of methods (in ActionsTool) using it but I'm torn between replacing them with the utility lookup plus fallback or leaving them as they are for 2.3 and changing them without fallback later. The current code provides an elegant lookup with fallback. AFAICS the only thing we need to do for backwards compatibility is using registerToolInterface. So it isn't urgent to deprecate and remove getToolByName. Okay. It might be useful to write a howto for people who want to modernize their code. Definitely. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a Düsseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] 2.3
Hi! Jens Vagelpohl wrote: On Apr 9, 2012, at 23:10 , Charlie Clark wrote: Am 22.03.2012, 13:28 Uhr, schrieb yuppie: The tools are *local* utilities. Including the ZCML doesn't fix this issue. You have to run the upgrade step. Should we add a warning to CMFTools.utils.getToolByName? To use getUtility and the interface instead? Just a general remark: The last time we added a warning to getToolByName it had to be taken back out. The protest was too big. No one wanted to spend the time on all the third-party packages that still use that API. What's worse, back then even the CMF packages were not switched to a pure utility model and would emit these warnings as well. AFAICS the only thing we need to do for backwards compatibility is using registerToolInterface. So it isn't urgent to deprecate and remove getToolByName. It might be useful to write a howto for people who want to modernize their code. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] 2.3
On Apr 9, 2012, at 23:10 , Charlie Clark wrote: > Am 22.03.2012, 13:28 Uhr, schrieb yuppie : > >> The tools are *local* utilities. Including the ZCML doesn't fix this issue. >> You have to run the upgrade step. > > Should we add a warning to CMFTools.utils.getToolByName? To use getUtility > and the interface instead? Just a general remark: The last time we added a warning to getToolByName it had to be taken back out. The protest was too big. No one wanted to spend the time on all the third-party packages that still use that API. What's worse, back then even the CMF packages were not switched to a pure utility model and would emit these warnings as well. jens ___ Zope-CMF maillist - Zope-CMF@zope.org https://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
