The test_resource test fails at least on all non x86 linux systems; the
test case notes:

# Now check to see what happens when the RLIMIT_FSIZE is small.  Some
# versions of Python were terminated by an uncaught SIGXFSZ, but
# pythonrun.c has been fixed to ignore that exception.  If so, the
# write() should return EFBIG when the limit is exceeded.

however instead of EFBIG errno is set to ESPIPE, causing an IOException.
and letting the test fail.

$ python Lib/test/test_resource.py
True
Traceback (most recent call last):
  File "Lib/test/test_resource.py", line 42, in <module>
    f.close()
IOError: [Errno 27] File too large

Patch please?

I just hit this as well when rerunning the 2.5 tests before checking
something else in. The test itself appears to be fine, but the call to
f.close() outside the try/except block attempting to flush the file to
disk and raising an IOError.

Didn't something like this get fixed recently? Did the new IO module in
py3k have a similar problem?

(assigning to Neal to make a call on the importance for 2.5.2)

I just compared the 2.5 test_resource with the trunk test_resource - the
latter has been modified to remove the file size limitation before it
attempts to close the file, eliminating the test failure without
changing the underlying behaviour of f.close.

It's fine to fix this in 2.5.2, as it is just a test.  (IMO you can just
copy the 2.6 test_resource.py into 2.5.2, assuming that works.)

I went ahead and pulled the 2.6 test back into 2.5-maint in
rev. 61016, and then realized that Nick actually backported the
change in rev. 60727.  I decided to leave it alone; the 2.6
test should still avoid the problem, has the additional 
feature of using unittest, and isn't a feature change to the interpreter
itself.

New changeset 59292f366b53 by Senthil Kumaran in branch 'default':
#1291 http.server's send_error takes an optional explain argument
http://hg.python.org/cpython/rev/59292f366b53

The last commit 59292f366b53  was for fixing issue12921 and not this. Wrongly linked.