Re: [Zope-dev] Zope Tests: 31 OK, 5 Failed
Hello, Subject: FAILED : Zope 3.4.1 KGS / Python2.4.6 32bit linux From: ccomb at free.fr Date: Sat Jun 12 00:00:48 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-June/015152.html TS - - The KGS failure *is* a buildfailure, tied to zope.testrunner 4.0.2. Ummm, very weird. It works locally (with stock ubuntu python 2.4.6), tho no fancy virtualenv around it. buildout does not even touch zope.testrunner. zc.recipe.testrunner is pinned at 1.0.6, which does not use zope.testrunner. -- Best regards, Adam GROSZERmailto:agros...@gmail.com -- Quote of the day: Alienation produces eccentrics or revolutionaries ___ 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 )
Re: [Zope-dev] deciding whether to do work in tpc_vote or tpc_finish
Laurence Rowe wrote: On 8 June 2010 12:59, Chris Withers ch...@simplistix.co.uk wrote: Laurence Rowe wrote: it fails you will end up in an inconsistent state whatever. It's just that with the maildir implementation, it pretty much can't fail as it is only a rename and that should always succeed. Really, it should register as an after commit hook instead. How do I do that? transaction.get().addAfterCommitHook(callable, args, kwargs) Hmm, I realised from looking at the code this morning that this won't. The reason being that there's no equivalent AfterAbortHook where I can abort the messaging transaction in the event of transaction-package transaction abort. I see these things called synchronizers, though... what are they and what is their intended purpose? Where are they documented? My other thought was to have it commit the message send in tpc_vote, and make sure it sorts before zope.sqlalchemy. That way, if the message send fails, the transaction will be aborted, and that will include rolling back the zope.sqlalchemy session rather than committing it. In that case if the sqlalchemy commit fails, you still sent the message. Yeah, I guess given that, of the possible failure modes, I'd prefer the message not to be sent in the event of sqlalchemy commit failure, I should have it sort after sqlalchemy... cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ 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 )
Re: [Zope-dev] deciding whether to do work in tpc_vote or tpc_finish
Jim Fulton wrote: I guess my concern is that the benefits from implementing this should outweigh the cost in higher complexity. I don't think it really increases complexity all that much. I agree the potential benefit is pretty limited. I think, given the transaction packages increasing use outside the realms of ZODB, I'd prefer this not to be implemented, if only to keep the already complex process on transaction commit a little bit simpler... cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ 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 )
Re: [Zope-dev] Zope 2.13 - next steps
Am 12.06.2010, 20:58 Uhr, schrieb Hanno Schlichting ha...@hannosch.eu: Comments, suggestions, more work you'd like to get into 2.13? Hi Hanno, thanks for the information. I'm a little confused by the narrative - is Plone 4.0 being held back by a Zope 2 release? As I don't use Plone I don't care about its release status and I don't think it should drive Zope's release status. Maybe that's what you were saying and I didn't understand it correctly. I'm also a little confused that your discussions have been with the community but not on this list. Not that this list should be the channel for all the discussions (it in its own way is as exclusive as many other channels). For the rest - deprecating zope.app on its own is probably a sufficiently large change to warrant a new point release which will hopefully tie into KGS. The same is true for five. Support for Python 2.7 would be great if doable (again not clear) and bumping the ZODB version. So the scope and schedule for the release is fine with me. We might want to add some of the issues to the weekly IRC meetings. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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 )
Re: [Zope-dev] Zope Tests: 36 OK, 8 Failed
Am 12.06.2010, 19:56 Uhr, schrieb Jens Vagelpohl j...@dataflake.org: I had grabbed this particular invocation somewhere on the web, its main aim is to ensure that the x86-64 architecture is always forced and not some package default that may or may not be correct. I'd second this. Apple seriously screwed up Python in Snow Leopard - it included private hacks and required reverse engineering by the Python developers for their own release. Quite a few changes in Snow Leopard cause problems when compiling. I would suggest using either MacPorts (my preference) or the Python.org version rather worrying about which compiler flags have to be set. Charlie -- Charlie Clark Managing Director Clark Consulting Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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 )
Re: [Zope-dev] Zope 2.13 - next steps
Hi Charlie, On Sun, Jun 13, 2010 at 2:06 PM, Charlie Clark charlie.cl...@clark-consulting.eu wrote: thanks for the information. I'm a little confused by the narrative - is Plone 4.0 being held back by a Zope 2 release? No, Plone 4 is delayed for all the normal reasons of too many open bugs caused by the massive amount of changes it has seen. But Plone 4 being delayed also delays the next major Plone (5) release. Traditionally Plone has only upgraded to new major Zope versions in its own major versions. As I don't use Plone I don't care about its release status and I don't think it should drive Zope's release status. Maybe that's what you were saying and I didn't understand it correctly. The Zope 2 release schedule has for some time now effectively been synced to match the Plone release schedule. We have seen what happens with a Zope 2 release that isn't used in Plone with the Zope 2.11 release. It's not seen much of any maintenance and has only caused extra effort, as we were forced to maintain multiple branches for a longer time. As I said back in March, I want to avoid any Zope 2 release that isn't directly picked up by Plone. This is also the reason why I briefly discussed the roadmap with some people in the Plone community - to get buy-in on the idea and then made a proposal to this list. Hanno ___ 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 )
Re: [Zope-dev] Zope 2.13 - next steps
On Sat, Jun 12, 2010 at 9:29 PM, David Glick davidgl...@groundwire.org wrote: Has the process of reviewing RestrictedPython against a new Python release been documented anywhere? Not that I know of. Stephan Richter and Sidnei da Silva were the last to do these reviews, maybe they know. Hanno ___ 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 )
Re: [Zope-dev] Zope 2.13 - next steps
On Sun, Jun 13, 2010 at 2:50 PM, Tres Seaver tsea...@palladion.com wrote: On the whole, I would actually favor getting a 2.13.0 out even sooner than Hanno suggests, to get it used (and therefore more polished) sooner. With the post-eggification reduction in Zope2's scope, I think a six month cycle for major releases would be a good target to aim at, rather than a year. I agree that a shorter release cycle is going to be more suitable again. I'm a bit conservative for 2.13 to make sure we really have a ZTK release in place and Plone 4.1 is picking this up. If both of these turn out to be true, than I can see another ZTK release used in 2.14 and Plone 4.2 picking this up again. I expect those kind of releases to aim for six month and some of them languishing a bit to end up with more like nine month. Still a lot shorter than the effective one to two years we have now. Hanno ___ 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 )
Re: [Zope-dev] Zope 2.13 - next steps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jonas Meurer wrote: thus i suggest to either provide monolithic tarballs which do contain the debendencies, or change release policy for the dependencies to not break backwards compability with every minor release. I think this discussion pops up over and over again. I bring it back the point: the native distribution packages for Zope friends are usually of interest for serious deployments. Our native deployment tool is 'buildout' as it is 'gem' for Ruby. Complete Python installations _by default_ are more in the interest of the end-user than having to deal with distribution specific problems that are not covered by the Zope Python community. My 2 cents, Andreas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwVCJsACgkQCJIWIbr9KYyyRwCfXr8OdibDwNGcQ8NZpHqC/vso rigAnRN1qHfuYzL2X7AL0efyJLKBUOs1 =+Rqr -END PGP SIGNATURE- attachment: lists.vcf___ 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 )
Re: [Zope-dev] Zope 2.13 - next steps
On 2010-06-13, at 1348, Hanno Schlichting wrote: On Sat, Jun 12, 2010 at 9:29 PM, David Glick davidgl...@groundwire.org wrote: Has the process of reviewing RestrictedPython against a new Python release been documented anywhere? Not that I know of. Stephan Richter and Sidnei da Silva were the last to do these reviews, maybe they know. There was talk of having a BoF at a conference or similar about the process of doing the RestrictedPython security audits, to make sure it doesn't become an arcane lost skill, any chance this could happen at PloneConf2010? Matt ___ 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 )
Re: [Zope-dev] Zope 2.13 - next steps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jonas Meurer wrote: hey, On 12/06/2010 Hanno Schlichting wrote: What do we have in Zope 2.13: [...] Comments, suggestions, more work you'd like to get into 2.13? another build system would be magnificent :-) the new build system in zope2.12 makes it hard/impossible to distribute zope2 binaries within linux/*bsd/hurd/... distributions. so far no distribution i know contains zope2.12, and the most obvious reason is the new build system. thus i suggest to either provide monolithic tarballs which do contain the debendencies, or change release policy for the dependencies to not break backwards compability with every minor release. Maintaining the mechoanism to release that monolithic tarball is not on anybody's plate at the moment. At the point that somebody does the work to make it painlessly automated, then we can ask the release manager to include that task in the release process. Until somebody does that work, this item is effectively tabled. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkwVGZ4ACgkQ+gerLs4ltQ5BKwCeIM41VBSJeGjEOe0J1EKKRYne 1yoAn1o6sUYJr9f5HJjlQjcCopEdzLWe =Ki1l -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 )
Re: [Zope-dev] Zope 2.13 - next steps
On Sunday, June 13, 2010, Hanno Schlichting wrote: On Sat, Jun 12, 2010 at 9:29 PM, David Glick davidgl...@groundwire.org wrote: Has the process of reviewing RestrictedPython against a new Python release been documented anywhere? Not that I know of. Stephan Richter and Sidnei da Silva were the last to do these reviews, maybe they know. There is no process really. You have to go through the changes in Python 2.7 and detect API changes in the C code to see whether any op-codes changed or a new API opens up some unwanted access. Regards, Stephan -- Entrepreneur and Software Geek Google me. Zope Stephan Richter ___ 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 )
