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.

Refine the Visual Studio 2008 build solution in order to improve how we deal with external components, as well as fixing outstanding issues with Windows x64 build support.  Introduce two new .vcproj files, _bsddb44.vcproj and sqlite3.vcproj, which replace the previous pre-link event scripts for _bsddb and _sqlite3 respectively.  The new project files inherit from our property files as if they were any other Python module.  This has numerous benefits.  First, the components get built with exactly the same compiler flags and settings as the rest of Python.  Second, it makes it much easier to debug problems in the external components when they're part of the build system.  Third, they'll benefit from profile guided optimisation in the release builds, just like the rest of Python core.

I've also introduced a slightly new pattern for managing externals in subversion.  New components get checked in as <name>-<version>.x, where <version> matches the exact vendor version string.  After the initial import of the external component, the .x is tagged as .0 (i.e. tcl-8.4.18.x -> tcl-8.4.18.0).  Some components may not need any tweaking, whereas there are others that might (tcl/tk fall into this bucket).  In that case, the relevant modifications are made to the .x branch, which will be subsequently tagged as .1 (and then n+1 going forward) when they build successfully and all tests pass.  Buildbots will be converted to rely on these explicit tags only, which makes it easy for us to switch them over to a new version as and when required.  (Simple change to external(-amd64).bat: if we've bumped tcl to 8.4.18.1, change the .bat to rmdir 8.4.18.0 if it exists and check out a new .1 copy.)

Issue2290: Support x64 Windows builds that live in pcbuild/amd64.  Without it, sysutils._python_build() returns the wrong directory, which causes the test_get_config_h_filename method in Lib/distutils/tests/test_sysconfig.py to fail.