January 2007 - Zope-Dev

Zope Tests: 7 OK
by Zope Tests Summarizer 29 Jan '07

29 Jan '07

Summary of messages to the zope-tests list. Period Sun Jan 28 12:00:00 2007 UTC to Mon Jan 29 12:00:00 2007 UTC. There were 7 messages: 7 from Zope Unit Tests. Tests passed OK --------------- Subject: OK : Zope-2.6 Python-2.1.3 : Linux From: Zope Unit Tests Date: Sun Jan 28 21:05:38 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007139.html Subject: OK : Zope-2.6 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sun Jan 28 21:07:09 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007140.html Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sun Jan 28 21:08:39 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007141.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sun Jan 28 21:10:09 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007142.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Jan 28 21:11:39 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007143.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Jan 28 21:13:09 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007144.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Jan 28 21:14:39 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007145.html

1 0

RFC: Acquisition and __parent__ pointers
by Philipp von Weitershausen 28 Jan '07

28 Jan '07

This proposal aims at bringing Zope 2 a bit closer to Zope 3 by making the widely used Acquisition API aware of Zope 3's __parent__ pointers. This will alleviate the need of using Acquisition base classes in Zope 2 for every security-sensitive object, be it persistent or just a dynamically looked up component such as a view. The goal is to enable the use of Zope 3 components in Zope 2 straight away without creating subclasses that mix in Acquisition for security's sake. See http://wiki.zope.org/zope2/AcquisitionAndParentPointers for the full proposal. Comments are appreciated. I expect little resistance to this as it pretty much doesn't change any existing semantics and just makes all of our lives much simpler. Also, if it helps, this has been blessed by Jim in discussion at the EuroPython 2006 sprint. As for the implementation, I gave it my best shot in the philikon-aq-and-__parent__ branch. My experience with C is limited, especially when it comes to debugging. Help is therefore highly appreciated. There's a reward waiting for whoever fixes the problem and helps getting the branch merged to the trunk (see the proposal text). :) -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5

4 3

Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
by Jean-Paul Ladage 28 Jan '07

28 Jan '07

> - ploneout (http://svn.plone.org/svn/plone/ploneout/trunk) is really > an environment that Plone 3 core developers could (should?) use as a > consistent way of setting up a Zope 2.10 instance with Plone 3 and all > dependencies. It uses svn:externals quite extensively to pull in Plone's > source code into src/ (the eggs) and products/ (the products) with the > intention that this is the code being developed. Ploneout's README.txt > has more information about this scenario. To through in an extra angle in this discussion, I would like to contribute the following thoughts. Unless Utopia really exists I think developers all have their own thoughts about setting up their development environment. In my opinion buildout's target should be deployment of complex production systems. I had to read the buildout documentation twice to even get a grip of it and yesterday I wondered around in a forest of recipes in ploneout. Although I see the value of buildout, copying over the entire buildout to setup a second sandbox, seems like a waste of disk space to me. We work on quite a number of different projects at once and want to be able to reproduce a working instance (running the production Data.fs preferably). To service our environment we (mainly the van Rees brothers) wrote instancemanager. We expect a minimal set of requirements: - Python installed - Zope libraries installed next to each other, e.g. /usr/local/zope/2.10.2, each version in a separate folder. Using instancemanager you can: * Create / Start / Stop / Restart instances * Backup / Restore / Pack instance databases * Install Products * Run tests * Generate Apache VirtualHost configs * Easy upgrade Zope versions During the Snowsprint we'll finish Windows compatibility and creation of Z3 instances. Minimal configuration in ~/.instancemanager/userdefaults.py to show instancemanager which zope's are available. zope_location_template = '/usr/local/zope/%(zope_verion)' Each instance is then configured using a project.py. ~/.instancemanager/demo.py Inside this project file we can define all needed instance configuration options: * Initial user and password * Portnumbers * Zope / Python version used * Whether to use zeo, and how many zeo clients * Sources to install in the Products or lib/python folder - symlink_sources : Allow svn checkouts of products to be linked. - symlinkbundle_sources : Allow for svn checkouts of bundles (3.0) - archive_sources: Allow for official release tar files to be extracted. - archivebundle_sources: Allow for official release tar bundles to be extracted. Sources are defined as a list of dicts: archive_sources = [ {'url':'http://www.zope.org/Members/shh/DocFinderTab/1.0.1/DocFinderTab-1.0.1.tar.gz'}, {'url':'http://plone.org/products/clouseau/releases/0.7.1/Clouseau.0.7.1.zip'}, ] Here I defined two developers tools that need to be downloaded and extracted to the Products folder of my instance. symlinkbundle_sources = [ {'url':'https://svn.plone.org/svn/plone/bundles/3.0',}, {'url':'https://svn.plone.org/svn/plone/bundles/3.0-lib', 'pylib':True,}, ] Here I define the 3.0 bundle of Zope Products that will be symlinked and for the second we added the key 'pylib' a value of True to indicate this set of sources need to be linked in the lib/python folder. Sources are downloaded to a configurable location, instancemanager has set the following defaults: archive_basedir_template = /home/myuser/downloads archivebundle_basedir_template = /home/myuser/downloads symlink_basedir_template = /home/myuser/svn symlinkbundle_basedir_template = /home/myuser/svn Downloading happens only once, to limit bandwidth. Again most developers are pretty demanding about setting up a development environment. Here at Zest most of us are comfortable with instancemanager. There's an egg available in the cheeseshop, but for the latest features you can also checkout https://svn.plone.org/svn/collective/instancemanager/trunk Kind regards, Jean-Paul

1 0

Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
by Ian Bicking 28 Jan '07

28 Jan '07

Martin Aspeli wrote: >> Eggs exist to pkg_resources (the runtime portion of setuptools) simply >> by being available on a path. E.g., if you have lib/python/ on the >> path, and lib/python/Foo-1.0.egg/ exists, then if you do >> pkg_resources.require('Foo') that will add lib/python/Foo-1.0.egg/ to >> the path, and you can import from it. When you can actually import from >> the egg it is "active". You can also see its entry points at that time, >> but not if it is just available. >> >> If lib/python/Foo-1.0.egg/ is on the path to start with you can import >> from it directly. > > This is what zc.reipe.egg does I believe. It activates (i.e., adds eggs to the path) in the scripts. I think setuptools' egg activation will be superfluous at that point, because a complete and consistent set of eggs is activated up-front. I'm not even sure if you can activate any extra eggs (that might be available on eggs/ or something) at that point, because the containing directory isn't on the path. But since buildout controls those directories that would be fine, I guess, assuming you don't put anything in those locations on your own. In that way I suppose lib/pythonX.Y/ would be a misnomer of sorts, as eggs/ is just a storage area for eggs that are managed elsewhere (in buildout.cfg). OTOH, easy_install and setuptools generally has no problem dealing with eggs that *aren't* on the path, if you use a .egg-link or .pth file to point to the egg (preferably both). So while Jim hopes to have a centrally located repository of eggs (where buildouts only draw on a subset), this is already possible using setuptools' conventions. Then lib/python could become (BTW, existing Zope 2 stuff often seems to prefer lib/python/ over lib/pythonX.Y/, for reasons I don't really understand -- it basically prefers the distutils --home option over the --prefix option. So using workingenv with Zope I use workingenv.py --home, which sets up the environment slightly differently) > Secondly, have you seen this proposal? I'm sure you'd have something to > add. > > http://wiki.zope.org/zope2/EggifyingZopesExtensionMechanismQuotProductsQuot > > zc.buildout also uses entry points for its recipes, and several people > have talked about entry points instead of ZCML slugs, so I think things > are moving in this direction. I left some comments over here a while back: http://wiki.zope.org/zope3/ZopeConfigurationEggSupport But that's more about ZCMLy things. Philipp's proposal looks fine to me, though it doesn't seem to address how products would be activated or not (it seems to mention that eggs wouldn't be installed as products by default, but doesn't propose a mechanism to select the products). Because of the difficulty scanning for entry points if the egg isn't activated, I'd advocate sticking to something like enumerating (or blacklisting) distribution names. Then if you have: [zope2.products] CMFDefault = Products.CMFDefault the entry point name "CMFDefault" wouldn't be significant. Or you could select not just distributions, but distributions+entry_point name. In Paste I use egg:Package#entry_point_name (where entry_point_name defaults to "main"). I believe buildout uses Package:entry_point_name, where entry_point_name defaults to "default". If we could all agree on a convention, that'd be nice. I strongly prefer "main", because that's really what I think the unnamed entry point is, not just default -- "default" just refers to the parsing/locating strategy, not the intent. I also would like something that is unambiguously different from a Python object specifier, so that you could take either an explicit object reference or an entry point in the same place and be able to clearly tell the difference. But if we can agree on something and document it, I'm willing to update Paste Deploy to support the new/standard syntax. Ian

2 1

Re: [Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
by Jim Fulton 28 Jan '07

28 Jan '07

whit wrote: >> I'm not clear on what the advantage would be. I'm probably missing >> some use cases. I think they are both valid approaches to the problem. >> > my main usecase is to be able to use buildouts in a workingenv without > having to rewrite the recipes... right now, I have to do one or the other. Sure. I still don't know what that means. :) *Maybe* you'd like to use workingenv to install eggs and use buildout to do other things like set up zope instances. If that's the case, then it's just a matter of writing recipes that take into account how you install eggs and scripts. But maybe that's not what you mean. ... >> If people really see value in having buildout and workingenv work >> together, perhaps Ian and I could explore this a bit at PyCon next month. >> > +1. my general feeling is that there is a enough overlap that this > would be beneficial. Specific use cases would help to guide this. >>> try to justify why a zope hammer is better and why zope folk keep >>> building new hammers that don't play nice with everyone else's hammer >>> loses us cred. >> >> You seem to be implying that workingenv is somehow a standard tool and >> that buildout is a zope-specific tool that needlessly duplicates a >> standard tool. > I was perhaps offbase in my comment about egg handling. > workingenv of course is not a standard tool. what I'm presenting here is > a perspective I face on a regular basis; for a developer using > workingenv already, it's far more standard than something else he is not > using...and vice versa. No, it's more familiar -- to these people. > in the case of tools that enable a developer to > start quickly, developers are very difficult to ween from habits that > are currently working. when a large and complex task such as building > plone becomes codified in a technology that is not familar or easily > compatible with the the developers current environment, it's an issue. The alternative seems to be a custom shell script. I can see how this would be familiar to the people who wrote it. When there are well established and documented buildout recipes for doing common tasks, then there will be familiar tools, for some definition of familiar. >> zc.buildout is in no way zope specific. Can a Zope developer not >> develop a tool without it being stamped as "zope specific"? > maybe... maybe not. When a developer struggles with more than one tool > from the same general source, it matters little to them whether one > depends on the other or not. That's true for languages, companies, > frameworks and everything else. > > I think it really depends whether something transcends it's immediate > community(and maybe here whether a z floats in front of it's name > somewhere). So lets see. To contribute to the wider Python community, I should change the name of my Company or change jobs. Hm. > for packages from zope or plone people, if they rides > roughly with existing python techs In what way does buildout "ride roughly with existing python techs". It builds on setuptools. Do you mean that if there is another community package that does something somewhat similar, we aren't allow to create a similar package just because we are associated with the Zope project. > and come from a zopeish repository, Oh, I have to use a different repository. > sadly they are liable to get branded w/ a legacy reputation that haunts > the name. Has it occurred to you that the problem here doesn't lie with the Zope project or Zope developers? > inversely, those of us zope and plonistas may be a bit uncritical of > projects coming from close to home Oh, as someone who gets lots of criticism, I really don't think that is much of a problem. > and allow such technologies to stay > inaccessible to wider audiences. How are we doing this? The primary forum for discussing buildout is the distutils sig. It is released through PyPI. It doesn't depend on any other technology that we use -- other than Python. What should I do to make it more accessible? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

2 3

Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
by Hanno Schlichting 28 Jan '07

28 Jan '07

Martin Aspeli wrote: > This thread is getting rather long... :) But except for the interaction of workingenv and buildout, which I'm not smart enough to say anything useful about, we are almost finished ;) > - There is a 2.5 branch of ploneout > (http://svn.plone.org/svn/ploneout/branches/2.5) which pulls down > Plone 2.5's tarballs. This is possibly less useful at the > moment, more as an experiment, because it doesn't really set you up for > developing Plone 2.5's code (for that, we should use svn:externals > similarly to ploneout trunk). I changed the branch to correspond to the usual Plone 2.5 core development setup. > For other projects, you can re-use the z2c.recipe.* recipes or any other > recipes. Recipes are just eggs being loaded with entry points. They are > also fairly easy to write once you've seen an example. Meanwhile all the recipes have releases on the cheeseshop, so you can play around with them. They lack any documentation expect the example used in ploneout so far, but I'll fix that soon ;) Among the new features that I implemented this weekend is one inspired by Gocept's zope3instance recipe. The zope2instance recipe will create a script in the buildout root bin folder now, that acts as a simple wrapper around zopectl. So you can run everything from "./bin/instance test -s Products.MyProduct" to "./bin/instance start" from the buildout root without having to go down into parts. I changed the test command a bit in that script though. It will now automatically put all activated eggs and Products on the test path, so you can run tests in eggs (managed by buildout) without having to specify --test-path manually, which I found extremely annoying as of late. Just as a side note, I found the recipes to be stable and feature-rich enough to dump my old development setup and use the ploneout trunk and 2.5 branch instead ;) Hanno

1 0

Zope Tests: 7 OK
by Zope Tests Summarizer 28 Jan '07

28 Jan '07

Summary of messages to the zope-tests list. Period Sat Jan 27 12:00:00 2007 UTC to Sun Jan 28 12:00:00 2007 UTC. There were 7 messages: 7 from Zope Unit Tests. Tests passed OK --------------- Subject: OK : Zope-2.6 Python-2.1.3 : Linux From: Zope Unit Tests Date: Sat Jan 27 21:04:47 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007132.html Subject: OK : Zope-2.6 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sat Jan 27 21:06:17 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007133.html Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sat Jan 27 21:07:47 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007134.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sat Jan 27 21:09:17 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007135.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sat Jan 27 21:10:47 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007136.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sat Jan 27 21:12:17 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007137.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Sat Jan 27 21:13:47 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007138.html

1 0

Zope Tests: 7 OK
by Zope Tests Summarizer 27 Jan '07

27 Jan '07

Summary of messages to the zope-tests list. Period Fri Jan 26 12:00:00 2007 UTC to Sat Jan 27 12:00:00 2007 UTC. There were 7 messages: 7 from Zope Unit Tests. Tests passed OK --------------- Subject: OK : Zope-2.6 Python-2.1.3 : Linux From: Zope Unit Tests Date: Fri Jan 26 21:07:06 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007125.html Subject: OK : Zope-2.6 Python-2.3.6 : Linux From: Zope Unit Tests Date: Fri Jan 26 21:08:36 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007126.html Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Fri Jan 26 21:10:06 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007127.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Fri Jan 26 21:11:36 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007128.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Fri Jan 26 21:13:06 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007129.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Fri Jan 26 21:14:36 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007130.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Fri Jan 26 21:16:06 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007131.html

1 0

Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like
by Ian Bicking 26 Jan '07

26 Jan '07

Whit pointed me to this thread. I won't reply to specifics, but maybe just describe what we're doing (and planning to do), and how workingenv differs from zc.buildout. So... recently we (The Open Planning Project -- more specifically Rob Miller) decided we need a better way to deploy our specific stack. It was hard, we couldn't tell other people how to do it, and we spent a significant amount of time debugging each other's installations, or chasing down bugs that we ultimately realized were just because of slightly different installations. I'm sure you all understand the motivation; it's similar to what buildout is for, though we were more focused on repeatability as a development tool than as a deployment tool. I actually tried to do this once before with zc.buildout, but I didn't get far -- probably a result of lack of effort and lack of familiarity with the overall stack. But I also recognize lots of the questions about stuff like the zope.conf file and Data.fs that still seem unresolved. The thing that frustrated me with zc.buildout is that I knew how to do what I wanted to do, but I still felt like I was a long way from being able to do it. And little things, like unhelpful error messages and frustratingly slow performance really killed my motivation. After setting that project aside someone else at TOPP (Luke Tucker) did a buildout for Deliverance because we needed to build some non-Python libraries and that was a feature of buildout; that did end up working eventually (after considerable effort), but it was not a very satisfying experience, and *using* the buildout was itself a real challenge. Since Deliverance is just a library, to do anything useful I also had to install another package that *uses* that library, and that was surprisingly difficult. Actually developing those libraries was even more frustrating. So then Rob decides to devote some time to deployment. And because Rob just wants to get this finished, he wrote the whole things from scratch. You can see the result of that here: https://svn.openplans.org/svn/topp.deploy/trunk -- it's not a generic setup tool, just what works for us. The end result is something that does everything we want, that we understand, and that we'll understand how to extend. An important difference from zc.buildout is that all the logic and work is in *our* script, not in a framework driven by a config file. In the future Rob plans to use buildit (http://cvs.plope.com/viewcvs/Packages/buildit/) and one of the motivations there is that it has handy routines to do what topp.deploy already does, but better. It's more like a library and less like a framework. I could make some generalization here but I'll restrain myself. The deployment script also uses workingenv, somewhat similarly because it is more library-like. Well, also because I work at TOPP and can easily support their use, which is certainly a nontrivial reason for the choice. Workingenv in this case is basically a tool that provides the isolation that we need to create something repeatable. This is the main feature overlap with buildout. Workingenv is not the framework in which topp.deploy is written, and workingenv is not intended as a framework. Note also that topp.deploy does not have the full set of features we'll ultimately need. You can't tell it to install another egg, or setup another script, or whatever. And we don't *have* to add those features, because workingenv is compatible with all the other tools. Where "all the other" is mostly easy_install. But someday there will be more, even if the progress is slow. buildout is basically incompatible with easy_install (the script). And frankly I like easy_install. It's probably 10x faster than buildout. easy_install is what people use in documentation, and its conventions are the ones people know (why does buildout not use "Pkg==version", for instance?). As for the technical reasons they don't work together: * workingenv allows and leaves it to setuptools to maintain the package installation database (basically easy-install.pth). This is not a very good database, but eh. buildout doesn't really have a database, but instead just enforces what buildout.cfg indicates. * workingenv relies on that database to give default versions and to setup the Python path. The fixup it does of installed scripts is fairly minimal, just setting up sys.path enough to force its site.py to get called. buildout enumerates all the activated packages, and ignores easy-install.pth. This is basically what makes it easy_install-incompatible. Plus buildout's desire to own everything and destroy everything it does not own ;) * As a result buildout supports multiple things in the same buildout that have conflicting version requirements, but where the packages themselves don't realize this (but the deployer does). If the packages know their requirements then setuptools' native machinery allows things to work fine. The solution with workingenv is to create multiple environments. Since the actual building happens higher up (e.g., topp.deploy), there's nothing stopping you from creating multiple environments from one deployment script. Anyway, in summary the way scripts are generated is one of the major incompatibilities between buildout and workingenv. In effect Buildout's jail is too strong for workingenv to penetrate, and buildout doesn't tell anyone else about what it is doing. * workingenv allows you to change versions without informing or using workingenv. Once you've created the environment you mostly stop using workingenv directly. * Some see bin/activate as a jail. Both workingenv and buildout are deliberately jail-like. Both Jim and I loathe the non-repeatability of system-wide installations (at least I think I can speak for him on that one point ;). bin/activate lets you into that jail, and lets you work there. There is no way into a buildout. Frankly this weirds me out, and is a big part of my past frustration with it. Maybe that's because I'm in the relatively uncommon situation that I actually know what's going on under the hood of Python imports and packaging, and so it bothers me that I can't debug things directly. Anyway, neither requires activation when using scripts generated in the environment. And bin/activate is really just something that sets PYTHONPATH and then does other non-essential things like changing the prompt and $PATH -- I should probably document that more clearly. Neither can be entirely compatible with a system-wide Python installation, because Python's standard site.py f**ks up the environment really early in the process, and avoiding that isn't all that easy. In some ways virtual-python is the more complete solution to all of this, and sometimes I think I should just use that technique (of a separate Python interpreter, and hence separate prefix) with some of the improvements I could take from workingenv. Anyway, this is my very long summary of why we aren't using buildout, and are using workingenv. Cheers, Ian

2 3

Zope Tests: 7 OK
by Zope Tests Summarizer 26 Jan '07

26 Jan '07

Summary of messages to the zope-tests list. Period Thu Jan 25 12:00:00 2007 UTC to Fri Jan 26 12:00:00 2007 UTC. There were 7 messages: 7 from Zope Unit Tests. Tests passed OK --------------- Subject: OK : Zope-2.6 Python-2.1.3 : Linux From: Zope Unit Tests Date: Thu Jan 25 21:06:27 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007118.html Subject: OK : Zope-2.6 Python-2.3.6 : Linux From: Zope Unit Tests Date: Thu Jan 25 21:07:57 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007119.html Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Thu Jan 25 21:09:27 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007120.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Thu Jan 25 21:10:58 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007121.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Thu Jan 25 21:12:28 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007122.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Thu Jan 25 21:13:58 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007123.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Thu Jan 25 21:15:28 EST 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-January/007124.html

1 0