Here's the "make -d" output:

         Prerequisite `Parser/Python.asdl' is older than target
`Include/Python-ast.h'.
         Prerequisite `Parser/asdl.py' is older than target
`Include/Python-ast.h'.
         Prerequisite `Parser/asdl_c.py' is newer than target
`Include/Python-ast.h'.
        Must remake target `Include/Python-ast.h'.
./Parser/asdl_c.py -h ./Include ./Parser/Python.asdl
/usr/bin/env: No such file or directory

And these are the file times:

orig/Python-2.6b2> ls -l Include/Python-ast.h
-rw-r--r-- 1 lemburg users 20081 2008-03-30 08:40 Include/Python-ast.h
orig/Python-2.6b2> ls -l Parser/asdl*
-rw-r--r-- 1 lemburg users 11306 2006-03-01 23:49 Parser/asdl.py
-rwxr-xr-x 1 lemburg users 39771 2008-06-09 06:58 Parser/asdl_c.py

Because Python-ast.h is older than the script used for generating it
(asdl_c.py), it always tries to rebuild the .h file. Since this requires
Python to be installed, it fails on a machine that doesn't always have
an existing Python binary installed.

This happens in both 2.6b1 and 2.6b2.

I guess the release process should make sure that the Python-ast.h and
Python-ast.c are always newer than the scripts used to build them.

As work-around, you can untar the source tarball and then touch the
files in question:

touch Include/Python-ast.h
touch Python/Python-ast.c

It should be simple to modify release.py to touch these files. Barry,
I'm on vacation now, but I should be able to do this before you spin the
releases.

This happened in my fresh unpack of the 3.0b2 tarball, as well.

Touching merely Include/Python-ast.h satisfied the dependency, and I did
not have to touch Python-ast.c.  Is the particular grammar-rebuild rule
needed for production tarballs anyway?  I can't think the majority of
people downloading the package want to start hacking the grammar right away.

Ok. I've updated release.py to do the dirty work in 65708.