[Buildbot-devel] Experiences and problems installing on Windows

Yoz Grahame yozlet at gmail.com
Thu Oct 14 15:06:18 UTC 2004

I'm currently trying to install buildbot 0.6.0 on WinXP & Win2K with
ActivePython 2.3.2, and documenting the process. While I have a fair
amount of Windows experience, the last time I did solid Python
programming was about ten years ago and I've forgotten most of it so
I'm relearning as I go.

So far there've been a couple of minor hitches, which I've managed to
work around, but I've now hit a blocker. I'll go through the hitches
and workarounds first, in the hope that this'll make things much
faster for other users trying to install on Windows, with the blocker
at the end:

1: In order to run commands like "trial" and "mktap" I needed to add
the path to the Python "Scripts" folder to the PATH environment
In the process I also created a buildbot batch file, which makes
executing buildbot slightly easier. Just stick this one line in

python C:\Python23\Scripts\buildbot %*

%* means "all following arguments" - I don't know which version of DOS
introduced it (I'm on WinXP) but it means you don't need to do the old
"%1 %2 %3... %9" hack . I mention this now because that old hack
returned to bite me on the arse later...

2: The trial command to run the tests works as long as you leave the
"PYTHONPATH=." off the front. However, seven tests fail:
* TestChangePerspective fails on line 39 of test_changes.py
* SlaveCommandTestCase fails on all the TestShellx tests from
test_slavecommand.py (some weird DOS execution thing? Will play with
it a bit more)
* WebTest fails on test_webPathname with "UNIX support is not present"
 from deep inside Twisted (I'll
* The various mail tests (maildir, mailparse) fail from not finding
the messages in the mail dir - don't think it's being created

3: Running the master server fails due to errors with the signal
module - it appears that signal on Win32 doesn't support SIGHUP but
seems to import okay. So I changed the top of master.py, forcing
signal = None
and now it runs fine.

4: The next thing I hit was pifflingly annoying - the buildbot
"slave" command didn't seem to be passing arguments properly to mktap:

S:\Yoz\buildbot\yoz1>python C:\Python23\Scripts\buildbot slave
testslave localhost:9989 bot1name bot1passwd
mkdir S:\Yoz\buildbot\yoz1\testslave
chdir S:\Yoz\buildbot\yoz1\testslave
mktap buildbot slave --basedir C:\Yoz\buildbot\yoz1\testslave --master
localhost:9989 --name bot1name --passwd bot1passwd
Option --passwd requires argument
mktap failed, bailing..

After several hours of chasing, it turned out that the supplied
mktap.bat from the Twisted install looks like this...
@C:\Python23\python.exe C:\Python23\scripts\mktap.py %1 %2 %3 %4 %5 %6 %7 %8 %9
... as per the old DOS hack mentioned earlier.
Trouble is, buildbot gives mktap.bat TEN arguments.
@C:\Python23\python.exe C:\Python23\scripts\mktap.py %*
... and all was well there.

5: At some point I also his various Twisted problems which were solved
by ensuring that twistd was always running in Win32 mode - so changed
line 75 of scripts/runner.py to this:
    cmd = "twistd --reactor=win32 -f buildbot.tap"

6: buildbot uses the system's own CVS command, so I dropped the
cvs.exe from Cygwin into my WINDOWS dir and it worked fine (this was
after trying the cvs.exe from TortoiseCVS, which doesn't have
:pserver: support)

7: Here's the blocker - I'm running the test setup that pulls down
buildbot from Sourceforge, and this is what happens:

command '['cvs', '-d',
':pserver:anonymous at cvs.sourceforge.net:/cvsroot/buildbot', 'login']'
in dir S:\Yoz\buildbot-0.6.0\buildbot-0.6.0\yoz1\testslave\full
(timeout 1200 secs)
(Logging in to anonymous at cvs.sourceforge.net)
CVS password: 
starting cvs operation
command '['cvs', '-z3', 'update', '-dP', '-r', 'HEAD']' in dir
(timeout 1200 secs)
cvs update: Updating .
cvs update: Updating bin
cvs update: Updating buildbot
cvs update: Updating buildbot/changes
cvs update: Updating buildbot/clients
cvs update: Updating buildbot/process
cvs update: Updating buildbot/scripts
cvs update: Updating buildbot/slave
cvs update: Updating buildbot/status
cvs update: Updating buildbot/test
cvs update: Updating buildbot/test/mail
cvs update: Updating buildbot/test/subdir
cvs update: Updating contrib
cvs update: Updating debian
cvs update: Updating docs
cvs update: Updating docs/PyCon-2003
cvs update: Updating docs/PyCon-2003/source
cvs update: Updating docs/examples
cvs update: Updating test
cvs update: Updating test/mail
cvs update: Updating test/subdir

remoteFailed: [Failure instance: Traceback from remote host --
Traceback (most recent call last):
  File "C:\Python23\Lib\site-packages\twisted\internet\defer.py", line
313, in _startRunCallbacks
  File "C:\Python23\Lib\site-packages\twisted\internet\defer.py", line
338, in _runCallbacks
    self.result = callback(self.result, *args, **kw)
  File "C:\Python23\Lib\site-packages\twisted\internet\defer.py", line
294, in _continue
  File "C:\Python23\Lib\site-packages\twisted\internet\defer.py", line
290, in unpause
--- <exception caught here> ---
  File "C:\Python23\Lib\site-packages\twisted\internet\defer.py", line
338, in _runCallbacks
    self.result = callback(self.result, *args, **kw)
  File "C:\Python23\Lib\site-packages\buildbot\slave\commands.py",
line 514, in doCopy
    return self.copyComplete(None)
exceptions.AttributeError: CVS instance has no attribute 'copyComplete'

I looked through the source for the copyComplete method but couldn't
find one, which explains why it's not working for me - and it only
gets called when not running on POSIX systems, which explains why most
users haven't hit it yet.
Is this just a case of something missing from the code?

-- Yoz

More information about the devel mailing list