Re: [Zope-dev] Zope 4.0 roadmap & release plan
On Sat, Sep 14, 2013, at 0:38, Baiju M wrote: Is there any roadmap & release plan for Zope 4.0 ? I'm not aware on anyone still working on Zope 4. The project might come back to life at some point, but for the past couple of months it's been very quiet. At my work, we use Zope 2.12 and we are looking forward to upgrading to Zope 2.13. Depending on Zope 4.0 availability, we can think about directly moving to Zope 4.0 Zope 2.13 should be an easy upgrade. You can also selectively upgrade to DateTime 3 (huge memory savings) and Products.ZCatalog 3 (support for "not queries" and "sort_on" with multiple indexes). Note that security support for Zope 2.12 (and Python 2.6) ends in October, so upgrading is a good idea. 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 )
[Zope-dev] Zope Toolkit - 2.0a1 released
Hi. I made a first alpha release of the current ZTK master, which technically just means there's a stable version file at: http://download.zope.org/zopetoolkit/index/2.0a1/ztk-versions.cfg and an overview page at: http://docs.zope.org/zopetoolkit/releases/overview-2.0a1.html I hope this will help people test their applications against it and provide a first stepping stone to a feature freeze. Currently the release claims compatibility with Python 2.6, 2.7 and 3.3, though the 3.3 support is pending the ZODB decisions. Things that we'll need before we can call this beta: - Release final 4.x versions for all the libraries that currently only have an alpha release - Wait on the ZODB decision, from a ZTK perspective we can live with partial Python 3 support (as we don't provide it for RestrictedPython either) - Hope Tres gets bored and makes more libraries compatible with Python 3.2 - Preferably wait for some feedback from BlueBream / Grok / Zope 2 developers and their tests - Decide what to do with the missing Python 3 toolchain libraries like Paste, zc.resourcelibrary (as noted in a section in the versions file) Cheers, 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 )
[Zope-dev] Zope Toolkit - 1.0.8 and 1.1.6 released
Hi. On behalf of the Zope Toolkit release team and the Zope community, I'm happy to announce the release of the Zope Toolkit 1.0.8 and 1.1.6. Both releases are minor bugfix releases. To use the new releases, you can use: [buildout] extends = http://download.zope.org/zopetoolkit/index/1.0.8/ztk-versions.cfg http://download.zope.org/zopetoolkit/index/1.0.8/zopeapp-versions.cfg Updated versions: [name = old -> new] distribute = 0.6.27 -> 0.6.36 pytz = 2012c -> 2013b mr.developer = 1.18 -> 1.25 zc.buildout = 1.4.4 -> 1.7.1 zc.lockfile = 1.0.0 -> 1.0.2 zc.recipe.egg = 1.2.2 -> 1.3.2 zdaemon = 2.0.4 -> 2.0.7 zope.app.i18n = 3.6.3 -> 3.6.4 zope.file = 0.6.1 -> 0.6.2 zope.tales = 3.5.2 -> 3.5.3 or: [buildout] extends = http://download.zope.org/zopetoolkit/index/1.1.6/ztk-versions.cfg http://download.zope.org/zopetoolkit/index/1.1.6/zopeapp-versions.cfg Updated versions: [name = old -> new] distribute = 0.6.27 -> 0.6.36 pytz = 2012c -> 2013b mr.developer = 1.18 -> 1.25 zc.buildout = 1.5.2 -> 1.7.1 zc.lockfile = 1.0.0 -> 1.0.2 zdaemon = 2.0.4 -> 2.0.7 zope.annotation = 3.5.0 -> 3.6.0 zope.app.i18n = 3.6.3 -> 3.6.4 zope.tales = 3.5.2 -> 3.5.3 Kind regards, 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] GitHub and Travis CI
On Mon, Mar 4, 2013 at 8:00 PM, Stephan Richter wrote: > So my question is: What do we want to do? I would suggest E-mails on status > change should be sufficient. Cool, but please change the default email notification, it's set to "spam everyone all the time". See http://about.travis-ci.org/docs/user/notifications/#Notifications So until we have a good policy, please use: notifications: email: false 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] ZTK 2.0: Deprecate zope.sequencesort
On Thu, Feb 28, 2013 at 2:43 PM, Stephan Richter wrote: > I would like to deprecate zope.sequencesort in ZTK 2.0, since it cannot > properly ported to Python 3, since it depends heavily on the cmp() way of > sorting. I am also not a user of the package and I only tried to port the > package for completeness sake. Thx for trying. I'd be fine to drop it from the ZTK - Zope depends on it, but that just means it falls under their responsibility to maintain it. I think Grok never used it - so it fails the "two users" rule. In the same way, I think we should remove RestrictedPython and zope.untrustedpython from the ZTK. Since those are also very much dependencies of Zope alone and porting is going to be a very challenging task. 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-tests - FAILED: 22, OK: 12, UNKNOWN: 2
On Thu, Feb 28, 2013 at 8:00 AM, Marius Gedminas wrote: > On Thu, Feb 28, 2013 at 01:00:02AM +, Zope tests summarizer wrote: >> [3]UNKNOWN : Zope-trunk Python-2.6.8 : Linux >> [4]UNKNOWN : Zope-trunk Python-2.7.3 : Linux > > Something new: > > Zope-trunk Python-2.6.8 : Linux (x86_64) > > Running ./bin/alltests --all > /home/stefan/autotest/zope_runtests_4.sh: line 13: ./bin/alltests: No > such file or directory > > Zope moved to github, I guess. Somebody ping the owners of > zope-te...@epy.co.at please. I mailed Stefan Holek in private - might take some days for him to have time to do something. 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] ZTK 2.0 process
On Wed, Feb 27, 2013 at 5:04 PM, Sebastien Douche wrote: > 2. z3c.recipe.compattest and zc.recipe.testrunner doesn't work with Buildout > 2. Both do now. You currently need z3c.recipe.compattest from trunk though. I updated the ZTK trunk in the last days, and most of it should work under Python 3.3 now. To test do: svn co svn://svn.zope.org/repos/main/zopetoolkit/trunk ztk-trunk cd ztk-trunk python3.3 bootstrap.py bin/buildout bin/test-ztk Locally I get test failures for 10 packages - since not all are ported yet. But the overall buildout and test infrastructure works. Note that this is pulling in ZODB, ZEO and the compattest recipe from Git/SVN via mr.developers auto-checkout option. For everything else it uses (alpha) releases. If you want to test the master of every package, you have to run "bin/buildout -c development.cfg". > Can you tell me what is missing or deprecated in this list ? > https://github.com/sdouche/zopetoolkit-py3.3/blob/master/ztk.cfg Best check back against the canonical file in SVN as mentioned above. 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] ZTK 2.0 process
On Tue, Feb 26, 2013 at 6:12 PM, Stephan Richter wrote: > Could you outline what the first step would be to create an alpha release list > for 2.0? We could manually include an sdist of the ZODB 4 py3 branch to make > the tests pass under Python 3. I'll have to look at the procedure again a bit. Will do so in the next days and start updating svn.zope.org/repos/main/zopetoolkit/trunk >> - Drop all zope.app packages from the KGS (most were deprecated in ZTK 1.1) > > Some of the zope.app packages (the ones not deprecated) should stay or simply > be renamed to not being called zope.app.*. Our rule for inclusion in the ZTK is: Whatever library is used by at least two out of the three frameworks (BlueBream, Grok, Zope). Given that BlueBream hasn't seen any release beyond a 1.0 about two years back, I'm not sure it's active or relevant anymore. Grok isn't seeing frequent releases, but there was a 1.5.5 mid last year. If you compare the version list from the last ZTK 1.1.5 (http://download.zope.org/zopetoolkit/index/1.1.5/zopeapp-versions.cfg) and Grok 1.5.5 (http://grok.zope.org/releaseinfo/1.5.5/versions.cfg), you'll notice that Grok already overwrites the version requirement for half of the non-deprecated packages with its own versions. And as I said, Zope isn't using any of them anymore for a long time. So I don't see any value in testing and promising stability for those zope.app packages, when there aren't any shared consumers for the specific versions. And the actually used versions by Grok are: zope.app.applicationcontrol, zope.app.appsetup, zope.app.debug - renaming those to a non zope.app prefix doesn't make a lot of sense for me either - as they are all about a specific app server configuration and not generally reusable libraries. 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] ZTK 2.0 process
Hi. The process for a ZTK 2.0 release isn't really well defined. I'm not sure if Jan-Wijbrand and Christophe are still interested in working on ZTK releases. Contrary to wait I said before I'd be willing to work on a ZTK 2.0 release (knowing the tools and procedure). My goals for a 2.0 release would be (comparing to http://docs.zope.org/zopetoolkit/releases/overview-1.1.html): - Drop support for Python 2.5 (ZTK 1.1 still supports that) - Add support for Python 3.x (either 3.3 or 3.2 and 3.3) - Drop all zope.app packages from the KGS (most were deprecated in ZTK 1.1) - Update to buildout 2 - Update to ZODB 4 Hanno On Tue, Feb 26, 2013 at 4:45 PM, Stephan Richter wrote: > Hi everyone, > > what is the process to start working on ZTK 2.0? We are about 5-6 packages > away from porting ZTK to Python 3 and I would like to start working on a new > release. > > 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 ) ___ 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] Changing id generation in OFS CopyContainer
Hi. Sorry, but 2.13 is in bug-fix-only mode. At least as long as I have to do the release management for it. Trunk is fair game, or up to Leonardo really. Hanno On Fri, Jan 11, 2013 at 2:09 PM, Wichert Akkerman wrote: > I want to use INameChooser to select the id of copied content. This is > currently not possible since manage_pasteObject does not pass the object to > be pasted to _get_id. I added a new wichert-ofs-paste-naming branch to > extend _get_id to make that possible. Are there any objections to merging > that change to 2.13 and trunk? > > Wichert. > ___ > 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 ) > ___ 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] Status of the buildout organization on github and a deleted branch
The buildout 1.6.x branch was renamed to "1". Jim discussed and announced that on the buildout-development list. Please follow-up on that list for buildout issues. Hanno On Fri, Jan 11, 2013 at 1:51 PM, Patrick Gerken wrote: > Hi, > > I thought I have was part of the buildout organization, but I am not now. > I noticed because I wanted to recreate a branch that went missing. > > Could I either get commit access or could somebody recreate the 1.6.x > branch. There is a buildout extension that breaks because of the missing > branch. > > There seems to be no way to identify where exactly the branch was deleted, > but the last mention of the branch is > ef8c5e2a0d689e88e2a038f8346259e631956a1f > > Committed by Adam. I don't know if that was a merge that removed the > branch or not, but as a starting point for a resurrected 1.6.x branch it > seems bo ge good enough > > Best regards, > >Patrick > > ___ > 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 ) > > ___ 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] Status of github migration
On Thu, Jan 10, 2013 at 3:59 PM, Jim Fulton wrote: > On Thu, Jan 10, 2013 at 9:50 AM, Jens Vagelpohl > wrote: > > I did not choose to include or exclude any branch. The test migration > uses the package used to migrate most Plone packages from SVN to GitHub, > which uses svn2git underneath. If there's whole branches missing the > migration has obviously failed. > > I had a bunch of problems with ZODB and the ruby svn2git. > If you used a ruby tool, then you didn't use the same one as the Plone migrations. Unfortunately there's at least two different tools named svn2git. The one used by the Plone migrations is from the KDE community and written in Qt. Some of the more useful info is at http://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git That tool doesn't really use git-svn. Instead it scan through all SVN revisions, looks at the changed paths and matches those against a ruleset. So you can tell it that both /foo/bar/trunk and /bar/trunk contain code that goes into the final bar.git repo. Since you can manually influence these rules, this tool tends to work better on projects which have moved their location in SVN a lot. It also does a single scan through the entire SVN repo and is able to generate many resulting git projects at once. Which made it perfect for a mass-migration. git-svn or tools based on it, tend to work well on small projects that always stayed in the same place, with the same structure. 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] Small fix in Products.ZCTextIndex, how to go further?
Hi. The change looks ok. But I think you broke an optimization. IIRC the code compares the old and new values for the index, and skips the indexing step if they are the same. The typical item.reindexObject() call sents data for all indexes, even if just one or two them have changed. The optimization made sure to skip any extra work, if there wasn't really any change for the text index. Without that check, you end up updating and writing a bunch of internal data structures in the text index every time. Those lead to slower write performance and more conflict errors. Could you have another look, and see if you can preserve the optimization? Thanks, Hanno On Wed, Nov 14, 2012 at 4:16 PM, Gauthier Bastien wrote: > Hi everybody, > > I made a small change in the current Products.ZCTextIndex product, the > change can be saw here : > > > http://svn.zope.org/Products.ZCTextIndex/trunk/src/Products/ZCTextIndex/ZCTextIndex.py?rev=128273&sortby=log&r2=128273&r1=113689 > > and I added a test here : > > > http://svn.zope.org/Products.ZCTextIndex/trunk/src/Products/ZCTextIndex/tests/testZCTextIndex.py?rev=128273&sortby=log&r2=128273&r1=113689 > > This fixes ticket : https://dev.plone.org/ticket/13310 : while > reindexing, if the new content is empty, the index is not reindexed and the > last indexed value is kept. > > I just wonder if it was the way to go, and if it was and if a reviewer can > confirm that changes are OK, what to do to release a new version because > this is a huge bug for us... > > Thank you and have a nice end of day, > > -- > > Gauthier Bastien > Support IMIO - CommunesPlone > rue de la Vieille Sambre 34 > 5190 Mornimont > Tél: +32(0)71 780979 > > Disclaimer > > Les informations contenues dans ce courrier électronique (annexes > incluses) sont confidentielles et réservées à l'usage exclusif des > destinataires repris ci-dessus. Si vous n'êtes pas le destinataire, soyez > informé par la présente que vous ne pouvez ni divulguer, ni reproduire, ni > faire usage de ces informations pour vous-même ou toute tierce personne. Si > vous avez reçu ce courrier électronique par erreur, vous êtes prié d'en > avertir immédiatement l'expéditeur et d'effacer le message e-mail de votre > ordinateur. > > De informatie in deze e-mail, bijlagen inbegrepen, is vertrouwelijk en is > als dus danig voorbehouden voor exclusief gebruik door de hierboven > vermelde bestemmeling(en). Indien u niet de bestemmeling bent, willen wij u > erop wijzen dat u deze informatie niet mag aanwenden voor eigen gebruik > noch verspreiden aan derden. Indien u deze e-mail per ongeluk hebt > ontvangen, gelieve de afzender onmiddellijk te verwittigen en deze e-mail > van uw computer te verwijderen. > > The information contained in this e-mail and the annexed documents is > confidential and exclusively available to the here above mentioned > addressee(s).Should you not be the addressee, please be informed that you > may neither disclose nor reproduce this e-mail, nor may the information > contained in this e-mail and its eventually annexed documents be used by > yourself or by a third party. If you erroneously received this e-mail, > could you kindly and immediately inform the addresser and delete the > message on your computer. > > ___ > 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 ) > > <>___ 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] SVN: Zope/branches/2.12/ LP #1047318: Tighten import restrictions for restricted code.
On Mon, Sep 10, 2012 at 10:31 AM, yuppie wrote: > CMF uses some ZTUtils in restricted code: Batch, LazyFilter, make_query and > SimpleTreeMaker. The new Zope 2 releases (2.12.24 and 2.13.17) are not > compatible with existing CMF releases. Is this intended? This wasn't intended. > CMF could declare the ZTUtils it uses as public. But that would require new > CMF releases for the new maintenance releases of Zope. And other packages > might have the same problem. ZTUtils is part of Zope2 and clearly intended for use inside templates / restricted code. So it should be fixed there. > Were the restrictions tightened too much in Zope? I'm not sure. There isn't really any clear documentation on what APIs you are supposed to use. It seems ZTUtils.__init__ sets __allow_access_to_unprotected_subobjects__ = 1 on the module scope level. But it doesn't use the allow_module or ModuleSecurityInfo APIs. I'm guessing this is all historical baggage and the "proper" APIs were only created much later. Maybe some other long term developers can chime in with their perspective? 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-tests - FAILED: 24, OK: 17, UNKNOWN: 2
On Wed, Aug 29, 2012 at 3:25 PM, Tres Seaver wrote: > That base class has been gone since ZConfig 2.9.2. I don't think the > Zope2 trunk has pinned / unpinned ZConfig in a long time, so I'm not sure > why it would just now break (ZConfig 2.9.2 was released in February, and > 2.9.3 in June). I updated the ZTK trunk to some new versions recently. Zope2 trunk likely tracks ZTK trunk and thus broke. 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] AccessControl bug fixed
On Thu, Aug 23, 2012 at 5:23 PM, wrote: > does this have any security implications? In short: No. Long answer: Not unless you have very custom code similar to what's in the provided test (providing a custom rolesForPermissionOn callable on a class). And that code would have never worked as intended or at least it would have already been broken in Zope 2.12. 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] AccessControl bug fixed
On Wed, Aug 22, 2012 at 3:00 PM, Yusei TAHARA wrote: > I found a bug in ZopeSecurityPolicy and fixed it. > > http://svn.zope.org/AccessControl/trunk/src/AccessControl/ZopeSecurityPolicy.py?rev=127548&r1=113657&r2=127548 > > Is it possible to release new version? I can do that. But is there any chance you could write a test for this. Or at least tell us how you found this bug? 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] We need to change how code ownership works.
The Plone Foundation adopted a policy for this, see http://plone.org/foundation/materials/foundation-resolutions/patch-policy-052011 As we don't have any terms of service stating so for any of our issue trackers, we don't get any copyright assignments for reported bugs or proposed patches. Patches can be sent we private email, posted to bug trackers, on paste.org like services or sent via pull requests. All of those are legally the same and it's the responsibility of the person doing the checkin to validate the copyright situation. That said a lot of patches don't actually contain any creative work that falls under the copyright rules. This last point is the reason most projects aren't very strict about this issue. Hanno On 19.08.2012, at 13:01, Lennart Regebro wrote: > On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl wrote: >> >> On Aug 19, 2012, at 10:17 , Lennart Regebro wrote: >> And since it becomes ever easier to accept code from unknown sources (e.g. pull requests) legal code ownership becomes an issue again. >>> >>> And that returns me to my first question: Is it really legally >>> different for a contributor to accept a pull request from a >>> non-contributor compared with a contributor merging a patch from a >>> non-contributor? >> >> Legally, both are disallowed unless there's some proof (written statement >> etc) from the code author that he assigns ownership of the patch or the >> contents of that pull request to the contributor who is doing the checkin. >> >> In the past we haven't done a good job of enforcing this clear ownership >> assignment chain. There are always code patches from non-contributors in the >> bug tracker that may make it into the code base with the help of a >> contributor. There's a grey area: Is the act of submitting a patch into the >> Zope bug tracker enough to signal "I am giving you ownership of this code"? >> I am not sure. >> >> GitHub makes this pulling in of "outside" code even easier. I'm afraid it >> will become even harder to really maintain this chain of custody. > > This is then, IMO a problem that we should fix. What you are in fact > saying is that the current system are violating people's copyright > everytime we merge a non-contributors patch. It is unfeasible to not > merge peoples patches, and I think it is also a big problem that the > way the ownership of the code works now inhibits the increased > simplicity of making and merging fixes for non-core contributors. > > In other words, we have had an ownership situation which is terrible, > and nobody seems to have realized this until now. Well, now we know. > > As such, the discussion must now shift from "don't do this" to "how do > we do this". Poeple want to contribute and we should not say "don't do > that", we have to figure out *how* to make it possible to do that, and > pretty pronto as well. > > //Lennart > ___ > 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 ) ___ 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] [Checkins] SVN: zc.buildout/ Moved to github
Please note that development of buildout 2 happens on github since April this year. The buildout developers decided to do the move after Jim suggested it. Legally you could see this move as a fork, but it was done by Jim and others. Alex just wanted to clarify the situation and also move the development of the stable branch into the same place. Hanno On 18.08.2012, at 09:49, Jens Vagelpohl wrote: > Hi Alex, > > Please revert this checkin. You can't just take core software pieces from > Zope Foundation-hosted repositories and move them somewhere else. > > Thanks! > > jens > > > > On Aug 18, 2012, at 3:09 , J. Alexander Clark wrote: > >> Log message for revision 127519: >> Moved to github >> >> >> Changed: >> A zc.buildout/README_MOVED_TO_GITHUB.txt >> D zc.buildout/trunk/ >> >> -=- >> Added: zc.buildout/README_MOVED_TO_GITHUB.txt >> === >> --- zc.buildout/README_MOVED_TO_GITHUB.txt(rev 0) >> +++ zc.buildout/README_MOVED_TO_GITHUB.txt2012-08-18 01:09:06 UTC (rev >> 127519) >> @@ -0,0 +1 @@ >> +https://github.com/buildout/buildout/tree/1.6.x >> >> ___ >> checkins mailing list >> check...@zope.org >> https://mail.zope.org/mailman/listinfo/checkins > > ___ > 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 ) ___ 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 trunk: browser views
On Tue, Jul 10, 2012 at 7:29 AM, yuppie wrote: > Zope 2 has customized implementations of the ``browser:view`` and > ``browser:page`` directives. I tried to make that code more similar to > zope.browserpage without breaking Zope 2 and CMF. I guess the biggest change > I made was removing the Five version of BrowserView from the base classes. > > Please let me know if you have any questions or if I did break something. Did you add a changelog entry? Maybe that could mention that the aq_* attributes are no longer available on those views/pages (Five's BrowserView's only purpose is to provide those for backwards compatibility). 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.intid and zope.keyreference.interfaces.NotYet exception (patch)
On Tue, Jul 3, 2012 at 1:56 PM, Jan-Wijbrand Kolman wrote: > At the end of this post, I pasted the diff from the current zope.intid > trunk against your "fork" on bitbucket. Maybe this would make it easier > for others to comment on it? It would be easier to read if you did the diff against the base version the fork was started from. Or otherwise update the fork with the changes done in the meantime. I see a bunch of unrelated changes in there, like the implements/implementer changes. I'm not sure what else is unrelated to the proposed change. 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] using WSGIPublisher
On Wed, Jun 6, 2012 at 7:06 PM, Tres Seaver wrote: > On 06/06/2012 12:11 PM, Hanno Schlichting wrote: >> I've looked into WSGI again at the Plone Symposium East sprint and I >> think we should remove the middleware approach again for Zope2. >> Primarily as we loose some features like publisher events and >> exception views, which in practice are used by Plone. [snip my subjective view on repoze project] >> So I'd probably just merge back the exception and transaction >> handling into the Zope2 WSGI publisher (keeping some of the code >> cleanup). > > That could still be a reasonable choice. Another choice would be to just > add an integration point into the publisher which wrapped the middleware > in at startup time, without requiring explicit configuration. As I said above, my main concern is keeping publisher events and exception views intact. Some of these events need to happen in code that's currently inside repoze.* middleware. Like "before transaction commit", "publication failure" or "publication success". For exception handling Plone wants to load some settings from inside the database. Mangling those into a WSGI environment is a bit tedious - having a real Zope request/response object makes that a bit easier. 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] using WSGIPublisher
On Wed, Jun 6, 2012 at 5:06 PM, Paul J Stevens wrote: > FYI, I'm using the following buildout: > > https://github.com/pjstevns/plone.mongrel2 You are missing some required middleware for the current un-documented WSGI feature. I made an experiment quite a while back and came up with: https://github.com/hannosch/zope2-wsgi/blob/master/templates/zope.ini I've looked into WSGI again at the Plone Symposium East sprint and I think we should remove the middleware approach again for Zope2. Primarily as we loose some features like publisher events and exception views, which in practice are used by Plone. There's a reason why Pyramid came up with the tweens concept and I think there's little benefit for existing Zope2 applications to be split up into middleware. Since the repoze project itself isn't moving forward any longer, there's little benefit in code re-use with it either. So I'd probably just merge back the exception and transaction handling into the Zope2 WSGI publisher (keeping some of the code cleanup). 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 )
[Zope-dev] Zope Toolkit - 1.0.7 and 1.1.5 released
Hi. On behalf of the Zope Toolkit release team and the Zope community, I'm happy to announce the release of the Zope Toolkit 1.0.7 and 1.1.5. Both releases are minor bugfix releases. To use the new releases, you can use: [buildout] extends = http://download.zope.org/zopetoolkit/index/1.0.7/ztk-versions.cfg http://download.zope.org/zopetoolkit/index/1.0.7/zopeapp-versions.cfg Updated versions: [name = old -> new] zope.event = 3.5.1 -> 3.5.2 zope.exceptions = 3.6.1 -> 3.6.2 zope.index = 3.6.3 -> 3.6.4 zope.sendmail = 3.7.4 -> 3.7.5 zope.tales = 3.5.1 -> 3.5.2 distribute = 0.6.24 -> 0.6.27 pytz = 2011n -> 2012c New tool chain versions: coverage = 3.5.2 nose = 1.1.2 or: [buildout] extends = http://download.zope.org/zopetoolkit/index/1.1.5/ztk-versions.cfg http://download.zope.org/zopetoolkit/index/1.1.5/zopeapp-versions.cfg Updated versions: [name = old -> new] zope.event = 3.5.1 -> 3.5.2 zope.exceptions = 3.6.1 -> 3.6.2 zope.index = 3.6.3 -> 3.6.4 zope.sendmail = 3.7.4 -> 3.7.5 zope.tales = 3.5.1 -> 3.5.2 distribute = 0.6.24 -> 0.6.27 py = 1.4.7 -> 1.4.8 pytz = 2011n -> 2012c New tool chain versions: coverage = 3.5.2 nose = 1.1.2 Kind regards, 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-tests - OK: 41
On Sun, May 27, 2012 at 3:39 PM, Tres Seaver wrote: > On 05/26/2012 09:00 PM, Zope tests summarizer wrote: > >> Non-OK results -- >> > Yay! Indeed! I updated the ZTK 1.0/1.1 branches to the latest respective bugfix releases. If the buildbots stay green, I'll tag new ZTK releases on Wednesday. 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 )
[Zope-dev] ZTK 1.0 lifetime
On Tue, May 22, 2012 at 4:32 AM, Patrick Gerken wrote: > Well, the question is, is there still a need for ztk 1.0 tests? If so, > who are the consumers and for how long should we run the tests for > 1.0? Zope 2.13 is based on the ZTK 1.0. There's no version of Zope 2 that uses ZTK 1.1 and a potential Zope 4 is aiming at a future ZTK 1.2 (currently ZTK master). So from Zope 2's and Plone's perspective the ZTK 1.0 tests are vital and should be supported for the next couple of years. The only difference is that Zope 2 requires at least Python 2.6, so testing Python 2.5 + ZTK 1.0 isn't required. And this shouldn't be all too hard, as there's no major differences between ZTK 1.0 and 1.1. 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-tests - FAILED: 122, OK: 33, UNKNOWN: 2
On Thu, May 10, 2012 at 6:49 PM, Tres Seaver wrote: > Can we please decomission the winbot until somebody has time to fix it? > The false negatives could be masking real problems. I tried to reproduce the problem manually on the winbot, but my remote connection died every 10 seconds - so after an hour I gave up. I've now disabled the "dev" builders using checkouts of all ZTK/ZopeApp packages and restarted the server. Let's see if the tests for released packages still work. 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-tests - FAILED: 1, OK: 37, UNKNOWN: 2
On Wed, May 2, 2012 at 3:40 PM, Adam GROSZER wrote: > or why that package gets included Adding zc.sourcefactory to the ZTK was a conscious choice. It was popular and often used in "Zope 3"-style projects, maybe even part of core Grok and BlueBream. We could remove it from ZTK 1.2, but cannot just drop it from the stable 1.0 and 1.1 series. 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-tests - OK: 34, UNKNOWN: 6
On Fri, Apr 27, 2012 at 3:18 PM, Adam GROSZER wrote: > On 04/27/2012 02:58 PM, Patrick Gerken wrote: >> There still seem to be processes hanging on the windows boxes, >> unfortunately. > > restarted the whole box > if this happens again then something is wrong with the tests lately This happened four times now, always hanging on the zc.sourcefactory tests. So I think it's safe to assume there's an actual problem with those tests and not the buildbot. 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-tests - FAILED: 6, OK: 33, UNKNOWN: 2
On Fri, Apr 20, 2012 at 4:03 AM, Tres Seaver wrote: > On 04/19/2012 09:00 PM, Zope tests summarizer wrote: >> [2] UNKNOWN UNKNOWN : winbot / ztk_dev py_265_win64 >> https://mail.zope.org/pipermail/zope-tests/2012-April/060786.html > > Ditto. Maybe that box needs an intervention? Yep. There were some hanging processes. I killed them all, cleaned the build folder and am restarting the box now. Should be better tomorrow, 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] Sanity Check on zope.sessions and Zope 2.12.x
On Wed, Apr 11, 2012 at 1:13 PM, Jeff Rush wrote: > I'm chasing a problem when trying to use zope.sessions with Zope 2.12.x, and > I'm beginning to think that they are an incompatible mix of Zope2 and Zope3 > technologies. > > Can anyone confirm either way, so I know whether I'm wasting my time. Sounds likely. I haven't heard of anyone trying to use zope.session in Zope 2. Does zope.session do something very different from the Zope 2 session manager? You might also want to look at http://pypi.python.org/pypi/collective.beaker for seamlessly integrating Beaker into Zope 2 - with all the advantages of Beaker and different backends. 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] Adding broken/missing support to zope.interface?
On Mon, Apr 9, 2012 at 10:33 PM, Tres Seaver wrote: > Persistent component registries are not a good enough reason to add such > coupling (I'd be in favor of splitting support for persistent registries > out of zope.component, too, while we're at it). > > Let's put the "broken" support into code which depends on > zope.interface, zope.component, and the ZODB, and invert the dependency > by having the new code install something into the base code which > provides the desired support: the only change to zope.interface should > be documenting the insertion point, and testing that it does the right > thing when a dummy is plugged into it. I looked at the possible contenders for that dependency description. The ZODB depends on zope.interface itself, though not on zope.component. zope.container is the one that has the most minimal dependencies, while still relying on zope.component and the ZODB. zope.site depends on zope.container, but given its scope sounds like the better place to me. I vaguely remember us discussing to move persistent registries into zope.site at some point. Since we moved zope.site.hooks into zope.component, zope.site doesn't have much else to do anymore. Apart from those two, there's a whole lot more that have far more dependencies or are unrelated in scope, like zope.annotation or zope.catalog. 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] Bugtracker for z3c.relationfield and reasons for objects loosing their parent pointers
On Tue, Mar 27, 2012 at 3:50 PM, Patrick Gerken wrote: > Hmm, since I didn't understand what magic happens with __parent__ pointers, > I tried the following in pdb: > unwrapped = aq_base(a) > unwrapped.__parent__ = aq_base(a.__parent__) > > So I stored a not acquisition wrapped object onto the __parent__ attr > of another unwrapped object. > But then the result, unwrapped.__parent__ was acquisition wrapped again! Yep. That's one thing we changed in Acquisition and ExtensionClass 4.0a1: Prevent wrappers to be created while accessing __parent__ on types derived from Explicit or Implicit base classes. Usually accessing any attribute on a type derived from Acquisition.Explicit or Implicit will force wrapping to take place, unless there's already a wrapper present. Maybe you remember the whole weird story with browser views in Zope 2 and the need for using "context = aq_inner(self.context)". That was the same problem. Accessing the context attribute of the view (self), created a wrapper equivalent to: "context = context.__of__(self)", as the view itself wasn't wrapped in anything. For views we got rid of the problem by removing the Acquisition.Implicit base class. For normal content classes in Zope 2, removing the Implicit base class is much harder, as there's more stuff depending on it, and you'd need to ensure to switch every type derived from this, to manually store parent pointers. But the 4.0a1 releases of AQ/EC at least treat __parent__ differently, as it doesn't make much sense to force wrapping for that particular attribute. 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] Bugtracker for z3c.relationfield and reasons for objects loosing their parent pointers
On Tue, Mar 27, 2012 at 2:53 PM, Patrick Gerken wrote: > I found out, somewhat surprised, that __parent__ pointers are just > disguised aq_parent pointers. Are you maybe trying to use or set __parent__ on Acquisition wrappers instead of unwrapped objects? AQ wrappers have various attributes, among those aq_parent and __parent__ being the same thing. If you store an actual __parent__ attribute on a "real" object, you should make sure to not wrap it in an Acquisition context or explicitly unwrap it before we Acquisition.aq_base(obj). You might need some compatibility code for "Zope 3" libraries, to introduce aq_base calls in the right places. On any one object, you use either parent pointers to real persistent objects, or you use Acquisition. Zope 2.12 has not introduced anything to actually store pointers to real objects. It just provides forward compatibility, so objects that do have those pointers, can avoid using Acquisition. And all of that while keeping the Acquisition API's like "from Acquisition import aq_parent, aq_get") intact and working for both types of approaches. Or well, this is a bit of a lie, Zope 2.12 actually did change things for browser views, so those don't inherit from Acquisition anymore, but with those view.__parent__ is just the same as view.context - so it's easier. We worked on actually storing parent pointers on objects during last years Zope 4 sprint at Plone Conf. But today I doubt using parent pointers actually works. Or at least you have to be really careful with Acquisition wrappers and cannot use API's like OFS.CopySupport or ZEXP export. 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] New release for zope.schema
On Wed, Mar 21, 2012 at 6:58 PM, Marius Gedminas wrote: > For packages that have C extension modules there are probably extra > steps needed to produce Windows binary eggs. I don't know those > steps (winbot is involved somehow), so I avoid making releases of > packages that have C extension modules. How do I check if a package > has C extension modules? I go to PyPI and look if there are Windows > binary eggs available for download for the current version. > zope.schema doesn't, so I'm just including this for general > reference purposes. The point of winbot is to take away all the pain and it does so. There's no extra steps at all for packages containing C extensions. Just make sure you create a release with a proper tag - winbot does the rest. 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-tests - FAILED: 4, OK: 35
On Thu, Mar 15, 2012 at 5:39 PM, Marius Gedminas wrote: > On Thu, Mar 15, 2012 at 03:40:25PM +0100, Hanno Schlichting wrote: >> z.a.publication added a new requirement for ZODB3>=3.10. But ZODB on >> its 3.10 branch notes its version as 3.10dev. > > Eh? That implies that 3.10 will be the next released version from that > branch, which makes no sense, given that the last release was 3.10.5. > The branch should identify itself as 3.10.6dev. I think Jim always used a slightly different approach, preferring to keep any version numbers out of SVN, so we are "lucky" it states 3.10 at all. As the ZODB isn't part of the ZTK, the ZTK guidelines on version numbers don't apply. I don't see any real issues here. >> As 3.10dev < 3.10 the >> check failed. >> >> Relaxing the check to "ZODB3>=3.10dev" should fix this. Alternatively >> "ZODB3>3.10.999" would have worked as well. > > Perhaps you meant ZODB3 > 3.9.999? yes, sure. 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-tests - FAILED: 4, OK: 35
On Thu, Mar 15, 2012 at 1:22 PM, Tres Seaver wrote: > On 03/14/2012 09:00 PM, Zope tests summarizer wrote: >> [1] FAILED winbot / ztk_dev py_265_win32 >> https://mail.zope.org/pipermail/zope-tests/2012-March/059300.html >> >> [2] FAILED winbot / ztk_dev py_265_win64 >> https://mail.zope.org/pipermail/zope-tests/2012-March/059301.html >> >> [3] FAILED winbot / ztk_dev py_270_win32 >> https://mail.zope.org/pipermail/zope-tests/2012-March/059302.html >> >> [4] FAILED winbot / ztk_dev py_270_win64 >> https://mail.zope.org/pipermail/zope-tests/2012-March/059303.html > > All fail with:: > > While: > Installing test-zopeapp. > Getting distribution for 'ZODB3>=3.10'. > Error: Picked: zodb3 = 3.10.5 > > Ideas? I think I fixed that in zope.app.publication now. Note that these are dev builds, so they use all packages from SVN. z.a.publication added a new requirement for ZODB3>=3.10. But ZODB on its 3.10 branch notes its version as 3.10dev. As 3.10dev < 3.10 the check failed. Relaxing the check to "ZODB3>=3.10dev" should fix this. Alternatively "ZODB3>3.10.999" would have worked as well. 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] Bad ZODB 3.10.5 egg on PyPI, cleanup needed
On Mon, Mar 12, 2012 at 10:55 PM, Marius Gedminas wrote: > http://pypi.python.org/pypi/ZODB3/3.10.5 contains various proper win32 > eggs in addition to that .win32.zip. The PyPI page for 3.10.4 did not > have any weird .win32.zip files. > > Can someone please remove that "dumb" binary file which is "built for > Windows XP" (and doesn't even mention for which Python version)? J1m apparently took care of that: add 2.7 file ZODB3-3.10.5.win32.zip 2012-03-12 20:22J1m 12.x.x.x remove file ZODB3-3.10.5.win32.zip 2012-03-12 22:06J1m 12.x.x.x 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] zc.async versus Zope 2 SIGTERM
On Thu, Mar 1, 2012 at 1:42 PM, Vincent Fretin wrote: > Did you look how http://pypi.python.org/pypi/plone.app.async have done the > integration with Zope2? IIRC we (Jarn) ran into the same problem when running p.a.async. Our "solution" was to switch to using SIGINT for process shutdown. We used supervisor, so for each Zope process section we added stopsignal=INT But on unexpected process or server restarts, we still had stuck workers once in a while. We never had the time to investigate, so just handled those manually. 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-tests - OK: 23
On Thu, Mar 1, 2012 at 1:36 PM, Tres Seaver wrote: > Hmm, has the winbot fallen over? Yep. Looks like the build slave hung up on Feb 28. Nothing interesting in the logs, so I just restarted the master and slave. One build finished successfully again, so this should work. There might be a false report about "ztk_11 py_265_win64" failing in the next report. 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 Toolkit - 1.0.6 and 1.1.4 released
On Tue, Feb 14, 2012 at 2:23 PM, Sebastien Douche wrote: > Cool! Any news for for the trunk? Any chance to see a ZTK 2.0? I'm not involved in ZTK discussions beyond 1.1 or Zope 2 discussions beyond 2.13. But even as a bystander I haven't seen anyone talk about such a release or anyone requesting it. 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 Toolkit - 1.0.6 and 1.1.4 released
On Mon, Feb 13, 2012 at 2:12 PM, Joshua Immanuel wrote: > Wonderful!!. It would be very helpful if there is a changelog associated > with it. So, that we can know the important changes that have taken > place in associated packages. Sure, that would be helpful. Unfortunately nobody has volunteered to write a script to produce such a changelog. You can download and diff the files at http://download.zope.org/zopetoolkit/index/ yourself. But in general there's no important changes in the ZTK maintenance releases, unless you've been tracking a specific issue relevant to one of your applications. 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 )
[Zope-dev] Zope Toolkit - 1.0.6 and 1.1.4 released
Hi. On behalf of the Zope Toolkit release team and the Zope community, I'm happy to announce the release of the Zope Toolkit 1.0.6 and 1.1.4. Both releases are minor bugfix releases. To use the new releases, you can use: [buildout] extends = http://download.zope.org/zopetoolkit/index/1.0.6/ztk-versions.cfg http://download.zope.org/zopetoolkit/index/1.0.6/zopeapp-versions.cfg or: [buildout] extends = http://download.zope.org/zopetoolkit/index/1.1.4/ztk-versions.cfg http://download.zope.org/zopetoolkit/index/1.1.4/zopeapp-versions.cfg Kind regards, 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-tests - FAILED: 26, OK: 39, UNKNOWN: 2
On Wed, Feb 8, 2012 at 10:07 AM, Gediminas Paulauskas wrote: > The majority of failures are in zope.testrunner, due to recent update > of versions. The offending one is testtools 0.9.13. With testtools > 0.9.12 the tests pass. Thanks for looking at those. I hopefully fixed the Zope 4 failures - related to not being allowed to download elementtree from effbot.org. I also likely fixed the winbot problems, which were due to missing binary eggs. Specifically zope.index 3.6.3 had no tag in Subversion, so the wineggbuilder couldn't create binary eggs for this release. I'm installing security updates on the winbot and will restart it in a few moments. Let's see what this night results will bring us. 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 )
[Zope-dev] [zope2] 2.12.x formal end-of-life
Hi. I just updated the 2.12.x branch with one last batch of bugfix versions. I'll let the buildbots run and if there's no troubles release one more version later this week. I consider this to be the last maintenance release for the 2.12.x series. From now on 2.12.x will only see security updates. I've also put an end-date to the security support (http://zope2.zope.org/releases), stating October 2013 as the end date. This happens to be the end of security support for Python 2.6 - the only Python version supported by the 2.12.x series. This is rather long in the future, one and a half years from now. I think that sets reasonable expectations and gives us a clear end date. It's not meant to prohibit anyone from doing security releases after this date - just set clear expectations to others, like Linux distributors shipping Zope 2 and relieve me of my formal duty ;-) The 2.13 series is going to be supported longer. How long depends on Python 2.7's support and how Zope 4 is going to progress. At this point there's no formal end-of-life date. If you have concerns, please speak up. Zope 2.x release managerly yours ;-) 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 )
[Zope-dev] ZTK maintenance releases coming up
Hi. I just updated the ZTK 1.0 and 1.1 branches to all latest bugfix versions. I'll give the buildbots until Wednesday to build and find any real problems. If there's no problems, I'll cut new ZTK 1.0.x and 1.1.x releases later this week. If you have any other bugfixes you want to get into those, now's the time ;-) 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 4 release management
On Mon, Feb 6, 2012 at 4:41 PM, Martijn Faassen wrote: >>> I would actually argue that "Zope4" have no real release cycle at all: >>> instead, the individual pieces which make up Zope should have their own >>> cycles, with perhaps a ZTK-like tracking set that Plone and others use as >>> platform targets. not sure whom I'm quoting here, but: Zope 2 is special in that it still has one big library named Zope2 at its center. It's not just a collection of libraries. And a lot of the bigger changes being proposed need coordinated changes to multiple libraries. Like the __parent__ work or likely any non-trivial change to publication. You can likely evolve DateTime, Record, Missing or DocumentTermplate on their own - but that's not terribly exciting. > I agree; actually "ZTK-like tracking set" is really already talking about > doing releases, just like the ZTK has releases. And just like ZTK releases > do, this needs some release management effort. > > Now I would advocate that Zope 4 releases mimic the ZTK in the way things > are managed. Just to clarify: Do you mean in terms of its release team? So instead of having one release manager constituting a team? A team representing the different consumer groups of Zope? Something like Plone, pure-CMF, non-CMF? In terms of its scope Zope 4 is meant to be a feature release, which needs coordination and decisions on what to include. That makes it a bit different from the ZTK, where the release team explicitly stays out of setting development direction and avoids influencing what happens in each library. So I'm not sure the ZTK release team model is directly applicable to Zope 4. The ZTK works fairly well for a mostly stable set of libraries, where not much happens and at most quarterly bug fix releases are needed. 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] Undo product stops working with recent Zope (StorageTransactionError)
On Tue, Jan 24, 2012 at 2:14 PM, wrote: > It used to work, but with the most recent versions of > Zope this error appears if the Undo by date is used > more than once: The undo API has changed with ZODB 3.10. As noted in the changelog: "The API for undoing multiple transactions has changed. To undo multiple transactions in a single transaction, pass a list of transaction identifiers to a database's undoMultiple method. Calling a database's undo method multiple times in the same transaction now raises an exception." Your code calls undo multiple times, and needs to be changed accordingly. 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-tests - FAILED: 3, OK: 60
On Thu, Dec 8, 2011 at 8:34 AM, Michael Howitz wrote: >> [3] FAILED winbot / ZODB_dev py_254_win32 >> https://mail.zope.org/pipermail/zope-tests/2011-December/053803.html > > Same errors like yesterday due to incompatibles with Python 2.4 reps. 2.5. I think I managed to remove that combination from the winbot. It's restarting now after getting some security updates. 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 )
[Zope-dev] Zope Toolkit - 1.0.5 and 1.1.3 released
Hi. On behalf of the Zope Toolkit release team and the Zope community, I'm happy to announce the release of the Zope Toolkit 1.0.5 and 1.1.3. Both releases are minor bugfix releases. A schedule for a ZTK 1.2 release is unknown at this point. To use the new release, you can use: [buildout] extends = http://download.zope.org/zopetoolkit/index/1.0.5/ztk-versions.cfg http://download.zope.org/zopetoolkit/index/1.0.5/zopeapp-versions.cfg or: [buildout] extends = http://download.zope.org/zopetoolkit/index/1.1.3/ztk-versions.cfg http://download.zope.org/zopetoolkit/index/1.1.3/zopeapp-versions.cfg Kind regards, 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] New ZTK-Release?
On Mon, Nov 7, 2011 at 9:01 AM, Michael Howitz wrote: > after having the buildbots green again, I think it would be a good point in > time for a series new ZTK releases: > > * 1.0.5 (yes, there are even on the 1.0 branch version updates), > * 1.1.3, > * 1.2c1 (a new release branch from the trunk) > > Who is in charge for the ZTK releases? > Is there still the ZTK team? The ZTK release team is still officially in place. I can take care of the ZTK 1.0 and 1.1 bugfix releases. I won't be involved in ZTK 1.2 decisions myself, the same way I won't take care of Zope2 4.0. So I'm not sure what the process for that will be. 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 )
[Zope-dev] Zope 4 - San Francisco sprint and beyond
Hi. A couple of us came together before the Plone conference to work on various Zope related topics. We worked on the following areas: - storing parent pointers (elro, davisagli): we have a branch of Zope that changes OFS to store parent pointers and fixed the issues that arose in copy/cut/paste and zexp export code. There's an issue remaining with Acquisition, where we lost some protection against cycle protection - I continue working on this. - catalog using intids (rossp): we have branches of Zope, ZCatalog and CMF which change the catalog to use intids as their internal uid and rid. This needs more testing, but looks very promising. Currently it uses plone.app.intid / five.intid to maintain an intid to physical path mapping. Once the parent pointer work is stable, we can stop doing this and load objects directly from the database connection - Chameleon (chaoflow): Florian worked on making Zope use Chameleon by default. This works for the most parts, but there's some problems left in tests, as Chameleon wants an utility to be registered but a lot of tests in Zope and CMF don't use ZCML test layers. - Traversal simplification: Mikko worked on researching traversal and options to simplify it. The first idea was to unify some of the code used for URL, path and path expression traversal to bring those more in line. Not sure how far he got ;) - WebOb (garbas): Rok worked on bringing in WebOb as an underpinning for the request/response objects and making both API's available at the same time. I think the request is done and a good deal of the response works. Doing this means we can deprecate parts of the old request API and encourage the use of the more standard WebOb API. - WSGI (matthewwilkes, hannosch): We fixed the bugs that had been reported about using the current WSGI support (mod_wsgi problems, forced dependency on repoze.who) on trunk and the 2.13 branch. Afterwards Matthew continued on a branch to remove the ZServer/medusa from Zope and leave only the WSGI publisher in place. We had a bunch of other ideas on what to do, like allowing Unicode ids in OFS, working on security and similar large topics. I hope I haven't forgotten anyone. Most of the code currently lives in branches or forks on https://github.com/zopefoundation. We haven't figured out yet how to proceed with that. In terms of copyright all committers to the GitHub repository have signed Zope contributor agreements already, so there's no imminent legal problem. Which of these branches should make it into Zope and for which release is completely open and is going to be up for discussion. On a personal note, I won't be available as the release manager for the next Zope 4 release - as originally outlined in my mail from 2010 (https://mail.zope.org/pipermail/zope-dev/2010-March/039880.html). I'll continue to take care of the maintenance releases for the 2.12 and 2.13 series. At least unless someone else shows an interest in picking up this work. Should there be anyone interested in this position, speak up on this mailing list. Once someone has been found, I'll make sure the person gets documentation and access to all relevant resources. 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-tests - FAILED: 12, OK: 39
On Thu, Oct 27, 2011 at 6:44 PM, Tres Seaver wrote: >> [12] FAILED winbot / z3c.form_py_265_32 >> https://mail.zope.org/pipermail/zope-tests/2011-October/051752.html > > Same failure as yesterday: perhaps it ran before Hanno's pinning fix. Yep. There's two green builds for this one now: http://winbot.zope.org/builders/z3c.form_py_265_32 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 4?
On Thu, Oct 27, 2011 at 6:26 PM, David Glick wrote: > On 10/27/11 9:05 AM, Jim Fulton wrote: >> Is there a more formal announcement anywhere? Is there a description >> of what it is envisioned to be? >> > That came out of this thread on zope-dev back in July: > https://mail.zope.org/pipermail/zope-dev/2011-July/043158.html There's no "more" public announcement, as it's all just work in progress. I made up a bad list of bullet points at: http://docs.zope.org/zope2/releases/4.0/WHATSNEW.html But the gist is: There's no point in doing a Zope 2.14 release with incremental improvements, as there's nothing such a release could contain. So it makes sense to do a less backwards compatible release and bump the major version number. People rightfully complained that doing a Zope2 3.0 release is a bit insane. So the next number up for grasp is Zope2 4.0 - at which point it can be called "Zope 4.0" again. 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-tests - FAILED: 7, OK: 41
On Wed, Oct 26, 2011 at 3:57 AM, Tres Seaver wrote: >> [6] FAILED winbot / z3c.form_py_265_32 >> https://mail.zope.org/pipermail/zope-tests/2011-October/051704.html > > I'm ignoring this one, except to note that it is *not* lxml related. This was a version conflict for some Chameleon libraries, as a result of half-pinning. I pinned all Chameleon versions and the build worked locally for me. Maybe it'll work soon on the winbot. >> [7] FAILED winbot / ztk_dev py_254_win32 >> https://mail.zope.org/pipermail/zope-tests/2011-October/051719.html > > This build should be disabled: the ZTK trunk is no longer compatible > with Python 2.5. I removed it. 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-tests - FAILED: 21, OK: 31
On Mon, Oct 24, 2011 at 5:08 PM, Tres Seaver wrote: > I also prefer that we drop 2.5 compatibility on the ZTK trunk. The > 2.5.6 release page says[1]: > > This release is most likely the final release of Python 2.5; under > the current release policy, no security issues in Python 2.5 will be > fixed after October, 2011. > > [1] http://www.python.org/download/releases/2.5.6/ Fine by me. We have ZTK 1.1 which can keep Python 2.5 support. For Zope 2, we have dropped Python 2.5 long ago and only do Python 2.6 and 2.7 these days. 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-tests - FAILED: 21, OK: 37
On Sat, Oct 22, 2011 at 9:41 PM, Tres Seaver wrote: > #10 - 20 omitted: perma-failing z3c.* tests esse delendam! I disabled the z3c.* tests on the winbot now. If someone has time to reconfigure it, so those are only run but don't sent out mail notifications - please go ahead. I did leave the actually used z3c.form enabled, but pinned the lxml dependency to version 2.3 - instead of taking "latest". 2.3 has binary eggs for most platforms including Windows, so the build has a chance to succeed. 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] [collective.recipe.solrinstance] Example not working
On Mon, Oct 17, 2011 at 8:05 PM, Laurence Rowe wrote: >> Should we migrate the recipe to github and get a free issue tracker? Ok. I've started the SVN to Git migration. Repo will be at https://github.com/hannosch/collective.recipe.solrinstance and anyone who has recently committed should have contributor rights to the new repo. Andreas: Please add an issue at https://github.com/hannosch/collective.recipe.solrinstance/issues ;) 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] [collective.recipe.solrinstance] Example not working
On Mon, Oct 17, 2011 at 11:19 AM, Andreas Jung wrote: > I used the single-core example for the solrinstance recipe: I think someone reported the Solr core examples to be broken in the latest releases. I don't use the core-variants myself, though. Without an issue tracker, it's hard to keep track of those reports. Should we migrate the recipe to github and get a free issue tracker? 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] Question about RestrictedPython installation with python2.6
On Mon, Oct 10, 2011 at 11:12 AM, Ruslan Mahmatkhanov wrote: > And this is breaks packaging on FreeBSD, since there will be no > before_and_after27.py[c,o] and security_in_syntax27.py[c,o] that we > expecting. > I know that this files included conditionally, but easy_install still > tries to compile them all independent of python version. As result - we > see this ugly errors. Is there anything i can do with this? (some > easy_install option to not compile this files) or can i anyhow to not > build and install tests? Thanks in advance for answer. There's no options for easy_install that prevent these. You'll have to either use the underlying setuptools API's or write some post-cleanup script that does what you need here. Those error messages are annoying, but we'll likely won't get rid of them before we switch to the new "packaging" / "distutils" libraries some time in the future. 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 )
[Zope-dev] Security vulnerabiity CVE 2011-3587: Arbitrary Code Execution
The Zope security response team is announcing a fix for a vulnerability in Zope 2.12.x and Zope 2.13.x that allows execution of arbitrary code by anonymous users. The hotfix for this vulnerability was pre-announced last week. This is a severe vulnerability that allows an unauthenticated attacker to employ a carefully crafted web request to execute arbitrary commands with the privileges of the Zope service. Versions Affected: Zope 2.12.x and Zope 2.13.x. Versions Not Affected: Zope 2.11.x, Zope 2.10.x or prior You can either install the Hotfix as an egg release from http://pypi.python.org/pypi/Products.Zope_Hotfix_CVE_2011_3587 or as an old-style product release available from http://download.zope.org/Zope2/hotfixes/Zope_Hotfix_CVE_2011_3587-v10.tar.gz. Alternatively you can upgrade to the latest bugfix release of Zope. Versions 2.12.20 and 2.13.10 will be released today and include the fix for this vulnerability. Please refer to http://zope2.zope.org/news/security-vulnerability-announcement-cve-2011-3587 for more details. The Plone community has also released a security hotfix today covering an additional security issue. If you are using Plone, please refer to http://plone.org/products/plone/security/advisories/20110928. On behalf of the Zope security response team, Hanno Schlichting ___ 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] Who has access to wineggbuilder was Re: zope.interface 3.8 win eggs
On Sat, Sep 24, 2011 at 4:25 PM, Adam Groszer wrote: > Something is totally borked there. > http://winbot.zope.org/builders/wineggbuilder/builds/13939/steps/release%20eggs/logs/stdio I took a look and fixed the problem. It came down to a missing version pin for BeautifulSoup and a new backwards incompatible 4.0b version of it. The missing binary eggs are build and uploaded as we speak. Adam: I also installed all the latest Windows security updates and restarted the server once for that. 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] cache_detail crash
On Thu, Sep 22, 2011 at 10:21 AM, Ruslan Mahmatkhanov wrote: > Can anybody reproduce this? Yes, it's a known bug reported at https://bugs.launchpad.net/zope2/+bug/838978 Patches are very welcome for this. 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] access to create z.i and z.c releases
On Thu, Sep 22, 2011 at 9:03 AM, Chris McDonough wrote: > I've made tags for zope.interface 3.8.0 and zope.component 3.11.0, as > described in a recent thread to this list, but I don't have PyPI owner > rights to publish them. Can someone add me to the owners list for those > packages (my pypi user name is "chrism")? Added, release away! 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] Passing variable across pages
On Wed, Sep 21, 2011 at 12:45 PM, Babylakshmi Muthusamy wrote: > Please suggest me a solution for this. Please post your question to the users mailing list at https://mail.zope.org/mailman/listinfo/zope This mailing list is for the development of Zope, not development with Zope. Thanks, 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] ohloh listings
Hi. On Sat, Sep 10, 2011 at 11:32 PM, Chris McDonough wrote: > Could you delete and readd the failed repository enlistments at > https://www.ohloh.net/p/zope/enlistments?page=13 Tried that - had no effect as it indeed recognized the old urls. So I removed them and added them instead via the http:// protocol. They are now on the first page at https://www.ohloh.net/p/zope/enlistments and currently not scheduled yet. Chris, if you want I can add you as a manager, I think you need to request that at https://www.ohloh.net/p/zope/manages/new 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.deprecation
On Mon, Sep 5, 2011 at 1:09 AM, Chris McDonough wrote: > I've given Python 3 support to zope.deprecation at > http://svn.zope.org/zope.deprecation/branches/chrism-unittesting/ > > - Which Python versions is this thing meant to support? I have it > functioning under 2.5, 2.6, 2.7 (and 3.2). Do we need it > to support 2.4? We no longer need Python 2.4 compatibility for new stuff (only for bugfixes to ZTK 1.0). > - I presume the version number after merge should be bumped to > 3.5 (it was branched from 3.42dev)? Yes, we treat Python 3 compatibility as a new feature. So this will only go into ZTK trunk. 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] RFC: proposal to split zope.configuration into ZCML and non-ZCML related packages
On Wed, Aug 31, 2011 at 9:17 AM, Wolfgang Schnerring wrote: > Splitting zope.configuration into core mechanics and ZCML support > makes a lot of sense to me. > > So, +1 from me. +1 here too 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-tests - FAILED: 10, OK: 28, UNKNOWN: 3
On Fri, Aug 19, 2011 at 7:14 PM, Tres Seaver wrote: >> [1] UNKNOWN FAILED (errors=1) : Zope-2.13-alltests Python-2.6.6 : >> Linux >> https://mail.zope.org/pipermail/zope-tests/2011-August/048315.html > > I think this failure is due to recent acquisition grubbing:: > > Error in test test_getObject_found > (Products.ZCatalog.tests.test_zcatalog.TestZCatalogGetObject) This was caused by changes to OFS.Traversable - I reverted those and the tests pass again. 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] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
On Wed, Aug 17, 2011 at 8:12 AM, Adam GROSZER wrote: > On Tue, 16 Aug 2011 22:50:42 -0400 you wrote: >> >> - - Merge the 'jbohman-zope.registry' branch of zope.component to the >> trunk, and bump its minor version accordingly. Great work, +1 on merging (I trust the GSoC mentor did a good code review... ;) > That sounds to me to rather have a *major* version number bump. If backwards compatible imports are left in place, I don't mind it being a 3.11.0 - but it might just as well be time to call it 4.0 :) 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] Segfault in Acquisition in Zope 2
On Mon, Aug 15, 2011 at 12:27 PM, Sylvain Viollon wrote: > I have this problem with: > > - Python 2.6 and Zope 2.12 > > - Python 2.7 and Zope 2.13 > > (All the latest ones). > > This have been observed on 64 bits computers (Mac OS X, FreeBSD and Linux). > I don't know about 32 bits > installations. > > Do you have any clues for me ? Just to make sure, you used Acquisition 2.13.8 ? That one solves one particular segfault on 64bit systems. 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] Pluggable template engine
On Sat, Aug 13, 2011 at 11:33 AM, Malthe Borch wrote: > I will merge this branch if there are no objections. No objections - only thanks and cheers :) 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.interface versions, ZTK 1.0 and later
On Sat, Aug 13, 2011 at 3:55 AM, Stephan Richter wrote: > On Friday, August 12, 2011, Tres Seaver wrote: >> Thoughts? > > +1. Sounds like a good plan. +2 :) 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] Pluggable template engine
On Wed, Jul 20, 2011 at 5:24 PM, Malthe Borch wrote: > I'd like to propose merging this into trunk. +1 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] wineggbuilder?
On Wed, Jul 20, 2011 at 3:36 PM, Chris McDonough wrote: > I'm pondering making a release of zope.i18nmessageid to PyPI. It has C > extensions. If I upload the release, does the wineggbuilder still come > along and push windows binary eggs up eventually? Yes. Just do the release, everything else follows automatically. And if it doesn't poke me or Adam. 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] congrats on the new zope.org launch, but..
On Fri, Jul 15, 2011 at 1:50 PM, Martijn Faassen wrote: > I'd just call the category "web framework"; 2 out of 3 already say they > are. Zope can then itself say in its description that it's an > application server if that's an important term. At least zope2.zope.org uses the "web framework" term to describe Zope 2 as well. "application server" doesn't describe todays Zope 2 codebase and aim anymore either. So I'd rather place all of the "big guys" in the "web framework" box. 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] SVN: Zope/trunk/ Optimized the `OFS.Traversable.getPhysicalPath` method to avoid excessive amounts of method calls. Thx to Nikolay Kim from Enfold
On Thu, Jul 14, 2011 at 7:03 PM, Tres Seaver wrote: > A further micro-optimization is to pre-allocate a big list in a thread > local. Running the attached script produces:: > > $ python perftest.py > Via insert_0: 24.8401839733 > Via append: 15.6596238613 > speedup: 37.0% > Via tuple_add: 21.9555268288 > speedup: 11.6% > Via prealloc: 10.5278339386 > speedup: 57.6% Thanks for that test! I've run it with a much more reasonable test data set from one of our live databases, for example: letters = ['', 'nordic', 'en', 'nordic-council', 'organisation-and-structure', 'committees', 'welfare-committee', 'meetings-and-meeting-documents', 'meeting-of-the-welfare-committee-31-march-2011-stockholm'] which produces quite a different result: Via insert_0: 4.35216093063 Via append: 4.80827713013 speedup: -10.5% Via tuple_add: 1.73557782173 speedup: 60.1% Via prealloc: 2.17882084846 speedup: 49.9% If I run it with a smaller segment, like: letters = ['', 'nordic', 'en', 'nordic-council'] the effect is even clearer: Via insert_0: 1.88715004921 Via append: 2.91810202599 speedup: -54.6% Via tuple_add: 0.809303998947 speedup: 57.1% Via prealloc: 1.56584882736 speedup: 17.0% Looks like the tuple add is faster until you hit very long sequences. But even if you had such a nested ZODB structure, the majority of lookups would still happen for the much shorter sequences. So I think the tuple add is the winner for this case. 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] z3c.form missing *.mo files?
On Tue, Jul 12, 2011 at 3:07 PM, Michael Howitz wrote: > To get the .mo files compiled at runtime you need the following variables in > os.environ: > > os.environ['zope_i18n_compile_mo_files'] = 'True' > os.environ['zope_i18n_allowed_languages'] = 'de,en' > > (You might replace 'de,en' with the languages you need :) > > Additionally you need to depend on the package 'python-gettext' which > contains the compiler. > > Sadly this is only documented in the source code of zope.i18n.compile and and > zope.i18n.config. The above is one approach I ported to zope.i18n from Plone's PlacelessTranslationService. I think it's only documented in Plone-level documentation. You can also integrate the compilation into your build process and use the gettext tools to do this: msgfmt --no-hash -o folder/locales/en/LC_MESSAGES/domain.mo folder/locales/en/LC_MESSAGES/domain.po The --no-hash isn't required, but makes the files a bit smaller by removing some data structures not used by Python's gettext implementation. It also makes sure the files are identical to those compiled with python-gettext. 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] www.zope.org relaunched
On Thu, Jul 7, 2011 at 3:39 PM, Sylvain Viollon wrote: > On Thu, 07 Jul 2011 13:58:27 +0200 > Andreas Jung wrote: >> on behalf of the Zope Foundation I please to announce >> the relaunch of the new www.zope.org web site. >> >> http://www.zope.org > > Great ! +10 :) 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] direction
Hi. On Tue, Jul 5, 2011 at 9:21 PM, Leonardo Rochael Almeida wrote: > I guess this is the biggest point of contention. Why does the ZMI have > to go? Although both Plone and ERP5 strive to gradually replace ZMI > based configuration with "native" interfaces (native to Plone/ERP5), > isn't there value in having a minimal OFS browser with the ability to > Add/Delete/Copy/Cut/Paste objects as a fallback? It doesn't seem to > conflict with your stated goal: I think having a minimal database browser is a good idea. I think something like https://github.com/davisagli/eye is the right starting point here. I don't want to have anything that lives in the same process as the rest of the application code. The ZMI is currently like running phpMyAdmin accessible to the world with the same credentials and on the same domain as the rest of your application. It's a huge security risk and pollutes model classes and views in the application code. > Or to put it differently, in which way does having a minimalistic OFS > browser for a ZMI conflicts or hinders Plone's objectives for the > Zope2 code base? The ZMI is a highly insecure, completely outdated and user-unfriendly interface. On the security level, there's no validation of user-input, there's no XSS and CSRF protection. Anyone being logged into your application who has ZMI access is susceptible to a large number of attacks. There's too much of stone-age code based on no-patterns to prevent these attacks - we can currently only fix them in a tedious process of finding one exploit after the other. We need a better strategy here - and the only one I can see is removing the existing ZMI code and moving any low-level interface to a completely separate codebase and process. On the other points, at least Plone tries to use modern web technologies and for example we just switched to a HTML5 doctype - having any end-user go to the ZMI and look at a frames-based interface undermines any marketing message we try to put out about being modern. And then the ZMI doesn't even do basic things like asking you for confirmation before removing your entire site and being in almost all regards a huge usability fail - again completely add odds with Plone's good end-user usability story. On the code level the ZMI-support code is mixed into all other model code and has often lead to arcane developer API's. There's far too many places where a manage_* method with a request argument is the only way to achieve anything. For whatever code we'll end up with in two to three years, I want to see good developer API's that actually make you productive. I hope this clarifies a bit more, why I feel the ZMI is an arcane beast that needs to be hunted down sooner than later. 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] direction
On Tue, Jul 5, 2011 at 2:44 PM, Jens Vagelpohl wrote: > "zopefour" as a domain isn't very helpful. It would add yet another > "top-level" name to the existing list (Zope 2, Zope 3). That was an April fools joke I was referring to. I didn't mean to suggest to actually use that in any way ;-) 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] direction
On Tue, Jul 5, 2011 at 12:10 PM, Jens Vagelpohl wrote: > On 7/5/11 11:56 , Martin Aspeli wrote: >> On 5 July 2011 10:31, Hanno Schlichting wrote: >> I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the >> defunct Zope 3, although I don't think there are any particularly good >> options here. > > I actually think it's a brilliant idea to "skip" 3.0 and call it 4.0. Ok, seems 4.0 is the more popular choice. We'll use that than and make Tres proud (http://www.palladion.com/home/tseaver/obzervationz/2009/zope-4.0-project - though zopefour.org has been taken over by a link farm). 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] direction
On Tue, Jul 5, 2011 at 11:56 AM, Martin Aspeli wrote: > On 5 July 2011 10:31, Hanno Schlichting wrote: >> So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or >> 5.0 or anything else doesn't make it any better at all. So 3.0 is the >> most sensible one :) > > Boy, that's going to be confusing. :) > I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the > defunct Zope 3, although I don't think there are any particularly good > options here. Zope2 4.0 would imply some sort of upgrade path from Zope 3 to this. That's as confusing as anything else and would lead to the question what happened to Zope2 3.0. Since we don't market Zope2 anymore, I think there's actually much less confusion from this than we'd fear. It's just an internal version number used in some buildout files, not something that has any particular meaning. 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] direction
On Mon, Jul 4, 2011 at 12:19 PM, yuppie wrote: > Long-term maintenance for Zope 2.13 would give these > projects/deployments at least a few more years. Yes. I'm willing to cut releases for it for quite a while. I just expect to see active maintenance from the Plone community to stop in a year or two. Judging from the ongoing maintenance we currently have for Zope 2.10 or 2.11 I don't think it's very realistic to expect much to happen once the Plone guys stop. >> What I'm outlining here has of course almost nothing to do with the >> original idea and scope of Zope 2. Maybe at some point this should get >> a different name ;-) > > I don't want to discuss names, but I think the next release from Zope > trunk should be explicitly a new *major* release. I think that's perfectly fine. Since I broke backwards compatibility with a number of changes I did, a major version increase is warranted. So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or 5.0 or anything else doesn't make it any better at all. So 3.0 is the most sensible one :) 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] direction
On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli wrote: > I would've thought it would also be possible for those who rely on this to > maintain the relevant eggs as optional installations against Zope 2.x, no? The ZMI is not a package - we don't have a split into zope and zope.app in Zope2. Once there's no more ZMI, Products.PageTemplates stops using RestrictedPython and the OFS base classes don't inherit from Acquisition.Implicit anymore, it'll be really hard to keep the legacy development approach working. Someone might try, but I think it's not a wise decision to spent any resources that way. At some point every application written in the legacy style has to be rewritten. I think it would be a better use of resources for anyone to start doing that than maintaining a dead-end. 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] direction
On Mon, Jul 4, 2011 at 2:04 PM, Leonardo Rochael Almeida wrote: > As for the rest, most of the things that have been removed from core > were done in such a way that they can still be used with Zope2, so > ERP5 can happily keep using them. If things can keep evolving with > this care we should be ok. I tried to be careful to make things optional in the past. But we have reached the end of where that is possible in many ways. Yes, we can still make the session/browser id machinery optional, as these are in separate packages and the application setup code no longer depends on them. But almost everything else is all tightly integrated and part of the App, OFS and Zope2 packages. There's some code we can move out of these, like App.Extensions can go into ExternalMethods and ZSQLMethods - but there's not much else left that's actually independent. >> - Once most of the ZMI is gone, it should be feasible to drop DTML or >> rewrite what little is left as page templates > > If DTML is still available as an optional product/package, this should > not be a problem for us, but we'll likely depend on ZSQLMethods > (hence, on DTML) for a long time, since our ZSQLCatalog functionality > is built heavily around it. DTML is a standalone distribution, so I don't see any problem with it being used independently. I think we can move the App.special_dtml.DTMLFile class over to the DocumentTemplate distribution to make that easier. > This one is rather easy to fix, we just need to move the object from > the Control_Panel into the Application Root, so I mention this for > future reference, in case others have this problem. Indeed. The control panel basically is a view these days. I think there might be one or two "profilers" out there which add entries there as well. All of these should be easy to change and move to the application root. I've been especially annoyed by the profilers, which all left broken objects in the control panel, without any UI to remove them. > But, for example, you committed some changes (and todos) relating to > removing icons. Out of curiosity What is the reasoning behind this? Icons don't add any functionality as such, so there were rather easy to remove, following my premise that all of the ZMI should go sooner than later. There's no really good technical reason to remove them - if the ZMI should go we just have to start somewhere. 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] direction
On Mon, Jul 4, 2011 at 10:49 AM, Sylvain Viollon wrote: > ... and I still do use the VirtualHostMonster > (you can trash all the other things). > > I agree that its code might not been the best in the world, but it > works for the moment and does what it says (I would love to see > shiftNameToApplication implemented with more than one pass). Ok. I didn't mean to remove the VHM at any point. I removed it from the default content over the weekend but given its popularity, I think I can safely put it back. 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] direction
On Tue, Jul 5, 2011 at 10:19 AM, Tobias Helfrich wrote: > OK, so you do think that we might use Zope 2.12 for a quite long time > without thinking about anymore updates? Will there be any security > updates for Zope 2.12 in the future? You want to use Zope 2.13. 2.12 is at the end of its active maintenance cycle as is Python 2.6 (the only Python version it supports). Zope 2.13 brings support for Python 2.7, which is a long-term maintenance release. How long Zope 2.13 is going to be supported and sees security fixes will depend on the community. The Plone community will use it for its 4.1 and 4.2 releases, as a result of our security policy that should result in us supporting Zope 2.13 for the next two years. Beyond that nobody knows what will happen. > Now i am completely shocked. We are building web applications for > the last 6 years in Zope 2.x. All those applications are using the > following techniques: [snip] What you are describing is exactly what I meant by old legacy Zope2 applications. You should be able to use this style of development with Zope 2.13. But you won't be able to upgrade to newer versions of Zope 2 anymore and expect your code to work unmodified. We discouraged this style of development for the past six years. It should come as no surprise that it will come to an end at some point. 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] direction
On Sun, Jul 3, 2011 at 7:09 AM, Chris McDonough wrote: > Zope still needs to the virtual host monster (or something like it) even > with the WSGI publisher; there's nothing equivalent in the WSGI world > (unless you could repoze.vhm, which is essentially just the virtual host > monster, and probably doesn't need to live in middleware; no one uses it > except people who use repoze.zope2). I'm expecting us to use repoze.vhm. But I've left the VHM in the code, so it's easy to install one if you still need it. For some time I expect Plone to install a VHM as part of its installation process. > I don't have any skin in this game, but FTR, Mike Bayer isn't feeling > all that confident about Beaker's sessioning component (or so he has > told me). Beaker was originally made as a caching component, and had > sessioning jammed into it quite late; nobody is really maintaining the > sessioning component of it now. Well, if I can choose between modern unmaintained code from Mike Bayer and stone-age unmaintained code from Zope, it's still an easy choice ;-) And looking at the basics of what Beaker does here, it's still much more useful and of better quality than what we have in Zope 2. If there's any other non-framework-specific session machinery out there, we could use that as well. But I think most other stuff is tied into Django. 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] direction
On Sun, Jul 3, 2011 at 1:03 AM, Leonardo Rochael Almeida wrote: > I noticed you've been very busy doing clean-up on the Zope2 code base > in the last few hours. As someone who has recently spent a lot of time > porting forward a large and mission-critical code base, ERP5, from > Zope 2.8 to Zope 2.12, I'm a little confused about the direction that > you're moving, and how much effort that could mean for future porting > efforts for Nexedi. I think moving to Zope 2.12 and 2.13 does have some value for Nexedi or other large existing codebases, as you get support for current versions of the ZODB, Zope Toolkit packages and support for Python 2.7 with Zope 2.13. Since Python 2.7 is a long-term maintenance release for Python itself, this should provide a stable and good basis for the next years - the statements from the Python community aren't completely clear - but I'd expect to see ongoing maintenance until 2013 or maybe even 2015. Going forward I can see two paths for Zope 2. Either we don't touch it at all anymore and let it bitrot or we try to move it forward and adept it to current best practices of development. Since complete rewrites almost always fail, like we have seen with Zope 3 - I prefer changing Zope 2. If you are interested in stability I think sticking with an "older" version of Zope 2 is a completely sane and good approach. What me and others from the Plone community are trying to do with the Zope 2 codebase is to actually move it forward. We can either do that as part of the official Zope 2 release series or fork the codebase. Since so far there isn't really anyone else interested in working on the Zope 2 codebase, we keep changing Zope 2 without forking it. > But can you explain to us a little of how you expect Zope2 to behave > with the changes you're doing? There's a number of things I want to do. Not sure when I'll or others will have the time, but these are things I expect to happen in the next months or releases: - Continue to remove functionality tailored for TTW development, like SiteRoot, AccessRules, HelpSys and step-by-step most of the ZMI - Document and use the WSGI publisher and remove obsoleted functionality like the virtual host monster, error_log, ZServer/medusa, zopectl/zdaemon - Make the browser id manager, session data manager, temporary storage optional and remove it and request.SESSION from the core, instead we can use something based on Products.BeakerSessionDataManager / collective.beaker if someone has a need for sessions - Start using and storing parent pointers and remove Acquisition.Implicit from the most common base classes (a branch for this already exists with almost all core tests passing) - Merge five.pt (Chameleon) into the core and use it instead of the zope.tal/zope.tales implementation (which means no more RestrictedPython for templates) - Once most of the ZMI is gone, it should be feasible to drop DTML or rewrite what little is left as page templates I think what's going to stay is AccessControl, OFS (a bit lighter), ZPublisher (WSGI), the ZODB, ZCatalog and all the wiring for a set of Zope Toolkit libraries like components, events, browser pages and so on. That's the kind of scope that should be possible to port to Python 3 and actually modernize enough to be understandable. At that point we should even be able to catch up with years of missed security updates - almost nothing in current Zope 2 protects against XSS, CSRF or any of the other common security risks we have on the web today. What I'm outlining here has of course almost nothing to do with the original idea and scope of Zope 2. Maybe at some point this should get a different name ;-) I hope this makes the direction of where I am headed clearer or more generally what Plone expects from its underlying framework. 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] versions on zope.org and launchpad.net
On Wed, Jun 29, 2011 at 10:56 AM, Jens Vagelpohl wrote: > On 6/29/11 10:34 , Hanno Schlichting wrote: >> That's a bit confusing. Either we remove the downloads from launchpad >> or we make sure it has all of the old ones. > > +1 for removing. I removed all of them from launchpad. 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 )
[Zope-dev] zc.async.queue.DispatcherAgents last_ping
Hi Gary, or any other zc.async developer, we use zc.async in one site and I noticed there's a hell of a lot of write transactions caused by it. Every 30 seconds there's a zope.minmax.Maximum() by the name of last_ping stored. It looks like this is coming from zc.async.queue.DispatcherAgents and the 30 seconds are a result of a class variable stating: "ping_interval = datetime.timedelta(seconds=30)" I tried to understand what this last_ping is used for and it seems to have to do with detection of dead workers. Is that indeed the only thing it's used for? If so can we change it in our setup to be 15 minutes instead without any big problems (other than potentially not having any active worker for 15 minutes)? Ideally I'd like to get avoid storing such information in the ZODB at all and would much prefer a volatile attribute, a thread local or something on the filesystem. But maybe I'm missing something here were this information needs to be shared across workers running on different machines. While the size of the transaction is only 140 bytes each, the overhead of new transactions is massive. Any insights appreciated, 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] versions on zope.org and launchpad.net
On Wed, Jun 29, 2011 at 8:51 AM, Wichert Akkerman wrote: > My question would be: why launchpad? Is anyone expecting launchpad to be > a canonical resource for Zope releases? As far as I know none of our > documentation refers to launchpad for downloads and launchpad has never > been used for anything other than it's bugtracker. We did upload all non-egg Zope2 releases to https://launchpad.net/zope2/+download but not the latest ones. That's a bit confusing. Either we remove the downloads from launchpad or we make sure it has all of the old ones. I don't care either way for this historical stuff. 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-tests - OK: 64, UNKNOWN: 1
On Tue, Jun 21, 2011 at 2:39 PM, Tres Seaver wrote: > Hmmm, many fewer reports than a normal weekday. :( I disabled the z3c and zc.buildout runs on the winbot, which had been failing for months now. Getting daily test failures hasn't convinced anyone to do anything about them, so there's no motivational factor here. At this point they only produced noise in the test summarizer and prevented us from getting a meaningful green light. That should account for some but not all of the fewer jobs. 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] Configurable Blob Permissions ZODB
On Fri, Jun 17, 2011 at 2:06 PM, Jim Fulton wrote: > On Fri, Jun 17, 2011 at 4:53 AM, Robert Niederreiter > wrote: >> Any doubts, suggestions, other ideas? > > -1 for a new configuration option. > > I would rather just have write permission *only* removed > from committed blob files. Read permissions should be controlled > by existing mechanisms such as umask. +1 on Jim's suggestion - much simpler :) 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] Sharing session between different zope servers
On Wed, Jun 15, 2011 at 7:26 PM, Baiju M wrote: > Is memcached a reliable storage for session data ? > > I would like to hear others experience with memcached > as a reliable storage for session data. It depends on what kind of reliability you need. Generally your sessions should be short-lived and memcached is fine for that. If you want to store really long-lasting session data, you can use any SQL database backend for Beaker via SQLAlchemy. 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] Sharing session between different zope servers
On Wed, Jun 15, 2011 at 6:50 PM, Subish K S wrote: > We have 10+ Zope (version 2.7) servers ( on different machines). Right now > each Zope server independently handles session management which means that if > a Zope server fails the users on that Zope server do not get redirected to a > functioning Zope server but get "stuck" on the failed Zope server. > Is there any way to manage the session of all the zopes servers in a common > place. If you have only a moderate number of sessions, you can store the session storage on the ZEO server. If you use buildout you'd do something like: [zeo] recipe = plone.recipe.zeoserver ... zeo-conf-additional = %import tempstorage name temp storage for sessioning [instance1] recipe = plone.recipe.zope2instance ... zodb-temporary-storage = mount-point /temp_folder server 10.0.0.1:8100 storage temp name zeo-temp-storage The config is the same if you just put these straight into zope.conf and zeo.conf. Zope 2's built-in session machinery should handle a couple dozen sessions at a time. Once you go beyond that look at Beaker (via collective.beaker) and memcached as a backend. This does apply to the currently supported Zope 2 versions (2.12 & 2.13). I have no idea what of this works in the ancient 2.7. 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-tests - FAILED: 9, OK: 72
On Wed, Jun 8, 2011 at 1:08 PM, Jan-Wijbrand Kolman wrote: > It seems the python-2.7 from the "deadsnakes" PPA that is installed on > this buildmachine behaves badly. I do not know why, and I do not really > feel like investigating it. I'll remove the python-2.7 PPA install from > this machine we'll start using the hand-build python-2.7 instead. The Python from PPA wasn't at fault here. It seems it just exhibits a rare configuration where sizeof(int) != sizeof(pointer). Please feel free to move back to the PPA build. I fixed the real issue in the code. 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-tests - FAILED: 9, OK: 72
On Sun, Jun 5, 2011 at 8:24 PM, Hanno Schlichting wrote: > $ bin/alltests -s Acquisition -t test_mixed_explicit_and_explicit > Running zope.testrunner.layer.UnitTests tests: > Set up zope.testrunner.layer.UnitTests in 0.000 seconds. > Segmentation fault > > I haven't yet tried to debug the problem itself. I took the time to investigate this. It came down to the same issue noted in https://bugs.launchpad.net/bugs/675064. Some code treated a C int as a pointer. Apparently on most platforms sizeof(int) == sizeof(pointer), but there's some where that's not the case. In this particular case it was a simple mistake of using the wrong variable: PyObject *expl=0; int explicit=1; UNLESS (PyArg_ParseTupleAndKeywords( args, kw, "O|i", acquire_args+1, &name, &filter, &extra, &explicit, &defalt, &containment )) return NULL; if (expl) explicit=PyObject_IsTrue(expl); The fix was to pass &expl instead of &explicit into PyArg_ParseTupleAndKeywords. Almost the same code existed in Wrapper_acquire_method and module_aq_acquire and only Wrapper_acquire_method got it wrong. I released a new Acquisition version and put it into Zope 2.x. Hopefully the buildbots will finally get green again. 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 )
[Zope-dev] Zope Toolkit - 1.0.3 and 1.1.2 released
Hi. On behalf of the Zope Toolkit release team and the Zope community, I'm happy to announce the release of the Zope Toolkit 1.0.3 and 1.1.2. Both releases are minor bugfix releases containing the fixes we did since April. To use the new release, you can use: [buildout] extends = http://download.zope.org/zopetoolkit/index/1.0.3/ztk-versions.cfg http://download.zope.org/zopetoolkit/index/1.0.3/zopeapp-versions.cfg or: [buildout] extends = http://download.zope.org/zopetoolkit/index/1.1.2/ztk-versions.cfg http://download.zope.org/zopetoolkit/index/1.1.2/zopeapp-versions.cfg Kind regards, Hanno Schlichting ___ 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 )
