[Zope-CMF] CMF Tests: 4 OK
Summary of messages to the cmf-tests list. Period Sun Feb 15 12:00:00 2009 UTC to Mon Feb 16 12:00:00 2009 UTC. There were 4 messages: 4 from CMF Tests. Tests passed OK --- Subject: OK : CMF-2.1 Zope-2.10 Python-2.4.6 : Linux From: CMF Tests Date: Sun Feb 15 21:04:58 EST 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-February/010913.html Subject: OK : CMF-2.1 Zope-2.11 Python-2.4.6 : Linux From: CMF Tests Date: Sun Feb 15 21:06:59 EST 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-February/010914.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.6 : Linux From: CMF Tests Date: Sun Feb 15 21:08:59 EST 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-February/010915.html Subject: OK : CMF-trunk Zope-2.11 Python-2.4.6 : Linux From: CMF Tests Date: Sun Feb 15 21:10:59 EST 2009 URL: http://mail.zope.org/pipermail/cmf-tests/2009-February/010916.html ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [Checkins] SVN: Products.CMFCalendar/trunk/setup.py - dependency cleanup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm wondering, ist it necessary to declare a dependency where we know that it is a required dependency for another dependency we already declare? Specifically, if CMFDefault is declared as dependency, is it necessary to also declare CMFCore because we know CMFDefault already declares it? jens On Feb 16, 2009, at 11:42 , Yvo Schubbe wrote: > Log message for revision 96579: > - dependency cleanup > > Changed: > U Products.CMFCalendar/trunk/setup.py > > -=- > Modified: Products.CMFCalendar/trunk/setup.py > === > --- Products.CMFCalendar/trunk/setup.py 2009-02-16 10:11:44 UTC (rev > 96578) > +++ Products.CMFCalendar/trunk/setup.py 2009-02-16 10:42:54 UTC (rev > 96579) > @@ -45,14 +45,19 @@ > setup_requires=['eggtestinfo', > ], > install_requires=[ > - #'Zope >= 2.10.4', > 'setuptools', > + #'Zope2 >= 2.10.4', > + 'Products.CMFCore', > 'Products.CMFDefault', > - 'Products.DCWorkflow', > 'Products.GenericSetup', > ], > - tests_require=['zope.testing>=3.7.0', > -], > + tests_require=[ > + 'zope.testing >= 3.7.0', > + 'Products.DCWorkflow', > + ], > + extras_require = dict( > + test = ['Products.DCWorkflow'], > + ), > test_loader='zope.testing.testrunner.eggsupport:SkipLayers', > test_suite='Products.%s.tests' % NAME, > entry_points=""" > > ___ > Checkins mailing list > check...@zope.org > http://mail.zope.org/mailman/listinfo/checkins -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmZVzUACgkQRAx5nvEhZLJ4OACggumqB1uszZgWL1Xs5qCMKDNY 2woAoKpVaHIuUnNhCjaoHyX35qpZcsHB =6ViM -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [Checkins] SVN: Products.CMFCalendar/trunk/setup.py - dependency cleanup
Hi! Jens Vagelpohl wrote: > I'm wondering, ist it necessary to declare a dependency where we know > that it is a required dependency for another dependency we already > declare? Specifically, if CMFDefault is declared as dependency, is it > necessary to also declare CMFCore because we know CMFDefault already > declares it? No. But as Hanno pointed out yesterday, it is good practice to specify all *direct* dependencies: http://mail.zope.org/pipermail/zope-dev/2009-February/034582.html The Zope2 package is an exception because it represents the Zope 2 platform and ships with a KGS. So direct dependencies on packages Zope2 also depends on should not be specified if Zope2 is specified as dependency. I thought that was consensus, but if you don't agree I'm fine with further discussions. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [Checkins] SVN: Products.CMFCalendar/trunk/setup.py - dependency cleanup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 16, 2009, at 13:29 , yuppie wrote: > Jens Vagelpohl wrote: >> I'm wondering, ist it necessary to declare a dependency where we know >> that it is a required dependency for another dependency we already >> declare? Specifically, if CMFDefault is declared as dependency, is it >> necessary to also declare CMFCore because we know CMFDefault already >> declares it? > > No. But as Hanno pointed out yesterday, it is good practice to specify > all *direct* dependencies: > http://mail.zope.org/pipermail/zope-dev/2009-February/034582.html > > The Zope2 package is an exception because it represents the Zope 2 > platform and ships with a KGS. So direct dependencies on packages > Zope2 > also depends on should not be specified if Zope2 is specified as > dependency. > > I thought that was consensus, but if you don't agree I'm fine with > further discussions. No, don't get me wrong, I did not signal any disagreement or agreement ;-) I was just wondering if there was a new set of "best practices" that I missed. I did not draw the line between the other discussion and your checkins at all, it did not strike me as related. Does anyone else have a specific opinion for this case, disregarding the five.localsitemanager discussion? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmZYK4ACgkQRAx5nvEhZLLq8wCeJEfA4DXKzauYg4Cl9qK2X83v WpkAoLX7504n+vjQI9ntqxgKhr1tfBHX =phKB -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [Checkins] SVN: Products.CMFCalendar/trunk/setup.py - dependency cleanup
Am 16.02.2009 um 13:08 schrieb Jens Vagelpohl: > I'm wondering, ist it necessary to declare a dependency where we know > that it is a required dependency for another dependency we already > declare? Specifically, if CMFDefault is declared as dependency, is it > necessary to also declare CMFCore because we know CMFDefault already > declares it? hm, do we always *know* that? Unless dealing with known behemoths aka Zope2, I'd go with explicit is better than implicit and expect declarations for any import statement. Then again I'm still not convinced that the CMF itself isn't a mini- behemoth to be eaten tail, toenails and all. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [Checkins] SVN: Products.CMFCalendar/trunk/setup.py - dependency cleanup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 16, 2009, at 13:50 , Charlie Clark wrote: > Am 16.02.2009 um 13:08 schrieb Jens Vagelpohl: > >> I'm wondering, ist it necessary to declare a dependency where we know >> that it is a required dependency for another dependency we already >> declare? Specifically, if CMFDefault is declared as dependency, is it >> necessary to also declare CMFCore because we know CMFDefault already >> declares it? > > > hm, do we always *know* that? > > Unless dealing with known behemoths aka Zope2, I'd go with explicit is > better than implicit and expect declarations for any import statement. Yes, that's a good point. > Then again I'm still not convinced that the CMF itself isn't a mini- > behemoth to be eaten tail, toenails and all. It depends on how you look at the dependencies. If you mean installation dependencies then I think there's been great progress disentangling the different packages. If you mean "I don't need Y for installing X, but really, X is not all that useful without Y" that's a different issue. But that's off-topic for this thread ;-) jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmZYjAACgkQRAx5nvEhZLIEmACeNPlN1ngSkfzSzyhu3Lr3WJ70 eRAAoIzMXWda+p7qTvzPPdBwreubx+3B =ZH9k -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFDefault/trunk/setup.py - dependency cleanup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yvo Schubbe wrote: > Log message for revision 96580: > - dependency cleanup > > Changed: > U Products.CMFDefault/trunk/setup.py > > -=- > Modified: Products.CMFDefault/trunk/setup.py > === > --- Products.CMFDefault/trunk/setup.py2009-02-16 10:42:54 UTC (rev > 96579) > +++ Products.CMFDefault/trunk/setup.py2009-02-16 10:43:09 UTC (rev > 96580) > @@ -45,14 +45,18 @@ >setup_requires=['eggtestinfo', > ], >install_requires=[ > - #'Zope >= 2.10.4', >'setuptools', > + #'Zope2 >= 2.10.4', >'Products.CMFCore', > - 'Products.DCWorkflow', >'Products.GenericSetup', >], > - tests_require=['zope.testing>=3.7.0', > -], > + tests_require=[ > + 'zope.testing >= 3.7.0', > + 'Products.DCWorkflow', > + ], > + extras_require = dict( > + test = ['Products.DCWorkflow'], > + ), Can somebody explain the dependency on DCWorkflow's ZCML getting loaded? This seems like it should be ripped out: no tests should need to get actaul DCWrolfow instances configured. Or are we trying to run functional tests against a site configured from a profile which uses DCWorkflow? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJmZfZ+gerLs4ltQ4RAhaEAKCwoZOfwjbjfltvdHOdAQ8OvQeFEgCfQDGp V2pNxMBXIYLVWBsaei2/y5k= =Sbzi -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFDefault/trunk/setup.py - dependency cleanup
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 16, 2009, at 17:44 , Tres Seaver wrote:
> Can somebody explain the dependency on DCWorkflow's ZCML getting
> loaded?
> This seems like it should be ripped out: no tests should need to get
> actaul DCWrolfow instances configured. Or are we trying to run
> functional tests against a site configured from a profile which uses
> DCWorkflow?
Well, the use of the DCWorkflow profile is indirect.
CMFDefault.testing defines a functional test layer that instantiates a
portal using the CMFDefault default profile. Without loading the
DCWorkflow profile, workflow creation fails with the traceback below.
jens
Set up Products.CMFDefault.testing.FunctionalLayer Traceback (most
recent call last):
File "/usr/local/py24/CMF.buildout-trunk/eggs/zope.testing-3.7.1-
py2.4.egg/zope/testing/testrunner/runner.py", line 360, in run_layer
setup_layer(options, layer, setup_layers)
File "/usr/local/py24/CMF.buildout-trunk/eggs/zope.testing-3.7.1-
py2.4.egg/zope/testing/testrunner/runner.py", line 536, in setup_layer
layer.setUp()
File "/usr/local/py24/CMF.buildout-trunk/src/Products.CMFDefault/
Products/CMFDefault/testing.py", line 41, in setUp
snapshot=False)
File "/usr/local/py24/CMF.buildout-trunk/src/Products.CMFDefault/
Products/CMFDefault/factory.py", line 63, in addConfiguredSite
setup_tool.runAllImportStepsFromProfile('profile-%s' % profile_id)
File "/usr/local/py24/CMF.buildout-trunk/src/Products.GenericSetup/
Products/GenericSetup/tool.py", line 327, in
runAllImportStepsFromProfile
ignore_dependencies=ignore_dependencies)
File "/usr/local/py24/CMF.buildout-trunk/src/Products.GenericSetup/
Products/GenericSetup/tool.py", line 1082, in _runImportStepsFromContext
message = self._doRunImportStep(step, context)
File "/usr/local/py24/CMF.buildout-trunk/src/Products.GenericSetup/
Products/GenericSetup/tool.py", line 996, in _doRunImportStep
return handler(context)
File "/usr/local/py24/CMF.buildout-trunk/src/Products.CMFCore/
Products/CMFCore/exportimport/workflow.py", line 126, in
importWorkflowTool
importObjects(tool, '', context)
File "/usr/local/py24/CMF.buildout-trunk/src/Products.GenericSetup/
Products/GenericSetup/utils.py", line 821, in importObjects
importer.body = body
File "/usr/local/py24/CMF.buildout-trunk/src/Products.GenericSetup/
Products/GenericSetup/utils.py", line 505, in _importBody
self._importNode(dom.documentElement)
File "/usr/local/py24/CMF.buildout-trunk/src/Products.CMFCore/
Products/CMFCore/exportimport/workflow.py", line 63, in _importNode
self._initObjects(node)
File "/usr/local/py24/CMF.buildout-trunk/src/Products.GenericSetup/
Products/GenericSetup/utils.py", line 566, in _initObjects
raise ValueError("unknown meta_type '%s'" % meta_type)
ValueError: unknown meta_type 'Workflow'
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkmZo08ACgkQRAx5nvEhZLJw/gCgtRL31njX0iG5oOAxs9Q51qre
OcAAn0Ra7YOYiCwpSRRHAi7z5e4wrUlz
=DfYB
-END PGP SIGNATURE-
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] SVN: Products.CMFDefault/trunk/setup.py - dependency cleanup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: > > On Feb 16, 2009, at 17:44 , Tres Seaver wrote: > >> Can somebody explain the dependency on DCWorkflow's ZCML getting >> loaded? >> This seems like it should be ripped out: no tests should need to get >> actaul DCWrolfow instances configured. Or are we trying to run >> functional tests against a site configured from a profile which uses >> DCWorkflow? > > Well, the use of the DCWorkflow profile is indirect. > CMFDefault.testing defines a functional test layer that instantiates a > portal using the CMFDefault default profile. Without loading the > DCWorkflow profile, workflow creation fails with the traceback below. Thanks, I had just chased that down myself. I have the sense that CMFDefault is probably ripe for a split: all the code which backs persistent objects (content types, the site itself, the tools) should stay, but the part which actually provides the default baseline profile should maybe be split out. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJmaT9+gerLs4ltQ4RAkr1AJ4yo2tW6q9juSZ8qntz2TLVS488IACeJaaN GZXjUslc1Gf/bWkUog4iJek= =gVze -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [dev] five.localsitemanager: dependencies
Tres Seaver wrote at 2009-2-14 20:31 -0500: > ... >For all its flaws, setuptools fixes a lot of what is horribly broken in >distutils: most of the flaws arise from the choice to stay >pseudo-compatible with distutils, and reuse it, rather than starting >from scratch. But the dependancy handling is obviously introduced by "setuptools". -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
[Zope-CMF] GenericSetup test failures on Python 2.5's tarfile
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Anybody have a clue what changed in the Python 2.5 tarfile module which
triggers these failures?
> [/home/tseaver/projects/CMF/CMF.buildout-trunk]
> $ bin/test -s Products.GenericSetup
> Running Testing.ZopeTestCase.layer.ZopeLite tests:
> Set up Testing.ZopeTestCase.layer.ZopeLite in 0.091 seconds.
>
>
> Failure in test test_getLastModified_directory
> (Products.GenericSetup.tests.test_context.TarballImportContextTests)
> Traceback (most recent call last):
> File "/home/tseaver/projects/Zope-CVS/lib/python2.5/unittest.py", line 260,
> in run
> testMethod()
> File
> "/home/tseaver/projects/CMF/CMF.buildout-trunk/src/Products.GenericSetup/Products/GenericSetup/tests/test_context.py",
> line 601, in test_getLastModified_directory
> self.assertEqual( ctx.getLastModified( SUBDIR ), WHEN )
> File "/home/tseaver/projects/Zope-CVS/lib/python2.5/unittest.py", line 334,
> in failUnlessEqual
> (msg or '%r != %r' % (first, second))
> AssertionError: None != DateTime('2004/01/01')
>
>
>
> Failure in test test_isDirectory_subdir
> (Products.GenericSetup.tests.test_context.TarballImportContextTests)
> Traceback (most recent call last):
> File "/home/tseaver/projects/Zope-CVS/lib/python2.5/unittest.py", line 260,
> in run
> testMethod()
> File
> "/home/tseaver/projects/CMF/CMF.buildout-trunk/src/Products.GenericSetup/Products/GenericSetup/tests/test_context.py",
> line 643, in test_isDirectory_subdir
> self.assertEqual( ctx.isDirectory( SUBDIR ), True )
> File "/home/tseaver/projects/Zope-CVS/lib/python2.5/unittest.py", line 334,
> in failUnlessEqual
> (msg or '%r != %r' % (first, second))
> AssertionError: None != True
>
>
>
> Error in test test_listDirectory_multiple
> (Products.GenericSetup.tests.test_context.TarballImportContextTests)
> Traceback (most recent call last):
> File "/home/tseaver/projects/Zope-CVS/lib/python2.5/unittest.py", line 260,
> in run
> testMethod()
> File
> "/home/tseaver/projects/CMF/CMF.buildout-trunk/src/Products.GenericSetup/Products/GenericSetup/tests/test_context.py",
> line 717, in test_listDirectory_multiple
> self.assertEqual( len( names ), 2 )
> TypeError: object of type 'NoneType' has no len()
>
>
>
> Error in test test_listDirectory_single
> (Products.GenericSetup.tests.test_context.TarballImportContextTests)
> Traceback (most recent call last):
> File "/home/tseaver/projects/Zope-CVS/lib/python2.5/unittest.py", line 260,
> in run
> testMethod()
> File
> "/home/tseaver/projects/CMF/CMF.buildout-trunk/src/Products.GenericSetup/Products/GenericSetup/tests/test_context.py",
> line 699, in test_listDirectory_single
> self.assertEqual( len( names ), 1 )
> TypeError: object of type 'NoneType' has no len()
>
>
>
> Error in test test_listDirectory_skip
> (Products.GenericSetup.tests.test_context.TarballImportContextTests)
> Traceback (most recent call last):
> File "/home/tseaver/projects/Zope-CVS/lib/python2.5/unittest.py", line 260,
> in run
> testMethod()
> File
> "/home/tseaver/projects/CMF/CMF.buildout-trunk/src/Products.GenericSetup/Products/GenericSetup/tests/test_context.py",
> line 740, in test_listDirectory_skip
> self.assertEqual( len( names ), 1 )
> TypeError: object of type 'NoneType' has no len()
>
> Ran 113 tests with 2 failures and 3 errors in 0.427 seconds.
Tres.
- --
===
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJmawT+gerLs4ltQ4RAp+OAKCDQ12U6OhZgGz0o49IiUE0JSW2hgCfVw0V
2aC5puF5Y27LDKTkdUrJyTM=
=xxVI
-END PGP SIGNATURE-
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] [Checkins] SVN: Products.CMFCalendar/trunk/setup.py - dependency cleanup
Jens Vagelpohl wrote at 2009-2-16 13:48 +0100: > ... >Does anyone else have a specific opinion for this case, disregarding >the five.localsitemanager discussion? Dependancies should be as loose as possible. If a component uses "CMFDefault" but only indirectly "CMFCore", it should specify "CMFDefault" as a dependency but not "CMFCore". If it explicitely uses both "CMFDefault" as well as "CMFCore", specifying both may be more future proof. -- Dieter ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup test failures on Python 2.5's tarfile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 16, 2009, at 19:10 , Tres Seaver wrote: > Anybody have a clue what changed in the Python 2.5 tarfile module > which > triggers these failures? Running against Python 2.5.2 using the same CMF.buildout I see no such failure. > Ran 113 tests with 2 failures and 3 errors in 0.427 seconds. According to your attached screen dump you ran "bin/test - sProducts.GenericSetup". I'm wondering why you only show 113 tests being run. I get 459 tests with that command line on my setup. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkmZwRYACgkQRAx5nvEhZLKq/QCfVdhoy897JiJmUu26gMrAo+qm vacAn1AvPBmYLCfhGYj+VxSNdfzJgG2I =/nfE -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup test failures on Python 2.5's tarfile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: > > On Feb 16, 2009, at 19:10 , Tres Seaver wrote: > >> Anybody have a clue what changed in the Python 2.5 tarfile module >> which >> triggers these failures? > > Running against Python 2.5.2 using the same CMF.buildout I see no such > failure. Hmm "'Curiouser and curiouser,' said Alice." I am running 2.5.1: I will try with 2.5.2. >> Ran 113 tests with 2 failures and 3 errors in 0.427 seconds. > > According to your attached screen dump you ran "bin/test - > sProducts.GenericSetup". I'm wondering why you only show 113 tests > being run. I get 459 tests with that command line on my setup. I trimmed off the tests which didnt fail. The total in 456, with 2 failures and 3 errors. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJmcvU+gerLs4ltQ4RAiv5AJ0flH4vfISr3h5mofK8YJERwE5YDgCfbVzB MI5JfRUni20/Lm6rn9zTsW4= =VDjk -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
Re: [Zope-CMF] GenericSetup test failures on Python 2.5's tarfile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: > Jens Vagelpohl wrote: >> On Feb 16, 2009, at 19:10 , Tres Seaver wrote: > >>> Anybody have a clue what changed in the Python 2.5 tarfile module >>> which >>> triggers these failures? >> Running against Python 2.5.2 using the same CMF.buildout I see no such >> failure. > > Hmm "'Curiouser and curiouser,' said Alice." I am running 2.5.1: I > will try with 2.5.2. The changelog for Python 2.5.2[1] has quite a large number of references to the 'tarfile' module. One in particular looks like it might be the culprit: - tarfile.py: Fix directory names to have only one trailing slash. [1] http://www.python.org/download/releases/2.5.2/NEWS.txt (Later) OK, after installing 2.5.2, all tests pass cleanly. Somebody really screwed the pooch in there. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJmdA++gerLs4ltQ4RAmaPAKCM9lVMNnP4IbpVTkMfSPKz7e1cQgCgkAXc CUEdtKeVL+ekXqyzmYkYdMI= =Q/od -END PGP SIGNATURE- ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
