I compiled Python 2.5 on a Linux user account on Debian
3.0.  configure and make seemed to go okay, but make
install failed at 'zipfile.py' when it was compiling
modules into bytecode.  I can still use the python
interpreter.  However, some important modules seem to
be missing such as 'time' and 'operator'.

Logged In: YES 
user_id=357491

Looking through the logs it looks like libinstall had an
error.  Did you run over quota in your home directory?  The
log for 'make' shows that 'time' was built.  I bet if you
run the Python executable in the directory where you
compiled you will find you can import 'time' and such fine.

Logged In: YES 
user_id=1642549

No I didn't run over quota.  Running python in the directory
it was built does not do anything differently.

The logs indicate that 4 regression tests failed during
'make test'.  This is reproducible.

Logged In: YES 
user_id=21627

I think I know what the cause of the problem is (although
not the root cause):

Compiling
/home/cs/csugrads/erflynn/stow/python/lib/python2.5/test/test_multibytecodec.py
...
Sorry: UnicodeError: ("\\N escapes not supported (can't load
unicodedata module)",)

So compilation for test_multibytecodec fails, causing
compileall to fail.

In the build directory, can you please run 

PYTHONPATH=/home/cs/csugrads/erflynn/stow/python/lib/python2.5
./python -Wi -tt

and do

import unicodedata
print unicodedata.ucnhash_CAPI
import test.test_multibytecodec


and report its output?

Logged In: YES 
user_id=1642549

It could be a good start...

erflynn@squall 267>./python -Wi -tt
Python 2.5 (r25:51908, Nov 10 2006, 20:10:11) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import unicodedata
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named unicodedata
>>> 

Maybe it's not linking some modules in?
Would it be helpful if I let you SSH to the box?

Logged In: YES 
user_id=21627

Can you please do

file build/lib.linux-i686-2.5/unicodedata.so

and also, in ./python

print sys.path

According to your make.log, unicodedata.so ought to be present.

Logged In: YES 
user_id=1642549

As I understand it, these modules are actually shared
libraries or 'extensions'.  

I unset PYTHONPATH and PYTHONHOME, and the build and install
went just fine.  Arrgh.

I wonder why I had to set them in the first place...

Thanks for the help.  I'm not sure what the protocol is for
creating source builds, but it might be nice if in the
future the source distribution would (a) run compileall
during make and not make install and (b) try to rely more on
configure options and not environment variables.

Logged In: YES 
user_id=21627

Ok, closing this as "works for me" - if you set PYTHON*
while building Python, you are on your own - don't do that,
then.

AFAICT, (a) running compileall during make would not have
helped, it still would not have found the correct
unicodedata module. (b) the installation doesn't rely on
environment variables; as you found, they actually hurt.

Logged In: YES 
user_id=1642549

OK but there should be a note about this in the README:
something like "if you are reinstalling Python or upgrading
to a newer version, make sure to unset PYTHONHOME and
PYTHONPATH."  Or have the makefile use "python -E" while
building Python.

It is pretty strange to see a "make" run fine but the "make
install" bombs.  If you move compileall to the "make" stage,
then you would know sooner if there was a problem.

Done in rev. 52754, 52755 (2.5).