homepage

Trying to build Python 2.5 from a fresh Mercurial checkout I get the
following error trying to build modules using setup.py build:
% nice make 
case $MAKEFLAGS in \
	*-s*) CC='gcc' LDSHARED='gcc -L/opt/local/lib -bundle -undefined dynamic_lookup' OPT='-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes' ./python.exe -E ./setup.py -q build;; \
	*) CC='gcc' LDSHARED='gcc -L/opt/local/lib -bundle -undefined dynamic_lookup' OPT='-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes' ./python.exe -E ./setup.py build;; \
	esac
Fatal Python error: subversion keywords missing
/bin/sh: line 1: 48054 Abort trap CC='gcc' LDSHARED='gcc -L/opt/local/lib -bundle -undefined dynamic_lookup' OPT='-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes' ./python.exe -E ./setup.py build
make: *** [sharedmods] Error 134
Even if no release is made I think this should be fixed in Mercurial
if possible.

-1. Changing the Mercurial tree will make it more difficult to maintain the subversion tree, which will be the tree from which future 2.5 releases will be made.
So if anything is done with this issue, please defer that after September 2011.

Can you explain how I'm supposed to build Python 2.5 from a Mercurial
checkout? What is magic about Sept 2011?

> Can you explain how I'm supposed to build Python 2.5 from a Mercurial
> checkout?
No, I can't. Just don't. Use subversion instead if you want to build 
Python 2.5 (or use one of the released versions).
> What is magic about Sept 2011?
Security releases will cease at that point, and the need to keep
subversion and mercurial synchronized will disappear.

The workaround turned out to be simple. I just expanded the $HeadURL$
subversion keyword as svn would have done it and committed the change
locally.

What’s the proper way to fix this? Mention in the devguide that 2.5 and 2.6 can’t be built from Mercurial, or commit some text in the place of the keywords in Mercurial?

If someone can propose a patch that has zero effect on a subversion checkout or export but fixes the issue with a hg checkout, I'd be fine adding it.
OTOH, I fail to see why this issue needs fixing.

How about the patch attached in the issue11579 

I was worried that the fatal error might not trigger anymore when doing something odd with subversion, but I guess this is unfounded worry. So I'm fine with the patch.

f9763c363cc3 didn't close this issue whereas its message contains "Closes #11579. Closes #11421.". This commit closed #11579.