net-zope/plone-2.0.3 version bump
http://plone.org/newsitems/plone-2-0-3
plone.org recommends using Zope-2.7.0 with Python-2.3.3 with Plone-2.0.3, but apparently Zope-2.6.4 with Python 2.2.3 is sufficient. Since dev-lang/python-2.3.3 is the stable package for Gentoo, and I seem to recall Zope-2.6.x having issues with Python 2.3.x, I think we should go with the Zope-2.7.0 recommendation. Unfortunately, Zope-2.7.x hasn't even hit the Portage tree yet (bug #41508). Based on the changelog (http://plone.org/downloads/changelog), it appears CMF-1.4.4 is required. The newest version in portage is net-zope/cmf-1.4.2. http://cmf.zope.org/download/CMF-1.4.4/cmf_1.4_released "This release consists primarily of bug fixes for version 1.4, released in April, 2003. All users of CMF versions should upgrade to version 1.4.4." The plone and cmf ebuild updates ought to be trivial, and even if the zope dependency was only >=net-zope/zope-2.6.4, we'd be okay. It's not clear to me what is holding up bug #41508.
Created attachment 33522 [details] plone-2.0.3.ebuild I worked on an ebuild for plone and some of it's dependencies. Most of them needed some editing from a previous version to get the version numbering right. Hopefully they will be useful.
Created attachment 33523 [details] archetypes-1.3.0_beta2.ebuild
Created attachment 33524 [details] cmf-1.4.4.ebuild
Created attachment 33525 [details] groupuserfolder-3.0_beta1.ebuild
Created attachment 33526 [details] ldapuserfolder-2.4_beta3.ebuild This is not actually a dependency, but it was something I needed anyway.
Created attachment 33527 [details] placelesstranslationservice-fork-1.0_rc7.ebuild
Created attachment 33528 [details] plonecollectorng-1.2_beta3.ebuild This also is not a dependency but a product I wanted to test out. Unfortunately, I never got it to work, although I am pretty sure the ebuild is correct. plonecollectorng is not yet in Portage, though it's precessor cmfcollectorng is (same author).
Created attachment 33529 [details] portaltransforms-1.0.4.ebuild
Comment on attachment 33525 [details] groupuserfolder-3.0_beta1.ebuild groupuserfolder-3.0 was released. The notes say: You can use GRUF3 with Plone 2.0 BUT user/group control panels won't work because of the API changes. http://ingeniweb.sourceforge.net/Products/GroupUserFolder/README-Plone.stx So for now it seems you must stick with GRUF2 with Plone.
Created attachment 34148 [details] portaltransforms/portaltransforms-1.0.4.ebuild It turns out that the 1.0.3 ebuild doesn't install some important files, or these files are new in 1.0.4. Without these, a lot of product installs just won't work.
Created attachment 34149 [details] externaleditor/externaleditor-0.7.2.ebuild
Created attachment 34150 [details] groupuserfolder/groupuserfolder-2.0.1.ebuild GRUF-3 won't fly with the current Plone without patches. The big Plone tarball includes 2.0.1.
Created attachment 34151 [details] cmfquickinstallertool/cmfquickinstallertool-1.5.0.ebuild
Created attachment 34152 [details] cmfquickinstallertool-1.5.0.ebuild
Created attachment 34153 [details] plonecollectorng/plonecollectorng-1.1.5.ebuild 1.2.0 is out, but requires archetypes-1.3.0_beta2. For now it's probably better to stick with 1.1.5. I actually got this one to work, once I debugged the portaltransforms build.
Created attachment 34155 [details] plone-2.0.3.ebuild Updated dependencies.
Comment on attachment 34151 [details] cmfquickinstallertool/cmfquickinstallertool-1.5.0.ebuild Duplicate
Comment on attachment 33523 [details] archetypes-1.3.0_beta2.ebuild Should stick with 1.2.5_rc4 for now.
2.0.4 is out. Apparently 2.0.3 will not work with Zope-2.7.2 due to increased XHTML parser strictness. Plone-2.0.4 will work Zope-2.7.2 but does not require it (apparently still works with Zope-2.6.x).
Comment on attachment 34153 [details] plonecollectorng/plonecollectorng-1.1.5.ebuild net-zope/plonecollectorng-1.2.2 is now in Portage.
Created attachment 37547 [details] plone-2.0.4.ebuild I went through the previous plone-2.0.3.ebuild and updated all the dependencies for 2.0.4. I expect most if not all to be simple version bumps. This ebuild is (as of now) untested; I probably won't have time to test it today.
Andy, thanks for your great work on this - and the informative comments posted in this bug. I'm currently trying to re-integrate a zope site into a (considerably) newer zope/plone installation and am now mindful of the complexities involved. Re #23 : > This ebuild is (as of now) untested; I probably won't have time to test it today. I will, and I shall post back with my results. I'm in the process of populating my PORTDIR_OVERLAY with the pre-requisities - I've noticed so far that placelesstranslationservice-fork is now known only as placelesstranslationservice (the -fork suffic has been dropped as of -rc8).
Quick update: I now have plone-2.0.4 installed with zope-2.7.2. I used zprod-manager to add all of the plone related components and discovered (much to my chagrin) that the same problem was occurring - as it had the first time I'd tried to use one of the newer plones (2.0.3 I believe) with zope-2.7.x; that is, python went crazy chomping up CPU usage and zope shut down shortly thereafter with nothing informative in the log. However, zope would always start fine without the products in question. After some head-scratching I determined that the offending component appeared to be archetypes - and I noticed that its layout had changed a little bit. Originally, I had rolled an archetypes-1.2.5_rc5 ebuild which was a clone of _rc4. Now, I changed: ZPROD_LIST="Archetypes ArchExample ArchGenXML generator validation" to: ZPROD_LIST="Archetypes PortalTransforms generator validation" and it seems to have solved the problem (no more stat errors with zprod-manager either). Now, I see that portaltransforms is handled by its own ebuild and I'm not sure if this is the correct thing to do - but so far things seem to be working as expected. I'll post back if I have anything more to report. Btw, I used the patch in bug 59217 for the zope-2.7.2 ebuild which worked fine (notwithstanding the inability to set the permissions under the circumstances described).
By the way, these are the components I am now using (in the net-zope category): net-zope/epoz-0.8.2 * net-zope/plonetranslations-0.1 * net-zope/formulator-1.6.2 * net-zope/cmfquickinstallertool-1.5.0 * net-zope/ploneerrorreporting-0.11 * net-zope/plone-2.0.4 * net-zope/portaltransforms-1.0.4 * net-zope/cmfactionicons-0.9 * net-zope/cmf-1.4.7 * net-zope/groupuserfolder-2.0.1 * net-zope/placelesstranslationservice-1.0_rc8 * net-zope/zope-2.7.2 * net-zope/cmfformcontroller-1.0.3_beta * net-zope/btreefolder2-1.0.1 * net-zope/externaleditor-0.8 * net-zope/archetypes-1.2.5_rc5 *
I was advised by the plone folks that archetypes-1.2.x shouldn't be touched with a bargepole (earler releases are deprecated, apparently) but they seem to be making releases thick and fast in a bid to get to a 1.3.0 final. I prepared an ebuild for the latest beta, and ran into a few minor issues related to comment 25; basically archetypes bundles it's own PortalTransforms (cutting edge 1.1.0 CVS checkout afaict), so I opted _not_ to add the portaltransforms product provided by the ebuild to my zope instance and use the archetypes provided one instead. I'm assuming that it's better to have it commented out from ZPROD_LIST and bump the ebuild instead for the new archetypes? Thus far, have had a complete nightmare trying to re-integrate my plone site as well (having tried untold combinations of things) but that's another story :( What I can say is that, in terms of a new deployment, plone seems to work like a charm with the aformentioned package list (only this time, I'm using net-zope/archetypes-1.3.0_beta5 as mentioned above). <slightly off-topic> Just in-case anyone else runs into similar issues: The problem I was getting in terms of site re-integration was an "Attribute Error" from portal_actions.listFilteredActions. To my horror, it still occurred even if I dumped the _exact_ same set of products I was using back before the upgrade (which I'd tarred up) - even though nothing was marked as broken. Nor did the migration_tool help. I had the following advice from the #plone channel (which I hope to actually make sense of real soon now - not being a python/zope expert as such): 20:37 < hazmat> kerframil, one of your action providers is borked 20:38 < hazmat> kerframil, you can try to localize it enough for a debug session by creating an external method and invoking the portal_actions.listFilteredActions with a pdb statement before hand, its tedium but its the only real mech for finding out which is borked.. 20:39 < hazmat> i suppose you could also loop through in a try except manually invoking them.. it just depends on how context dependent the action provider is </slightly off-topic>
OK, I just used the Import/Export feature on the old database (with regard to the relevant parts of my plone site) and re-imported them into a fresh instance. Works great now (and some really annoying bugs have been fixed) :) Apparently, I'm not using archetypes in my plone site, so I can't comment on the effectiveness of the new version. All the packages I'm using are as described in comment 26 (except archetypes) and, just for informational purposes, the products provided by the new archetypes (as shown in the global Products list) are as follows: * Archetypes (Installed product Archetypes (1.3.0-beta5 (CVS/UNRELEASED))) * MimetypesRegistry (Installed product MimetypesRegistry (1.3.0-3 (CVS/UNRELEASED))) * PortalTransforms (Installed product PortalTransforms (1.3.0-3 (CVS/UNRELEASED))) * generator (Installed product generator (1.3.0-3 (CVS/UNRELEASED))) * validation (Installed product validation (1.3.0-3 (CVS/UNRELEASED))) Hopefully, the pace of development on a few of the components (notably archetypes) will slow up a little in the not-too-distant future. I might upload my ebuilds if I find the time (but the tweaks are few and far between, and minor in nature).
This bug report related to the archetypes ebuild http://bugs.gentoo.org/show_bug.cgi?id=61396 may be of interest to this effort
*** Bug 53329 has been marked as a duplicate of this bug. ***
*** Bug 59545 has been marked as a duplicate of this bug. ***
*** Bug 46396 has been marked as a duplicate of this bug. ***
finally commited.
