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)
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
30, in ?
File "/var/tmp/portage/zope-2.5.0/work/Zope-2.5.0-src/inst/do.py", line 62, in
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
I don't see an ebuild for Zope 2.5. Can you please say what ebuild are you
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:
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.
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?
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
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
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
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
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
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 )"
(Give me a break, I've only been gentooing a few weeks) :-)
Pasting directly from 2.4.0-r6.ebuild:
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.
Oh. Make sure you merge only Zope, as the zope ebuild has various messages it
might display at the end of merging.
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 ?
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.