(original) (raw)
On Tue, Apr 13, 2010 at 14:43, David Bolen <db3l.net@gmail.com> wrote:
Although the fix still needs a bit of cleanup, test\_os seems to be working fine on this buildbot now. The test now waits for the subprocess to communicate back that it is running, rather than the time.sleep hacks, then it goes forward with os.kill.
Big thanks to David for access to the machine.
Brian Curtin <brian.curtin@gmail.com> writes:Yes, that's correct. �Cygwin is on my buildbot just for management
> The tests are run on a native Win32 build as compiled by VS2008\. The
> functionality is Win32 specific and wouldn't work on Cygwin, so the tests
> are skipped there. I believe Cygwin is used for kicking off the tests and
> other buildbot stuff, but they don't actually run through Cygwin.
convenience. �The build slave happens to be started from a Cygwin bash
shell (and beneath a Cygwin-based home directory, which is why you see
it in various path references in logs), but the buildbot code itself
is responsible for executing the python process directly for testing.
And python itself is built normally with VS 2008 as a pure win32
build, no Cygwin dependency.
I did also verify over the weekend that the failures occur whether the
python\_d process is started from a Cygwin bash shell or from the
normal Windows cmd process, and even if test\_os is used directly,
without running through rt.bat. �The case that ran successfully was
not via test\_os, but only by interactively replicating the test.
I'm back at this point, and to the extent my buildbot is the only
place currently replicating the problem, am working with Brian for
whatever access or resources might be helpful.
\-- David
Although the fix still needs a bit of cleanup, test\_os seems to be working fine on this buildbot now. The test now waits for the subprocess to communicate back that it is running, rather than the time.sleep hacks, then it goes forward with os.kill.
Big thanks to David for access to the machine.