Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 468 - Zope 2.4.0/2.5.0 both give error about not having boot target
Summary: Zope 2.4.0/2.5.0 both give error about not having boot target
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Server (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Jon Nelson (RETIRED)
: 1226 (view as bug list)
Depends on:
Blocks: 469
  Show dependency tree
Reported: 2002-01-31 17:31 UTC by Yannick Koehler (RETIRED)
Modified: 2003-02-04 19:42 UTC (History)
9 users (show)

See Also:
Package list:
Runtime testing required: ---

ebuild for Zope 2.5.1 (zope-2.5.1.ebuild,2.91 KB, application/octet-stream)
2002-07-05 20:32 UTC, Matt Behrens

Note You need to log in before you can comment on or make changes to this bug.
Description Yannick Koehler (RETIRED) gentoo-dev 2002-01-31 17:31:58 UTC
cp /usr/lib/python2.2/config/ .
make -f 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/", line 39, in ?
    if __name__=='__main__': main(sys.argv[0])
  File "/var/tmp/portage/zope-2.5.0/work/Zope-2.5.0-src/", 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/", line 33, in
    import build_extensions
"/var/tmp/portage/zope-2.5.0/work/Zope-2.5.0-src/inst/", line
30, in ?
  File "/var/tmp/portage/zope-2.5.0/work/Zope-2.5.0-src/inst/", line 62, in
    do('make -f boot PYTHON=%s' % sys.executable)
  File "/var/tmp/portage/zope-2.5.0/work/Zope-2.5.0-src/inst/", line 32, in do
    if i and picky: raise SystemError, i
SystemError: 512
Comment 1 Leo Lipelis (RETIRED) gentoo-dev 2002-02-08 09:54:09 UTC
I don't see an ebuild for Zope 2.5.  Can you please say what ebuild are you
talking about?
Comment 2 Yannick Koehler (RETIRED) gentoo-dev 2002-02-08 09:57:19 UTC
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.
Comment 3 Leo Lipelis (RETIRED) gentoo-dev 2002-02-08 19:26:44 UTC
I see what the problem is.  Looks like the new 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.
Comment 4 Leo Lipelis (RETIRED) gentoo-dev 2002-02-08 20:17:09 UTC
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?
Comment 5 Leo Lipelis (RETIRED) gentoo-dev 2002-02-08 22:11:14 UTC
Actually, I've done even more digging.  Looks like that particular is not even supposed to be installed for Python 2.2.
Comment 6 Leo Lipelis (RETIRED) gentoo-dev 2002-02-08 22:14:23 UTC

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.
Comment 7 Leo Lipelis (RETIRED) gentoo-dev 2002-02-08 23:43:22 UTC
Ok, just tried putting in the original 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
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?)
Comment 8 Rolf Offermanns 2002-03-14 12:16:22 UTC
So what is the status of this issue?
Comment 9 Rolf Offermanns 2002-03-14 12:16:22 UTC
So what is the status of this issue?
Shouldn´t the zope ebuild be masked if it is not working?
Comment 10 Chad Huneycutt (RETIRED) gentoo-dev 2002-03-18 20:17:04 UTC
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?
Comment 11 Daniel Robbins (RETIRED) gentoo-dev 2002-03-19 16:33:57 UTC
gbevin: can you help?
Comment 12 Geert Bevin 2002-03-20 04:24:57 UTC
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.
Comment 13 Sloan Poe 2002-03-21 00:30:59 UTC
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.
Comment 14 Matt Behrens 2002-06-04 14:46:40 UTC
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 in CVS), but see; 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.
Comment 15 Seemant Kulleen (RETIRED) gentoo-dev 2002-06-08 22:14:34 UTC
Jon, you're a python guy -- care to investigate this?
Comment 16 Seemant Kulleen (RETIRED) gentoo-dev 2002-06-08 22:16:29 UTC
*** Bug 1226 has been marked as a duplicate of this bug. ***
Comment 17 Didier Georgieff 2002-06-09 13:28:59 UTC
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) ?
Comment 18 Jon Nelson (RETIRED) 2002-07-02 22:43:21 UTC
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 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.

Comment 19 Matt Behrens 2002-07-03 17:35:41 UTC
Yeah, I'll give making a better ebuild a shot.  INSTANCE_HOME is definitely the
way to go.
Comment 20 Matt Behrens 2002-07-04 07:04:37 UTC
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?
Comment 21 Jon Nelson (RETIRED) 2002-07-04 09:23:14 UTC
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?
Comment 22 Matt Behrens 2002-07-05 20:31:26 UTC
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.
Comment 23 Matt Behrens 2002-07-05 20:32:11 UTC
Created attachment 1988 [details]
ebuild for Zope 2.5.1
Comment 24 Matt Behrens 2002-07-05 21:45:17 UTC
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) :-)

Comment 25 Jon Nelson (RETIRED) 2002-07-05 22:32:46 UTC
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.
Comment 26 Matt Behrens 2002-07-06 08:17:47 UTC
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.
Comment 27 Jon Nelson (RETIRED) 2002-07-08 18:35:05 UTC
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.

Comment 28 Jon Nelson (RETIRED) 2002-07-08 18:37:21 UTC
Marking this fixed.
Comment 29 Thorsten Ebers 2002-09-23 00:55:03 UTC
Hi, as it looks the bug has been solved, can then the ebuild be unmasked or is 
there a good reason for not doing ?

Comment 30 Tom von Schwerdtner 2002-11-11 10:12:00 UTC
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. 
Comment 31 Tom von Schwerdtner 2002-11-11 10:17:24 UTC
Note: zope-2.6.0 ebuild in portage is broken, the ebuild from bug #9474 works 
and should be commited as -r1.