Amaury and Martin: there is a problem on one machine with test.test_tcl.TclTest.testLoadWithUNC that you two jointly wrote, reviewed, and applied in #6470.

This issue (17883) is above getting the tcl/tk/tkinter tests to actually be run on 2.7, which they were not before. Zack's patch succeeded in doing that, and the tests all pass on all buildbots except (if I understand correctly) on one Snakebite machine "x86 Windows Server 2003 [SB] 2.7". 

(According to http://buildbot.python.org/all/builders/, the only other Server-2.7 bot is x86 Windows Server 2008 [SB] 2.7, and that seems not to have run these tests: the most recent(?) log says "test_tk skipped -- DLL load failed: The specified module could not be found.". But if I understand, this was back in January.)

With the original
   f = os.popen('%s -c "import Tkinter; print Tkinter"' % (unc_name,))
f.read() returns '', so 'Tkinter' is not found in the null string and the assertion that it is fails.

To get more info -- from an error traceback presumed to be on stderr -- we tried using subprocess.POpen instead and the child process startup fails with "WindowsError: [Error 5] Access is denied", so the Python import is never tried. Unless there is an error in the subprocess call or if Win Servers require a different version of UNC, it would seem that the test is not at fault. 

a) Is Windows Server 2003 is really meant to be spported?
b) Are UNCs expected to behave differently on Server 2003?
c) Can UNCs be disabled on a particular machine?
In other words, should we just ignore this error, and possibly catch it with 'except WinError"?