This is the summary for test reports received on the zope-tests list between 2013-03-05 00:00:00 UTC and 2013-03-06 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 ---------------- [1] Still Failing - zopetoolkit_trunk - Build # 193 winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 [2] winbot / z3c.contents_py_265_32 [3] winbot / z3c.formui_py_265_32 [4] winbot / z3c.language.switch_py_265_32 [5] winbot / z3c.layer.ready2go_py_265_32 [6] winbot / z3c.pagelet_py_265_32 [7] winbot / zc.resourcelibrary_py_265_32 [8] winbot / zope.app.http_py_265_32 [9] winbot / zope.app.pagetemplate_py_265_32 [10] winbot / zope.app.renderer_py_265_32 [11] winbot / zope.browserpage_py_265_32 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 Non-OK results -------------- [1] FAILED Still Failing - zopetoolkit_trunk - Build # 193 https://mail.zope.org/pipermail/zope-tests/2013-March/073094.html [2] FAILED winbot / z3c.contents_py_265_32 https://mail.zope.org/pipermail/zope-tests/2013-March/073091.html [3] FAILED winbot / z3c.formui_py_265_32 https://mail.zope.org/pipermail/zope-tests/2013-March/073090.html [4] FAILED winbot / z3c.language.switch_py_265_32 https://mail.zope.org/pipermail/zope-tests/2013-March/073092.html [5] FAILED winbot / z3c.layer.ready2go_py_265_32 https://mail.zope.org/pipermail/zope-tests/2013-March/073087.html [6] FAILED winbot / z3c.pagelet_py_265_32 https://mail.zope.org/pipermail/zope-tests/2013-March/073088.html [7] FAILED winbot / zc.resourcelibrary_py_265_32 https://mail.zope.org/pipermail/zope-tests/2013-March/073108.html [8] FAILED winbot / zope.app.http_py_265_32 https://mail.zope.org/pipermail/zope-tests/2013-March/073107.html [9] FAILED winbot / zope.app.pagetemplate_py_265_32 https://mail.zope.org/pipermail/zope-tests/2013-March/073093.html [10] FAILED winbot / zope.app.renderer_py_265_32 https://mail.zope.org/pipermail/zope-tests/2013-March/073089.html [11] FAILED winbot / zope.browserpage_py_265_32 https://mail.zope.org/pipermail/zope-tests/2013-March/073109.html
On Thu, Mar 07, 2013 at 01:00:02AM +0000, Zope tests summarizer wrote:
[1] Still Failing - zopetoolkit_trunk - Build # 193 https://mail.zope.org/pipermail/zope-tests/2013-March/073094.html
The usual ./bin/buildout -t 3 -v -c development-python.cfg failing because there's no development-python.cfg in SVN. There's a development-python2.cfg (rather new, added 3 days ago) and a development.cfg (which is older). Typo in the Jenkins job build steps?
[2] winbot / z3c.contents_py_265_32 [3] winbot / z3c.formui_py_265_32 [6] winbot / z3c.pagelet_py_265_32 [5] winbot / z3c.layer.ready2go_py_265_32
lxml
[4] winbot / z3c.language.switch_py_265_32
Latest build is green!
[7] winbot / zc.resourcelibrary_py_265_32
The usual weirdness with WindowsError.
[8] winbot / zope.app.http_py_265_32
Hm, HEAD is now at 9df6d04 Pin zope.app.wsgi to <4.0dev to avoid test failures and then a failure in File "c:\eggs\zope.app.wsgi-4.0.0a3-py2.6.egg\zope\app\wsgi\testlayer.py", line 21, in <module> so the pin didn't take effect. Huh? I see bin/buildout is version 1.7 on buildout, despite my replacing of bootstrap.py with the latest http://downloads.buildout.org/2/bootstrap.py. Why? The same fix worked for zope.app.publication somehow. Despite it also using zc.buildout 1.7, despite my latest bootstrap. Or did it? Nope, but that build happened four minutes after midnight and didn't make it into this build summary. Oh, right, the bootstrap step is c:\Python26_32\python.exe c:\buildmaster\bootstrap.py everything is clear now. (Including the fact that most packages I try to build locally fail because their bootstrap is too old. I was wondering why they didn't fail en-masse on winbot.)
[9] winbot / zope.app.pagetemplate_py_265_32 [11] winbot / zope.browserpage_py_265_32
\r\n
[10] winbot / zope.app.renderer_py_265_32
Renamed to zope.renderer. Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development
On 03/07/2013 09:51 AM, Marius Gedminas wrote:
On Thu, Mar 07, 2013 at 01:00:02AM +0000, Zope tests summarizer wrote:
Oh, right, the bootstrap step is
c:\Python26_32\python.exe c:\buildmaster\bootstrap.py
everything is clear now.
(Including the fact that most packages I try to build locally fail because their bootstrap is too old. I was wondering why they didn't fail en-masse on winbot.)
Ohh yeah, there's some crap laying around regarding bootstraps. This was the easy solution. Now that we seem to care about the packages again I could switch it back to the package's own bootstrap. Opinions? -- Best regards, Adam GROSZER -- Quote of the day: Faith on a full stomach may be simply contentment- but if you have it when you're hungry, it's genuine. - Frank A. Clark
On Thu, Mar 07, 2013 at 10:05:30AM +0100, Adam GROSZER wrote:
On 03/07/2013 09:51 AM, Marius Gedminas wrote:
On Thu, Mar 07, 2013 at 01:00:02AM +0000, Zope tests summarizer wrote:
Oh, right, the bootstrap step is
c:\Python26_32\python.exe c:\buildmaster\bootstrap.py
everything is clear now.
(Including the fact that most packages I try to build locally fail because their bootstrap is too old. I was wondering why they didn't fail en-masse on winbot.)
Ohh yeah, there's some crap laying around regarding bootstraps. This was the easy solution. Now that we seem to care about the packages again I could switch it back to the package's own bootstrap.
Eventually, yes. Let's not do that before we find a volunteer who will check out every package tested by buildout and see if bootstrap.py needs to be outdated. Sounds like a fun project for an afternoon. Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development
On Thu, Mar 07, 2013 at 10:51:14AM +0200, Marius Gedminas wrote:
[7] winbot / zc.resourcelibrary_py_265_32
The usual weirdness with WindowsError.
Ha ha. That's just buildout on Windows trying to report a legitimate error, which on Linux comes out as Error: Error downloading extends for URL http://svn.zope.org/repos/main/zopetoolkit/trunk/zopeapp.cfg?p=109918: (404, 'Not Found') zc.resourcelibrary's buildout.cfg has extends = http://svn.zope.org/repos/main/zopetoolkit/trunk/ztk.cfg?p=109981 http://svn.zope.org/repos/main/zopetoolkit/trunk/zopeapp.cfg?p=109918 committed three years ago, with http://zope3.pov.lt/trac/changeset/110144 Fixed. Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development
Am 07.03.2013 09:51 schrieb "Marius Gedminas" <marius@gedmin.as>:
On Thu, Mar 07, 2013 at 01:00:02AM +0000, Zope tests summarizer wrote:
[1] Still Failing - zopetoolkit_trunk - Build # 193 https://mail.zope.org/pipermail/zope-tests/2013-March/073094.html
The usual
./bin/buildout -t 3 -v -c development-python.cfg
failing because there's no development-python.cfg in SVN. There's a development-python2.cfg (rather new, added 3 days ago) and a
development.cfg
(which is older).
Typo in the Jenkins job build steps?
Its an easy to fix typo. Im just never in front of a real computer atm.
[2] winbot / z3c.contents_py_265_32 [3] winbot / z3c.formui_py_265_32 [6] winbot / z3c.pagelet_py_265_32 [5] winbot / z3c.layer.ready2go_py_265_32
lxml
[4] winbot / z3c.language.switch_py_265_32
Latest build is green!
[7] winbot / zc.resourcelibrary_py_265_32
The usual weirdness with WindowsError.
[8] winbot / zope.app.http_py_265_32
Hm,
HEAD is now at 9df6d04 Pin zope.app.wsgi to <4.0dev to avoid test
failures
and then a failure in
File
"c:\eggs\zope.app.wsgi-4.0.0a3-py2.6.egg\zope\app\wsgi\testlayer.py", line 21, in <module>
so the pin didn't take effect. Huh?
I see bin/buildout is version 1.7 on buildout, despite my replacing of bootstrap.py with the latest http://downloads.buildout.org/2/bootstrap.py. Why?
The same fix worked for zope.app.publication somehow. Despite it also using zc.buildout 1.7, despite my latest bootstrap. Or did it?
Nope, but that build happened four minutes after midnight and didn't make it into this build summary.
Oh, right, the bootstrap step is
c:\Python26_32\python.exe c:\buildmaster\bootstrap.py
everything is clear now.
(Including the fact that most packages I try to build locally fail because their bootstrap is too old. I was wondering why they didn't fail en-masse on winbot.)
[9] winbot / zope.app.pagetemplate_py_265_32 [11] winbot / zope.browserpage_py_265_32
\r\n
[10] winbot / zope.app.renderer_py_265_32
Renamed to zope.renderer.
Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
On Thursday, March 07, 2013 10:42:59 AM Patrick Gerken wrote:
[2] winbot / z3c.contents_py_265_32 [3] winbot / z3c.formui_py_265_32 [6] winbot / z3c.pagelet_py_265_32 [5] winbot / z3c.layer.ready2go_py_265_32
lxml
BTW, Adam is waiting for the Rackspace credentials, so he can make a backup of the Windows VM. Then he will install the latest MSVC version and compile eggs for the latest lxml releases. Of course, we are then pending access to PyPI. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
On Thu, Mar 07, 2013 at 10:51:14AM +0200, Marius Gedminas wrote:
[9] winbot / zope.app.pagetemplate_py_265_32 [11] winbot / zope.browserpage_py_265_32
\r\n
I made the tests accept \r\n as correct. I'm not sure that's the right thing to do. Perhaps page templates, when given a file on disk with \r\n, should normalize the line endings to \n? Opinions? Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development
On Thursday, March 07, 2013 05:46:48 PM Marius Gedminas wrote:
I'm not sure that's the right thing to do. Perhaps page templates, when given a file on disk with \r\n, should normalize the line endings to \n?
Opinions?
I think we should retain EOL characters as long as clients (i.e. browsers) understand them, which they do. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/07/2013 11:51 AM, Stephan Richter wrote:
On Thursday, March 07, 2013 05:46:48 PM Marius Gedminas wrote:
I'm not sure that's the right thing to do. Perhaps page templates, when given a file on disk with \r\n, should normalize the line endings to \n?
Opinions?
I think we should retain EOL characters as long as clients (i.e. browsers) understand them, which they do.
With template source, tools may require platform-specific line endings. For rendered HTML / XML, no tool / browser that wants to work with the 'net at large can have such expectations, which makes preserving them a non-use-case. +1 to Marius' proposal to open template files with 'U' in the mode. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlE4yVoACgkQ+gerLs4ltQ6mEgCffTFzG8t0Pj1zMjSclJAo6bKE t5oAoMvDejWwpKceqfG5ilogZfJoIdXm =Yryz -----END PGP SIGNATURE-----
On Thu, Mar 07, 2013 at 12:07:38PM -0500, Tres Seaver wrote:
On 03/07/2013 11:51 AM, Stephan Richter wrote:
On Thursday, March 07, 2013 05:46:48 PM Marius Gedminas wrote:
I'm not sure that's the right thing to do. Perhaps page templates, when given a file on disk with \r\n, should normalize the line endings to \n?
Opinions?
I think we should retain EOL characters as long as clients (i.e. browsers) understand them, which they do.
With template source, tools may require platform-specific line endings. For rendered HTML / XML, no tool / browser that wants to work with the 'net at large can have such expectations, which makes preserving them a non-use-case.
+1 to Marius' proposal to open template files with 'U' in the mode.
Was that my proposal? If only it were that easy... * On Windows, opening the templates in text mode should've already converted \r\n to \n, even without specifying 'U'. This didn't happen, why? * There are two kinds of templates: HTML ones and XML ones. zope.tal uses different parsers for the different kinds: expat for XML and HTMLParser for HTML. * zope.tal 4.0.0a1 opens XML templates in binary mode (which doesn't support 'U') because expat insists on bytes, and on Python 3 files opened in text mode give you Unicode. * HTML templates are opened in text mode (which implies newline conversion on Windows) * Most of the templates that caused these test failures on winbot were HTML templates. They should've been normalized at this point: https://github.com/zopefoundation/zope.tal/blob/master/src/zope/tal/htmltalp... * Am I going crazy? * Wait, PageTemplateFile doesn't use parseFile! It reads the template as bytes and feeds it to the wolves^H^H^H^H^H^H page template engine after maybe decoding it to Unicode (for HTML templates; XML ones get bytes): https://github.com/zopefoundation/zope.pagetemplate/blob/master/src/zope/pag... So, I think any \r\n normalization should be done in zope.pagetemplate's PageTemplateFile. If we want to do \r\n normalization. Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development
participants (6)
-
Adam GROSZER -
Marius Gedminas -
Patrick Gerken -
Stephan Richter -
Tres Seaver -
Zope tests summarizer