The trunk's been frozen for a few days now, which is starting to cut into the window for new fixes between b1 and b2 (down to just under 3 weeks, and that's only if b1 was ready for release today). Is work in train to address or document the remaining buildbot failures (e.g. test_os on Windows [1]). At what point do we decide to document something as a known defect in the beta and release it anyway? (My question is mostly aimed at Benjamin for obvious reasons, but it would be good to hear from anyone that is actually looking into the Windows buildbot failure) Cheers, Nick. [1] http://www.python.org/dev/buildbot/trunk/builders/x86%20XP-4%20trunk/builds/... -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Sat, Apr 10, 2010 at 10:51, Nick Coghlan <ncoghlan@gmail.com> wrote:
I contacted David Bolen for some details about the his buildbot because I can't reproduce the failure on any Windows XP, Server 2003, or 7 box that I have, and it's also not a problem on the other XP buildbot. He's traveling at the moment but will try to get me access to the box after the weekend is over. When manually running test_os how buildbot runs it (via test.bat, which runs rt.bat) he sees the failure. When running the test on a clean checkout outside of how buildbot does anything, he doesn't see the failure. I'll try to get access to figure out what the difference is.
On Sat, Apr 10, 2010 at 13:37, Tim Golden <tjgolden@gmail.com> wrote:
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.
Brian Curtin <brian.curtin@gmail.com> writes:
Yes, that's correct. Cygwin is on my buildbot just for management 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
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.
Nick Coghlan <ncoghlan <at> gmail.com> writes:
I'm not handling the test_os issue (which I think is in Brian Curtin's hands), but as far as test_ftplib is concerned (behaviour change with newest OpenSSL versions), it was decided to address the issue after the beta. Regards Antoine.
On Sat, Apr 10, 2010 at 10:51, Nick Coghlan <ncoghlan@gmail.com> wrote:
I contacted David Bolen for some details about the his buildbot because I can't reproduce the failure on any Windows XP, Server 2003, or 7 box that I have, and it's also not a problem on the other XP buildbot. He's traveling at the moment but will try to get me access to the box after the weekend is over. When manually running test_os how buildbot runs it (via test.bat, which runs rt.bat) he sees the failure. When running the test on a clean checkout outside of how buildbot does anything, he doesn't see the failure. I'll try to get access to figure out what the difference is.
On Sat, Apr 10, 2010 at 13:37, Tim Golden <tjgolden@gmail.com> wrote:
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.
Brian Curtin <brian.curtin@gmail.com> writes:
Yes, that's correct. Cygwin is on my buildbot just for management 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
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.
Nick Coghlan <ncoghlan <at> gmail.com> writes:
I'm not handling the test_os issue (which I think is in Brian Curtin's hands), but as far as test_ftplib is concerned (behaviour change with newest OpenSSL versions), it was decided to address the issue after the beta. Regards Antoine.
participants (6)
-
Antoine Pitrou -
Benjamin Peterson -
Brian Curtin -
David Bolen -
Nick Coghlan -
Tim Golden