GeezerVison

The debug part of the test pass should pass locally with these fixes, except for test_datetime.
See this PR for test_datetime: #13073
I am re-running test.bat now with these fixes, which takes more than an hour.
The last pass took 4 hours and 23 minutes on my secondary ARM test device, but on the buildbot ARM test device it's been taking about an hour and a half.
I still need to try the WindowsArm32ReleaseBuild steps, but expect the same results.

Enabling is_python_build( ) to return true on the test target uncovered more failing tests.
There is still one failure in test_pyexpat that I will be investigating next.

======================================================================
FAIL: test_exception (test.test_pyexpat.HandlerExceptionTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\py\lib\test\test_pyexpat.py", line 453, in test_exception
    parser.Parse(b"<a><b><c/></b></a>", 1)
RuntimeError: a

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\py\lib\test\test_pyexpat.py", line 469, in test_exception
    self.assertIn('call_with_frame("StartElement"', entries[1][3])
AssertionError: 'call_with_frame("StartElement"' not found in ''

----------------------------------------------------------------------

I simplified the deployment script to copy entire directories instead of picking files, except for PCBuild and Modules which have many files that aren't needed for the test run. This should make the script more resilient to test changes.

I think the Windows ARM32 test pass is green now when I run the scripts manually, if #13073 is included.

@tiran can you please review?
Some of these changes are required to enable the Windows arm32 buildbot to start working.
Thanks!

@paulmon I'm happy to merge without Christian's review once the updates I suggested in my last one are done.

@zooba I merged your suggested changes. I think it's ready

@paulmon The Py_DEBUG_WIN32 change needs the references to that variable updated as well. I didn't go through and suggest a change on each one.

@paulmon The Py_DEBUG_WIN32 change needs the references to that variable updated as well. I didn't go through and suggest a change on each one.

I'm not sure I'm following you. Are suggesting adding a check for arm/arm64 to Py_DEBUG_WIN32? That would be incorrect for Windows IoT Core x86/x64 which also use UCRT for everything.

@paulmon The Py_DEBUG_WIN32 change needs the references to that variable updated as well. I didn't go through and suggest a change on each one.

I'm not sure I'm following you. Are suggesting adding a check for arm/arm64 to Py_DEBUG_WIN32? That would be incorrect for Windows IoT Core x86/x64 which also use UCRT for everything.

No, I'm saying elsewhere you are referring to Py_DEBUG_Win32 which is now undefined. They need to be changed to Py_DEBUG_WIN32 as well

No, I'm saying elsewhere you are referring to Py_DEBUG_Win32 which is now undefined. They need to be changed to Py_DEBUG_WIN32 as well

Thanks. I noticed the whitespace change but somehow didn't see the uppercase change.

@zooba Thanks for the help
I fixed test_ssl and test_math so they pass on my dev machine.
All of the PR checks pass now.

Thanks @paulmon for the PR, and @zooba for merging it 🌮🎉.. I'm working now to backport this PR to: 3.8.
🐍🍒⛏🤖

GH-14244 is a backport of this pull request to the 3.8 branch.

@paulmon Seems like it still fails: https://buildbot.python.org/all/#/builders/197/builds/338

@paulmon Seems like it still fails: https://buildbot.python.org/all/#/builders/197/builds/338

The raspberry pi was in a bad state. I have restarted it

Also, ssh.exe and scp.exe somehow don't exist when running under the buildbot, which is breaking the script.

@paulmon Different PATH setting? Or perhaps it's running with different file redirection settings (as a 32-bit app, maybe)?

@paulmon Different PATH setting? Or perhaps it's running with different file redirection settings (as a 32-bit app, maybe)?

The PATH is echoed at the top of the log and includes the PATH to ssh.
I hadn't thought of WoW as a possible cause. I installed from the link on python.org so I got the 32-bit version of python. I'll update to the 64-bit python and see if that helps. There isn't a SysWOW64 version of ssh.exe, so that could be it.