http://tbpl.mozilla.org/?tree=Try&rev=b68765e872d3 win64_vm try opt test jetpack on 2013-08-27 18:19:20 PDT for push b68765e872d3 slave: tst-w64-ec2-002 Traceback (most recent call last): File "tools/buildfarm/maintenance/purge_builds.py", line 34, in <module> from win32file import RemoveDirectory, DeleteFile, \ ImportError: No module named win32file program finished with exit code 1 May need the module, a compatibility library or the win64 equivalent of win32file.

Reported by another win64 ec2 slave slave: tst-w64-ec2-001 ImportError: No module named win32file

http://stackoverflow.com/questions/2144748/is-it-safe-to-use-sys-platform-win32-check-on-64-bit-python sys.platform will be win32 regardless of the bitness of the underlying Windows system, as you can see in PC/pyconfig.h (from the Python 2.6 source distribution): #if defined(MS_WIN64) /* maintain "win32" sys.platform for backward compatibility of Python code, the Win64 API should be close enough to the Win32 API to make this preferable */ # define PLATFORM "win32"

We probably don't have the pywin32 extensions installed. I wished purge_builds.py did not use them. FTR, Jetpack jobs still use the old factories instead of ScriptFactory. That is why the other jobs are not failing.

We should be able to install this via the internal pypi mirror: http://puppetagain.pub.build.mozilla.org/data/python/packages/pywin32-216.win32-py2.7.exe

Comment on attachment 8392291 [details] [diff] [review] [cloud-tools-windows] install pywin32 into c:\Python27 http://hg.mozilla.org/build/cloud-tools/rev/48626a1aa728