July 2009 - Zope-Dev

Re: [Zope-dev] SVN: Zope/trunk/versions.cfg Revert r101557 and put back version pins for zodbcode and zope.app.interface. These are actual dependencies of zope.app.zcmlfiles, which in turn is a test dependency of numerous packages we use. Having a co
by Hanno Schlichting 07 Jul '09

07 Jul '09

On Tue, Jul 7, 2009 at 2:31 AM, Tres Seaver<tseaver(a)palladion.com> wrote: > Hanno Schlichting wrote: >> Log message for revision 101616: >> Revert r101557 and put back version pins for zodbcode and zope.app.interface. These are actual dependencies of zope.app.zcmlfiles, which in turn is a test dependency of numerous packages we use. Having a consistent known set of packages for tests is as important as having one for production. > > Shouldn't we just rip zodbcode et al out of a new version of zcmlfiles? Sure. That's what Jim wanted to do as well, as announced in another thread. I'd just like to remove the versions pins *after* we have done so ;) Hanno

1 0

Re: [Zope-dev] SVN: Zope/trunk/versions.cfg Revert r101557 and put back version pins for zodbcode and zope.app.interface. These are actual dependencies of zope.app.zcmlfiles, which in turn is a test dependency of numerous packages we use. Having a consistent known set of packages for tests is as important as having one for production.
by Tres Seaver 07 Jul '09

07 Jul '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote: > Log message for revision 101616: > Revert r101557 and put back version pins for zodbcode and zope.app.interface. These are actual dependencies of zope.app.zcmlfiles, which in turn is a test dependency of numerous packages we use. Having a consistent known set of packages for tests is as important as having one for production. Shouldn't we just rip zodbcode et al out of a new version of zcmlfiles? Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver(a)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 iD8DBQFKUpdu+gerLs4ltQ4RAiTyAKDbLJUCqtzAr60SJbtrZIw21GXGJQCfTbB5 tJsphRvfvTBTU/ejJX/OGFk= =K7Li -----END PGP SIGNATURE-----

2 1

zope.html with FCKEditor security fix
by Benji York 06 Jul '09

06 Jul '09

Version 1.2.0 of zope.html has just been released. It includes the security fix release of FCKEditor (2.6.4.1) which addresses http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-2265. -- Benji York Senior Software Engineer Zope Corporation

1 0

Re: [Zope-dev] [Distutils] Where is the setuptools source repository?
by Jim Fulton 06 Jul '09

06 Jul '09

Switching to zope-dev. On Jul 2, 2009, at 10:40 AM, Chris Withers wrote: > Jim Fulton wrote: >> buildout works fine. The problem is the zope.testing test runner, >> which will find tests in your eggs directory if your buildout is in >> your software path. > > I'm safe from this one, since I store all my eggs in ~/buildout-eggs > as specified in my ~/.buildout/default.cfg. > > However, the same problem occurs with the contents of the build > directory :-( It is really rather shallow and should be easy to fix. The issue is that the test finder will descend into directories that don't have __init__.py files, and shouldn't. Jim -- Jim Fulton Zope Corporation

2 2

Re: [Zope-dev] [Distutils] Where is the setuptools source repository?
by Christian Theune 04 Jul '09

04 Jul '09

On Sat, 2009-07-04 at 11:25 -0400, Barry Warsaw wrote: > On Jul 4, 2009, at 6:30 AM, Christian Theune wrote: > > > It was shallow after understanding it ... ;) > > > > The test runner already tried to avoid those directories, except there > > wasn't a test for this and obviously it was bound to be broken. > > > > It's fixed on the testrunner trunk now. > > Very cool, thanks Christian. I'm already using 'src' in most of my > active packages, but I'll try it out and see. Is this fix in > zope.testing 3.7.6? Nope, I didn't care to cut a release right away. If you can't/don't want to use the trunk I'd be happy to cut one. Christian -- Christian Theune · ct(a)gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development

1 0

A suggestion for changing exception handler when loading 'c' optimisations to make modules more friendly for GAE
by Tim Hoffman 03 Jul '09

03 Jul '09

Hi all Can I make a suggestion that would make a couple of modules more gae friendly ;-) zope.interface and zope.i18nmessageid have 'c' optimisations which obviously don't work under app engine. When these modules are imported you get the following exception. gae/1.333250465889549129/zope/i18nmessageid/_zope_i18nmessageid_message.py", line 6, in __bootstrap__ imp.load_dynamic(__name__,__file__) File "/base/python_dist/lib/python2.5/py_imp.py", line 116, in load_dynamic raise NotImplementedError('This function is not supported on App Engine.') Unfortunately the code (in this case in zope.i18nmessageid.Message) does the following which doesn't deal with the Exception raised by the app engine runtime. try: from _zope_i18nmessageid_message import Message except ImportError: pass To make it more "gae friendly" I think we should change these occurrences to try: from _zope_i18nmessageid_message import Message except ImportError, NotImplementedError: pass Regards Tim

6 12

issues with building zope2.11.3
by Jonas Meurer 02 Jul '09

02 Jul '09

Hello, at preparing zope2.11.3 for debian, i came across several byte-compiling errors. three of them are due to the new tests for python2.5 and python2.6, and are just failing because python2.4 is the python version debian uses for zope2.11. but the last one seems to be a real bug: Compiling /usr/lib/zope2.11/lib/python/mechanize/_firefox3cookiejar.py ... File "/usr/lib/zope2.11/lib/python/mechanize/_firefox3cookiejar.py", line 91 yield row SyntaxError: 'yield' not allowed in a 'try' block with a 'finally' clause I also found this error in list archive logs of zope-tests(a)epy.co.at. from 'pydoc2.4 yield': The yield statement is not allowed in the try clause of a try ... finally construct. The difficulty is that there's no guarantee the generator will ever be resumed, hence no guarantee that the finally block will ever get executed. is this a known bug, and does a fix exist? greetings, jonas

2 5

zope.testing 3.7.7
by Christian Theune 02 Jul '09

02 Jul '09

I just released zope.testing 3.7.7. It only contains a single change: installing the test runner callable via a console_script entry point to allow simple usage without buildout. Christian -- Christian Theune · ct(a)gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development

2 4

FYI: svn.zope.org change for svn:// protocol service
by Jens Vagelpohl 02 Jul '09

02 Jul '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, This is a heads-up that affects anyone accessing the SVN repositories using the svn:// protocol (so it does not affect anyone accessing SVN over HTTP, or svn+ssh): So far the svn service was run through xinetd. We had recurring problems where either during really busy times or when too many svn service processes hung for unknown reasons xinetd would refuse to start more of them. This would lead to strange errors for people accessing the service. To hopefully solve that problem, and maybe solve the "hanging process" issues as well, I have switched to using the svnserve process in daemon mode instead of using it through xinetd. If you do use the svn:// protocol (maybe directly, or indirectly through a svn:extrnals definition, or for replicating the repositories with "svnsync") and see any issues please contact me directly off-list. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkpMwSkACgkQRAx5nvEhZLJgKwCglIvmEO9jeoEa3ZrYGo3fas+g 5LQAoJf+F7r4L31He5jrvubNqz7YnTpV =37QJ -----END PGP SIGNATURE-----

1 0

Re: [Zope-dev] How to test changes to ZTK packages?
by Jim Fulton 01 Jul '09

01 Jul '09

On Jun 30, 2009, at 10:14 AM, Stephan Richter wrote: > On Tuesday 30 June 2009, Jim Fulton wrote: >> I should know this, but I don't. What is the recommended way to test >> changes to core ZTK packages to mitigate the risk that changes affect >> other packages? Is there a page somewhere with instructions? >> >> I tried using using zope.release. Building the trunk of zope.release >> with Python 2.4 and running the tests gives lots of test import >> errors >> and test failures. (Lots of tests want to import z3c.pt.) The tests >> hang when I try to build and run with Python 2.6. > > Yes, I think testing with zope.release is a good way of doing this > right now. What is the difference between zope.release and zope.kgs? Is the latter a fossil? Does it need to go away? Why does zope.release have a 2-step build process? Perhaps naively, it seems that one could define a simple project that defined a test script over a "known good set" of projects. Is the 2-step process a consequence of maintaining the index or tar ball? (I'm not criticizing, I'm just trying to understand.) Jim -- Jim Fulton Zope Corporation

2 2