cp /usr/lib/python2.2/config/Makefile.pre.in . make -f Makefile.pre.in boot PYTHON=/usr/bin/python make: *** No rule to make target `boot'. Stop. Traceback (most recent call last): File "/var/tmp/portage/zope-2.5.0/work/Zope-2.5.0-src/w_pcgi.py", line 39, in ? if __name__=='__main__': main(sys.argv[0]) File "/var/tmp/portage/zope-2.5.0/work/Zope-2.5.0-src/w_pcgi.py", line 37, in main import wo_pcgi; wo_pcgi.main(me) File "/var/tmp/portage/zope-2.5.0/work/Zope-2.5.0-src/wo_pcgi.py", line 33, in main import build_extensions File "/var/tmp/portage/zope-2.5.0/work/Zope-2.5.0-src/inst/build_extensions.py", line 30, in ? make('lib','python') File "/var/tmp/portage/zope-2.5.0/work/Zope-2.5.0-src/inst/do.py", line 62, in make do('make -f Makefile.pre.in boot PYTHON=%s' % sys.executable) File "/var/tmp/portage/zope-2.5.0/work/Zope-2.5.0-src/inst/do.py", line 32, in do if i and picky: raise SystemError, i SystemError: 512
I don't see an ebuild for Zope 2.5. Can you please say what ebuild are you talking about?
Well I made my own 2.5.0 ebuild, but the 2.4.0 got me nearly the same issue. I'ts more like if you use update the ebuild to zope 2.5.0 it won't work ;-) But the 2.4.0 also doesn't work.
I see what the problem is. Looks like the new Makefile.pre.in that comes with Python 2.2 doesn't have a boot: target. I'm going to try to find why not and/or what happened to this target.
Found an interesting note here: http://lists.zope.org/pipermail/zope/2002-January/107904.html I'm going to keep digging. Have you gotten Zope 2.5.0 to work with Python 2.2? If yes, then how well does it run for you and, obviously, what have you done to make it work, if you don't mind?
Actually, I've done even more digging. Looks like that particular Makefile.pre.in is not even supposed to be installed for Python 2.2.
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Misc/Attic/Makefile.pre.in Take a look at this. This is the file that *used* to be copied there. It's totally not the same file that our ebuild installs (which is also a hack). I'm still digging.
Ok, just tried putting in the original Makefile.pre.in from Misc dir of Python 2.1 and the compilation got a bit further but stuck with: /bin/sh: sedscript: command not found It looks like this way of building modules is simply no longer supported in Python 2.2 and hacking around it simply makes no sense. Considering that we will be using SLOT functionality soon, we should simply arrange to install both Python 2.1 and Python 2.2, imo. Definitely we should not any Makefile.pre.in into /usr/lib/python2.2/config, because the *right* one is gone. The old file that used to go there is now in the attic and is no longer in the 2.2 tarball. We need Python 2.1 *if* we want to be compatible with packages like Zope who simply will not change their build procedure or anything else until a new revision of Python forces them to do so. I don't know what the plans for Zope are; for all I know, they will skip 2.2 and wait for 3.0 to come out. So, there is no easy way to solve this without a system-wide Python policy decision. (Like keeping both 2.1 and 2.2 installed using SLOT functionality?)
So what is the status of this issue? Shouldn
So what is the status of this issue? Shouldn´t the zope ebuild be masked if it is not working?
OK. I masked this until we can figure out a solution. I don't know anything about Python, so maybe someone else should deal with this?
gbevin: can you help?
Well my problem is that I know nothing about zope, and the only python that I've done was for portage bugfixes. Don't have much experience with it. I'll try to have a look at the issue later on.
I believe a simple solution to this problem would be to call /usr/bin/python2.1 instead of /usr/bin/python. That way you would be sure that the correct version of python. I've installed zope 2.5.0 on my machine by hand by calling python2.1 even though I have both python2.1 and python2.2 installed. Of course you should probably also fix is so the "start" script calls python2.1 as well or else you get a lot of deprication errors.
Permit me to at least settle a few of these questions, as an occasional Zope contributor: ZopeCo doesn't support Python 2.2 for any version of Zope at present. Zope 2.4+ needs Python 2.1.3, specifically. On Linux it seems to work with 2.2, there are several options for getting it to compile (including a setup.py in CVS), but see http://collector.zope.org/Zope/200; Zope 2.5.1 with Python 2.2.1 crashes and burns on other platforms, suggesting to me fairly strongly that there are some issues. Zope 2.6 is going to come out of the gate still carrying the Python 2.1.3+ requirement.
Jon, you're a python guy -- care to investigate this?
*** Bug 1226 has been marked as a duplicate of this bug. ***
I can confirm that Zope 2.5.1 (and 2.6 as well) will need python 2.1.3. So any Zope ebuild should have a strict depnnds on python 2.1.3. I was in the process of creating a zope ebuild for 2.5.1, (install also a python 2.1.3 and call it by default for Zope, compile --with-threads, ...) but the way Zope works raise some other questions : * straight install or INSTANCE_HOME install * replace Data.fs and Products or not, * etc .. Anyone interested in making a proper zope.ebuild from Zope wource (and not from debian source) ?
Python 2.1.3 as it stands in the archive now is both emergable (you may have to go directory to the dev-lang/python directory and emerge python-2.1.3-whatever.ebuild), *and* should fix the Makefile.pre.in bug. I was able to then build zope-2.4.0-r6 with it, but zope is still blocked. Make sure you update that ebuild as well if you try it.
Yeah, I'll give making a better ebuild a shot. INSTANCE_HOME is definitely the way to go.
Something else which I think is important... actually, Zope 2.5.1 (as well as 2.4.4) depend on >=2.1.3 _and_ <2.2. I don't believe there is a way to specify this in DEPEND (in the OpenBSD Zope port, I said python->=2.1.3,<2.2, but of course dependencies work a little differently there.) Is there?
Take a look at the 2.4.0-r6 ebuild -- it properly builds with and depends on python2.1(.3) When possible, please explain why INSTANCE_HOME is better?
I did. But that dependency is not strictly correct, as I said. 2.1.3, or any future 2.1 is acceptable (2.1.4, 2.1.5...) for Zope 2.4 on up; however 2.2 on up is not. I looked at the source and I don't believe portage can do this. In any event, I made a 2.5.1 ebuild based on 2.4.0, which I'll attach next. Justification for INSTANCE_HOME: it's a fully-supported separation of the Zope core software and the software and data particular to an instance. Think postgresql -- you create as many databases as you need. I noticed that the old ebuild produces half of an INSTANCE_HOME. A good writeup is available at http://www.zope.org/Members/4am/instancehome. 2.6 is going to come with better support for installing the core software and for creating INSTANCE_HOMEs, so I think it might be worthwhile to wait for 2.6 to overhaul the ebuild.
Created attachment 1988 [details] ebuild for Zope 2.5.1
Whoops, hold the phone. Does this satisfy what I'm talking about? I saw mozilla's ebuild doing something similar: RDEPEND="( >=dev-lang/python-2.1.3 <dev-lang/python-2.2 )" DEPEND="virtual/glibc $RDEPEND" (Give me a break, I've only been gentooing a few weeks) :-)
Pasting directly from 2.4.0-r6.ebuild: DEPEND="virtual/glibc =dev-lang/python-2.1*" RDEPEND="=dev-lang/python-2.1*" This is the appropriate way of specifying *exactly* python 2.1* Note that this would fail should there ever be a python 2.10 or greater. ;-) I don't think we'll have to worry about that.
Yeah, the problem is that 2.1 thru 2.1.2 have reliability issues. 2.1.2 and 2.1.3, in fact, as well as some of the later Zope 2.4's, came out to address various crashers. So, really, anything new needs 2.1.3 or any patch release that may come out after 2.1.3. 2.1 thru 2.1.2, while it will "work", can cause crashers.
I'll be doing a CVS commit for 2.5.1 in a few minutes. Matt especially, please give this a go-round. Thanks! Oh. Make sure you merge only Zope, as the zope ebuild has various messages it might display at the end of merging.
Done! Marking this fixed.
Hi, as it looks the bug has been solved, can then the ebuild be unmasked or is there a good reason for not doing ? Thorsten
Please update reasoning in package.mask for zope being masked (or unmask it). I dont care if its masked (nor do I suspect anyone would care if I cared) but zope is a mighty big (in the popularity sense) app and its masking is seemingly a mystery at this point.
Note: zope-2.6.0 ebuild in portage is broken, the ebuild from bug #9474 works and should be commited as -r1.
