raise a signal, but switching to subprocess makes the code cleaner anyway.

least two of the linux build bots aren't leaving zombie processes around for
os.waitpid to wait for, causing ECHILD errors. This would be a symptom of a bug
somewhere, but probably not in signal itself.

Add documentation for linux_distribution() API.

and sys.getwindowsversion() to get at the Windows version info.

For the machine and processor uname() values, use the environment variables
for these on Windows XP and later.

argument error on ioctl.  This was caused by the added test_fcntl ioctl test
that hard coded 0 as the fd to use.  Without a terminal, this fails on solaris.
(it passed from the command line on sol 10, both 32 and 64 bit)

Also, test_ioctl exists so I moved the test into there where it belongs.

Revert r61650; the intent of this commit was to try and address alarm failures on some of the build slaves.  As Neal points out, it's called after test_main(), so it's not going to factor into the test when run via regrtest.py (and removes the original functionality that Jeffrey wanted that would kill the test if it took longer than 3 seconds to run when executing it directly during development).

when used on platforms that actually define ioctl as taking an unsigned long.
(the BSDs and OS X / Darwin)

Adds a unittest for fcntl.ioctl that tests what happens with both positive and
negative numbers.

This was done because of issue1471 but I'm not able to reproduce -that- problem
in the first place on Linux 32bit or 64bit or OS X 10.4 & 10.5 32bit or 64 bit.

running test file.

Closes issue2407. Thanks Jerry Seutter.

Bump the SIGALM delay from 3 seconds to 20 seconds, mainly in an effort to see if it fixes the alarm failures in this test experienced by some of the buildbots.

Force a clean of the tcltk/tcltk64 directories now that we've completely changed the tcl/tk build environment.

Fix the x64 Windows build environment used by the buildbots.  %VS90COMNTOOLS%\vsvars32.bat is fine for 32-bit builds, but doesn't work for x64 builds, regardless of /MACHINE:AMD64 and /USECL:MS_OPTERON flags passed to cl.exe.  Launch the x86_64 cross compilation environment via '%VS90COMNTOOLS%\..\..\VC\vcvarsall.bat x86_amd64'.  I don't have access to any systems *without* Visual Studio 2008 Professional installed (i.e. just Express Edition), so I can't test if x64 compilation works w/ VS Express at the moment.

Additionally, force a clean in our build.bat files before building, just whilst we're going through these build system updates.

And finally, add in the missing MACHINE=AMD64 option to our Tcl/Tk x64 build.

up on the machine.

Closes issue2411. Thanks Michael Bishop.

Thanks Nick Coghlan.

Lets have another try at getting the Windows buildbots in a consistent state before rebuilding using the new process.