Hi,
This is because you did the steps above as root. I guess you have another buildout user.
The newer zc.buildout includes that extension. Just remove
# Load the DumpPickedVersions extension, which will notify
# you of versions picked by buildout that were not specifically
# pinned.
extensions = buildout.dumppickedversions
from your buildout.cfg. Then everything should work 
Hi Thomas
Sorry for not getting back earlier, but I had some famiily duties...
I'm getting further 
- but not to the end yet: I had to change the owner of the file buildout.cfg to nobody:root and I had to comment out the line you mentioned in the file base.cfg 
After that, it goes as following:
(Python-2.7)root@vm-0019:/work/plone/zinstance# buildout
Getting distribution for 'setuptools==0.6c11'.
While:
Installing.
Getting section instance.
Initializing section instance.
Installing recipe plone.recipe.zope2instance.
Getting distribution for 'setuptools==0.6c11'.
An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
File "/work/plone/Python-2.7/local/lib/python2.7/site-packages/zc/buildout/buildout.py", line 1992, in main
getattr(buildout, command)(args)
File "/work/plone/Python-2.7/local/lib/python2.7/site-packages/zc/buildout/buildout.py", line 550, in install
[self[part]['recipe'] for part in install_parts]
File "/work/plone/Python-2.7/local/lib/python2.7/site-packages/zc/buildout/buildout.py", line 1135, in __getitem__
options._initialize()
File "/work/plone/Python-2.7/local/lib/python2.7/site-packages/zc/buildout/buildout.py", line 1239, in _initialize
self.initialize()
File "/work/plone/Python-2.7/local/lib/python2.7/site-packages/zc/buildout/buildout.py", line 1245, in initialize
recipe_class = _install_and_load(reqs, 'zc.buildout', entry, buildout)
File "/work/plone/Python-2.7/local/lib/python2.7/site-packages/zc/buildout/buildout.py", line 1199, in _install_and_load
allow_hosts=buildout._allow_hosts
File "/work/plone/Python-2.7/local/lib/python2.7/site-packages/zc/buildout/easy_install.py", line 883, in install
return installer.install(specs, working_set)
File "/work/plone/Python-2.7/local/lib/python2.7/site-packages/zc/buildout/easy_install.py", line 714, in install
for_buildout_run=for_buildout_run):
File "/work/plone/Python-2.7/local/lib/python2.7/site-packages/zc/buildout/easy_install.py", line 568, in _get_dist
dist = self._env.best_match(requirement, ws)
File "/work/plone/Python-2.7/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 1120, in best_match
dist = working_set.find(req)
File "/work/plone/Python-2.7/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 718, in find
raise VersionConflict(dist, req)
VersionConflict: (setuptools 36.2.7 (/work/plone/Python-2.7/lib/python2.7/site-packages), Requirement.parse('setuptools==0.6c11'))
(Python-2.7)root@vm-0019:/work/plone/zinstance#
So sorry for bothering you again: What possibilities do I have now? Should I possibly get rid of some version entries in the buildout.cfg? Or others in the base.cfg? Or can I somehow change version of the setuptools to the desired version?
-> And how do I find out the version of that one?
Thank you very much and kind regards
David
no, he had that version because it was the version pinned for Plone 4.1; see:
http://download.zope.org/zopetoolkit/index/1.0.7/ztk-versions.cfg
you have to try a little bit harder, buddy: the error message is there and it tells you what to to:
VersionConflict: (setuptools 36.2.7 (/work/plone/Python-2.7/lib/python2.7/site-packages), Requirement.parse('setuptools==0.6c11'))
that is, in plain English, you are supposed to be using setuptools==0.6c11 but you somehow managed to install setuptools==36.2.7.
I suggest you to pin setuptools = 36.2.7 in your buildout configuration and run buildout again.
Or you just unpin setuptools with setuptools = in your buildout.cfg, just like you did with zc.buildout.
Let us know how it works
Hello
Thank you for your support!
Now I'm confused understanding "pin" or "unpin": When I made the entry in the versions-section of buildout.cfg:
[version]
...
zc.buildout = 2.5.0
Did I pin that version or unpin it (my understanding is: I pinned it, but how I understand the message of Thomas, I unpinned it 
)?
-> So how would I do the other one (pin/unpin)
Which of these two gives me more flexibility to update further after going to version 4.2.6?
Thank you and kind regards
David
Hi,
if you unpin it, it means you unset a version constraint and let buildout choose the newest version or, if installed in your virtual environment, use that one. An unpin is done by setting the version to nothing, like setuptools =.
You can also pin the version, like zc.buildout = 2.5.0 which is totally fine and gives you more control in your buildout.
For setuptools and zc.buildout, I like to install them in the virtual environment and unpin them in buildout.cfg, in case they are set in one of Plone's version.cfg's. This is also the way how Plone's ansible plone role does it.
Hi Thomas
So my buildout would look the following in case it is pinned:
[version]
...
zc.buildout = 2.5.0
setuptools = 36.2.7
(-> As suggested by hvelarde)
Unpinned variant would mean:
[version]
...
zc.buildout =
setuptools =
So I understood that, right? To go back to the other question above:
Which is more flexible in regards of future updates of Plone?
-> If I interprete your message correct: Flexibility in both cases the same, with unpinned verisons I might have to touch the buildout.cfg less, as for the system it is open, what versions to use...
About the concept of virtual environment: We activate the virtual environment via source .../bin/activate, right? To deactivate this again I so far just quited the terminal session. Is that the correct way or what is the correct way out of this?
-> But the buildout.cfg I am changing keeps the changes, right? (at least for me it looks like: I change the buildout.cfg in my zinstance folder while in virtual environment and see the changes been done as usual outside my virtual environment - sorry didn't get this properly yet )
And: Do I just work within the virtual environment to fix my buildout-problem or do you suggest to do any changes with buildout on the Plone system within the virtual environment?
Why I ask all those questions: So far in all my commands I always used the paths and commands within the Python-folder and the config-files which are in the plone environment... So I was asking myself, if I possibly could work without the virtual environemnt...
Thank you and kind regards
David
Neither. You'll have to do the work of figuring out your own known good sets in any case. Mostly a case of do you want things to fail early or fail late in lack of manual effort.
Joni
Look, I touched this Plone site - from a system/setup point of view - the last time about six years back due to other priorities in our business which is mostly not Plone nor LINUX at all. This was a mistake, which I see now clearly.
But due to the stability of Plone and LINUX and the content which is in the CMS which is heavily used daily, I'd rather not change the plattform.
That means for me (lessons learnt) to more often touch it and bring it to the newest version.
BUT: Even then, I won't ever become a LINUX/Python/Zope/Plone-crack and therefore look for the way of doing things in a way, that I can do those updates with the least frictions, trying to avoid conflicts as good as possible from scratch. That's why ask this way. This goal cannot be reached completely as no one of us can look into the future, but I can at least try to do it that way as good as possible.
So: Yes, you are right, absolutely, but I still look for ways to avoid obvious problems from the beginning 
I thank you and Thomas very, very much for your help!
It seems, that I could update my Plone from 4.2.5 to 4.2.6, where I had the troubles with buildout. I unpinned both and now buildout ran through. I then could update my Plone-site 
Unfortunately I cannot do it on the old Plone with 4.2.5 (but Python 2.6) that way.
(No activate-script available, tried to install the Python-package virtualenv but didn't work as I expected...)
Therefore I will now to take both sites to 4.2.5, try to configure the site on the new server with the same configuration as the old (LDAP for domain authentication, Theming, ...) and then transfer the content from the old server to the new.
After that I know now, that I can update the site further on - and will see, how far
So for the moment, I thank both of you very much! If you still have an input with this, I will still follow this topic. If I am further down the road, could import/export my content, but get stuck again, I will come back to this topic again...
Thank you again and kind regards
David
Hello
This case could be resolved: I managed to migrate the content to the new server with 4.2.5, could afterwards upgrade the new server according what we were working through in this topic to 4.2.6.
The finally needed steps were (just as a summary for somebody with a similar problem):
source ../Python2.7/bin/activatepip zc.buildout==2.5.0After these steps I could finally run buildout properly to update - task done, thank you!
If you are interested: I have now an issue after upgrading to version 5.0.7 in topic Ugrade 4.3.15 -> 5.0.7 seems ok but cannot upgrade site within browser - so my story is not finished yet...
Thank you again for your efforts and kind regards
David