zope-tests - FAILED: 8, OK: 39
This is the summary for test reports received on the zope-tests list between 2011-11-11 00:00:00 UTC and 2011-11-12 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 ---------------- Bluebream / Python2.5.5 64bit linux Bluebream / Python2.6.7 64bit linux Bluebream / Python2.7.2 64bit linux ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.7 Linux 64bit ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.5.5 Linux 64bit ZTK 1.1 / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.7.2 Linux 64bit ZTK 1.1dev / Python2.5.5 Linux 64bit ZTK 1.1dev / Python2.6.7 Linux 64bit [1] ZTK 1.1dev / Python2.7.2 Linux 64bit [2] Zope 3.4 KGS / Python2.4.6 64bit linux [3] Zope 3.4 KGS / Python2.5.5 64bit linux [4] Zope 3.4 Known Good Set / py2.4-32bit-linux [5] Zope 3.4 Known Good Set / py2.4-64bit-linux [6] Zope 3.4 Known Good Set / py2.5-32bit-linux [7] Zope 3.4 Known Good Set / py2.5-64bit-linux Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux winbot / ZODB_dev py_254_win32 winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 [8] winbot / z3c.form_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 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 winbot / ztk_dev py_270_win32 winbot / ztk_dev py_270_win64 Non-OK results -------------- [1] FAILED ZTK 1.1dev / Python2.7.2 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-November/052554.html [2] FAILED Zope 3.4 KGS / Python2.4.6 64bit linux https://mail.zope.org/pipermail/zope-tests/2011-November/052563.html [3] FAILED Zope 3.4 KGS / Python2.5.5 64bit linux https://mail.zope.org/pipermail/zope-tests/2011-November/052564.html [4] FAILED Zope 3.4 Known Good Set / py2.4-32bit-linux https://mail.zope.org/pipermail/zope-tests/2011-November/052550.html [5] FAILED Zope 3.4 Known Good Set / py2.4-64bit-linux https://mail.zope.org/pipermail/zope-tests/2011-November/052548.html [6] FAILED Zope 3.4 Known Good Set / py2.5-32bit-linux https://mail.zope.org/pipermail/zope-tests/2011-November/052559.html [7] FAILED Zope 3.4 Known Good Set / py2.5-64bit-linux https://mail.zope.org/pipermail/zope-tests/2011-November/052552.html [8] FAILED winbot / z3c.form_py_265_32 https://mail.zope.org/pipermail/zope-tests/2011-November/052551.html
[1] FAILED ZTK 1.1dev / Python2.7.2 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-November/052554.html
This is the same hour-long timeout as yesterday in the buildout step:
mr.developer: Updated 'zope.viewlet' with subversion.
command timed out: 3600 seconds without output, killing pid 22071 process killed by signal 9 program finished with exit code -1 elapsedTime=4054.018485
I have no idea what is failing.
[2] FAILED Zope 3.4 KGS / Python2.4.6 64bit linux https://mail.zope.org/pipermail/zope-tests/2011-November/052563.html
[3] FAILED Zope 3.4 KGS / Python2.5.5 64bit linux https://mail.zope.org/pipermail/zope-tests/2011-November/052564.html
[4] FAILED Zope 3.4 Known Good Set / py2.4-32bit-linux https://mail.zope.org/pipermail/zope-tests/2011-November/052550.html
[5] FAILED Zope 3.4 Known Good Set / py2.4-64bit-linux https://mail.zope.org/pipermail/zope-tests/2011-November/052548.html
[6] FAILED Zope 3.4 Known Good Set / py2.5-32bit-linux https://mail.zope.org/pipermail/zope-tests/2011-November/052559.html
[7] FAILED Zope 3.4 Known Good Set / py2.5-64bit-linux https://mail.zope.org/pipermail/zope-tests/2011-November/052552.html
If somebody who cares about the KGS could look at these failures and figure out why knew versions are slipping into the mix, that would be great. Otherwise, we should just quit testing it.
[8] FAILED winbot / z3c.form_py_265_32 https://mail.zope.org/pipermail/zope-tests/2011-November/052551.html
Stephan said yesterday he thought this was a chameleon bug. I just tried to reproduce this on a Linux box with a fresh checkout, using Python 2.5.5. The tests don't even run for me::
Traceback (most recent call last): File "/tmp/zft/bin/test", line 26, in <module> '--test-path', '/tmp/zft/src', File "/tmp/zft/eggs/zope.testrunner-4.0.4-py2.5.egg/zope/testrunner/__init__.py", line 30, in run failed = run_internal(defaults, args, script_parts=script_parts) File "/tmp/zft/eggs/zope.testrunner-4.0.4-py2.5.egg/zope/testrunner/__init__.py", line 41, in run_internal from zope.testrunner.runner import Runner File "/tmp/zft/eggs/zope.testrunner-4.0.4-py2.5.egg/zope/testrunner/runner.py", line 46, in <module> import zope.testrunner.tb_format File "/tmp/zft/eggs/zope.testrunner-4.0.4-py2.5.egg/zope/testrunner/tb_format.py", line 19, in <module> import zope.exceptions.exceptionformatter File "/tmp/zft/eggs/zope.exceptions-3.6.1-py2.5.egg/zope/exceptions/__init__.py", line 24, in <module> import zope.security File "/tmp/zft/eggs/zope.security-3.8.3-py2.5-linux-i686.egg/zope/security/__init__.py", line 17, in <module> from zope.security.management import checkPermission File "/tmp/zft/eggs/zope.security-3.8.3-py2.5-linux-i686.egg/zope/security/management.py", line 20, in <module> from zope.security import interfaces File "/tmp/zft/eggs/zope.security-3.8.3-py2.5-linux-i686.egg/zope/security/interfaces.py", line 19, in <module> from zope.schema import Text, TextLine File "/tmp/zft/eggs/zope.schema-4.0.0-py2.5.egg/zope/schema/__init__.py", line 16, in <module> from zope.schema._field import Field, Container, Iterable, Orderable File "/tmp/zft/eggs/zope.schema-4.0.0-py2.5.egg/zope/schema/_field.py", line 78 class SourceText(Text): ^ SyntaxError: invalid syntax
Tres. -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
Le 13/11/2011 14:22, Tres Seaver a écrit :
[1] FAILED ZTK 1.1dev / Python2.7.2 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-November/052554.html
This is the same hour-long timeout as yesterday in the buildout step:
mr.developer: Updated 'zope.viewlet' with subversion.
command timed out: 3600 seconds without output, killing pid 22071 process killed by signal 9 program finished with exit code -1 elapsedTime=4054.018485
I have no idea what is failing.
[2] FAILED Zope 3.4 KGS / Python2.4.6 64bit linux https://mail.zope.org/pipermail/zope-tests/2011-November/052563.html
[3] FAILED Zope 3.4 KGS / Python2.5.5 64bit linux https://mail.zope.org/pipermail/zope-tests/2011-November/052564.html
[4] FAILED Zope 3.4 Known Good Set / py2.4-32bit-linux https://mail.zope.org/pipermail/zope-tests/2011-November/052550.html
[5] FAILED Zope 3.4 Known Good Set / py2.4-64bit-linux https://mail.zope.org/pipermail/zope-tests/2011-November/052548.html
[6] FAILED Zope 3.4 Known Good Set / py2.5-32bit-linux https://mail.zope.org/pipermail/zope-tests/2011-November/052559.html
[7] FAILED Zope 3.4 Known Good Set / py2.5-64bit-linux https://mail.zope.org/pipermail/zope-tests/2011-November/052552.html
If somebody who cares about the KGS could look at these failures and figure out why knew versions are slipping into the mix, that would be great. Otherwise, we should just quit testing it.
The initial build process of the kgs has no versions pinned, so it was being built with some of the latests libs that fail under python2.4. I have added versions in the toplevel buildout.cfg so that it shouldn't fail again. I don't know if someone is interested but we have enough minor versions upgrade available to be able to release a maintenance versions of the KGS: 3.4.2
[8] FAILED winbot / z3c.form_py_265_32 https://mail.zope.org/pipermail/zope-tests/2011-November/052551.html
Stephan said yesterday he thought this was a chameleon bug. I just tried to reproduce this on a Linux box with a fresh checkout, using Python 2.5.5. The tests don't even run for me::
Traceback (most recent call last): File "/tmp/zft/bin/test", line 26, in<module> '--test-path', '/tmp/zft/src', File "/tmp/zft/eggs/zope.testrunner-4.0.4-py2.5.egg/zope/testrunner/__init__.py", line 30, in run failed = run_internal(defaults, args, script_parts=script_parts) File "/tmp/zft/eggs/zope.testrunner-4.0.4-py2.5.egg/zope/testrunner/__init__.py", line 41, in run_internal from zope.testrunner.runner import Runner File "/tmp/zft/eggs/zope.testrunner-4.0.4-py2.5.egg/zope/testrunner/runner.py", line 46, in<module> import zope.testrunner.tb_format File "/tmp/zft/eggs/zope.testrunner-4.0.4-py2.5.egg/zope/testrunner/tb_format.py", line 19, in<module> import zope.exceptions.exceptionformatter File "/tmp/zft/eggs/zope.exceptions-3.6.1-py2.5.egg/zope/exceptions/__init__.py", line 24, in<module> import zope.security File "/tmp/zft/eggs/zope.security-3.8.3-py2.5-linux-i686.egg/zope/security/__init__.py", line 17, in<module> from zope.security.management import checkPermission File "/tmp/zft/eggs/zope.security-3.8.3-py2.5-linux-i686.egg/zope/security/management.py", line 20, in<module> from zope.security import interfaces File "/tmp/zft/eggs/zope.security-3.8.3-py2.5-linux-i686.egg/zope/security/interfaces.py", line 19, in<module> from zope.schema import Text, TextLine File "/tmp/zft/eggs/zope.schema-4.0.0-py2.5.egg/zope/schema/__init__.py", line 16, in<module> from zope.schema._field import Field, Container, Iterable, Orderable File "/tmp/zft/eggs/zope.schema-4.0.0-py2.5.egg/zope/schema/_field.py", line 78 class SourceText(Text): ^ SyntaxError: invalid syntax
Tres.
Le 14/11/2011 01:52, Christophe Combelles a écrit :
Le 13/11/2011 14:22, Tres Seaver a écrit :
[1] FAILED ZTK 1.1dev / Python2.7.2 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-November/052554.html
This is the same hour-long timeout as yesterday in the buildout step:
mr.developer: Updated 'zope.viewlet' with subversion.
command timed out: 3600 seconds without output, killing pid 22071 process killed by signal 9 program finished with exit code -1 elapsedTime=4054.018485
I have no idea what is failing.
[2] FAILED Zope 3.4 KGS / Python2.4.6 64bit linux https://mail.zope.org/pipermail/zope-tests/2011-November/052563.html
[3] FAILED Zope 3.4 KGS / Python2.5.5 64bit linux https://mail.zope.org/pipermail/zope-tests/2011-November/052564.html
[4] FAILED Zope 3.4 Known Good Set / py2.4-32bit-linux https://mail.zope.org/pipermail/zope-tests/2011-November/052550.html
[5] FAILED Zope 3.4 Known Good Set / py2.4-64bit-linux https://mail.zope.org/pipermail/zope-tests/2011-November/052548.html
[6] FAILED Zope 3.4 Known Good Set / py2.5-32bit-linux https://mail.zope.org/pipermail/zope-tests/2011-November/052559.html
[7] FAILED Zope 3.4 Known Good Set / py2.5-64bit-linux https://mail.zope.org/pipermail/zope-tests/2011-November/052552.html
If somebody who cares about the KGS could look at these failures and figure out why knew versions are slipping into the mix, that would be great. Otherwise, we should just quit testing it.
The initial build process of the kgs has no versions pinned, so it was being built with some of the latests libs that fail under python2.4. I have added versions in the toplevel buildout.cfg so that it shouldn't fail again.
I don't know if someone is interested but we have enough minor versions upgrade available to be able to release a maintenance versions of the KGS: 3.4.2
fixed http://buildbot.afpy.org/kgs3.4/builders/Python2.4.6%2064bit%20linux/builds/...
[8] FAILED winbot / z3c.form_py_265_32 https://mail.zope.org/pipermail/zope-tests/2011-November/052551.html
Stephan said yesterday he thought this was a chameleon bug. I just tried to reproduce this on a Linux box with a fresh checkout, using Python 2.5.5. The tests don't even run for me::
Traceback (most recent call last): File "/tmp/zft/bin/test", line 26, in<module> '--test-path', '/tmp/zft/src', File "/tmp/zft/eggs/zope.testrunner-4.0.4-py2.5.egg/zope/testrunner/__init__.py", line 30, in run failed = run_internal(defaults, args, script_parts=script_parts) File "/tmp/zft/eggs/zope.testrunner-4.0.4-py2.5.egg/zope/testrunner/__init__.py", line 41, in run_internal from zope.testrunner.runner import Runner File "/tmp/zft/eggs/zope.testrunner-4.0.4-py2.5.egg/zope/testrunner/runner.py", line 46, in<module> import zope.testrunner.tb_format File "/tmp/zft/eggs/zope.testrunner-4.0.4-py2.5.egg/zope/testrunner/tb_format.py", line 19, in<module> import zope.exceptions.exceptionformatter File "/tmp/zft/eggs/zope.exceptions-3.6.1-py2.5.egg/zope/exceptions/__init__.py", line 24, in<module> import zope.security File "/tmp/zft/eggs/zope.security-3.8.3-py2.5-linux-i686.egg/zope/security/__init__.py", line 17, in<module> from zope.security.management import checkPermission File "/tmp/zft/eggs/zope.security-3.8.3-py2.5-linux-i686.egg/zope/security/management.py", line 20, in<module> from zope.security import interfaces File "/tmp/zft/eggs/zope.security-3.8.3-py2.5-linux-i686.egg/zope/security/interfaces.py", line 19, in<module> from zope.schema import Text, TextLine File "/tmp/zft/eggs/zope.schema-4.0.0-py2.5.egg/zope/schema/__init__.py", line 16, in<module> from zope.schema._field import Field, Container, Iterable, Orderable File "/tmp/zft/eggs/zope.schema-4.0.0-py2.5.egg/zope/schema/_field.py", line 78 class SourceText(Text): ^ SyntaxError: invalid syntax
Tres.
_______________________________________________ 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 )
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/14/2011 04:50 PM, Christophe Combelles wrote:
Le 14/11/2011 01:52, Christophe Combelles a écrit :
Le 13/11/2011 14:22, Tres Seaver a écrit :
If somebody who cares about the KGS could look at these failures and figure out why knew versions are slipping into the mix, that would be great. Otherwise, we should just quit testing it.
The initial build process of the kgs has no versions pinned, so it was being built with some of the latests libs that fail under python2.4. I have added versions in the toplevel buildout.cfg so that it shouldn't fail again.
I don't know if someone is interested but we have enough minor versions upgrade available to be able to release a maintenance versions of the KGS: 3.4.2
fixed
http://buildbot.afpy.org/kgs3.4/builders/Python2.4.6%2064bit%20linux/builds/...
I
don't understand why r123334 was needed to "fix" the KGS buildout: I thought the KGS was "pinned" by virtue of using its 'versions.cfg' file: http://download.zope.org/zope3.4/3.4.1/versions.cfg (Actually, I don't know what the intended relationship is between that file and http://download.zope.org/zope3.4/3.4.1/controlled-packages.cfg ). Actually, I thought we were supposed to have a PyPI-like index which ensured that no unwanted versions would creep in, e.g.:: http://download.zope.org/zope3.4/3.4.1/index/ Can somebody who remembers how that dance was supposed to work enlighten us? 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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7BlRMACgkQ+gerLs4ltQ7YhwCg2g8n/s26u0z5FvkrgwtTV+z8 ExQAoLrqxIAdMhQ+G1skUR2o7qa6LoOA =BrQZ -----END PGP SIGNATURE-----
Le 14/11/2011 23:24, Tres Seaver a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/14/2011 04:50 PM, Christophe Combelles wrote:
Le 14/11/2011 01:52, Christophe Combelles a écrit :
Le 13/11/2011 14:22, Tres Seaver a écrit :
If somebody who cares about the KGS could look at these failures and figure out why knew versions are slipping into the mix, that would be great. Otherwise, we should just quit testing it.
The initial build process of the kgs has no versions pinned, so it was being built with some of the latests libs that fail under python2.4. I have added versions in the toplevel buildout.cfg so that it shouldn't fail again.
I don't know if someone is interested but we have enough minor versions upgrade available to be able to release a maintenance versions of the KGS: 3.4.2
fixed
http://buildbot.afpy.org/kgs3.4/builders/Python2.4.6%2064bit%20linux/builds/...
I
don't understand why r123334 was needed to "fix" the KGS buildout: I thought the KGS was "pinned" by virtue of using its 'versions.cfg' file:
The problem doesn't come from the KGS itself, but from the package that creates the KGS, I mean zope.release. (which itself depends on the logic of zope.kgs). During the release process, zope.release generates a buildout that will be used to launch tests. So there are 2 buildouts : the one from zope.release itself, and the one generated by the generate-buildout command.
(Actually, I don't know what the intended relationship is between that file and http://download.zope.org/zope3.4/3.4.1/controlled-packages.cfg ).
The versions.cfg is generated from the controlled-packages file, and contains only the latest versions. controlled-packages was supposed to track all the compatible versions (even older ones) of the KGS. But it happens to be mathematically wrong and impossible, because the cobinatory explosion of versions makes it unrealistic to handle all the combinations.
Actually, I thought we were supposed to have a PyPI-like index which ensured that no unwanted versions would creep in, e.g.::
http://download.zope.org/zope3.4/3.4.1/index/
Can somebody who remembers how that dance was supposed to work enlighten us?
Everything is here http://svn.zope.org/zope.release/branches/3.4/README.txt?rev=89181&view=auto This is much simpler with the ZTK now.
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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7BlRMACgkQ+gerLs4ltQ7YhwCg2g8n/s26u0z5FvkrgwtTV+z8 ExQAoLrqxIAdMhQ+G1skUR2o7qa6LoOA =BrQZ -----END PGP SIGNATURE-----
_______________________________________________ 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 )
Am 14.11.2011 um 23:24 schrieb Tres Seaver: [...]
I don't understand why r123334 was needed to "fix" the KGS buildout: I thought the KGS was "pinned" by virtue of using its 'versions.cfg' file:
I think it would be a good idea to extend this file in the zope.release buildout.cfg. (So we can get rid of the lately manually added version pins.) Any objections? Yours sincerely, -- Michael Howitz · mh@gocept.com · software developer gocept gmbh & co. kg · Forsterstraße 29 · 06112 Halle (Saale) · Germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development
On Sun, Nov 13, 2011 at 08:22:38AM -0500, Tres Seaver wrote:
[8] FAILED winbot / z3c.form_py_265_32 https://mail.zope.org/pipermail/zope-tests/2011-November/052551.html
Stephan said yesterday he thought this was a chameleon bug. I just tried to reproduce this on a Linux box with a fresh checkout, using Python 2.5.5. The tests don't even run for me::
Traceback (most recent call last): File "/tmp/zft/bin/test", line 26, in <module> '--test-path', '/tmp/zft/src', File "/tmp/zft/eggs/zope.testrunner-4.0.4-py2.5.egg/zope/testrunner/__init__.py", line 30, in run failed = run_internal(defaults, args, script_parts=script_parts) File "/tmp/zft/eggs/zope.testrunner-4.0.4-py2.5.egg/zope/testrunner/__init__.py", line 41, in run_internal from zope.testrunner.runner import Runner File "/tmp/zft/eggs/zope.testrunner-4.0.4-py2.5.egg/zope/testrunner/runner.py", line 46, in <module> import zope.testrunner.tb_format File "/tmp/zft/eggs/zope.testrunner-4.0.4-py2.5.egg/zope/testrunner/tb_format.py", line 19, in <module> import zope.exceptions.exceptionformatter File "/tmp/zft/eggs/zope.exceptions-3.6.1-py2.5.egg/zope/exceptions/__init__.py", line 24, in <module> import zope.security File "/tmp/zft/eggs/zope.security-3.8.3-py2.5-linux-i686.egg/zope/security/__init__.py", line 17, in <module> from zope.security.management import checkPermission File "/tmp/zft/eggs/zope.security-3.8.3-py2.5-linux-i686.egg/zope/security/management.py", line 20, in <module> from zope.security import interfaces File "/tmp/zft/eggs/zope.security-3.8.3-py2.5-linux-i686.egg/zope/security/interfaces.py", line 19, in <module> from zope.schema import Text, TextLine File "/tmp/zft/eggs/zope.schema-4.0.0-py2.5.egg/zope/schema/__init__.py", line 16, in <module> from zope.schema._field import Field, Container, Iterable, Orderable File "/tmp/zft/eggs/zope.schema-4.0.0-py2.5.egg/zope/schema/_field.py", line 78 class SourceText(Text): ^ SyntaxError: invalid syntax
I managed to reproduce it with Python 2.6. It turned out to be a bug I introduced with the zope.schema 4.0.0 Python 3 support. I've fixed it in 123340 and released as 4.0.1. -- Brian Sutherland
participants (5)
-
Brian Sutherland -
Christophe Combelles -
Michael Howitz -
Tres Seaver -
Zope tests summarizer