Jack Diederich schrieb: > Faced with the choice of believing in a really strange platform specific > bug in a commonly used routine that resulted in exactly the failure caused > by one of the two files being updated or believing a failure occurred in the > long chain of networks, disks, file systems, build tools, and operating > systems that would result in only one of the files being updated - > I went with the latter. Please reconsider how subversion works. It has the notion of atomic commits, so you either get the entire change, or none at all. Fortunately, the buildbot keeps logs of everything it does: http://www.python.org/dev/buildbot/trunk/g4%20osx.4%20trunk/builds/1449/step-svn/0 shows U Lib/test/test_itertools.py U Modules/itertoolsmodule.c Updated to revision 51950. So it said it updated both files. But perhaps it didn't build them? Let's check: http://www.python.org/dev/buildbot/trunk/g4%20osx.4%20trunk/builds/1449/step-compile/0 has this: building 'itertools' extension gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -g -Wall -Wstrict-prototypes -I. -I/Users/buildslave/bb/trunk.psf-g4/build/./Include -I/Users/buildslave/bb/trunk.psf-g4/build/./Mac/Include -I./Include -I. -I/usr/local/include -I/Users/buildslave/bb/trunk.psf-g4/build/Include -I/Users/buildslave/bb/trunk.psf-g4/build -c /Users/buildslave/bb/trunk.psf-g4/build/Modules/itertoolsmodule.c -o build/temp.macosx-10.3-ppc-2.6/Users/buildslave/bb/trunk.psf-g4/build/Modules/itertoolsmodule.o gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.3-ppc-2.6/Users/buildslave/bb/trunk.psf-g4/build/Modules/itertoolsmodule.o -L/usr/local/lib -o build/lib.macosx-10.3-ppc-2.6/itertools.so So itertools.so is regenerated, as it should; qed. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4